Communication

• Summary

Serial connection

• Specification

BiDiBus

• Specification
• Background information

Network

• Specification
• Background information

BiDiBus, a Highspeed-Bus for model-railways, occupancy detectors and DCC-BiDi

Content

• 1. General
  • 1.1. Objective target, unique properties
  • 1.2. Legal environment, License
  • 1.3. Revisions
  • 1.4. Glossary
• 2. Electrical, mechanical parameter
  • 2.1. Wiring
  • 2.2. Rules for bus subscribers:
• 3. Bus timing
  • 3.1. Microtiming
  • 3.2. Macrotiming
• 4. Bus protocol
  • 4.1. General Requirements
  • 4.2. Bus assignment, interface messages
  • 4.3. Addressing, Broadcast
  • 4.4. Logon procedure
  • 4.5. Bus behaviour in special cases
  • 4.6. system time

1. General

1.1. Objective target, unique properties

Classic model train and bus protocols such as S88, RS-bus, Xpressnet® or LocoNet® often reach their limits when it comes to bus access, data security and noise immunity with an increasing digitalization of the layout. Together with the BiDiB protocol, the following bus system was created, which is a significant step forward in comparison of the classic bus protocols above. BiDiBus combines a data connection for BiDiB with a layout-wide distribution of the track signal, command confirmation of the track signal and power over BidiBus. This bus can represent a segment of an BiDiB system within an entire system. BiDiB segments can also be connected in a tree shape through hub modules.

• High speed of 500kBaud.
• Secure transmission with checksum.
• Dynamic adjustment of the bus assignment for lowest latency.
• Free wiring without bus addresses or DIP switches, easy configuration (Plug & Play).
• Maximum of 200m bus length per segment, short stub lines are allowed.
• Maximum bus devices: > 1000, (max. 32 for each segment)

1.2. Legal environment, License

BiDiB protocol and the physical connection BiDiBus is intended for use with a model railroad control software and can be implemented without any license fees on both the PC side as well as on the hardware side. To ensure compatibility, the following license terms apply:

• The general licence conditions of BiDiB shall be applied. See general protocol description

Additionally, following terms apply

• At least 2 assemblies have to be provided to the BiDiB working group in order to test the compatibility. Measurement results, scope prints and inspection records must be provided on request. In case of compatibility problems, the implementation must be disclosed.
  When problems can't be solved in the above described way, a call up or meeting with all participants should be proceeded in order to find the root cause of the problem.
• The BiDiB logo may be used only with the explicit permission of the BiDiB working group. Even this limitation is primarily to ensure the compatibility and not to block competitors
• Connectors (plugs, jacks) according to the BiDiB standard must be marked with the logo (<<BiDiB>>).

1.3. Revisions

This document describes BiDiBus revision 0.12 from 23 March 2016. This revision is stable and tested.

1.4. Glossary

The following terms for each protocol participant or properties will be used at this document:

2. Electrical, mechanical parameter

2.1. Wiring

Data medium RJ45 (CAT5) is used for BiDiB. The ground shield has to be connected and through wired at each node. The transmission takes place in RS485 standard with 500kBaud.

Wiring rules: The bus must be routed straight and the maximum cable length is 200m. The cable must be terminated with 120 ohm at both ends. For this purpose, a termination resistor must be provided and the schematic must be designed with the option to enable or disable this resistor (see below). A maximum of 8 branched lines is allowed at not terminated lines. (Stubs). The maximum length of these stubs is 4m. At least 30cm cable must be installed between two adjacent nodes.

This wiring rules guarantees a safe operation. Anyway, the bus can be operated safely up to 500m if the the wiring installation is clean (cable and plug quality) and correct installed, specially impedance correct.

BiDiBus uses the following wiring diagram:

Explanations:

DATA_RS485+, DATA_RS485-:

DATA_RS485+ means the non-inverting output of the RS485 driver (EIA-485 called it the 'B', but commonly the pin is described with A in the most datasheets).

This wire should be idle if DATA_RS485+ > DATA_RS485-. Status IDLE means an H-level on TX or RX at the serial connection to the processor.

VCC:

The bus is powered preferred by the interface with a line voltage between 9V and 13V DC. Power feeding must be done over a serial connected diode plus a self-resetting fuse. Maximum feeding current is 1A. A node which is feeding 12V into the bus has to be labeled with the maximum current at the plug.

