u-blox UBX Packet Decoder
Decode u-blox UBX binary protocol packets from hexadecimal bytes. Inspect sync characters, message class, message ID, payload length, raw payload bytes and the two-byte Fletcher-style UBX checksum.
B5 62 are synchronization bytes. The checksum is calculated over
CLASS, ID, LENGTH and PAYLOAD bytes only; the two sync bytes and the checksum
bytes themselves are excluded.
—
—
What Is the u-blox UBX Protocol?
UBX is a binary communication protocol used by many u-blox GNSS receivers. Unlike human-readable NMEA sentences, UBX messages use binary fields and a fixed packet envelope consisting of synchronization bytes, message class, message ID, payload length, payload and checksum.
The protocol is commonly used for navigation output, receiver configuration, acknowledgements, monitoring information, raw GNSS measurements and timing messages.
UBX Packet Structure
Byte 0 0xB5
Byte 1 0x62
Byte 2 CLASS
Byte 3 ID
Byte 4 LENGTH low byte
Byte 5 LENGTH high byte
Bytes 6... PAYLOAD
Final -2 CK_A
Final -1 CK_BThe payload length is stored as a 16-bit little-endian integer, so the low length byte appears first.
UBX Synchronization Bytes B5 62
Every normal UBX packet begins with hexadecimal bytes
B5 62. These bytes allow a parser to locate the start of a binary
message stream.
Expected sync:
B5 62If the first two bytes are different, this calculator reports a synchronization error rather than treating the packet as valid UBX data.
UBX Message Class
The CLASS byte groups related message types. The following are several commonly encountered UBX classes.
| Class | Name | Purpose |
|---|---|---|
| 0x01 | NAV | Navigation results |
| 0x02 | RXM | Receiver manager / measurement data |
| 0x04 | INF | Information messages |
| 0x05 | ACK | Acknowledgements |
| 0x06 | CFG | Receiver configuration |
| 0x09 | UPD | Firmware/update-related messages |
| 0x0A | MON | Monitoring information |
| 0x0D | TIM | Timing messages |
| 0x13 | MGA | Multiple GNSS assistance |
| 0x21 | LOG | Logging functions |
| 0x27 | SEC | Security-related messages |
Common UBX NAV Messages
| Class / ID | Message |
|---|---|
| 01 01 | NAV-POSECEF |
| 01 02 | NAV-POSLLH |
| 01 03 | NAV-STATUS |
| 01 04 | NAV-DOP |
| 01 07 | NAV-PVT |
| 01 12 | NAV-VELNED |
| 01 20 | NAV-TIMEGPS |
| 01 21 | NAV-TIMEUTC |
| 01 35 | NAV-SAT |
UBX NAV-PVT
NAV-PVT is one of the most widely used navigation messages in modern u-blox receivers. Depending on receiver generation and protocol version, its payload contains fields such as GPS time of week, date, UTC time, fix type, number of satellites, longitude, latitude, height, ground speed and heading.
Those payload fields have fixed offsets defined by the applicable u-blox interface specification. This page recognizes the NAV-PVT class and message ID but does not apply a potentially incompatible receiver-generation layout unless that exact payload decoder is explicitly implemented.
UBX ACK-ACK and ACK-NAK
The ACK class reports whether certain configuration messages were accepted or rejected.
ACK-NAK:
Class = 0x05
ID = 0x00
ACK-ACK:
Class = 0x05
ID = 0x01Their payload normally contains the class and ID of the message being acknowledged.
UBX Payload Length
The payload length uses two little-endian bytes.
Length bytes:
02 00
Length =
0x0002
= 2 bytes
Another example:
5C 00
Length =
0x005C
= 92 bytesThe expected full packet length is therefore:
Total packet bytes =
2 sync
+ 1 class
+ 1 ID
+ 2 length
+ payload length
+ 2 checksum
= payload length + 8How the UBX Checksum Works
UBX uses two eight-bit checksum accumulators named CK_A and CK_B. Calculation begins with both values set to zero.
CK_A = 0
CK_B = 0
For each byte from CLASS through the final PAYLOAD byte:
CK_A = CK_A + byte
CK_B = CK_B + CK_A
Both values are kept modulo 256.
The synchronization bytes B5 62 are not included, and the
received checksum bytes are not included in their own calculation.
UBX Checksum Example
Consider the structural portion:
05 01 02 00 06 01
05 = ACK class
01 = ACK-ACK ID
02 00 = 2-byte payload
06 01 = payloadThe calculator iterates across those bytes to produce CK_A and CK_B and then compares the result against the final two bytes of the supplied packet.
UBX vs NMEA Messages
A u-blox GNSS receiver may support both UBX binary messages and NMEA text sentences. They are different protocols even when both carry navigation data.
| Feature | UBX | NMEA Text |
|---|---|---|
| Encoding | Binary | ASCII text |
| Typical Start | B5 62 | $ or ! |
| Message Identification | Class + ID | Sentence identifier |
| Payload | Binary typed fields | Comma-separated text fields |
| Integrity | CK_A / CK_B | Sentence checksum |
Why UBX Payload Meaning Can Vary
The structural UBX packet format is stable, but the precise payload layout of a particular message can depend on the receiver family and protocol/interface version.
For that reason, a generic structural decoder should not guess field offsets for an unknown message. This calculator always exposes the raw payload and message class/ID even when a safe application-level interpretation is not available.
u-blox UBX Packet Decoder FAQs
What bytes begin a UBX packet?
What does the UBX CLASS byte mean?
What is UBX-NAV-PVT?
What is UBX-ACK-ACK?
What is UBX-ACK-NAK?
Is the UBX payload length big-endian?
Are B5 and 62 included in the UBX checksum?
Are CK_A and CK_B included in their own calculation?
Can this tool detect a corrupted packet?
Can the tool decode every u-blox payload field?
Decode u-blox UBX Binary Packets
Inspect UBX synchronization bytes, class and message identifiers, little-endian payload length, payload boundaries and CK_A / CK_B checksum validity directly from GNSS packet hexadecimal data.