Set-up
- Reach Dev Kit ReahView c2.2.7-r0
- Testing against a professionally surveyed point.
- Supplied antenna is mounted to a 5 inch base plate which we use for other GNSS units as well.
- Base plate screws onto a Seco Tri-Max with optical plummet site.
- Tri-pod is raised over head level.
- Correction source is our own RTCM3 base station served over TCP/IP port. We have tested this station against a couple dozen RTK rovers.
In past experience with RTKLIB we found the following settings to produce FIX quality points at centimeter level accuracy and precision with a few different of low cost chips L1 band chips and RTKLIB. Note we measure accuracy as the distance between the average position estimate in the sample and the surveyed location. We measure precision as the deviation of the sample from the average position estimate, such as 2DRMS, DRMS, CEP.
With these settings we found the system reliably produces a fix.
- Output the solution stream as NMEA0183 to text file
- Log the rover and base streams to file in the event debugging is needed. ( Time-Tag is crucial)
- Static Positioning Mode
- 15 degree elevation mask.
- 40 SNR masks for all elevations on rover and base.
- Rec Dynamics and Earth Tides are OFF
- Iono = Broadcast
- Tropo = Saastamoinen
- Ephem = Broadcast
- No PRNs excluded
- All constellations checked
- Integer Ambiguity
—GPS = Instantaneous ( found by trial and error)
—GLO = On - Min Ratio = 2 ( found by trial and error)
- Min Lock = 200 ( found by trial and error)
- Min Elevation = 0
- Outage = 5
- Slip = 0.050
- Max Age Diff = 30
- Sync Solution = ON
- GDOP = 6
- Innov = 30
- Filter Iteration = 1
- RTKNAVI seems to use the old ephemerides indefinitely until new are supplied by one of the input streams. Deleting the ephemeris data at the end of rtknavi.ini. (it will be at the end after “eph_00” ) and restarting RTKNAVI is sometimes necessary. We found that the L1 lower cost chips have trouble pulling down ephemerides sometimes, especially if the antenna is not high quality or the real world collection location is less than ideal.
Explanation
-
Time-Tag: This seems to synchronize the base and rover streams based on time when stream source is a file. With out it, RTKNAVI can produce slightly different results each time the “start” button is clicked. I suppose this is because the rover and base streams get matched differently under some sort of race condition. The Time-Tag file seems to get them match up consistently under multiple runs. Also, without the time-tag file you need to set Max Age Diff higher such as to 120 seconds.
-
Instantaneous AR for GPS: Both “Fix-and-Hold” and “Continuous” can produce FIX points that are relatively poor. From what we have read in various locations, these settings cause some data to carry or average across epochs. Once a bad fix is locked in it can stay bad for a long time. When using Instantaneous, if the system reports “FIX” the point estimate is usually very good. That’s a good time to hit the “Collect” button on the Mobile GIS app.
-
Min Lock as 200: Honestly not sure what this is. Found that this helps reduce unwanted low quality “FIX” points.
-
Min Ratio as 2: Default is 3, but the system stays in float mode and never grabs a FIX. Float is a good name because the point floats around the map at about 1 meter accuracy. In FIX the point locks in fairly close to the surveyed point and reproduces that quality over and over. This creates a very good 2DRMS statistic. I have read that lowering to 2 reduces the quality of the FIX point. This may be true, but from our experience a FIX with ratio 2 is better than a float. The reality is that very often the system will not lock onto a FIX at 3.
So finally my comments and questions about the Reach . . .
-
Please add the ability to export the Time-Tag. This is necessary to debug the real-time NMEA solution after the fact.
-
How is the emlid version of RTKLIB handling ephemeris data? So far in my testing the rover file contains valid ephemeris data, but old data can produce a bad solution unbeknownst to the user. It’s better to drop the old data, at least the user is alerted to a problem when the system is unable to produce a point estimate.
-
Since my old RTKNAVI tricks for getting a FIX won’t work with the ReachView GUI, how can I get the system to FIX? I have experimented with all available ReachView settings with no luck.The few FIX points I have achieved are poor, about 1 meter away from the surveyed location.