Each node can draw a maximum current of 30mA out of the bus plus the additional current which arises through active transmission. (typically 40mA = 2,4V at 60 Ohm). the power consumption of the node must be stated in the datasheet. In case the power consumption is higher, the node must be feeded from a separate power supply.

If the power for a node is taken from the bus, a safety resistor of 22 Ohm and a polarity protection diode (in serial to the resistor) must be connected in the VCC line.

In case the wiring exceeds 100m, a second power infeed may be required. The maximum DC bus load should not be used.

It is recommended that the interface provide a control measurement for voltage and current.

DCC_RS485+, DCC_RS485-:

The DCC-line pair is used for synchronous distribution of the track signal to multiple Booster assemblies. The DCC signal on the bus is always differential, it contains no cutout. The track outputs of a booster have to be marked with '+' (or 'P') and '-' (or 'N'). If DCC_RS485+ > DCC_RS485+, the '+' or 'P' labeled track output must have a higher potential than the '-' or 'N' labeled output.

The allowed delay time of the track output signal over RS485 line is 0µs to 5µs.

DCC_RS485+ should have a higher polarity in the first half of a DCC bit than DCC_RS485-, this means the DCC signal starts with a rising edge.

DCC signal is intended for distribution to booster assemblies and not for control of bus subscribers.

A bus node, which acts as interface must amplify the DCC signal for its own bus system. A maximum latency of 50ns (typical gate delay) is allowed.

The feature FEATURE_GEN_DRIVE_BUS determines whether a node sends or receives on the DCC lines. It is not allowed to have more than one sending. default setting:

• Interfaces have a value of 1 on this feature and are controlling the DCC lines of their (sub-)system.
• Regular nodes have a value of 0 on this feature and are receiving.

ACK:

Open collector ring for command confirmation at the DCC bus and for booster control. The ACK line is pulled up with a current source of around 5mA..10mA to VCC at the interface (usually a 1k pull up resistor). Each subscriber can pull the ACK line to Low through a resistor of 22 ohm. ACK is considered to be active (low) when the level of the ACK line is below 0.8V.

The ACK sends two information:

• DCC command confirmation: A low-pulse on the ACK after the DCC telegram signals that the loco/accessories decoder confirmed the previous command of the DCC telegram (recognized and executed).
  This allows the optimization of the signal output at the central station, possibly planned repeats of the DCC command can be saved. In this way, a significant increase of theiroughput can be reached in a DCC system.
  Following timing definitions are related to end of the endbit of the DCC telegram. Typically, there is a cutout (464us) followed by the preamble bits of the next telegram. The timing values are choosen to allow the sampling of the ACK in the command station during the transmission of the next dcc 0-bit.

  Timing ACK pulse (from end of DCC telegram)

  	min:	max:
  Start:	0us	1400us
  End:	2500us	4000us
  Evaluation:	1750us	2450us

• Booster-Emergency-Stop: If ACK is pulled to low for more than 10 ms, a command station assembly must be switch off. Status off becomes permanently preserved until it is canceled by a system command.
  Booster assemblies should be turn off if there is no edge change detected at the DCC signal for longer then 15ms. On recovery of the DCC signal at the input, the booster should switch on automatically if ACK is high. This applies even if it has been switched off by ACK. This allows a synchronously start-up for all installed boosters through a simple interruption of the DCC signal after an emergency shutdown.

reserved:

This wire has to be connect 1:1 at each bus node.

Voltage levels:

All nodes are tied to the same potential (GND), this is also the reference for the track signal (DCC). Booster drive DCC at levels between GND and supply. If railcom-cutout is enabled, this cutout is created at the low side.
Compensation currents across booster domains (when a car travels from one domain to another) should be carried with an additional GND wire (at the power supply).

Example schematics:

Simple interface without DCC outcoupling. The voltage regulator for the RS485 driver is not shown. It should be noted that in case of malfunction or reset of the node, the bus can not be driven and it's recommended to provide a pulldown resistor at BIDIB_DIR.

2.2. Rules for bus subscribers:

Each installed bus subscriber must provide two fixed RJ45 plugs to allow the loopthrough of the bus.

A switchable 120 Ohm termination resistor has to be provided. The disabling of this resistor mechanical/electrical has to be designed prefereable in a way that the termination will be off in case both cables are plugged. If termination ist switchable by means of a jumper, this jumper should be labelled 'TERM'.

Biasing (see below) is only allowed at the interface. The typical power dissipation of about 125mW (maximum 250mW) has to be observed.

Only transceiver chips which comply with the following specifications are allowed. The data sheet of the transceiver chip, the clock accuracy and the validation data for micro timing must be disclosed on demand.

A protection of the transceiver with a TVS diode (transient voltage suppressor) is recommended (e.g. Semtech SM712, SOT23).

Rise time (slew rate):

Here, a lower limit of 200 ns is defined. This corresponds to the 200mV minimum sensitivity of the receiver with a slew rate of > 1µs/V. Well, this makes it possible to avoid reflections on not terminated, short stub lines.

Clock accuracy:

To ensure error free reception of messages, following tolerances of baud rates are acceptable:

Specification baud rate BiDiBus

Baud rate:	>500kBaud
Error (Interface):	< 200ppm
Error (Node):	< 1%

Identification:

Every subscriber must have the possibility to trigger a so-called identification. This is preferably a button, labeled with IDENTIFY. Each subscriber must be able to display the identify state clearly, for example, by a rapidly flashing LED.

Special rules for Interfaces:

For an interface, only one fixed RJ45 plug for connecting the bus is sufficient.

An interface must monitor its own controlled bus and establish predetermined voltages (Biasing). The predetermined voltages are created with a 1.5kOhm resistor from A to VCC and 1.5kOhm resistor from B to GND.

Special Rules for hubs:

Hubs expand the protocal area to a further structure. Here it might be necessary to disconnect wires and therefore the validity ranges for DCC and ACK. For this case, bus hubs must be able to disconnect this wires.

Special Rules for branching points:

Modules that have more than two plugs (e.g. for connecting handheld throttles via a stub) must label these additional plugs explicitly.

3. Bus timing

The bus is operated in half duplex mode, which means the data on the bus will be transmitted as serial UART-data with the parameters 500kBaud, 9 bits, no Parity, one stop bit (also commonly known as 9N1).

A maximum of 32 bus subscribers are allowed on each level.

3.1. Microtiming

Normal operation:

The interface controls the bus assignment and grant send permissions to the individual nodes. For this purpose a poll command which consists 9 Bits is used. 8 Bits are low and the last Bit is high (frame identifier). After transmitting of the poll command, the transmitter of the interface is shall shut down not later than 1µs after the stop bit timeout. The interface shall enable its receiver not later than 2µs after the stopbit. It is recommended to keep a gap of 1µs between shut down of the transmitter an enable of the receiver to suppress errorneous reception of a floating bus line. (This rule of fast shutdown applies only to the interface but not for nodes. This makes it easier for the node to keep the correct timing.)

A bus node, which is assigned to the bus may not start with his own startbit before 2µs after the end of the stop bit from the poll command and latest 20µs after the stop bit. A node must perform its data transmission without gaps and need to shut down its own transmitter within 5µs after the transfer of the stop bit which is send after the last character. The interface sends out that next poll command earliest 10µs after the stop bit of the last received message. It is allowed, that the interface takes a longer break.

If a message from a node (for error reasons) stops before reaching the announced number of characters, the node is assumed to be 'broken' after 50µs and will be not addressed any more.

Logon procedure:

During the logon process it might be possible that there collision of messages from different nodes occur. In order to avoid them as good as possible, different rules apply when answering logon commands:

A bus node that responds to a login command may answer at the earliest after a delay time NODE_CA_TIME. NODE_CA_TIME is a time in the range of 2 to 34µs. Each node must individually calculate this time from its unique ID. Before the response is actually sent, the entire time range NODE_CA_TIME has to be monitored for activity at the bus. If there is a 'MARK' detected (i.e. another node is already transmitting a response to the logon command), then the transmission of the own response may not be started.

(NODE_CA_TIME: CA=Collision Avoidance, time interval for collision avoidance)

3.2. Macrotiming

A bus subscriber must answer a (any) ping or poll command of the interface within the 'bus timeout' time. Permissible response is any meaningful data transfer or even a blank message. A bus node that sends no response within the 'bus timout' will be removed from the active list.

A bus subscriber which was not actively addressed or pinged since the 'bus timeout', has to be regarded as disconnected, and must re-logon.

4. Bus protocol

4.1. General Requirements

The interface gives transmit permissions to a bus subscriber through the poll command. This also applies to the interface itself - it has the fixed local address 0 and 'issue' the transmit permission by itself through the poll command.

Within the bus, BiDiB is used as the protocol. The following message structure is mandatory:

BIDIBUS_PKT ::= P_LENGTH  MESSAGE_SEQ  CRC
MESSAGE_SEQ ::= ε | MESSAGE  MESSAGE_SEQ

A BIDIBUS_PKT contains a MESSAGE_SEQ, begins with a length field and is protected by a CRC field. MESSAGE_SEQ comprises zero (in exceptional cases), one or more MESSAGEs (see BiDiB message structure), therefore a node can combine multiple messages in one response. This property is particularly important for interfaces, which summarize messages of a separate bus structures and transmit it further in 'one block'. Also feedback detectors benefit from this function as they can transmit occupancy states summarized to the host if they are powered on the first time.

P_LENGTH specifies the packet size in bytes. This is the length of MESSAGE_SEQ, P_LENGTH and CRC is not counted.

CRC designates the CRC8 byte. At the transmitter side, the polynomial x⁸ + x⁵ + x⁴ + 1 will be generated over the packet (i.e. length, message(s)) starting at P_Length, init=0, none inverted. At the receiver side, the CRC will be calculated with the same polynomial over the packet but including CRC, the result must be 0.

Inside the message there is a address included, this address may consists one or more bytes. If the message comes directly from a node, then the address is 0. The local address of the node will be added in the interface. Is the message coming from a sub node, the address bar begins with the local address on the sub structure. The interface adds the address field behind the local address.

4.2. Bus assignment, interface messages

The interface controls its bus via bus commands. There are commands for local management (system commands) and also for bus assignment and for normal data transmission (poll commands). Bus commands have nine data bits and will be sent from the interface, the MSB (9th bit) is high (set).

• System commands:

  SYSTEM ::= (SYS_MSG + 0x40 + PARITY * 128)
  SYS_MSG ::= 0x00 | … | 0x3F
  PARITY ::= (XOR(SYS_MSG) ^ 1)

  In a system command (= SYS_MSG) the bit number 6 is set (0x40) and the type of system command will be encoded in the lower 6 bits.

  • 0x3F: reserved

    This command is reserved and not used. Reason: Results in slightly wrong detection.

  • 0x3E: BIDIBUS_LOGON (logon prompts)

    The interface periodically sends a login prompt. If no further logon prompts has taken place after 64 consecutive logon prompts, then the interface assumes that the first logon was made and reports NODETAB available to the host.

    A client who wants to logon, responds with a package to a BIDIBUS_LOGON. This package contains a single message with MNUM 0 and the following structure. Specific rules to reduce possible bus collisions has to be observed thereby (see below).

    P_LENGTH M_LENGTH 0x00 0x00 MSG_LOCAL_LOGON UNIQUE_ID CRC8

    Here UNIQUE_ID length is 7 bytes, this results in M_LENGTH of 10 and P_LENGTH of 11. Address and MNUM is 0 in this case. The systematic structure of the logon message is identical to the normal messages.

  • 0x3D: BIDIBUS_BUSY

    The interface can't currently accept messages (e.g. the transmission to the host is overloaded or blocked). Anyway, the nodes will be still notified of the activity from the interface in order to prevent a logout from the bus. A node does not respond to BIDIBUS_BUSY.

  • 0x00 … 0x3C: reserved
• poll command:

  POLL ::= (NODE_ADDR + 0x00 + PARITY * 128)
  NODE_ADDR ::= 0x00 | … | 0x3F
  PARITY ::= XOR(NODE_ADDR)

  A poll command consists the node address (maximum 6 bits) and the parity bit. Parity will be generated by XOR over bit 0…6 and inserted as bit 7. The byte (Bit 0…7) have even parity.

  After a poll command, only the node whose address is equal to the transmitted NODE_ADDR is allowed to send a message.

  The message of the node consists of:

  BIDIBUS_PKT ::= P_LENGTH  MESSAGE_SEQ  CRC

  In case the node doesn't want to send a message, it sends just a single byte P_LENGTH (ping function), no payload and no CRC. As content for P_LENGTH 0, 1, 2 or 3 are allowed. (note: minimum P_LENGTH of a regular package is 4.)

  P_LENGTH	Definition
  0	NODE_READY: Node is online and ready for receiving messages.
  1	NODE_BUSY: Node is online but not ready for receiving messages.
  2	reserved.
  3	reserved.
  4…64	Node transmits a message sequence, followed by additional bytes.
  65…127	reserved.
  128…255	MSB reserved for length extension.

  A packet may have up to 64 bytes of payload, every receiver allot enough memory to be able to handle this. Longer message sequences need to be split apart and spread to multiple packets.

