RINEX Application

Thanks Wombo. I downloaded RTKLIB along with the NGS CORS data from TXMX, which is the nearest observation site from https://www.ngs.noaa.gov/UFCORS/. Here is how I loaded everything into  RTKPOST:

Just to keep it simple, here is how the 'Options" are configured:

Note that I am only using GPS and L1, just to see if I get anything at all. I selected 'Execute' and RTKPOST processed through the data. Here is the result:

Apparently I got no solution. I tried different 'Option' configurations including GLONASS and Galileo, along with L1+L2 and L1+L2+L3+L4+L5 with the same result. Without going deeper into this swamp. I'm not sure what I need to do. I guess I could try collecting RINEX data with multiband turned off to see if I get anything useable.

Thanks,

W

You're actually on the right track and almost there with only some fine tuning needed. Your file works OK here with the correction files I downloaded. It’s a float solution, not fixed but that’s still good as RTKLIB/Garmin fixed isn’t always ideal.

Without seeing your correction files or other settings a couple things that stand out so far:

Your base reference position isn’t right, the 90.000000000 -6335367.6285 -6335367.6285 indicates that Positions tab, Base Station may be set to “Lat/Lon/Height” and its default coordinates.

In your case don’t bother trying to input the correct coordinates, just set Base Station to “Rinex Header Position” as I can see NGS are doing the smart thing and the TXMX RINEX approximate position XYZ is set to its precise NAD83 location like we do here. 

https://www.ngs.noaa.gov/cgi-bin/ds_cors.prl?CorsSelected=|TXMX&CorsTypeSelected=Arp

Then on the Output tab also make sure Datum/Height is set to WGS84 & Ellipsoidal. RTKLIB will think it’s ellipsoidal but because the base reference is actually NAD83 and its differential correction the result will also be NAD. It also saves messing with Geoid models, and on top of that inheriting additional transformation error.

If you are working in UTM you will have to transform the final Lat Lon in the NGS or similar tool.

I would also set the Filter Type to “Combined”. Processing in both directions e.g., by going both Forward and Backward through the data can generally pick up more and give a better solution.

Don’t be afraid to initially go for broke with everything you have. Start with L1-L5, GLONASS & Galileo. You can selectively back things out later when reprocessing to look for any improvement if you want to.

You can overlay files in RTKPLOT to view the differences and there’s a lot of options so it’s easy to forget what changes you made where. So, when processing, set/append meaningful names for the resultant .pos files to reflect the changes you make each time to keep track.

The dropouts you may be seeing in the file might be the missing L5 data? Not every SV has L5 yet so it’s normal. Don’t weed out the file, you need as many observations from as many SV’s as you can feed in, and you could also cause problems like creating cycle slips in the L1 processing by pulling those out.

When using RTKLIB I tend to use V242 as I’ve had some quirks with 243 including no solution, and some graphics sizing issues on my high-res screen. Your file did run OK in 243 for me but it could be another factor in why yours didn’t.

Suggest next step is fine tune and invest an hour or so to test over a good survey mark. This will give a reference to see what processing settings give the best (or even correct) result. As an example, here’s a comparison of Static vs one version of Kinematic processing for your file:

Preferably test over a 1st order mark, the two nearest to your location are BZ0458 or BZ1137 but you could squat on one anywhere else handy: https://geodesy.noaa.gov/NGSDataExplorer/

Stand the device vertically with the offset antenna over the point. You won’t have to worry about the antenna calibration files for processing this level of accuracy as you are not interested in vertical, and from what I've seen previously the phase center for GPS & Galileo is pretty much within the helix.

When you have this we can try different things to see what works best and post the settings.

Wombo,

Thanks for your guidance and suggestions on helping me find a solution to this issue. The error I had was in not providing a reference position for the base observer. That information was available to RTKLIB in the header of the file but the default was not set to use that info for the solution. For newbies like me that could cause hours of trying to figure out what the error was. I worked at optimizing the solution to the point that I am satisfied with the performance. With some care in setting up the Garmin 66SR, I'm sure I could improve on it's measurement accuracy. Still, I would think it would be to Garmin's advantage to work with NOAA's National Geodetic Survey so they are able to read Garmin's RINEX file.

To readers of this forum that have a 66SR and would like to use the RINEX capability, follow what Wombo and I were able to pull together to come up with a solution. 

1. Download the RTKLIB software from here.
2. Collect at least 60 minutes of RINEX data you want to analyze.
3. Download the CORS data from the nearest station using the CORS site.
4. The primary RTKLIS tool you want to use is RTKPOST. Go to the bin folder of the RTKLIB download and double click on that.
5. Fill out the entries that are detailed on this thread.

Here is where I am with respect to my surveyed referenced point:

If you have any questions, post them on this thread. Good luck!

Willie

Another option is to use the free Emlid Studio. It's essentially a newer simplified and more intuitive single interface built around the RTKLIB components and accepts Garmin Rinex. It doesn't include many of the advanced options but less potential pitfalls and it does resolve some bugs.

Hi Wombo,

I took your advice and found a 1st order monument. I collected about 30 minutes of data with my 66SR mounted on a tripod. I used RTKLIB to analyze the data against three CORS sites and obtained errors of about 12 inches, where the errors were grouped together. I decided to try another analysis package called Net_Diff which, quite frankly, made my head hurt in trying to run it. However, I was able to squeeze out a good result as you can see from the plot below. The error was about three inches.

Cheers,

Willie

Have you tried Natural Resources Canada? Precise Point Positioning (nrcan-rncan.gc.ca)

They will process L1 data (GPS + GLONASS).  In kinematic, its about 50% more accurate than my 66sr using L1+L5, but I have not done much with it.  In Static, I get within inches.

Thanks for the lead. I had about ten hours of RINEX data that I processed through that site and the result was within about 2-1/2' of the actual location. Using Single RTK and PPPStatic RTK, my error was about 4.7'.

Which GPSr?

I also suggest outputting the datum as ITRF (unless you really know what you are doing...)