UBX checksum is incorrect
Opened this issue · 4 comments
According to UBlox documents:
The checksum is calculated over the Message, starting and including the CLASS field up until, but excluding, the Checksum Field
What I've noticed in reality that 2 bytes of class ID are not taken into account when UbxGps.h
calculates checksum, thus any NAV-PVT message is never considered valid
For example, this packet (without 2 checksum bytes at the end):
packet =[0xB5,0x62,0x01,0x07,0x54,0x00,0x98,0xBA,0x8A,0x1D,0xE7,0x07,0x04,0x07,0x11,0x28,0x0D,0x07,0x1A,0x00,0x00,
0x00,0x60,0x17,0xFE,0xFF,0x03,0x01,0x0B,0x08,0x4F,0xA9,0x21,0xF6,0xED,0xC1,0xBC,0x10,0xF0,0xA8,
0x04,0x00,0xCD,0x1F,0x04,0x00,0x79,0x24,0x00,0x00,0xBB,0x2B,0x00,0x00,0x01,0x00,0x00,0x00,0x52,
0x00,0x00,0x00,0x2D,0x00,0x00,0x00,0x52,0x00,0x00,0x00,0xD4,0xEA,0xAA,0x00,0x03,0x02,0x00,0x00,
0x93,0xB8,0x46,0x00,0xC9,0x00,0x00,0x00,0x84,0xD3,0x11,0x00]
The valid checksum would be CK_A = 0xD9
and CK_B = 0x71
Meanwhile the library expects CK_A = 0xC0
and CK_B = 0x16
And fails because it got CK_A = 0x11
If you exclude 2 bytes for class ([0x01,0x07]
) then calculated checksum matches i.e. a checksum for
packet =[0x54,0x00,0x98,0xBA,0x8A,0x1D,0xE7,0x07,0x04,0x07,0x11,0x28,0x0D,0x07,0x1A,0x00,0x00,
0x00,0x60,0x17,0xFE,0xFF,0x03,0x01,0x0B,0x08,0x4F,0xA9,0x21,0xF6,0xED,0xC1,0xBC,0x10,0xF0,0xA8,
0x04,0x00,0xCD,0x1F,0x04,0x00,0x79,0x24,0x00,0x00,0xBB,0x2B,0x00,0x00,0x01,0x00,0x00,0x00,0x52,
0x00,0x00,0x00,0x2D,0x00,0x00,0x00,0x52,0x00,0x00,0x00,0xD4,0xEA,0xAA,0x00,0x03,0x02,0x00,0x00,
0x93,0xB8,0x46,0x00,0xC9,0x00,0x00,0x00,0x84,0xD3]
would indeed be CK_A = 0xC0
and CK_B = 0x16
Basically, checksum is calculated for packet size 4 bytes shorter than it actually is (2 bytes for Class ID and 2 bytes for packet size field which is in Int16 Little Endian format - [0x54,0x00]
)
I need a help with fixing this code because without UART debugger playing with byte offsets by printing strings to serial is a nightmare :)
Found it!
Class props take 10 bytes, not 8 thus Class ID gets overwritten.
Easy fix:
unsigned char offsetClassProperties = 10;
It fixed checksum issue, but now data makes no sense - like weird year on incorrect Lat/Lon
Probably another offset somewhere
unsigned char offsetClassProperties = 12;
Because 2 bytes for HeaderClass is needed for proper offset in memory mapping
Now everything looks good
Hello @RomanTheLegend , since the NavPvt was tested with u-blox, it could be that the module you have has a different offset – what GPS module you are using, and what protocol document you are referring to in the first message?