Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UBX checksum is incorrect #27

Open
RomanTheLegend opened this issue Apr 7, 2023 · 4 comments
Open

UBX checksum is incorrect #27

RomanTheLegend opened this issue Apr 7, 2023 · 4 comments
Assignees

Comments

@RomanTheLegend
Copy link

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 :)

@RomanTheLegend
Copy link
Author

Found it!

Class props take 10 bytes, not 8 thus Class ID gets overwritten.

Easy fix:

  unsigned char offsetClassProperties = 10;

@RomanTheLegend
Copy link
Author

It fixed checksum issue, but now data makes no sense - like weird year on incorrect Lat/Lon

Probably another offset somewhere

@RomanTheLegend
Copy link
Author

  unsigned char offsetClassProperties = 12;

Because 2 bytes for HeaderClass is needed for proper offset in memory mapping

Now everything looks good

@loginov-rocks
Copy link
Owner

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?

@loginov-rocks loginov-rocks reopened this Apr 11, 2023
@loginov-rocks loginov-rocks self-assigned this Apr 11, 2023
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

No branches or pull requests

2 participants