I’m using two Reach RS units (base and rover) in a system that requires a high degree of reliability i.e. the system operates all day long and work stops if no RTK fix is available. In the trials I’ve done so far I regularly have issues maintaining an RTK fix. This is in an area with a clear view of the sky in all directions (>15deg), however, there is frequently a significant amount of cloud cover.
When an RTK fix is available the performance (accuracy) is great. The primary concern is that an RTK fix is not always available.
I’m trying to establish whether this behavior is typical or whether it can be significantly improved. Currently I estimate that we obtain an RTK fix about 70% of the time. We require an RTK fix for more like 99% of the time.
If it is possible to achieve this high level of reliability where do I start with troubleshooting this issue? I am happy to post my settings and conduct trials if it means we can achieve the high level of reliability we are looking for.
If the current level of RTK fix availability is to be expected what is the main limitation?
The Reach RS is an L1 only receiver. Is there an advantage in using a dual frequency (L1/L2) receiver?
The Reach RS can be configured for use with GLONASS and BeiDou satellites, but not simultaneously. I’m operating near Melbourne Australia where I could potentially take advantage of both. Would I notice a significant improvement in RTK fix availability using a multi-constellation receiver?
I’m currently using one Reach RS unit as a base and the other as a rover. Would I see a significant improvement in RTK fix availability using the CORS network instead of a base station?
I think you can do better than 70%, especially if you work is some kind of a field. I would start by sharing your usual work settings and a pair of logs with your typical conditions.
A couple of things to check:
Correction link. CORS has no significant advantage over Reach as a base except for a well known position. In case you don’t really move it around and are looking for day-to-day accuracy for something like autonomous vehicles, this doesn’t matter. What are using to pass corrections to the rover? It is worth checking the age of differential during your tests, to see if there’s anything interfering with the corrections.
Number of satellites. I can’t stress this enough. The more sats you have, the better the results in RTK are. We can’t use both BeiDou and GLONASS at the same time due to a hardware limitation. You definitely should use one of them, though. Whichever provides more visible satellites.
We are using the Reach RS system for an agricultural application (typically open fields). I’m currently testing in an urban area but with with a good view of the sky.
##Log Files
I collected the following log files over a period of about 1/2 an hour this afternoon. An RTK fix was obtained relatively quickly (1 minute or so). The fix was held for about five minutes and then lost for the remainder of the test.
###Base raw_201706200322.zip (4.8 MB)
I’m using the LoRa radio to pass corrections from the base to rover.
An age of differential of 2 to 3 seconds is typical with my settings. This seems too high but dropping the number of RTCM3 messages seems to have a bigger impact on performance than the long age of differential.
I have tried swapping GLONASS for BeiDou numerous times. I always get better results with GLONASS even though the GPS predictor seems to indicate there are more BeiDou satellites available in my area.
Any suggestions on how to improve the reliability of an RTK fix would be much appreciated.
Hey Ben, just a suggestion: If you recorded the base corrections at the rover end (RTCM3), then that file would be useful for comparing received corrections vs. base observations. Plus the .LLH file would be nice to have to compare processed results vs. RTK results.
After posting the above I continued testing and found that I get much better results when GPS AR mode (both rover and base) is set to continuous not fix-and-hold. I might have just got lucky because the user manual suggests that in real life conditions fix-and-hold provides better overall performance.
Does it matter if the base and rover use a different GPS AR mode? Does one mode work better for the base and other better for the rover?
Yes, it is just a binary file instead of text, but contains the same data.
Continuous is continuously scrutinizing, so it is more picky, and you will get less fixes in sub-optimal conditions. It is great for static points. It is a trade-off which means less fixes, but more confidence in the precision of those fixes. Fix-and-hold grabs on to a fix, and holds on to it. Example: If you have a fix, but move into poor conditions you haven’t lost your fix when you get back out into the open, which is great for higher productivity for survey or navigational purposes. It is a trade-off which means more fixes, but less confidence in the precision of those fixes.
Only the rover AR mode matters.
In the older ReachView software versions, you had to pick either base or rover mode. With the new ReachView, your Reach/ReachRS is always a rover that can simultaneously be used as a base. This is the best of both worlds.
In a typical situation, you will set your base like so:
RTK settings:
choose satellite constellations
choose frequency
positioning mode and AR mode are irrelevant
Base mode:
corrections output on
choose correction output type and it’s sub-settings
enter base coordinates (or average them if need be)
Agree that something strange is happening in this log file. From the configuration only the RTCM messages selection is untypical, so this is the first thing that I would suggest to alter.
There is no need to send ephemeris, it will only waste the radio bandwidth. Please try the following:
##Results (Test 1)
After 10 minutes of operation I was not able to obtain an RTK fix. Also, the age of differential continued to increase (60 seconds after 10 mins of operation). It appears that the radio link is not able to keep up with the 1Hz RTCM rate.
##Results (Test 2)
In the above test I forgot to enable logging so I repeated the test (the only configuration change was to enabled logging). This time I obtained an RTK fix after only a few minutes and the age of differential was steady at 2 to 3 seconds.
I repeated the above test but with RTCM messages updated at 0.5 Hz.
The results were much better. The system was able to maintain an age of differential of around 2 to 4 seconds. There was a brief period of time where it reached 10 to 15 seconds but it recovered.
Over the duration of this test I was able to achieve an RTK fix for about 90% of the time. There was only one significant drop out after the initial RTK fix.
I ran the same test again. This time I logged the status of the RTK fix. After an operating period of about 2 hours an RTK fix was available for 76% of the time (one drop out that never recovered).
During this test both base and rover were stationary and there was a clear view of the sky.
When the RTK fix is lost I know from experience that a restart will resolve the issue within a few minutes. But if left unattended the unit is unlikely to recover by itself.
I’ve also observed that changing settings can trigger an event that recovers the RTK fix status. It almost seems irrelevant which settings are changed. The fact that a change has occurred matters more than the change itself. Is this to be expected?
If the log files are required I am happy to post them.
Have you looked into log files to see what causes fix not to recover? When fix drops out, are that reading from output solutions or from postprocessing? And have you compared PP with RTK ?
I might give log files a try. If you got raw and output
I have tried looking into the log files but I’m still getting up to speed with how to read them. I typically loose a fix when the the number of satellites in view changes (either more or less). The AR drops dramatically on a change, sometimes the AR recovers quickly and other times it never recovers. In the case where it never recovers changing a setting or restarting the unit will usually resolve the issue quickly.
When I loose a fix I am referring to the output solution. I have not checked if the fix can be maintained with post processing (I’m not sure how to do this).
How do I compare PP with RTK? I can use RTKlib to do basic things like open, convert and view files. But I’m not sure on how to use this tool to diagnose my problem.
I posted my log files in an earlier post in this thread. Are these files not the ones you need? Which files do you need and I will post them again.
that makes a lot of sense now. I have been changing settings and thinking it was the setting itself that was resolving the issue only to find that the issue (permanently lost fix) returns at a later time. I now understand that it is the restarting of RTK that is temporarily resolving the issue.
This issue is reproducible. Which log files do you require?
Today I have been testing with NTRIP corrections instead of LoRa. Using NTRIP I can use faster update rates and significantly reduce the age of differential. Typical age of differential values are:
LoRa: 2.0 to 4.0 sec (0.5 Hz update)
NTRIP: 0.5 to 1.0 sec (2.0 Hz update)
Since switching to NTRIP I have not had a lost fix. Has anybody else had good success with LoRa? If so what settings work?
It is quite natural that you are able to send more data through NTRIP than through LoRa. The LoRa radio has low bandwidth, but it is fantastic in hitting long ranges at tiny power levels. Try setting speed to 9.11 and only enable position at 0.1Hz and GPS observation at 1Hz, Galileo observations at 0.5Hz. There is a chance that initially you have low age of differential with LoRa, but overtime it adds up. Monitor the age for a slightly longer period of time.
We are working on improvements to better automate rate selection and make radio configuration more bulletproof.
I have monitored the age of differential for extended periods of time (hours) and it is steady at 2 to 4 seconds using LoRa. Even when I loose at fix the age of differential is steady.
Today I tested the system with NTRIP corrections for many hours and did not loose an RTK fix even once. When switching back to LoRa I had problems maintaining an RTK fix.
I will try your recommended LoRa settings tomorrow. In the mean time I have some more questions:
Is there a maximum age of differential beyond which the system will have trouble maintaining a fix? It seems to me that anything over 1 second can be problematic.
Is there a combination of settings known to work with LoRa that will result in a low age of differential and maintain a robust fix over an extended period of time?
When I use a mixture of RTCM update rates I have noticed that there are some combinations that cause erratic behaviour of the SNR bars on the status page. Is it important to match the update rates of some RTCM messages?
I have tried your recommended settings (as listed below):
LoRa air data rate: 9.11 bk/s
1002 GPS L1 observations: 1 Hz
1006 ARP station coordinates: 0.1 Hz
1097 GALILEO: 0.5 Hz
With these settings I get an age of differential of 0.9~2.3 sec so the bandwidth is okay for this amount of data. However an RTK fix is problematic for a few reasons:
After obtaining a fix the AR ratio jumps erratically between a number above three (green) and a number below three (red). I think this is due to the inconsistent update rates. I do not see this problem when using consistent update rates. After quite some time the AR ratio settles down at a number above three and a steady RTK fix is obtained (at least for a while).
The same issue persists where after an extended period of time the RTK fix is lost and never recovers.
This means that I still cannot find a solution that works reliably with LoRa. Either:
(A) the update rate is too slow (0.5~1.0 Hz) and a reliable RTK fix is problematic; or
(B) the update rate is fast enough for a reliable RTK fix (2 Hz) but there is insufficient bandwidth.
I have done some further testing with NTRIP corrections. In really overcast weather (see image below) the ReachRS performed flawlessly. The ReachRS was able to obtain and maintain a reliable RTK fix over the entire duration of the test (many hours).
I’m now convinced that my problem with getting a reliable RTK fix is related to using LoRa corrections.
I’m just not sure how to fix this issue.
Does anybody else have a solution that works reliably with LoRa?
Is it possible to replace the internal radios with an alternative? If so, is it possible that this will improve things?
