ah, thats interesting. you can enter the known point in post - you dont have to enter it into the reach app whilst you’re logging necessarily??
in this case we logged the base for about 3 hours, and we also logged about 6 other points for about 20mins each using another reach rover. i processed them with the obs of the base. the rover points were even more out of alignment than the base 
This whole day was spent with trying to test our workflow and the reach units against the aeropoints. in the future i want to be confident of using the reach for fairly accurate PPK and i wont have the aeropoints (i have borrowed them for a few weeks) to help me
Do you need absolute or relative positioning?
Absolute ideally
I think you should give it a go again. Does you have CORS station closer than 15 km.m?
Is it a point you will be returning to often?
the nearest was just below 15KM. I am marking out some other points more local to me whilst i still have the aeropoints so i can keep trying again and again, but i am starting to feel like i may be wasting time
Can you check the base position of the CORS provider? Don’t take for granted that it is in the system you want to use.
EUREF CORS have many different base station positions for the same CORS, depending on what system you want to work in.
Finally, you can also consider doing a 24h log on the RS+, and submit it for PPP (with NRCAN i.e.). This result will come back as ITRF2014, so you would have to transform that as well.
1 Like
As to your chichester.zip data which should match Aeropoint #1? Well it doesn’t, but
see below.
For static fix-integer processing of L1 data with a 15 km baseline 30 minutes is usually
more than enough. Your data processes just fine. Using the Rinex Header Position for
the base station coordinates you will get a ETRS89 position since that’s what is listed
in the base station file. In the header section of hard019k.20o it says “NOT APPROXIMATE
APPROX POSITION XYZ replaced with ETRS89 station coords”.
So, in RTKPOST with hard019k.20o as your base and raw_202001191203.obs as your “rover”
with static processing you should get a position quite close to:
50.865574803 N 0.695910169 E 86.81 (height, roughly the L1 phase center of antenna)
This is a ETRS89 position. To get a OSGB36 position it needs to be converted. Using:
OS-Net | Ordnance Survey we get:
589802.641 110803.665 42.25
which doesn’t look at all like point #1 of your Aeropoint data. BUT, if we make the
longitude West - put a minus sign in front - like in the spreadsheet we get a match.
491867.621 108151.796 RTKPOST value transformed, but the longitude made West
491867.607 108151.788 From Aeropoint spreadsheet
Within a couple centimeters.
Seems there’s an East vs West longitude issue. The Aeropoint spreadsheet says you are
West of Greenwich and RTKPOST says you are East. I would guess your Aeropoint spreadsheet
has a problem.
3 Likes
Fantastic! 
i will read it several more times for sure, but i am very grateful for your help.
Faith restored 
This serves as a good example why black-box cloud solutions aren’t necessarily a panacea. It becomes hard to troubleshoot and find where the errors lie.
i agree, its why i wanted to use the reach and start learning. i only borrowed the aeropoints to give me something tangible to practice against. i have checked the aeropoint coordinates and they are correct:
i’ll keep looking!
Sure enough, the Aeropoint data is right and RTKPOST is wrong. Well actually RTKPLOT.
For just doing one point I took the displayed coordinates in ETRS89 from the RTKPLOT window and RTKPLOT seems to have a East/West longitude bug. I don’t know the extent of it, but it seems real as I tried processing a few data files on both sides of Greenwich and it seems repeatable.
The good news is this is just the display in RTKPLOT. The *.POS file from RTKPOST is correct.
So anyway the basic workflow seems fine. Process your GNSS data with a UK CORS using the RINEX Header to get ETRS89 coordinates. Take the coordinates from the *.POS file and convert them to OSGB36.
1 Like
hi jbonde002,
I was comparing the lat/long from post process on RTKPOST with the lat/long of the Aeropoints which why i was so far off. The lat/long of the aeropoints are in ETRS89 but don’t sync with REACH result for some reason?
Another area that confuses me is that in rtkpost we can only select WSG84 but the result is ETRS89:
Is this mearly because the Rinex header of the CORS is given to us in ETRS89?
Finally i have the same co-ordinates in X and Y, but my height is a little different:
please can you tell me how you reached 86.81?
Thank you very much.
Now i can move on to processing the rover data
actually i have just noticed my rtkpost results are different to yours in X and Y too
Mine: 50.865580083 N, -0.695909069 W, 86.4635
Yours: 50.865574803 N 0.695910169 E 86.81
so i guess i am not doing something right in the post process:
i noticed that selecting ‘single’ for Solution for static mode instead of ALL made quite a difference. not sure which is correct!
As to RTKPOST processing with the WGS84 datum and getting results in ETRS89?
RTKPOST does do the math assuming your coordinates are WGS84, but for differential processing if you enter base coordinates in a similar system like ETRS89, NAD83, etc. you will get output coordinates in the same system as your base. Sure there’s some error involved, but it’s tiny for baselines that aren’t continental distances.
Anyone can check this using CORS data. For example I grabbed 4 hours of data from the UK HARD and FARB CORS which are about 40 km apart. Using RTKPOST with the base coordinates set to use the RINEX Header (ETRS89 coordinates) I did a L1 fixed-integer solution from HARD to FARB and RTKPOST gave me the ETRS89 coordinates of FARB good to the centimeter level. No transforming of WGS84/ETRS89 needed.
Why do we have different heights? Part of it is that I used an antenna model file for the base station since that info is in the RINEX data file. That’s not all of it though. Also as you noted our horizontal positions are just a bit too far off.
I see from your screen shot that you don’t have the RTKPLOT display error I mentioned. Perhaps Emlid has fixed this as I’m using the standard RTKLIB software version 2.4.3 b32 (and the latest RTKExplorer version). The software versions shouldn’t create position differences of more than a couple cm so I’m not really sure what’s going on right now.
Maybe we could try another point in your Aeropoints spreadsheet making the assumption that those coordinates are correct. If I can process data to match another point then I’ll feel better about the whole process as there are a lot of variables involved.
Hi,
Many thanks for the reply.
i noted the antenna type from the rinex header
and then from this site Antenna phase centre offsets found an .atx file for all the antenna offsets in OSNET, which i uploaded here:
then i selected the same antenna in this section:
i wasn’t sure if i should add the offsets in this section also? i figured the file would contain them anyway so left them blank. That did make a small difference to the ORI but not much;
is that the correct procedure?
Whilst this unit was stationary over the Aeropoint #1, we took another RS and logged 15-20 minutes of a selection of the other Aeropoints. My intention was to use the data from the base to process the rover points. The reach rover and aeropoints are not in sync AP2=RP1 etc:
reach_point1_AP2
reach_point2_AP3
reach_point3_AP5
reach_point4_AP6
reach_point4_AP8
reach_point5_AP7
rover data: https://1drv.ms/u/s!AmhN-JSb2qsPldEoQ78EDsXQTYDSAQ?e=HtJVhe
i’d be really grateful if you could take a look! thank you
Yes you want to use an antenna file (*.ATX) like you did. If the RINEX header has the correct information in it you can just use the * for the type to read everything automatically. You can do that for the UK CORS. If you don’t have an antenna file, like for the Reach, then you still check the antenna type box, but enter nothing (a blank will be the first option in the scroll down menu) and then enter the pole height in the Delta-U box. This would be the estimate of the L1 phase center which for your data seems to be 2.065 meters. That takes care of the height info.
Now going back to your Reach data collected over Aeropoint #1 and entering the 2.065 meter height for the rover I get an ETRS89 ellipsoid height of 84.739 which is within error tolerances of 84.766 from the Aeropoints spreadsheet. It looks like the Aeropoints collected data for a couple of hours and then you collected a couple of hours of data over Aeropoint 1. A 2.7 cm disagreement in height on a 15 km L1 baseline is reasonably good.
The converted OSGB36 coordinates are:
491867.621 108151.796 39.367 (RTKPOST)
491867.607 108151.788 (AEROPOINTS)
Now we still haven’t figured out why you aren’t getting this result.
Looking at the other data you collected over some of the Aeropoints I chopped it up into 6 separate static files. Point 1 to point 6 each about 20-30 minutes in length and then processed them individually in the same manor as the above point. That is using the UK HARD CORS as a base with the above mentioned antenna type corrections and the RINEX Header position.
I got a fixed-integer solution for the first 4 points. There was no base station data available for the last two (CORS data not available).
Point 1 50.865968652 -0.696873217 88.222
491799.079 108194.395 42.848 RTKPOST
491799.099 108194.367 Aeropoint 7
Point 2 50.865986441 -0.697484471 89.678
491756.031 108195.615 44.304 RTKPOST
491756.021 108195.585 Aeropoint 8
Point 3 50.866172726 -0.696603307 87.254
491817.672 108217.422 41.880 RTKPOST
491817.638 108217.407 Aeropoint 6
Point 4 50.866554672 -0.697244905 88.365
491771.774 108259.097 42.990 RTKPOST
491771.783 108259.060 Aeropoint 5
Basically agreement to better than 5 cm so I’m fairly sure of my methods. This was only using GPS. GLONASS is also available from the CORS, but not usable for fixed-integer work in RTKPOST with differing types of receivers.
That was the hard way to get the coordinates for a target. What you were doing is better. Set up one receiver as a base over a target and move a rover over the others. You would really just need to spend a very short time over each point. Doing it this way the data processed quite well. Here GPS+GLONASS could be used because the receivers were identical. The whole kinematic track was fixed.
Just as another check I pulled out one point (no averaging) from the time period when you were over Point 5 (Aeropoint 3) and Point 6 (Aeropoint 2).
Point 5 50.865466503 -0.697759399 86.604
491737.704 108137.458 41.230 RTKPOST
491737.741 108137.447 Aeropoint 3
Point 6 50.865434250 -0.696852864 85.979
491801.560 108134.997 40.606 RTKPOST
491801.560 108135.032 Aeropoint 2
Again, good agreement.
None of this matters if you can’t replicate it. The above was primarily to convince myself things were working as they should. I’m not sure where you want to go now? If you have any questions I’d be happy to try and help. I’ll still give the issue some thought.
Just a couple more comments. You may want to turn on Time Interpolation of Base Station Data under Misc Options. This will usually help more than it hurts. When collecting GNSS data just go with a rate that’s fast enough for your needs. A 1 Hz rate would have been more than enough for these data sets. 5 Hz is just harder to work with in multiple ways.
And finally that East/West longitude bug in RTKPLOT that I have and you don’t. It seems RTKPLOT won’t read a *.POS file correctly if it is in DMS format and the longitude is between 1 and 0 degrees West. It will incorrectly report the longitude as East even though the *.POS file is fine. Write the *.POS file in DD format and there’s no bug.
2 Likes
Hi @jbonde002, @malcolmdavidge,
Thanks for noticing! We’ll look into it.
As @jbonde002 said, if the base coordinates are specified in ETRS89, RTKLib will provide the solution in that coordinate system, even if it would regard it as WGS84. Rover coordinates highly depend on base coordinates as a rover calculates its position knowing the precise distance to a base station.
As for the height difference, I also agree with @jbonde002 and would recommend you specifying the rover pole height plus 65 mm in RTKPost.
1 Like
I finally managed to get similar result to @jbonde002 and the aeropoints. I had selected ‘ALL’ as my solution for static mode. When i switched it to 'singl’e my result was finally aligned.
i do wonder why selecting ‘single’ should be so much different to that of the ORI of ‘ALL’’?
When i go on to the next stage to process my Rover i assume i will change positioning mode to kinematic (is this correct? even though i was collecting each point for 20minutes), and then editing the time for each point and note the ORI from the points within that time.
Glad you are making some progress.
I think I see what was going on. With RTKPLOT the coordinates shown aren’t necessarily the solution you want. They are based on all the data in the *.POS file. Now if all the data is of high quality the coordinates for the origin of the plot will basically be the solution you are looking for. If your *.POS file has some lower quality data that will affect the plot origin somewhat.
From your screenshots above there is a lot of red (low quality data). This is because the base station file is missing an hour of data (that’s a CORS issue, nothing you did). You also have RTKPOST Output Options set to Output Single if Sol Outage - so an hour’s worth of uncorrected data is shifting the RTKPLOT origin a bit. That’s my guess anyway.
It’s something you won’t see with good quality data, but you may want to turn off that output option so single quality positions aren’t output. Anyway you should always look at the *.POS file for a solution and it will ideally be quality 1 (fixed) data. When you set the Solution for Static Mode to Single it seems it automatically just used quality 1 data.
Another point here is you really want to use the combined solution, not just a forward one. As long as things are processing fine the combined solution is more robust.
Yes you process your rover data as kinematic. Assuming it processes fine the low tech way to get static points would be to average time periods from the *.POS file when you know you weren’t moving. There has been some work done to automate this, but I haven’t really looked into it.
2 Likes
Hello again ,
Thank you again for your helpful insights. Just my luck to try and learn about post processing with holey CORS data!
So i am comfortable processing static base data now. I have tried some other sites/data and i am getting good results.
I have been experimenting with the rover data to try and match yours / Aero data.
I found that processing either using the CORS or the REACH as a base and editing the time in RTK PLOT gives me very varied results.
I also found using the CORS as a base and editing the time in RTK POST gave me another result entirely.
If however i used the REACH as a base and edited the time in RTK POST i was very close to you and the Aero:
Does this match how you did your processing too please?
I was a bit lost as to why i couldn’t process all the data and use RTK PLOT to edit the time (as i believe this is the usual method?)
I noticed that processing without editing any time (leaving it unchecked) in RTK POST resulted in just above 50% of Q1 data:
but if i edited the time in RTK POST 1st (from beginning survey to finished survey) i got about 98% Q1:
So then i made sure to set my time in RTK POST from start of survey to end of survey, then opened RTK PLOT and edited the time i was over each point. This improved my REACH Base+Rover position so i was a few mm from yours. The CORS base+Rover was also better although some way off still:
i thought this maybe due to the missing cors data, but when i processed the time in RTK POST only (for this point) my position was approx 750mm away.
I then moved on to another dataset with the same set up (REACH units collecting on top of Aeropoints) only this time we forgot to log the base! So processing the rover to a CORS station which was 48KM away was just over 100mm from the Aeropoints which i am very happy with.
moving forward my ideal scenario is to arrive to site,
let my RS2base average single for 20-30minutes,
collect GCP’s via RTK with REACH+
PPK the base
calculate the shift from the base average single coordinate to the PPK
apply that to all the GCP’s.
Do you think that is feasible?
Thank you!