NTRIP corrections dropout when outputting NMEA position

[Adrian]

Hi,

I noticed this behaviour after flashing v2.3 firmware and updating the Reach to v2.9.1.

When the Reach is configured to output the position via Serial port in NMEA format, it doesn’t handle NTRIP corrections via Wi-Fi (VRS - RTCM3). The ReachView Status screen becomes choppy and laggy and it loses the float / fixed status. The base correction log shows a data dropout during this period, but the the raw data appears to be correct.

After changing the output coordinates format (or disabling position output), it recovers float / fixed status and ReachView returns to work smoothly.

Is anyone else facing this issue with the v2.9.1? In v2.7.4 and previous versions (v2.3 firmware) it worked well (I didn’t tried the v2.8.0).

[TB_RTK]

I use the exact same setup but without vrs enabled. And its stable here. Could you check with vrs off?
I have baudrate at 4800

[Adrian]

Hi, @TB_RTK.

I own only a Reach and use it as rover to record raw data and base corrections (connecting it to a 3G Mobile Wi-Fi modem).

I need a 9600 baud output rate, but at 4800 the issue is still present. I will try another RTK solution (FKP or MAC) that does not depend on sending rover NMEA position to the server, as it could be the cause.

About other configs, base mode is off and RTK settings are:

@TB_RTK, what’s your workflow?

Is anyone with access to a NTRIP server able to reproduce my issue?

Thanks in advance.

[TB_RTK]

Hi,
I use Continuous and also Galileo system.
Here is link to serial output setting. Other then that i dont use VRS and has ntrip via www.rtk2go.com
The RTK boat project - #15 by TB_RTK
I am no sure what version i run, need to check this

[igor.vereninov]

Hi Adrian,

This is an interesting issue!

Is it reproducible? Meaning NMEA OFF everything is good, NMEA ON laggy status page?

What if you change update rate to 1Hz?

[Adrian]

Hi, @igor.vereninov.

Yes, when outputting NMEA data, the Reach stops recording NTRIP corrections (no FKP, no MAC, no VRS). Turning off the position output, it works well (after a restart).

I just tried to change the update rate to 1Hz and it also works, but that’s a bit slow for photogrammetry.

I hope the issue can be easily fixed.

Thank you very much for looking into it.

[egor.fedorov]

Hi Adrian,

Could you please check whether this happens only with USB-to-PC serial option or with every other kind of serial as well?

[Adrian]

Hi,

It also occurs in UART mode. I haven’t tried USB OTG.

[egor.fedorov]

Bug confirmed, will try to fix asap. For now the problem will occur if the device is configured to use USB-to-PC and the output is not being read. Also with UART on low baud rates.

[Adrian]

Thank you so much!

Let me know if I can help you in any way.

[Simon_Allen]

Hmm, the failure mode is familiar, I am going to check bluetooth today…

[arnaldoasneto (Arnaldo)]

I had the same issue using GPS and SBAS at 14HZ. Everything works out until for 10 minutes or util you start to inject corrections. I figure out that with the SBAS constellation OFF this does not happen anymore.

[egor.fedorov]

Hey guys,

This got fixed in the latest v2.9.3. Bluetooth latency as well. Would great if you could check it out and confirm.

[Adrian]

Hi @egor.fedorov, sorry for my late reply.

I just updated to the v2.9.3 and, unfortunately, the issue is still present.

When enabling NMEA position output (Serial > UART > 9600), the Reach stops logging base corrections. After disabling it, it works again.

[egor.fedorov]

Well, seems like we fixed the lag only. We’ll take a look.

UPDATE:

I think that 9600 is simply not enough for NMEA to go through. Please confirm if this still happens on 115200 or 230400.

[Simon_Allen]

4800 or 9600 are standard NMEA data rates.
Might it be time to choose the messages that get sent via NMEA?

[egor.fedorov]

Well, they are standard for the standard NMEA data rates, which are 0.5 and 1 Hz. 5 Hz requires more throughput.

[Adrian]

That would be great. In fact, I just need to get GPGGA sentences.

@egor.fedorov, right now I can’t check it, but I’ll publish the results at other baud rates ASAP.