Beware, there is a very long time between the time corrections are lost and the FIXED status changes to single (or in a rare situation float). It is now required to check the status before taking every shot to view the corrections and residuals / deviations.
The app needs to be corrected so that there is basically no delay or least the no more than 2-3 seconds from the time corrections are lost and the FIXED status is dropped.
If the time to respond from fix to single can not be fixed, then the corrections status and residuals should be displayed on the survey screen so that the users know the true status of corrections.
This can result in bad data being collected during RTK, especially if someone was taking short shots (ie 5-10 seconds). It is in my opinion RTK on the RS2 is far more reliable than PPK . When using NTRIP (via celular) or LoRA, it is very possible for corrections to drop out from time to time so it is vital for this flaw to be corrected.
Christian,
Here you go. Yesterday I was testing to see if using a higher gain antenna on the base would help provide significant distance improvement. It did help, but very little over the stock RS2 antenna. Today I will raise the antenna to about 20 feet and test it again.
But the problem is not with the environment. It is that Emlid flow is keeping a fix for quite some time after the corrections are no longer being received. When I test the base antenna at 20’, I will put a timer to show how long it stays fixed after the corrections are lost. I talked to another Emlid user and he already checks the standard deviations and age of corrections before each shot. So for now I will do the same.
It would be very nice for those values to be displayed directly on the survey window so that you knew what they were at the time of the observation.
I would say the problem is going to be more profound using LoRa on the outer limits of Lora vs using NTRIP, but it happens with both.
My base was located in the very top left near the first observed point.
Reach should be placed in good environmental conditions and have an appropriate line of sight if you work with radio or a stable internet connection if you use NTRIP. Such conditions ensure a stable fixed solution and reliable results.
But, of course, it’s not always possible to maintain them since the environment or internet coverage can change. We always recommend double-checking PDOP, Age of differential, and RMS when working in challenging conditions and potential cases of corrections stream interruptions.
In the latest stable release (Reach Firmware 31), the maximum Age of differential was reduced to 10 seconds. Thus, if you lose the corrections, the solution will certainly change to SINGLE in 10 seconds. We believe that this change should help in the cases you described.
Liudmila,
Would it be possible in a future release to make the maximum age of corrections user definable? If we could set the maximum that would be great. I would set it to more like 4 seconds, maybe lower in some case.
We tested this configuration and concluded that 10 seconds is a suitable maximum for the age of differential. At the moment, we don’t have plans to allow change of this setting in the app. But I’ll let the team know about your request.
Hello Liudmila, and on Reach RX, have you also considered limiting the age of corrections? In addition to that, there are two bugs that I have identified in the Emlid Flow app when connecting to Reach RX. The first bug is that I cannot obtain RTK corrections in 2G. The NTRIP protocol I use requires only an average of 9.6 kbps of data, but if connected in 2G, with, for example, 120 kbps of internet speed available, I cannot obtain corrections. I presume that the Emlid Flow app is not well optimized to work with low internet speed because, for example, if I use the Lefebure NTRIP client or Survx software, I can obtain corrections on the RX with the same phone, the same NTRIP protocol, and the same internet speed.
The second bug is that the Emlid Flow app takes too long to recover corrections when there is a loss of corrections for any reason. Even with a 4G connection, it only recovers corrections after 1 to 2 minutes. A trick that I noticed works is to restart the app to recover corrections, but this should not be necessary; the app should attempt to recover corrections every 3 seconds, and we should not have to wait 1 to 2 minutes.
The last situation I will mention is a suggestion for improving the Emlid Flow app and not a bug. I suggest that, next to the satellite count information (top of the screen), include information about the age of corrections. When there is a loss of corrections, the app only goes from FIX to FLOAT after 1 minute. This can cause errors when obtaining coordinates. If the information about the age of corrections is visible, and not just in the status menu (which is not practical), the surveyor obtaining coordinates has an exact perception of the age of corrections, giving them greater confidence in obtaining accurate coordinates.
