Handling Databurst-Type Messages > 250 bytes
Through my testing of RTCM3 injection on Rover-4.1.0-rc1, I found a need for a slightly different version of the ESP-Now bridge discussed above.
MAVLink messages generally fit within ESP-Now’s 250 byte limit, so any ESP-Now message could be assumed a fully formed packet ready for further transmission and processing. RTCM3 messages, on the other hand, can be as large as 1023 bytes, generally hovering in the 400-600 byte range.
The original sketch’s serial polling simply waited for a delay just long enough (in μs) to ensure that any given serial message had been fully collected in a buffer before sending it forward. The receiver simply dumped that message to the serial port immediately upon receipt.
That same serial polling routine works for the sender even when dealing with larger databurst-type transmissions like RTCM3, but the receiver must also do some work to collect things up before passing a message forward. In the case of 1Hz RTCM3 messaging, I found that a 50ms delay between ESP-Now messages is more than adequate to have reasonable certainty that a fully formed packet has been received before writing the entire thing to the serial port (just like @ktrussell uses in his Serial_to_LoRa logic) .
I arrived at the sketch linked below, which was tested up to 460800 baud using external 2.4GHz antennas and resulted in complete coverage of a 2 acre property (where I run my Rover mower) at ranges of up to ~75m, with some elevation changes and obstacles like buildings and trees with virtually no data loss.
I’m so encouraged by the results that I plan to use this method for RTCM3 injection on Zed-F9P modules as a permanent solution for my mower.
A minor footnote: I still recommend the original ESP-Now-Serial-Bridge linked above for MAVLink - it’s faster and likely more reliable for smaller message sizes.