Deciphering Low Level BiDiB Messages

1. For a given BiDiB message, check its message type.

• The general structure of a BiDiB message is described in the BiDiB protocol description.
• Once you have identified the byte for the message type, check bidib_messages.h for its encoded name.

2. Each message type has a particular message encoding.

• The message encoding is described in the BiDiB protocol description.

Example 1

A servo is connected to address 0x0a of a OneControl board (address 0x01) and the command 0x01 is sent to set the servo into the "normal" position. Suppose we receive the following BiDiB error message:

SWTbahn error message queue: 0x09 0x01 0x00 0x0f 0xb8 0x0a 0x01 0x02 0x80 0x06

We can break the message down:

• MSG_LENGTH: 0x09 (9 bytes long, excluding this MSG_LENGTH byte)
• MSG_ADDR: 0x01 0x00 (OneControl board; last byte of MSG_ADDR is always 0x00)
• MSG_NUM: 0x0f (monotonically increasing message index to check for lost messages)
• MSG_TYPE: 0xb8 (MSG_ACCESSORY_STATE)
• DATA: 0x0a 0x01 0x02 0x80 0x06 (to be decoded)

The data can be decoded by looking at Accessory Control (4.6.4. Uplink: Messages for accessory functions):

• ANUM: 0x0a (servo is at address 0x0a)
• ASPECT: 0x01 ("normal" position)
• TOTAL: 0x02 (servo has 2 possible positions)
• EXECUTE: 0x80 (bit 7 is 1, so an error has occurred; WAIT provides the cause)
• WAIT: 0x06 (feedback error)

Example 2

One can see the single bytes of the BM_ADDRESS message, which lead to the log messages that train cargo entered segment 6: - 0xa3: message type (BM_ADDRESS) - 0x06: segment number - 0x02 and 0x00: first train address - 0x01 and 0x80: second train address So there are really both addresses reported by the BiDiB system.