I recently set up my Reach RS (latest v 2.3) over a base marker (PSU1b) and let it collect for about 25 minutes. My goal was to see what my post-processed positional accuracy is in good conditions (minimal interference from buildings/trees) and very near (less than 1km) a CORS station (PSU1).
Collection parameters: Reach RS was in static mode, solution status was reported as single in ReachView. The SNR bars were mainly >40 the whole time, and I’ve included the obs file so you’ll be able to see I had reasonably good satellite views.
My raw data in RTKPLOT has a large (and expected) spread, but the coordinates for PSU1b fall right in the middle. When I post-process, the Q=1 solution is more than a meter off of the reported PSU1b location. The images below show both the raw data and the processed data in the same plot -the processed data is at the origin on the plot. I have performed a datum transform on the reported location using NOAA’s HTDP tool (HTDP - Horizontal Time-Dependent Positioning). In this case I only transformed the location reported on PSU1b’s data sheet.
I think the problem has to do with datum differences, but I haven’t found any information in the forums about converting the CORS files for use in RTKPOST. I have also been told that the .obs and .nav files are in satellite units and it’s only when RTKPOST gives the position file are the locations plotted in reference to WGS84. Do I need to transform the CORS data?
Does anyone have suggestions for improving my ppk results? The spread is quite small but that doesn’t help me at all if the accuracy isn’t great. I was hoping to get at least centimeter accuracy but if everything is correct, I’m looking at a couple of meters. Hopefully I’m missing something simple and I’ve just been looking at it too long to see it. Any and all suggestions welcome!
Just a quick reply. I see on the Penn State CORS page:
New Coordinates: In IGS08 epoch 2005.00 and NAD 83(2011,MA11,PA11) epoch 2010.00
So yes, you should transform the CORS from the above into WGS84 and use it as your base coordinate.
I think the satellite units you speak of are XYZ ECEF. Which means 0,0,0 is the center of the earth. The problem with using that is there is no sense of ‘level’ and no understanding of ‘sea level’ either. At least WGS84 approximates the surface of the earth so you have a good idea of what level is and also where sea level is.
Thank you!!! I didn’t realize that the rinex header setting (rtkpost > options > positions: Base Station) was giving RTKPOST the CORS coordinates in NAD83, I thought it was referencing the xyz location. Changing this setting to Lat/Lon/Height and inputting the converted coordinates (using the same HTDP tool I linked above) for the base station did the trick! Now my coordinates are plotting within a cm of the marker, which is well within the uncertainty that comes from using a less-than-survey-grade tripod.
For others who might stumble upon this post looking for answers to a similar problem, here’s a brief outline:
-I collected observations for ~25 minutes over a known location with an emlid Reach RS system.
-emlid outputs location data in reference to WGS83 datum.
-The known location (PSU1b) is reported in NAD83.
-The CORS data I got for post processing has, in the header, a lat/long/h which is in reference to NAD83.
-In post processing if you allow RTKPOST to get the base’s location (the cors station in this case) from the rinex header, it references the NAD83 location.
-This means you’re post processing data which references WGS84 against data which references NAD83. Resulting error will be on the order of meters.
Solution: Use Lat/Lon/Height setting instead of rinex headers if you need to perform an datum transform on the reference station location. Use a tool like HTDP - Horizontal Time-Dependent Positioning to perform the transformation. This will also adjust the reference station coordinates for plate velocities, which is important if you’re hoping for cm or better accuracy.