4.3. Addressing, Broadcast

Downstream:

The interface sends data with preceded poll command to address 0. The destination address of the message is the first byte in the address field of the message. Within a packet from the interface, it may happen that messages for various nodes are included. The nodes must therefore decode messages from the interface and check whether they are addressed to them or not.

Broadcast:

Is the local address of a message is empty (i.e. only the closing 0 is present), then this message is a broadcast. Broadcasts will not be acknowledged on the BiDiBus and they are provided for 'minor' messages such as "time of day" or for testing and debugging purposes such as emergency operation or a switch operation ignoring route locks.

Upstream:

The interface transmits a poll command to all registered nodes. The contained address inside the poll command is also the first byte of the message address, if this message is then passed up in the interface. This means, the address field of the message contains 0 (if this message comes from the addressed node itself) or from the address stack of sub nodes.

4.4. Logon procedure

The interface sends a login prompt periodically (as a system message), this request goes to all the nodes in this level.

All idle nodes may (and should) answer to this login prompt. Special timing rules are existing for login prompt answers.

Now, three different cases can occur:

• no node sends a reply: there is no further action from the interface, it will continue to send periodic logon prompts (BIDIBUS_LOGON).
• exactly one node sends a reply: The interface detects it's with the fact that the message of the node has been received error-free. This process is protected by the fact that the unique ID of the node will be transmitted within this message. It confirms the node logon and assigns a NODE_ADDR. This is done with a broadcasted MSG_LOCAL_LOGON_ACK. The node can only take over the NODE_ADDR from MSG_LOCAL_LOGON_ACK if the transmitted UNIQUEID matches its own.
  The host will finally verify the correct acquisition by a query (via the normal command structure) of the node UNIQUEID.
• multiple nodes reply simultaneously: it results in a collision, the response to the logon message is wrong. There is no assignment to a NODE_ADDR.
  • The interface sends no acknowledge and continues to send periodic logon prompts.
  • The node gets no logon confirmation. He responds no longer to logon prompts for a certain time (called backoff). The number of ignored logon prompts is determined by a random number which includes also the unique ID in the start condition. This random number will increase with each failed logon attempt to a (specific) maximum value (=63). The algorithm for this purpose is shown in the sample code.

If for any reason a LOGON from a node is not processible by the interface (and this condition may be permanent), then the interface broadcasts a MSG_LOCAL_LOGON_REJECTED message with the Unique-ID of this node. The addressed node should display an error condition and should stop further logon attempts. Only one additional attempt (after a timeout of 2s) is allowed.

There is still a special case during power up: To avoid that all nodes responds on the first logon prompt, each node may have a (derived from the unique ID, random) separate delay time of 50…200ms after the power-up message of the interface. The time delay at logon is also important to avoid multiple logons in case of hotplugging (and multiple start due to contact bouncing).

Also, the first value for backoff must be determined as random value within a range of 1…63.

4.5. Bus behaviour in special cases

For irregular transactions on the bus, the following behaviours has been defined:

• If the host can't fetch any messages from the interface (data jam), the interface does not poll the nodes any longer and prevents itself from receiving more messages that he can't send further. The local ping keeps running.
• It's the discretion of the interface how to priorize the poll commands. But the interface should avoid sending directly a poll command to these node which was actual the current destination of the message.
• The correct timing sequence of messages is guaranteed only to one end node.

4.6. system time

For the system time synchronisation, the interface regularly sends MSG_LOCAL_SYNC broadcast messages. The timestamp contained therein refers to the end of the poll command (after the stop bit). An interface that supports BiDiB system time has to send such MSG_LOCAL_SYNC messages at least once every 32 s (2¹⁵ms); thereby nodes with typical quartzes (deviation ≤30 ppm) are still supplied often enough. Furthermore it should be minded to do a synchronisation of new nodes right after their logon.