SPP Dropping incoming RTCM NTRIP bytes

[nseidle]

Originally report by @Stefal here.

With ESP32 Core Debug Level set to verbose, SPP is reporting buffer overruns when NTRIP is sending data from phone to ZED.

[E][BluetoothSerial.cpp:316] esp_spp_cb(): RX Full! Discarding 478 bytes
[E][BluetoothSerial.cpp:316] esp_spp_cb(): RX Full! Discarding 302 bytes
[E][BluetoothSerial.cpp:316] esp_spp_cb(): RX Full! Discarding 478 bytes
[E][BluetoothSerial.cpp:316] esp_spp_cb(): RX Full! Discarding 302 bytes
[E][BluetoothSerial.cpp:316] esp_spp_cb(): RX Full! Discarding 278 bytes
[E][BluetoothSerial.cpp:316] esp_spp_cb(): RX Full! Discarding 293 bytes

I can replicate:

• Connect to SW Maps
• Connect to NTRIP Client (reports ~600bytes per second)

While I am able to get RTK lock, I suspect some RTCM sentences are getting corrupted.

The solution that I've found is modifying the RX_QUEUE_SIZE within BluetoothSerial.cpp (reference) of the ESP32 core from 512 to 1024 bytes (and maybe larger depending on stefal's reports).

My suspicion is that the task is trigger fast enough, but that SW Maps and Lefebure (what stefal uses) may be sending large single transmissions. I really don't want to modify the core (that's error prone). I'll keep looking to see if it's settable.

[nseidle]

ZED is reporting bad frames as well:

These numbers show a few seconds of NTRIP data. The 'Skipped' number is a a bit misleading as it shows bytes skipped and the the smaller 'RTCM' number is successful messages received.

[nseidle]

This has been fixed in RC-May28. We now include a copy of the BluetoothSerial library with the buffer size modified to 2048.

This issue was affecting all previous versions. We should see slightly faster RTK lock (it's already really fast) and theoretically better RTK lock resiliency.

Note - using telemetry radios connected to UART2 also shows dropped bytes.

I suspect this is corrupt bytes from the radio link. The ZED is robust enough to reject these and needs RTCM regularly every 10-15s so a single lost RTCM packet at 1Hz won't bring down the link (hence why we didn't see this issue break RTK lock).

Thanks for reporting Stefal. I'll be watching this in the future.