I think I have an understanding of the differences between the types of ARINC word formats, but would just like to get some input to see if my understanding is correct. In the ARINC 429 specification, it is discussed that there are some differences in how messages are handled between the two formats.

Data Field

This one just seems like basic arithmetic concepts and doesn't concern me as much. From what I understand, the BCD data-field works the following way:

Data-Field = 0x12340, means that the data is actually 12,340 (twelve thousand, three-hundred-forty) in base-10.

Then, BNR data-field would work like:

Data-Field = 0x7FD1C, means that the data is actually -740 (based on two's complement arithmetic).

Sign-Status Matrix Field

The operational codes just mean different things. Or in other words, the code numbers are the same, but the codes themselves have different meanings for BCD messages than BNR ones. Now, if there aren't any other differences, I would also like to know why the op-code schemes are slightly different.

My Question

So, I guess in a single sentence my question would be: are these the only differences between the types of ARINC messages?


2 Answers 2


Your basic decoding strategy looks correct -I didn't double-check the values, but the logic is sound. Note, however, that the difference of BCD vs two's-complement is not the only difference between BNR and BCD (and Discrete labels, which are also common). Binary-coded decimal (BCD) and binary (BNR) labels generally do decode as you have shown, but the Sign-Status Matrix (SSM) plays a large part in interpreting that data and using it is not optional.

For BCD labels, the SSM informs whether the data is positive or negative (or what direction is points), hence "Plus, North, East, Right, To, Above" vs "Minus, South, West, From, Below". It also informs if the data is invalid ("No Computed Data"). BNR labels include sign information already in the two's-complement encoding, so duplicating that information into the SSM would waste valuable bandwidth. The SSM still informs you of invalid data, but can also inform of (non-)operation in reversionary mode ("Failure Warning") or correct behavior ("Normal Operation").

What that of that means for a given LRU (line-replacable unit)1 can be completely different from any other LRU. To have any confidence in your interpretation of a label, you must obtain a hardware integration guide for the specific LRU in question to determine what format data is or must be provided in and what the SSM values imply. This integration guide is a separate document from any user or maintenance manual you may have received with an LRU for installation into an aircraft. It is usually only provided to original equipment manufacturers of other LRUs.

For example, a BNR label might still contain a readable value when the SSM is set to "Failure Warning", but whether or not you can still use that data depends on what the failure implies for the particular LRU. I once encountered an LRU that provided a label for barometric altitude that reverted to GPS height above ellipsoid when failure mode was set. This change in represented value was not appreciated at the time, but did teach me to always inspect the SSM first before believing any particular value. Furthermore, many BNR labels are also scaled by some arbitrary factor to provide a wider range of representable values. The scale factor is provided in the integration guide, and is usually a fixed value, but I have encountered some labels with values scaled by values from other labels.

The format for Discrete labels is always specific to the LRU. To know what this encoding is, you must have the integration guide.

Ultimately the difference between each particular ARINC429 label will depend on the specific equipment to which you are interfacing. The standard data types (BNR/BCD/Discrete) provide a rough idea of how the data is packaged, but the integration guide is the authoritative source for data encoding.

1: I use LRU as shorthand to mean any ARINC429 node. In practice, many ARINC429-compatible devices are not necessarily line-replacable.

  • $\begingroup$ Would there ever be an instance where the SSM is used as space for the data field (when in BCD) similarly to how this is done for the BNR-formatted numbers? $\endgroup$
    – Snoop
    Commented Jul 5, 2016 at 11:23
  • 1
    $\begingroup$ I have never encountered a BCD label which overrode the SSM for use as additional data space. I would strongly suspect that any device which needs more data space in a new revision to change a BCD label to a BNR label rather than extend the BCD. This change would provide a much larger boost to available encoding space. That said, there may still be a device manufacturer that has elected to use a non-standard BCD label in stead. Any such exceptions should be well-documented in the integration guide. $\endgroup$ Commented Jul 5, 2016 at 13:17
  • $\begingroup$ I pretty much had that inclination, and know for a fact that BNR is sometimes overriding the SSM. $\endgroup$
    – Snoop
    Commented Jul 5, 2016 at 13:56

As you may notice from this spec tutorial or this errata report, the two bits that serve as a "sign-status" field for BCD data show only status, not sign, for BNR data. The status codes for BNR data include a "failure warning" code; it is not necessary to signal a failure warning in the sign-status matrix of BCD data because the individual digits can be set to 1111 (four consecutive 1s) in order to indicate that the values are unreliable.

Also, when latitude and longitude are encoded to 0.1 minute in BCD format, a different BCD format than usual must be used. See the commentary in section 2.1.2 of the errata report. The positions of each digit's encoding are moved 2 bits so that the first digit has maximum value 1 instead of 7, and bits 9 and 10 are used for data.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .