We’ve completed our testing of the Reach system and I have some outcomes to share.
Our goal is to use the Reach RS as a real time GIS data collection tool for utility assets. We’ve tested commercial GNSS systems at all price points and form several manufactures/chip-set providers. We have also built our own prototype low cost L1 band receivers and base stations based on RTKLIB. In this set of testing the RTK correction source was our own on-prem Hemisphere base station serving RTCM 3 over TCP. It is a multi-band, multi-constellation system including Galileo.
Observartions
The RS physical device and packaging is very good. It’s something I could see our research customers taking into the field.
The ReachView application is a very nice overlay on RTKLIB, works well and easy to learn. It has some nice added features above and beyond straight RTKLIB. I like the robust set of communications options between PC, Base and Rover.
Registering the Reach.Reach RS to a WiFi hot spot is a smart design choice. This allows the Reach to receive RTCM corrections data from base stations broadcasting via NTRIP WITHOUT the need to create a virtual serial port on the mobile data collection tablet in order to re-forward the corrected NMEA sentences into a Mobile GIS application. I won’t break down the gritty details, but if you work with a Mobile GIS that does not happen to have a NTRIP manager built in then you know what I’m talking about.
Stability and reliability were good. It turned on every time, the charging system worked, held Wifi connections, held bluetooth connections, retained config settings, and the software did what you asked it to do, for example if we had logging turn on, it logged the data. I mention it because we’ve worked with “budget” systems which were neither stable nor reliable which makes field data collection frustrating if not impossible. The Reach did it’s job.
Accuracy - The Reach proved capable of both very good accuracy and very bad accuracy. At most of our test sights it produced good mapping grade ( mapping grade is 1 foot or better in my opinion) points. But a small minority of test sites it was really really bad. But this is to be expected and is exactly what we saw in the low cost L1/RTKLIB units we have built ourselves in the past.
Fix performance - again like other L1/RTKLIB systems we’ve tested you get a lot more “floats” than “fixes” as compared to high-end very expensive RTK systems.
We are no longer looking at building our own L1/RTKLIB systems, at the current price point we’re going to focus on the Reach RS for now.
Suggestions
The issues with accuracy and fix performance are likely tied to the low cost ublox chip-set. Don’t put in a better chip, keep the price point of the Reach RS low. I recommend exploring software solutions to automate a mitigation strategy or software based “workflow helpers” to help the user avoid collecting at the time where the system goes weird for a a bit. Keep in mind that in a real time asset GIS data collection scenario there is the luxury of a bit more time for processing as compared to a 20Hz real-time fight navigation setting.
As I’ve posted here before, in my experience with other L1/RTKLIB systems you sometimes need to drop to AR ratio to 2 to get it to lock onto fixes sooner and more frequently. This may be particularly true in a “non-matching” base station scenario where the RF front ends on Rover and Base do not match. You could add a mode to the ReachView software called “Matching Rover/Base”. When check on the GLONASS AR is set to “ON” and AR Ration is set to 3. When checked off, then GLONASS AR is set to “OFF” and AR Ration is set to 2.
Conclusion: I’m very close to recommending the RS as a mapping grade GNSS system GIS data collection. I think with some clever software coding on Emlid’s part they can compensate for the issues with fix performance and accuracy consistency. We plan to further test the Reach RS and we will continue to post suggestions.
Thank you for a through review! I agree that there is room for improvement in software to help detect false positions. Would you mind sharing some of the data that you have collected if you still have it on hand? An exact coordinate, raw data set and the result that you got from Reach RS would help us understand the reason behind differences that you saw. You can share this data with me over private messages and we will include it as a part of our automated testing procedures.
Thank you and I hope to see more reviews from you in the future
Progress Update, Good News!. Note have upgraded to v2.9.1
I have conducted 3 additional tests of the Reach RS and have some general notes.
Original round of testing earlier this year included 20 minutes of logging at several observation sites while connected to out private on-premises RTK single base. The base supports L1/L2/L5 and GPS/GLONASS/Galileo. We analyze both precision and accuracy with accuracy being the distance between the known position of the observation site and the average position of the sample. Generally, the Reach RS struggled to obtain and hold a fix, but still at a few sites showed a lot of promise producing 10-20 centimeters precision and 20-30 centimeters accuracy. On the other hand at a few sites the Reach RS produced unacceptable precision and accuracy. But at most sties the Reach RS produced 10-20 centimeters of precision but very unacceptable accuracy of 1 or more meters.
After installing v2.9.1, we re-tested the Reach RS at one observation site connected to our private base. The sample size was 6,015 position estimates over 20 minutes. The ReachRS did not produce a Fix but did produce a promising set of Float samples; Accuracy was 0.402 meters and 2DRMS precision of 0.85 meters. Note, this is about a 55 meter base line rover to base.
In a second attempt, we connected the Reach RS to the Indiana State Department of Transportation INCORS RTK Network. This system produce a virtual reference station about 73 km away. At the standard 1ppm accuracy degradation we would expect to see about 7.3 centimeters of additional in-accuracy. INCORS is a L1/L2 and GPS/GLONASS system. Again, the Reach RS did not produce a Fix but Float samples were: Accuracy was 0.432 meters and 2DRMS precision of 0.399 meters. These Float samples are very similar to many other RTK units we test which produce a set of Floats just prior to locking down a Fix. It is as if the Reach RS is just on the verge of producing a very good fix but just can’t quite get there.
In a third test, we set up the Reach RS at one known observation point on a Tri-max tri-pod with an optical plumment. The base coordinates were manually entered into ReachView as the known position of the observation point. The Base RS was set to transmit correction via LoRa. The second Reach RS was set up as a Rover at the test observation point using an identical tripod and set to receiver corrections via LoRa. A 10 minute sample was collected via ReachView logging. The system was stuck in Float for about 3.5 minutes. The Float sample was typical; Accuracy was 0.516 meters and 2DRMS precision of 1.32 meters. However, at 3.5 minutes the Reach RS obtained and held a Fix solution for the remaining 6.5 minutes. The results were EXCELLENT!: Accuracy was 0.0388 meters and 2DRMS precision of 0.108 meters. In our opinion these numbers are acceptable given the nature of Reach RS core technologies and price point.
I will send the raw logs to Igor via PM for review.
I noticed that the Reach RS transmits RTCM3 messages 1002/1010/1097 for GPS/GLONASS/Galileo observations. To my understanding message 1002 and 1010 support L1 signals only. However, both our private base and the INCORS system transmit message 1004/1012 for GPS/GlONASS which support multiple frequency bands. Additionally, our private base transmits message 1094 for Galileo observations.
To avoid the frequency bias issue impacting GLONASS satellites for AR solution, we turn off AR for GLONASS in ReachView when connected to any base OTHER than another Reach RS. But, is there another compatibility issue base on the RTCM3 message type difference as stated above which causes the Reach RS to have a harded time locking onto a Fix when connected to non-ReachRS bases?
