ZED-X20P RXM-RAWX corruption when logging over I2C

GPS/GNSS
1

ZED-X20P RXM-RAWX packets corrupted when logging over I2C

Hi, I’m trying to log RAWX/SFRBX data from a SparkFun ZED-X20P for PPK using an ESP32 and the SparkFun u-blox GNSS v3 library.

SFRBX is logging correctly, but every RAWX packet fails its UBX checksum.

For my latest test file (~674 kB), I found:

  • 2,285 valid RXM-SFRBX packets
  • 234 apparent RXM-RAWX packets
  • 0 checksum-valid RAWX packets
  • RAWX lengths look reasonable at ~2,000–2,160 bytes

I’ve stripped the test down to:

  • X20P over I2C at 400 kHz
  • UBX only, NMEA disabled
  • RAWX + SFRBX enabled at 1 Hz
  • No PVT/SAT/SIG output
  • No callbacks or position polling
  • 8192-byte GNSS file buffer
  • 512-byte SD writes

The buffer doesn’t appear to be overflowing. Peak usage in the latest test was only 3364/8192 bytes (41%).

I’ve also tried a ~65 kB buffer, different SD write sizes, removing the I2C mux, etc. Same result: SFRBX packets are valid, RAWX packets are corrupted.

Has anyone successfully logged RXM-RAWX from the ZED-X20P using the SparkFun v3 library over I2C? Is there anything X20P-specific I’m missing, or could this be related to the much larger RAWX packets?

I can share the test sketch and UBX files if useful.

2

I have been trying to further isolate the RXM-RAWX issue. I have tried the following things and still have not been able to get a single RAWX message with a valid UBX checksum:

  • Reduced the code to a minimal RAWX/SFRBX-only logger with no other sensors, PVT or CSV logging
  • Tried both I2C/Qwiic ports on the X20 board
  • Reduced I2C speed from 400 kHz to 100 kHz
  • Bypassed the SparkFun parser and file buffer and captured the X20 I2C byte stream directly
  • Disabled the X20 internal I2C pull-ups
  • Configured the X20 output RAWX and SFRBX over UART1 rather than I2C 115200 baud

Across the tests, the RAWX packets generally have plausible message IDs and payload lengths, but I still have not been able to get one with a valid checksum. None of these configurations have worked, even switching to UART did not fix the issue. Any help is appreciated

3

Hi Will (@Will_Ronan ),

Welcome!

Thank you for reporting this issue. I am able to replicate this. I have opened an issue for it at the link below. I will report back here once the issue is resolved. It does look like the RAWX message length could be the issue.

Best wishes,
Paul

4

@Will_Ronan : if you are using UART, please be careful with your baud rate.

At 100kHz (roughly equivalent to UART 115200 baud), with SFRBX and RAWX at 1Hz, the I2C bus is almost at capacity:

image
image764×360 11.2 KB

If you have any other messages enabled (e.g. the standard NMEA messages), you may be overloading the UART at 115200. I suggest increasing to at least 460800 baud.

5

Hi Will (@Will_Ronan ),

Version 3.1.15 of the library should be available through the Arduino library manager later today. Please give it a try. Please let me know if it resolves your issue.

Best wishes,
Paul

6

Hi Paul,

Thank you for your help. Unfortunately this fix has not eliminated the issue. I have tried the code again from “SparkFun_u-blox_GNSS_v3/tree/main/examples/Data_Logging/DataLoggingExample3_RXM_SFRBX_and_RAWX” and while the file ubx file saves successfully, not one RAWX packet has a valid checksum.

I looked through the documentation of your patch and it does not seem like you replicated the same issue that I had. My logging of the RAWX never stalled, they are just not being logged properly. There must be some sort of misalignment or overflow because 100% of RAWX packets have invalid checksums.

This is shown when I try to convert the .ubx file into RINEX files using RTKLIB, the .obs file fails to be created. When going through the error trace I get “2 ubx checksum error: type=0213 len=48” for every “RAWX packet that gets saved.”

When using AI tools to help me debug this issue, they suggest perhaps the I2C buffer is being overflown?

I am going to try reducing the amount of satellites do reduce the RAWX data to see if that helps.

This is out of my area of expertise as I am quite new to RTK/PPK so any ideas you have are appreciated!

Best,

Will

7

Hi Will,

Ok. Let’s try and narrow this down…

Are you using the logging example as-is? Completely unmodified? Or have you made changes?

Which ESP32 board are you running this on? Please share a link.

How long is the Qwiic cable between the two boards?

Which version of the Espressif ESP32 Arduino board package are you using?

Please share as much information as you can. Photos help too.

You can attach zip files to these posts, but you need to give them a .txt extension. Rename to name.zip.txt and then attach.

Any data you don’t want to share publicly, you can send to me in Private Messages.

Best,
Paul

8

Hi Paul!

I think I may have solved the issue! It was not an issue with the I2C the library or the module after all.

Apologies wasting your time. The problem was that I have been using a script I wrote to download the .ubx file via the serial output of the ESP32 using picocom. The .ubx file was getting corrupted during this process, I guess it doesn’t handle the raw binary output of the .ubx file well.

Thank you for your help!

Will

9

No problem Will - thanks for the update,
Paul