Skip to content

Deciphering Low Level BiDiB Messages

Jump to bottom
Eugene edited this page Jan 10, 2020 · 13 revisions
  1. For a given BiDiB message, check its message type.
  2. Each message type has a particular message encoding.

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)

In summary, the servo could not be switched into its required position.

Example 2

A servo is connected to address 0x00 of a OneControl board (address 0x04) and the command 0x01 is sent to set the servo into the "normal" position. Suppose the servo was disconnected when the command is sent, and that we receive the following BiDiB feedback message:

Sep 24 16:55:47: Message bytes: 0x09 0x04 0x00 0x18 0xb8 0x00 0x01 0x02 0x01 0x11

We can break the message down:

  • MSG_LENGTH: 0x09 (9 bytes long, excluding this MSG_LENGTH byte)
  • MSG_ADDR: 0x04 0x00 (OneControl board)
  • MSG_NUM: 0x18 (monotonically increasing message index to check for lost messages)
  • MSG_TYPE: 0xb8 (MSG_ACCESSORY_STATE)
  • DATA: 0x00 0x01 0x02 0x01 0x11 (to be decoded)

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

  • ANUM: 0x00 (servo is at address 0x00)
  • ASPECT: 0x01 ("normal" position)
  • TOTAL: 0x02 (servo has 2 possible positions)
  • EXECUTE: 0x01 (bit 7 is 0, so normal operation with target state not reached; WAIT provides the cause)
  • WAIT: 0x11 (switch time of 1.7s)

In summary, the OneControl board is waiting for the servo to finish switching. Suppose a subsequent BiDiB feedback message is received about two seconds later (i.e., after the 1.7s switch time):

Sep 24 16:55:49: Message bytes: 0x09 0x04 0x00 0x1e 0xb8 0x00 0x01 0x02 0x80 0x06

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

We decode the data:

  • ANUM: 0x00 (servo is at address 0x00)
  • 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)

In summary, the initial feedback reported that the servo had not moved into position, and the subsequent feedback reported that the servo could not be switched to its required position.

Example 3

The occupancy of a track output (address 0x06) has changed. Suppose the following BiDiB notification message is received:

0x08 0x00 0xda 0xa3 0x06 0x02 0x00 0x01 0x80

We can break this message down:

  • MSG_LENGTH: 0x08 (8 bytes long, excluding this MSG_LENGTH byte)
  • MSG_ADDR: 0x00 (GBMboost Master board)
  • MSG_NUM: 0xda (monotonically increasing message index to check for lost messages)
  • MSG_TYPE: 0xa3 (MSG_BM_ADDRESS)
  • DATA: 0x06 0x02 0x00 0x01 0x80 (to be decoded)

The data can be decoded by looking at Occupancy Detection (4.7.4. Uplink: Messages for occupancy detectors):

  • MNUM: 0x06 (track segment with address 0x06)
  • ADDR_L ADDR_H: 0x02 0x00 (address of first train is 0x02, orientated to the left)
  • ADDR_L ADDR_H: 0x01 0x80 (address of second train is 0x01, orientated to the right)

In summary, two trains (addresses 0x01 and 0x02) are now on track segment 0x06.

Clone this wiki locally