The same ARINC 429 word is label 205 and label 241

Take the 32-bit word 0xE00640A1. Its label field — bits 1 through 8 — holds the bit pattern 10100001. Ask one decoder what the label is and it says 205. Ask another and it says 241. Both have the same eight bits in front of them, and neither is malfunctioning.

This costs people hours, because every instinct says one of the two must be a bug. It is not. The disagreement is in the documentation, and it does not resolve by reading more of it.

What is actually in dispute

Nothing about the wire. The sequence of ones and zeros a transmitter puts on the bus is the same under both readings. What differs is which end of the label field is called the most significant bit — and therefore what octal number those eight bits spell.

Read 10100001 with the MSB at bit 8 and you get octal 241. Read the same field with the MSB at bit 1 — that is, reverse it to 10000101 — and you get octal 205. One field, two numbers, no contradiction in the bits themselves.

Both conventions are published

MSB at bit 1. Holt's bit-mapping table for the HI-35850 annotates ARINC bit 1 as “Label (MSB)”. Holt and Wikipedia both give the same worked example:

Most software decoders you will meet do this, which is why it is the default here.

MSB at bit 8. The transmission order published by AIM, GE/Ballard and MaxT is bits 8, 7, 6, 5, 4, 3, 2, 1, then 9, 10, … 32 — label MSB first. Under that ordering the label octet reads directly as the octal number, with no reversal. GE's tabulated discrete word backs it up concretely: it spells out label 005 as bit 1 set and bit 3 set.

These are not two descriptions of one convention. They are two conventions, each internally consistent, each with worked examples in vendor documentation. Picking one because it appeared in more search results is guessing.

What everyone does agree on

It is worth being precise about how narrow the disagreement is, because it is easy to conclude the whole standard is unreliable. It is not.

The field layout is unanimous across AIM, GE, MaxT, Holt and Wikipedia: bits 1–8 label, 9–10 SDI, 11–29 data, 30–31 SSM, 32 parity. Parity is unanimous: odd, on bit 32 — GE states it as “if bits 1–31 contain an even number of 1 bits, bit 32 must be set to create ODD parity”. SSM index construction is unanimous. BNR negatives are two's complement in both AIM and GE.

One field's bit numbering is in dispute. Everything else lines up.

How to tell which one you need

Not by reasoning about it — by testing against something you already know. Two ways that work:

Use a label from your own ICD. If your interface document says a particular parameter is label 203, capture that word and decode it both ways. One reading gives 203; that is your convention. This is the reliable method, because it settles the question with your equipment rather than with someone's datasheet.

Decode a whole capture, not one word. A real bus carries a small set of labels repeating at fixed rates, not arbitrary values. Decode the entire capture both ways and compare each resulting set against the label list in your ICD — one reading will produce labels that are on the list and the other will produce labels that are not. A set is far more decisive than a single word, because a single word looks equally plausible either way.

Two things that do not work. Hoping an invalid label gives it away: reversing eight bits produces another eight-bit value, so both readings are always a legal three-digit octal label and there is no illegal case to catch the wrong convention. And assuming the tool that produced the capture and the tool reading it share a convention — they frequently do not, and neither will say so.

Why the decoder here shows both

Because the alternative is silently picking one, and a decoder that silently picks a side is worse than useless when the value does not match: you have no way to tell whether your word is wrong, your ICD is wrong, or the tool just numbers bits the other way.

So the bit order is a setting, and every decoded word carries the other reading next to the chosen one. 0xE00640A1 reports label 205 with the note that read the other way it is 241 — and the same word under the other setting reports 241 with 205 alongside. The builder does the same, so a word you construct can be checked against whichever numbering the receiving equipment uses.

The label-to-meaning tables are a separate matter and are deliberately not implemented. Those live in ARINC's paid specifications and in per-aircraft interface documents; a decoder that guesses at them would be plausibly wrong, which is the worst thing an engineering tool can be.