loginov-rocks/UbxGps

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?