RINEX Application

The device allows for RINEX logging. Why does a consumer Outdoor Recreation device have this feature?

I've spent a few hours studying this, and it looks like a consumer can buy some specialized software to process the output, but why spend the money?

There are some free governmental processing sites like OPUS, GAPS and AUSPOS, but they seem to want multi-band data, and I believe the 66i only receives L1 data.

There is a Garmin Support Article which mentions RTKLIB, but it works in a Windows environment, and I don't.

How does the typical consumer involved with outdoor recreation actually use this functionality?

  • 4.7 feet. My standard deviation value is on the order of 3 meters.

  • On my tests, the DRMS for kinematic was ~20 inches.  I am a relative novice at this. however.  My sample duration was ~24 hours.  I also noticed that the defalut datum skewed my position by ~ 2-3 feet.  the ITRF datum was much better.  I did not use a reference marker, rather I conducted multiple recordings and had consistant results.  In static, I would even go as far to say within the 10cm precision Garmin eludes to.  Initially I was put off by static, but realized the last point rendered is the final result. Good open sky is key.  Geographical location matters as well.  If your location is far from a reference station, your accuracy will suffer more.  My location was in Portland, OR, USA.

  • To me the RINEX logging in the 66 and other models appears to be an "experimental mode".  It would seem the RINEX logging has the capability of achiving a more accurate location then operating as a normal GPS reciever.  It does not achieve engineering survey grade accuracy, but it may meet the needs in certain survey situations.  As I stated above, Natural Resources Canada provides L1 only solutions and is not restriced to Canada only.  The 66sr and 67 does record L5 data (the 67 RINEX logging is waiting on a firmware fix at this time).  There was an experiment in Germany that suggests the 5cm precision or less is possible using L1+L5, but it would seem that processing L5 data remains a future state.  RTKLIB works, but is clunky.  Net_Diff is supposed to be more accurate, but is even less intuitive then RTKLIB.  Both run in Windows but I bet either could run in the WINE environment as well.  RINEX logging is NOT for outdoor navigation.  While I suppose it's possilble to have a Garmin reciever operate in a RTK fashion if connected to your smartphone, RINEX requires open skies and the whole setup would be cumbersome and power consuming.  Basically, RINEX logging on a Garmin is for those who want to tinker with better accuracy and have the time and resources to do so.  

  • Definitely not an experiment, maybe so 20 years ago when we were using Gringo and P4 processor to extract and post-process RINEX data from Garmin handhelds. It’s all mainstream now.

    RINEX has never been intended for navigation, it was specifically designed for file based open post processing (e.g., after the fact) between any kind of receiver and it has become ubiquitous in that role across science, mapping & survey.

    The only real difference here is Garmin now directly supports that niche market segment of low-cost mapping accuracy in a user-friendly device. Think bang for buck, for example in the scientific & mapping communities and a great learning ground for beginners. If you only want a small number of reasonably accurate reference points and don’t want to spend many thousands, it’s a good option. Particularly if you already have access to one, everything else is free.

    For your results I wouldn’t use ITRF coordinates on their own. ITRF is a virtual frame with no practical connection to the earth and everything is moving so it’s time dependent. You need to transform the coordinates to your local datum at a specific date (epoch) to accommodate differences that apply then so they can relate to the land surface and maps you are using. Once you have coordinates locked to your local datum / plate for all practical purposes they are then permanent and will drift with you. If the service is offering you the datum transformation it’s generally better accept it, they know what they are doing and will save you the manual transformation effort and potential errors.

    And if you are not using a known reference position you can’t be sure of where you are. If your position was consistent, you may have precision, but that is very different to the accuracy to the actual known point. L1 only isn’t correcting for ionospheric effects and this could explain the difference you saw to the local datum coordinates. Best to do a check to a known point.

    BTW to clarify, post processing (using the RINEX) and RTK are different ways to achieve better accuracy. Once you have it set up, RTK is quicker as you are getting the results in real time and can use them immediately. But depending on differences in proximities of the source locations, and transmissions delays of the RTK stream, it may not be as accurate or even possible depending on the medium e.g., mobile coverage. Either way the receiver needs to see as many satellites as possible, there is no difference there.

    There is no RTK in Garmin, one of the reasons you pay much more for professional equipment. And the big issue for RTK is that Garmin would have to make a massive upgrade to onboard time dependent datum transformations (along with the associated user complexity and management) to realize the gains. Today the shortcomings in the simplistic datum transformations are already beginning to outweigh the benefits of multiband, and the error increases over time as they don’t compensate for plate drift.

  • Good post Wombo. I am keeping all my coordinates in NAD83 (2011). The Canadian CSRS-PPP site calculates a 2-sigma (95%) value of 0.655 m N, 1.060 m E. The difference between my measurement as analyzed on the Canadian website and a measured survey point is about 2.56 feet, which is consistent with the standard deviation of the result. Also, some of that difference can be explained in my setup (maybe six inches). I only collected ten hours of data, and the measurement looks pretty noisy from the RTKLIB plot (see plot below). The Canadian result looks much less noisy, but there is no visibility into how these calculations are made. That being said, it's nice to be able to drop off a file on their website and receive a result within a few minutes without having to gather up all the other files required for the analysis using RTKLIB. It can only get better from here.

  • Here are the position tracks from RTKLIB. Note that the noise predominates and I'm not getting any convergence. The standard deviation is about 3 to 4 meters.

  • To clarify experimental mode, I a refer to the practice of writing an application and including a function that may or may not function correctly and the programmer takes no responsibility for the results of that function. Garmin has basically stated that they do not guarantee the quality of RINEX output to any degree.  Also, there is no calibration provided or any guidelines on positioning the receiver.  Basically, the user assumes a higher risk versus using Garmin's normal functions.  As for why I suggested ITRF, it's at starting point suggestion if one is a lay person like me and is unconcerned with accuracy of my results with respect to "professional" survey standards.  I do agree that correct datum is critical if you want to conduct proper surveys.   My view may change on this as I continue to mess around with this.  I own both a 66sr and a 67 and I intend to try out using one as a base and the other as the rover (whenever Garmin gets the 67's RINEX output working properly).

  • Garmin's statement is actually quite different and completely reasonable in that "RINEX data (Example: grmn300p08.21O) is not compatible with any Garmin programs; however, third party programs, like RTKLIB, can be used to convert the data to KML format for use with Garmin programs. Garmin does not support third party programs, or the process of converting or modifying RINEX data." Where have you seen something different?

    Put simply they make the RINEX available, and the rest is up to you. Very open, clear & fair enough.

    Non geodetic receiver content and accuracy aside, my 66i RINEX files are good. Fully compliant with V3.04 and they are accepted fine in all my apps including top tier professional Trimble Business Centre. There is no risk to functionality.

    The point about ITRF is not about professional survey standards or accuracy, it's actually about how grossly inaccurate you can be. Even for simple day to day use. For basic use you would normally want to relate your position to local maps in the local datum and the differences can be out by many meters. So much so that the uncorrected autonomous position given to you by the Garmin could well be more accurate than your incorrect "corrected" ITRF coordinates.

  • Having used both the 66sr and the 66 (I once had a 66 and admit there were fewer issues with that model).  At early revisions (and still with the 67), the RINEX outputs have been corrupted.  Garmin's response to such issues have been slow.  my point if want a device that logs RINEX files reliably out of the box, historically Gamins are not a great choice if you need to collect data right away.  My statement is a aggregation of Garmin's statement and my observed performance (my 67 I bought a couple of months ago remains unusable for RINEX logging - would this be acceptable if you bought a high-end Timbal?).  I agree the produced files are good - when one finally gets the right firmware update.  As for the ITRF debate, my collected data disagrees with your last sentence.  That being said, I don't consider myself an authority on the subject either...

  • How have you validated the accuracy of your ITRF coordinates?

    The only way to validate accuracy is to measure against a calibrated known point.
    Survey marks in the US are established in the ground by the NGS - in NAD83 - exactly for this reason and there are hundreds across Portland:


    And here’s an example data sheet for one in central Waterfront Park: https://www.ngs.noaa.gov/cgi-bin/ds_mark.prl?PidBox=RD0455  

    On the other hand, ITRF is a virtual, invisible sphere, based on the center of gravity about which the satellites orbit. You can’t see it let alone see where you are in it, and your best sense of gravity only enables you to walk upright let alone precisely measure it.

    And you are surfing through this invisible ITRF on your piece of dirt. If you wanted to later get back to your theoretical ITRF point in space you would have figure out how far back, the direction and even the elevation (rotation) change you would need to walk back on your plate board.

    Yes, it's absolutely possible to calculate the difference, that’s how the system works. But to do so you need the precise parameters, and the dates they apply.

    But to confirm the accuracy of the result you still need to measure to a known reference point….and they are only on the ground in NAD83.

    If you can provide more details on what steps you actually took I can give some more specific advice.