Description
Trying to find a way to get Lora to work with postcard since it's quite noisy. Maybe I need to disable much of the nmea on the base. But I also noted for another project using rp2040
Our system uses the Raspberry Pi RP2040 processor on the main board to interact with the GPS receiver and the radio. The software is written for the Arduino IDE and is available, at our Serial Modem project on GitHub. For the base station the RP2040 receives the RTCM formatted correction data from the GNSS receiver and then sends it out in packets over the LoRa radio. LoRa packets are restricted to 256 bytes by the protocol, so the RP2040 breaks up the messages into that sized packets. On the rover, the RP2040 receives the packets from the LoRa radio, parses them into messages (including data spread across packets), and then sends them to the RXD2 port on the rover’s GNSS receiver. The GNSS receiver uses these RTCM messages to produce an an RTK solution with centimeter level accuracy.
Is there a way to break up packets?
I haven't found a definitive guide to what rtcm opus needs but my goal is to set up a base logging while providing corrections over Loraserial and have my rover do work and correct my base later. Espnow works fantastic so I believe I'm overload lora.
Activity
PaulZC commentedon Mar 25, 2025
Hi Ryan (@ryanmurray ),
Please post a link to your Serial Modem project. Thanks!
Best wishes,
Paul
ryanmurray commentedon Mar 25, 2025
https://tinkerbugrobotics.com/how-to-send-rtk-corrections/
Paul I am using sparkfuns Lora serial radios. I believe this may be an issue of the postcard being very noisy. Reading the manual a little more last night is there guidance (I tried low bandwidth defaults) on maybe what minimal nmea messages are needed (maybe none?).
Also am I understanding I could turn the frequency of the rtcm messages down?
Finally my idea was to adjust the Lora airspeed.
Basically I'm just trying to get Lora to work with the postcard (I've also tried with the facet as a base) since espnow works great I'm assuming that the link is just way too noisy. So maybe some guidance on messages for rinex conversion, rtcm messages needed to the rover for RTK, minimal nmea messages. I was going to try to play around a little more but where others gave up on the Loraserial I believe it probably can work.
ryanmurray commentedon Apr 1, 2025
Think I found a better solution in rover mode disable uart3 transmit. Once I disconnected the jst wire the Lora worked fine from base to rover. I used 19200 airspeed I am going to retest decreasing that.
PaulZC commentedon Apr 1, 2025
Thanks for the update Ryan (@ryanmurray ),
We haven't yet had time to look into this. Please keep the updates coming - and thank you for spending time on this.
Best,
Paul
[-]Lora serial settings[/-][+]Add Option to Disable Serial Output During Rover to Reduce LoRa Traffic[/+]nseidle commentedon Apr 1, 2025
I believe what you are asking is for the ability to disable serial transmission on the RADIO port, during rover, correct?
[-]Add Option to Disable Serial Output During Rover to Reduce LoRa Traffic[/-][+]Add Option to Disable Serial Output During Rover to Reduce Radio Traffic[/+]ryanmurray commentedon Apr 1, 2025
Exactly Nathan and since rtk postcards just have the one port for uart 3 that's what I've been connecting loras to, as soon as I disconnected the transmit wire on the rover postcard I got corrections. It was a moment of glory. On the base I disabled nmea and only broadcast 1005, and the msm7 messages for glo, gal, and gps. I obtained an instant 8mm by 11mm fix. Basically the rover back feeding over serial (I'm in multipoint mode btw) overwhelms the link. I was using the jst cables. as you stated the facet I own does not behave this way. And would make sense why 2 torches can do it fine also.
The only issue I could see ( I use corrections on my phone when using state network) is that you need gga on that but my application does that versus the rover itself. But maybe if someone was using onboard ntrip that would break?
cturvey commentedon Apr 1, 2025
I had suggested removing the Radio RX pin connectivity on the Rover side to basically prove/demonstrate in a hard fashion whether the traffic there was an issue or not.
The LoRa radio basically being a half-duplex channel, and synchronizing to the burst output of the GNSS aligned to top-of-second, and potentially self-jamming or treading on itself.
So basically the ability of Rover(s) to be silent on radio side comms. I've generally avoided disabling radio side UART RX, as this just makes (re)configuration and enabling debugging extra difficult. But data TX over radio could be gated or suppressed there too.
Now for NTRIP, in a one-to-one connection, you typically need GLL or GGA to establish a location to find closest mount point, allow for VRS, act as a walled garden, or establish continued life/operation of the connection
Jeffpostcn commentedon May 2, 2025
Ok this Comment has me thinking I do not really understand the "Configure Ports" Serial Menu for the RTK Postcard:
My thinking was that option 1 was to set the Baud Rate for the internal ESP-NOW radio and option 2 set the baud rate for the "4-pin locking JST-GH connector" which I now see listed on the Schematic as the RADIO Port 🤯. Please Confirm? also what then is the "Data Port" ? (My guess: not functional item for the RTK Postcard?)
nseidle commentedon May 2, 2025
RADIO port is the JST-GH connector. DATA is USB (C connector) port B on the CH342.
PaulZC commentedon Jul 9, 2025
I'm taking a look at this now.
Do we do this using port protocol settings, or by disabling individual NMEA messages on the RADIO port.
LG290P:
With firmware v4, NMEA message rates can be set independently on individual ports via PQTMCFGMSGRATE.
Individual port output protocols can be set via PQTMCFGPROT.
mosaic-X5:
NMEA messages are configured on COM2 (RADIO) using NMEA streams. Each "connection descriptor (Cd)" (COM1 (ESP32), COM2 (RADIO), USB1 (USB Virtual COM), DSK1 (microSD)) has two streams dedicated to it. Each stream can only have one Cd. Individual NMEA messages could be enabled / disabled on COM2 by changing the two streams via sno.
Individual port output protocols can be set via sdio.
ZED-F9P:
NMEA message rates can be set independently on individual ports via (e.g.) CFG-MSGOUT-NMEA_ID_GGA_UART2.
Individual port output protocols can be set via (e.g.) CFG-UART2OUTPROT-NMEA.
UM980:
NMEA message rates can be set independently on individual ports via (e.g.) GPGGA COM3 1
I can't see a way of setting the individual port protocols. It looks like there isn't one. In the RTK Everywhere Firmware,
setCorrRadioExtPort
doesn't do anything on the UM980.The LG290P, mosaic-X5 and UM980 GNSS classes all have
enableNMEA
methods which can be adapted.On the ZED-F9P, the NMEA messages are configured by
setMessages
using the hugeubxMessages
table. But, it looks like we made a decision to only allow RTCM3X output on UART2. These lines inconfigureGNSS
and these lines ensure that NMEA is disabled on UART2.OK. Enough procrastinating... I'm going to add a "NMEA output on RADIO port:" enabled / disabled setting to the ports menu. And then modify
enableNMEA
to do the necessary.PaulZC commentedon Jul 9, 2025
On Torch, it looks like we don't need to do anything.
loraProcessRTCM
writes data to the LoRa for transmit.loraProcessRTCM
is only called byprocessRTCM
. AndprocessRTCM
is only fed by the arrival of RTCM data when in Base mode... Nothing to do here. Move along...Add enableNmeaOnRadio - resolves #604
PaulZC commentedon Jul 10, 2025
Resolved by #668
PaulZC commentedon Jul 10, 2025
The ports menu now looks like this - on mosaic-X5. Postcard has the same option.
https://github.com/sparkfun/SparkFun_RTK_Everywhere_Firmware/blob/release_candidate/docs/img/Terminal/SparkFun%20RTK%20Everywhere%20-%20Ports%20Menu.png
nseidle commentedon Jul 16, 2025
This feature has been added to v2.2 and is documented here.