Radio port & RTCM -> MavLink wrapper?

GPS/GNSS Enclosed Products
1

On the RTK Express kit - the Radio port - I have RTCM messages being output to telemetry module to my Rover. I’m wondering if this radio port is directly connected to the ublox module or is there a chance to intercept the output (in code) and wrap the packets with MavLink GPS_RTCM_DATA headers? I’d really like to not have to use another processor to stuff them into the ardupilot system if at all possible.

2

The radio port is J9 here and looks like it is connected directly to the ZED-F9P UART2

You could try the ‘config ublox’ usb and poke around to see if there is a way to add a custom header to the packets via u-center’s settings (be sure to save if you find something!)

If not…things will be more tricky :-/

You could put this in the radio port and have it going to a MCU doing the reformatting and then that MCU passing it along to the radio

You can try using this test sketch SparkFun_RTK_Firmware/Firmware/Test Sketches/GNSS_Serial_Test/GNSS_Serial_Test.ino at main · sparkfun/SparkFun_RTK_Firmware · GitHub and passing the reformatted stuff over BT

3

Thank you for your reply. I have already started going down the path of having an ESP32 in between the radio port and the serial telemetry module to wrap the sentences into MavLink format. Was just hoping I could eliminate the need for extra hardware if the stream was already being managed. Thanks though : )

4

I ended up creating a sketch for my ESP32 and got it working as intended. I plan to package up the code and make it available for others shortly once I polish it off a bit. It takes RTCM raw data from the express kit radio port and outputs it on another serial port to my telemetry module wrapped in MavLink packet format.

However - now I see there is a DATA port on the Express RTK Kit. I see its controlled by the mux and does end up going thru the esp32. Is it possible to direct the RTCM data from the ZED thru the mux and I could write a routine to wrap it in MavLink packets directly? I havent dug thru the code enough to understand if the esp32 is already getting the raw rtcm packets from the zed module.

Thanks!

5

Here is the code / project page for what I ended up making. The esp32 could go on either end - the rover side or the base side. I prefer the base side so I dont have to power the esp32 from the rover.

Its rough but works. Modifications or comments welcome. I’m sure if the Sparkfun code could be modified to allow the sentences to come out the data port directly you’d sell a handful more kits.

2 Likes
6

Observations, the maximum message length record is 10-bit, so 0-1023, so packet header, payload, and CRC24Q can run 1029 bytes. The top 6-bits in the second byte are zero ie & 0xFC, not 0xF8

The content of the packet are binary, so could contain 0xD3,0x00 type patterns internally, so if you can walk intact packets with correct checksums, things will be more robust, you can align to packet boundaries, and only send on valid packets.

2 Likes
7

Thanks! Your code helped me do some debugging. I was using the Dump function and getting about 99% passing the checksums. I’ll make some verifications before forwarding soon. I know if the ublox output has any other sentences etc I need to filter those as well. Especially when using Lora which is good to keep the total bandwidth around 1200 baud or so. I just got it barely working on my rover and now its time to harden it : )

1 Like