BiDiB, Communication over serial interfaces

The German version is the definitive specification. Any discrepancies between this translation and the original are unintentional.
BiDiB - Bidirectional Bus - Logo

Content

1. General

The intention of BiDiB protocol is to control a model railway. It allows the control of locomotives, accessories and safe transmission of feedback information from the model railway to the controlling computer.

BiDiB can be transported over different transmission media, framing and protection of messages is guaranteed.

The used terms and the basic principles will be explained in the general part of the protocol description. Hints for usage and the license can be found there too.

The following description shows how to use a serial link, i.e. RS232 or virtual COM-Port via USB.

2. Serial connection

2.1. Transmission parameter

Communication is made by a serial port with a variable baud rate from 19200 Baud, 115200 Baud or 1MBaud. Further parameters are 8 Data bits, 1 Stop bit, no Parity. (commonly known as "8N1"). The used baud rate must be determined from host during start-up by querying the system ID. Prefered baud rate is 1MBaud. Therefore, the host needs to test a maximum of 3 baud rate settings.

(Note for the baud rate: 1MBaud is working well on common USB-Uarts (i.e. FTDI) and on all modern microcontrollers. On older microcontrollers a suitable crystal (i.e. 16MHz) is necessary for 1MBaud)

CTS and RTS will be used. On both sides (Host and Interface) FiFo's have to be used in the design. After CTS-off up to 8 bytes can be still transferred.

There is no data communication at all after powering up and connecting to the BiDiB system. First, the system ID of the interface has to be read successfully (to check for the correct baud rate) and the transfer of spontaneous messages has to be enabled at the interface.

2.2. Framing, Data integrity

The serial data package looks like the following:

PACKET ::= MAGIC  MESSAGE_SEQ  CRC  [MAGIC]
MESSAGE_SEQ ::= ε | MESSAGE  MESSAGE_SEQ
MAGIC ::= 0xFE

A serial PACKET always starts with a special character ([MAGIC]=0xFE) and can contain one or more messages (MESSAGE). The whole package is protected by CRC (Cyclic Redundancy Check) to recognize data errors during transmission. MAGIC-characters within messages will be 'escaped'. For this, a ESCAPE character (=0xFD) will be insert and the following character will be XOR-linked with 0x20. The ESCAPE character itself will ve also escaped within the transmission. This means: Instead of MAGIC, an ESCAPE-character (=0xFD) followed by an MAGIC ^ 0x20 = 0xDE will be send. Instead of ESCAPE-character 0xFD + 0xDD will be send. Escaping is made at the complete coded PACKET including CRC (CRC is calculated over the whole message without MAGIC).

The MESSAGE is addressed from the host to a certain node. Inside the package, MESSAGES for different nodes can be integrated

CRC means the CRC8-Byte; On the transmitter side, the polynom x8 + x5 + x4 + 1 will be generated over the message, starting at the first byte from the message, Init=0, none inverted. On receiver side, the CRC with the same polynom will be generated over the whole message including CRC. The result must be 0.

Every data package is followed by an MAGIC, this can be also the start of the next package at the same time. If there is no package left for transmit, the MAGIC will be transmitted anyway. The receiver recognize that the message ends up, based on the MAGIC-character, and starts the CRC-check.

It's not allowed to transmit more characters then the maximum length capacity (MSG_PKT_CAPACITY) between 2 MAGIC-characters Escaping will be not counted in this case.

Under certain circumstances the MESSAGE field could be empty, in this case MAGIC 0x00 MAGIC (0x00 is an empty CRC) or MAGIC MAGIC will be transmitted.

2.3. Protocol

The system time is transmitted via MSG_LOCAL_SYNC messages if desired by the host. They are constantly sent in intervals of less than 32,3 s (which, assuming a 30ppm quartz in the node, yields a maximum drift of 1 ms during that timespan). The timestamp contained in the message refers to the end of the previous MAGIC character. This point in time often can be queried from the driver after declaring MAGIC as an event character.