About to embark on my first try at establishing a base station here in the UK and am trying to put together my workflow to do this. I have a pair of RS2’s.

I intend to post process a solution so that I can eventually enter the precise coordinates of my base station which I presume must be entered into Reachview as WGS84.

If I gather station observations as WGS84 the only source of RINEX data I know of comes from our Ordnance Survey organisation - which will be in ETRS89.

How might I deal with this datum mismatch in the data - especially with respect to a post processed solution in RTKLib.

thank you

If you supply your base position in ETRS89 the resulting coordinates are also in this reference system.
Elevation-wise, if using RTKLib, you have to supply values in ellipsoid. You can however process directly out to a local geoid, giving you have the correct file for it.

Thank you but I don’t know my base position ACCURATELY - so I must surely gather 2hrs+ of base data from my station to process with the RINEX files from OS NET to produce a PPK position for MY base (https://www.ordnancesurvey.co.uk/gps/os-net-rinex-data/)?

However my base observations from the RS2 will be in WGS84 (as I understand it the only datum supported by Reachview) whereas my 3rd party correction data is supplied by OS in the UK is referenced to ETRS89. Surely there must be a transformation used somewhere…but how?

I apologise if I am missing or confusing something…

There is no transform required, once you establish your base coordinates by post processing using the OS data they will be aligned to ETRS89. We do this all the time when establishing base marks for aerial surveys. Once the resultant rover observations are transformed to OSGB36 (using OSTN15 / OSGM15) we are achieving valid sub centimetre accuracy. ETRS89 is just the European version of WGS84 that takes account of continental drift, over time it varies quite significantly, but by using the OSNet observations you can be assured your observations are perfectly aligned to ETRS89.

1 Like

Rory - thank you. I hadn’t realised that processing with the OS Net RINEX data would for want of better word ‘take into account’ those differences between WGS84 and ETRS89.
So from this would a typical workflow be:-
1/ Establish base at imprecisely known position and log data for n hours between specific times.
2/ Obtain RINEX files from OS NET for the same period.
3/ Post process through RTKLib.
4/ Output from 3 = a set ETRS89 referenced coordinates.
5/ Feed these coords back into Reachview as precise ‘Base’ coordinates(???).
6/ Survey with rover to acquire points.
7/ Transform those points to OSGB36 if required to merge with another OS data set.

Spot on. If you’re establishing a permanent base I would recommend two or three observations over different days (and check the predicted satellite geometry and estimated DOP values - I use the GPS Plan iOS app but there’s plenty online resources). Depending on where your nearest OSNet stations are, you could use different reference stations for some of the observations. Once you have your solutions you could average them, or at least check / confirm the RMSE is within a few mm. Ideally leave the Reach unit in position the whole time.

The public OS RINEX data is only 30s sample rate so good long observations are recommended, even with the RS2. We normally go for 30 minutes plus five minutes per km baseline from the OS station.

Hi Rory, thanks for your reply.
What is confusing is that folk (even OS) sometimes use the WGS84 and ETRS89 terms interchangeably, then later on go on to focus on the differences. I understand the geodetic differences (continental drift etc.) and the need for a european system but I need to better understand the practical implementation. I’m struggling to understand the various ‘same yet different’ descriptions.

So, just to get my head around this you’ve confirmed my step 5 (above) i.e even though there is a ~75cm difference between the two datums it is fine to put the ETRS89 post processed coordinates of my base station back into Reachview’s entry fields for WGS84 base station co-ordinates.

Why is this? Is it because that by using ETRS89 coords I’m actually putting an offset into my base position (WGS84 -> ETRS89) which will be carried across to the rover positions so everything I gather will actually be ETRS89?
Or is it because they are IN PRACTICE interchangeable?

thank you!

OSNet has done the transform for you, it’s effectively WGS84 coordinates offset to ETRS89. They are certainly not interchangeable. This short article from Novatel explains it quite well, and also indicates where pitfalls can happen when using augmentation systems:

Hi Rory

OK Thank you, so surely my step 5 (above) must actually be wrong and I have to transform the RTKLib processed ETRS89 base coordinates back to WGS84 in order to put an accurate base location into Reachview (which only works with WGS84)?

Thank you for your patience.

Only if your further workflow require WGS84 to etrs89 transformation later. I.e. where it is expected that input data is not already in etrs89.

If you’re in the UK and want accurate coordinates that can easily be transformed to OSGB36 (British National Grid) then leave them as ETRS89. Don’t get hung up on the two, as long as you are working with data from OSNet then don’t transform back to WGS84, it will just add complexity. You can effectively think of the solution from RTKLib as WGS84 as far as your Reach unit is concerned, it doesn’t know any different!

1 Like

Thank you - what are the knock on effects for the Rover then which is receiving/working with it’s own positions in WGS84 but getting corrections from a base that doesn’t know it’s user entered coords are in ETRS89? Do you see how this might cause confusion for me.

I apologise if I appear pedantic but I’m really trying to understand how things are working. It’s the sort of thing that would probably be easy to communicate and resolve face to face. Would it be possible to talk?

Your base is providing corrections to your rover, just like the OSNet station provides the correction data when you establish your base position. So your rover is effectively operating in ETRS89. Don’t get too hung up about it, it works and is very accurate!

We use our Reach RS2 units to establish base marks and GCPs for aerial surveys. Our SUAS uses a different base unit to provide RTK corrections to the drone but we feed in our established coordinates to it. We normally work in OSGB36 so once our survey is complete we convert the GCPs and all the aerial photo coordinates before processing.

We regularly achieve cm level accuracy against the National Grid, have a look at the mapping section of our website to see some of the projects we’ve done using the Reach units with OSNet data:

Hi Rory - I see how it is all implemented now and so it all makes sense.
Even a little lack of detail at the outset can make everything appear confusing.

A big thank you to both yourself and Christian for you help. It’s very much appreciated.

very best regards


On a related note there is a nice guide here for positioning your base station using NRCAN PPP.

Also I’ve got a question about post processing in RTKLib however that maybe someone could confirm. The log produced after running RTKPost (see attached screenshot) seems to suggest that the base station location is converted to WGS 84 during processing. Is this the case? Does it matter?


Hi Mark,

May I ask you to elaborate on your difficulties with PPK? Do you process Reach logs with logs from a reference station?

Hi @tatiana.andreeva, I’ve no issues with PPK (sorry if I gave that impression).

My question was just related to the main topic of this thread. When post-processing with data from a UK cors, the base station position as specified in the Rinex header is referenced to ETRS89.

I would expect the post-processed positions to therefore also be in ETRS89 as detailed by @RoryG above.

The logs produced by RTKlib post processing (as in my screenshot) however refers to WGS84 (e/n/u- baseline=WGS84). I was just wondering if rtklib might be doing some type of conversion to WGS84, (although I doubt that is actually the case).

I guess it could be a little confusing if the logs say the post processed positions are in WGS84 when in fact they are in the reference frame of the base station.

Hi Mark,

RTKLib is able to provide the solution in the WGS84 coordinate system only. In this case, if you’d like to get the position in another coordinate system, you’ll need:

  • Convert base position from RINEX header to WGS84 in any online converter
  • Before PPK, specify the base coordinates manually in RTKPost
  • Process the data. RTKPost will output the WGS84 coordinates
  • Convert the results into the desired coordinate system in any 3rd-party software (for example, in QGIS)

Hi @tatiana.andreeva . Thanks for the clarification.

Would you consider @RoryG above correct however? That not doing any conversion and entering your base station coordinates as ETRS89 “…your rover is effectively operating in ETRS89”?

There’s no real conversion happening. ETRS89 and WGS84 are aligned in the fact they use exactly the same GNSS data but ETRS89 adds an offset for Europe. Once you set your base up with ETRS89 coordinates derived from post processing OSNet RINEX data you’re good to go, Reach doesn’t care, as far as she’s concerned she has WGS84 coordinates.