Skip to content

Conversation

@santaimpersonator
Copy link
Contributor

Changes:
Update MAX_PAYLOAD_SIZE from 276 to 512 to support getModuleInfo() on the ZED-X20P GNSS module, which requires at least 288 bytes.

I verified this modification with an ESP32 Thing Plus and the ZED-X20P breakout.

SparkFun u-blox Example
FWVER: 2.0
Firmware: HPG
PROTVER: 50.2
MOD: ZED-X20P

Resolves:
When utilizing Basics > Example8_GetModuleInfo with the ZED-X20P, the library appears to run into a buffer overflow before it can detect the end of the response payload.

Debug Message:

Sending: CLS:MON ID:0x4 Len: 0x0 Payload:
sendCommand: Waiting for No ACK response3
checkUbloxI2C: 288 bytes available
processUBX: counter hit maximum_payload_size + 6! activePacketBuffer: 0 maximum_payload_size: 276
waitForNoACKResponse: TIMEOUT after 1100 msec. No packet received.

Updated MAX_PAYLOAD_SIZE from 276 to 512 to support getModuleInfo() on the ZED-X20P GNSS module, which requires at least 288 bytes.
@PaulZC
Copy link
Collaborator

PaulZC commented Jul 30, 2025

Thanks Wes (@santaimpersonator ),

I can't replicate this. The X20P I have returns 250 bytes. It doesn't include the "MOD=" extension. Your firmware must be slightly different, and does include the "MOD=", taking the payload length to 280 bytes. (Each extension is 30 bytes.)

But it's clear we need to increase. RAM is still precious on some platforms, so I think we should go with 300, not 512...

Cheers!
Paul

@PaulZC PaulZC merged commit 711eddf into main Jul 30, 2025
10 checks passed
@PaulZC PaulZC deleted the increase_buffer branch July 30, 2025 12:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants