The short answer, before the detail
On a passenger car or a light vehicle bus, 11-bit is almost always right. On a truck, a bus or
construction machinery that already speaks J1939, 29-bit is usually the only option that does not
fight the rest of the network.
That is the decision in one line. What follows is why, and what each choice costs you.
What actually differs
| 11-bit standard | 29-bit extended | |
|---|---|---|
| Identifier space | 2,048 IDs | ~536 million IDs |
| Who uses it | Passenger cars, light vehicles, most OEM-specific buses | J1939, NMEA 2000, most heavy vehicles and construction machinery |
| Typical TPMS use | A handful of IDs, one per group of wheels | J1939-format message sets, PGN-based layouts |
| Filter setup | Simple and cheap on any controller | Needs 32-bit mask/match filters — most CAN peripherals support it, but you must configure it |
| Arbitration priority | Higher priority relative to the same ID in extended space | Lower priority; 11-bit always wins arbitration over these |
The last row is the one people miss. Arbitration is decided per bit, and an 11-bit frame carries a
dominant IDE bit, so a busy 11-bit bus can starve 29-bit traffic. On a machine where the 11-bit
traffic is dense and continuous, an extended-frame TPMS node may simply lose arbitration every time it
tries to speak. That is not a receiver fault and it does not show up as an error — the data just arrives
late.
Choose 29-bit when the bus already speaks J1939
If the machine builder already runs J1939, matching it is not about elegance, it is about **who else is
listening**. A gateway, a telematics unit, a service tool — they are already parsing 29-bit frames and
their filters are set for that space. Adding an 11-bit node means every consumer needs a second filter
set, and the vehicle's diagnostics tools will not see the tyre data at all.
We work in 29-bit extended frames, and we have deployed J1939-format message sets in construction
machinery integrations with major OEMs. What that means for you: the layout can be aligned to your
parameter set or your DBC rather than handed over as a fixed, odd-looking map. It does not mean the
device is J1939-certified — we hold no conformance certificate, and if a programme requires one we say
so honestly rather than claim it.
Choose 11-bit when nobody needs J1939
For a light vehicle, a trailer module, an aftermarket controller or a conversion, 11-bit is simpler in
every direction:
- ID planning is trivial. You need a few IDs; the space is 2,048 wide, and the layout can be
blocked into a small readable range.
- Filters are simple on cheap controllers. Many small MCUs struggle with 32-bit extended filters.
- Tooling is friendlier. Handheld CAN analysers, serial-to-CAN bridges and the average workshop
scanner all handle 11-bit first-class.
- Bitrate is usually standard. 500 kbps is common on light vehicles; a TPMS node at that rate is
easy to place.
The cost is future compatibility: if the same fleet later moves to a J1939-based telematics platform,
someone has to translate. If that is likely, spend the extra day now and start on 29-bit.
The mistake that costs a week
Choosing the frame by the receiver instead of by the bus. The receiver is built with one interface
per unit, fixed at the factory — CAN is one of the options, and the frame format is part of that
configuration. So this has to be decided before the units are built, not adjusted at commissioning.
We have seen the failure mode twice: a technical package sent with a 29-bit DBC and an 11-bit reference
document, because both files were simply named "V1.9" and nobody checked the identifiers. The customer
opened them and found `0x18FDB1D8` in one and `0x111` in the other. If you are handed files, check the ID
range first:
| What you see | What it is |
|---|---|
| `0x111` … `0x122`-style short IDs | 11-bit standard frames |
| `0x18FDB1D8`, `0x18FDBxxx`-style long IDs | 29-bit extended frames (J1939-ish range) |
| File called "generic" or "universal" with no bit-width in the name | ⚠️ Verify, do not assume |
What to tell us, and what we send back
Four answers close the decision:
1. What is on the bus today — J1939, an OEM-specific 11-bit layout, or nothing yet.
2. Who consumes the data — your controller, a gateway, a telematics unit, a display.
3. How many wheel positions, and whether they group (axle-level) or need to be individual.
4. Bitrate, and whether the bus is busy enough that arbitration priority matters.
With those we reply with the interface configuration, the frame layout and, if the project needs one, a
DBC. That is the whole handover — the rest is your integration.
If you are unsure which frame your bus uses, a CAN log of ten seconds is enough to tell: look at the
identifier length. Send us the log and we will tell you which configuration to order.
See the industrial receiver configurations, the frame details on
the TR100 page, or the wider view on CAN bus TPMS integration.