Bit Numbering

Because of different software tools and conventions in the industry, there are multiple ways to refer to bits within a CAN message. This doesn’t change the actual data representation (like a different byte order would) but it changes how you refer to different bit positions for CAN signals.

The vehicle interface C++ source assumes the number of the highest order bit of a 64-bit CAN message is 0, and the numbering continuous left to right:

Hex:         0x83                     46
Binary:      10000011              01000110
Bit pos:   0 1 2 3 4 5 6 7   8 9 10 11 12 13 14 15 ...etc.

The tool used at Ford to document CAN messages (Vector DBC files) uses an “inverted” numbering by default. In each byte of a CAN message, they start counting bits from the rightmost bit, e.g.:

Hex:         0x83                     46
Binary:      10000011              01000110
Bit pos:   7 6 5 4 3 2 1 0   15 14 13 12 11 10 9 8 ...etc.

When building CanSignal structs manually, you must use the normal, non-inverted bit numbering.

When using JSON mapping format and the code generation tools, you can control the bit numbering with the bit_numbering_inverted flag. By default it assumes normal bit ordering unless you are using a database-backed mapping, in which case it defaults to true - the DBC files we’ve seen so far have all stored signal information in the inverted format.