Major delay in changing FIX solution after corrections are lost

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.

Can this error be fixed in Emlid Flow?

What does your environment look like?
Can you post a few raw files?

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.

Here is a link to UBX, LLH, and CSV file from yesterday

Hi Tim,

Thanks for your valuable comments.

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.

1 Like

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.


Hi Tim,

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.


1 Like

Hi Liudmila,
Thank you for the update! Have a great weekend.

1 Like