Hyundai odometer over UDS: DID B002 and its two record layouts

Odometer mileage is not part of the classic OBD-II data set, so reading it from a Hyundai means asking the instrument cluster a manufacturer-specific question. The cluster answers a UDS request for DID B002, and on some models that reply contains the mileage. Which bytes hold it, and whether it is there at all, depends on how long the reply is. This note covers three Hyundais from a working bay. One was checked against its dash, one had its mileage on file, and one is still an open question.

The 12-byte reply that matched the dash

On a 2019 Hyundai Santa Fe, the scan sent 22 B0 02 to the cluster at address 7C6. The reply came back from 7CE across three CAN frames. Reassembled, it reads:

62 B0 02
D0 00 00 00 8A 8A 00 00 00 02 4F E0

0x024FE0 is 151,520 km, which is 94,150 miles. The dash, read within the same hour, showed 94,152 miles. That is 2 miles apart, or 0.002 percent.

A second number from the same scan agrees: the scan also read an ignition cycle count of 14,898, which works out to about 10 km per start, in the normal range.

The first reading was 13.6 million kilometers

The scan originally read the first three bytes of the record, which is where community-published data for some Hyundai models put the counter. On this car, D0 00 00 is 13,631,488 km. The plausibility check threw it out and the scan showed no mileage, even though the cluster had answered.

What found the right bytes was the log. An earlier capture (the Azera below) had shown that the log printed only the three bytes the scan read, not the whole reply. After that fix, the log printed the whole record, and the counter could be found at the end and checked against the dash.

Same DID, seven bytes, no odometer

A 2016 Azera and a 2018 Elantra answered the same request with a shorter record:

Azera    62 B0 02  C0 00 00 00 32 97 00
Elantra  62 B0 02  C0 00 00 00 41 A9 00

Both are seven bytes, and both start C0 00 00 00. Neither gives a mileage the way the Santa Fe's record does:

• The last three bytes: the Azera's 32 97 00 is 3,315,456 km.
• The first three bytes: C0 00 00 is 12,582,912 km on both cars.

The Elantra's mileage was on file for that visit: 52,666 miles, or 84,758 km. No run of two, three or four bytes anywhere in its record decodes to within 2 percent of that, read as kilometers or as miles. Whatever that record holds, it is not a plain odometer count.

Here is the trap. Bytes four to six of the Elantra's record, 00 41 A9, decode to 16,809 km. That is a believable number for a car, and it is about a fifth of the real figure. No plausibility check can catch it. Multiplied by 5 it lands within 1 percent of the mileage on file, but one car cannot tell a scale factor from a coincidence. The same position on the Azera gives 12,951, just as believable, and nobody has read that car's dash.

What the scan does now

• It reads the last three bytes as kilometers only when the record is exactly 12 bytes long, the length that was checked against a dash.
• It decodes nothing from bytes four to six of a 7-byte record. After the Azera that looked like the obvious candidate, and on the Elantra it would have shipped 16,809 km.
• For other lengths it falls back to the first three bytes, which is what the community data describes. That read has not been checked against a dash here, and the plausibility check stays in front of it. On both 7-byte cars it is rejected, so the mileage stays empty.
• A reply that arrives shorter than its declared length is thrown away, not sliced. The last three bytes of a partial reply are whatever happened to arrive.
• When a read is rejected, the log keeps the whole reply, so the next car with a readable dash can settle its layout.

What to take from this

1. On a 2019 Santa Fe, 22 B0 02 at 7C6 returns a 12-byte record whose last three bytes are the odometer in kilometers, verified against the dash.
2. The same DID returns a 7-byte record on a 2016 Azera and a 2018 Elantra, and on the Elantra no plain kilometer or mile count in it matches the mileage.
3. Gate a decode on the shape of the record, not on whether the number looks reasonable. 16,809 km looks reasonable.
4. Log the whole reply when you reject a read. It is the only way the next capture can tell you what you got wrong.

The Azera's layout is still unsettled. If you have a Hyundai that answers B002 with seven bytes and can photograph its dash next to the reply, that capture would close it.

Related: the Toyota odometer and DID 0103, the same kind of problem on a different make.