Communication
Serial connection
BiDiBus
Network

BiDiBus Background Information

On this page, explanations for BiDiB standard can be found, this information will give a closer look to the functionality of BiDiB.

Is it possible to run locos manually without using a computer?

This issue was discussed intensively.

First off all, we have to clarify what means 'drive manually': This are also two different aspects: what means 'manually' and what means 'drive'?

This raises the question of which type of control-model you have in mind, and what role the user plays in it: Is he dispatcher, driver or shunter? Depending on the selected role, the interpretion of 'manual' and 'drive' might me different.

This is accompanied by the question of how to set the control-model: Is there a central point which holds all information or is the status information distributed?

Furthermore, it has to be considered what effects the control-model and information distribution on the bus system has. If there is no specification for the role of the operator, we have to communicate all messages globally or inform each subscriber separate inside the bus system about status changes of an node. In parallel, we need a method to check for changes in the user-focus that is able to represent new states. Both requires a quite large bandwidth on huge layouts but there is still the unresolved question of the logical combination of conditions (i.e. driveway, block securing).

In addition, there is still the issue of security to clarify: Based on which rules, a throttle or control panel may interfere in driving? There are quite different demands depending on the layout. There are small layouts with a single user who combines all functions in one person and this person is able to change its role rapidly. On the other hand there are club or exhibition facilities, where rules for accident-free operation are required.

BiDiB was developed primarily as an efficient transport medium from and to an central supervisory. This supervisory also defines the management model and the corresponding distribution of the information – what is shown on which control panel and where entries should be made. Unlike, a fairly complex model railway can not be managed or it's operating is highly restricted and subject to rigid rules.

Now there are also situations they actually not exists in the central supervisory (e.g. derailment, lost car). To solve such cases, a direct intervention in the control without any logical security is helpful.

For such situations, BiDiB mechanisms should be integrated that allows direct access to the track signal generators to intervene without any protection (low level).

A final note on this: 'drive manually' is often required also because the computer takes too long until he is ready to go. And there is no reason that the first bus-master is a well-equipped conventional command station (which is nothing more than a small computer too) which makes manual driving possible without the usage of a PC.

Why BiDiBus is based on RS485 and not CAN?

We also discussed CAN as a possible physical base. CAN provides, at a first glance a good arbitration system with dominant and recessive bits. CAN is used by OpenLCB, CBUS and S-9.5.1 (were candidates for nmranet, Summer 2010).

This scheme fits well with event-based buses and producer-consumer models, but is not suitable for addressable systems because the word length of CAN header is to short. Addressability is necessary to implement configuration and monitoring which means in fact reliability.

Where one calls addressability (long Unique-ID), it have to squeeze into the CAN: There are various proposals to generate the CAN ID from the Unique-ID for the current session. For example: Every single node calculates the CAN ID by hashing the own local UniqeID and sends them out in order to check if no other node "protests". If this way is used, we:

  1. lost the advantages of CAN and
  2. give away the possibility of being able to control the load specific bus-distribution.

That leaves CAN actually nothing more than the physics with its quick access (especially at low bus loads) to the bus medium.

Under heavy load, a CAN node can lock out low priority messages completely. There is no 'master' and nothing who is able to assign 'fair' priorities.

RS485 systems using a single master, multiple slave principle with cyclic polling of the slaves. This generates a low minimum latency even at low loads. This latency can be suppressed down to a single-digit millisecond range with some intelligence during polling and make it in fact irrelevant. At high loads or even temporary overload, a single-master system can slow down all nodes equally, in order to keep the basic functionality of the bus upright.

The fact, that a RS485-system (due to the single-master principle) must not perform a permanent collision check, the bus speed can be increased: At CAN, there must be a check within one bit if there was a collision: Assumed 16cm/ns (for e(r)=4) results in 2.4 microseconds for a forward and reflected wave on a 200m cable. At RS485, this time must not be considered for each bit but only if a poll has been sent to a node and checked if the node responds. Therefore the baud rate might be set higher until other limits and restriction appears (based on the fact that model railroad wiring is often not perfect).

If you take look at the implementation side, especially smaller, low pricing processors don't have a CAN controller implemented but a UART (for RS485) is always there. Even at the integrated circuits we have seen advantages for RS485: RS485 is industrial tested and many inexpensive devices from different manufacturers are available in the market, including fully-isolated versions. This is an argument for occupancy detectors, whose reference point is on a track potential and therefore they need always potential isolation at some point. Potential isolation directly at the RS485 bus is less expensive than the separation of each feedback section with single optocouplers.

Why the number of nodes is limited to 32 in a BiDiBus-segment?

From a BiDiB protocol view, the address is composed hierarchically, each bus segment is managed with an 8-bit address, so there are 255 addresses in one structure level (bus segment) possible. The transfer technology within a bus segment is freely selectable and RS485-based transmission is one possible implementation.

There are several compromises to make with this number of nodes on a structure level:

  • Power limitation:
    Each node that is feeded from the bus will draw power from the bus cable. CAT5 cable comes with 0.4 mm wire diameter, which results in a resistance of 3.5 ohms per 100m.
    It makes sense to restrict the power consumption to 30mA for each node, so you can easily feed a microcontroller with some accessories. With an acceptable voltage drop of 4V on the bus and the node current the result is 1A and therefore 32 nodes.
  • Speed limitation:
    BiDiB is designed for high speed, this includes a short latency time: At 32 nodes and a single poll command, with a total of 11 bits (start, 9N1) the resulting turnaround time is 1.7 ms. This means, messages of the parent node will be forwarded with a very low latency time because of the restriction to 32 nodes. And even if all nodes transmits in parallel with the maximum word length (that's the worst case, up to now there are no messages existing that exceeds the 64Byte limit), the turnaround time is 43ms.
  • Wiring:
    Model railroad wiring is often not properly designed – in terms of a continuous correctly matched impedance and unfavorable distribution of connection points (capacitive bus load). Therefore the restriction to 32 nodes provides some safety for the electrical design too.

Restrictions within a structure level is no problem for BiDiB: Levels can be (similar to USB hubs) easily extended and even with the restriction to 32 nodes and 3 levels, still 31.776 nodes can be addressed..

Considerations for choosing the right speed

BiDiBus is defined for 500kBaud. There are arguments for and against a faster or slower speed:

  • Freedom of wiring:
    If wiring is allowed to build up branched networks, we may have to deal with non terminated stub lines. Especially they are not avoidable at throttle connection points.
    Stubs are relatively easy to handle if the double electrical length are much smaller than the signal rise time. So you can decide for transmission speed or maximum permitted stub line length. Taking εr with 4, the result for 16cm/ns for a 5m stub line with a electrical length of 5/0,16*2 = 62ns. With the required transceivers, (slew rate-limit 200 ns) stable transmission conditions can be reached. Notes can also be found in: "Ten Ways To Bulletproof RS-485 Interfaces".
  • Availability of RS485 Transceivers:
    This type of transceivers are available from various manufacturers in both 5V and 3.3V versions.

Two waveforms for explaination (same bus was simulated in each example): 280m (918 feet) long, with multiple mismatched 5m branches, additional load capacitors and contact resistance, which is a quite realistic scenario:

Rise time 15ns
Visible reflections up to threshold level – not stable!		 Rise time 200ns
small reflections by wiring faults, but it's below threshold level.

Requirements for microtiming

  • The minimum waiting time of 2µs after the transmssion of the token was chosen as small as possible. After the transmitter of the bus master shuts off, only the the bias resistors and the wire capacity of the bus are in effect. The bus is not electrically driven for a very short time and will settle. This transient oscillation may lead to a 0 being picked up when the received is already active.
    In case of a toggle time of 0µs and the immediate activation of the master's receiver, this could cause the mistaken recognition of a start bit. The bus master therefore should not activate its receiver until 1-2µs past the disable of TX, and the node must not earlier than 2µs after the stop bit begin with its response.
  • In parallel to the specification of the minimal timing, a tight but still satisifiable even by 8 bit processors maximal time has been defined to cut down the idle times in the bus allocation.

Why ACK is a separate wire?

ACK is used by the track signal generator (command station) as an accelerated command confirmation and it's closely linked with the DCC signal. This command confirmation has the following key requirements:

  • Very small bandwidth from a maximum of 200 baud. Only one bit for each DCC command will be transmitted.
  • It does not require bus arbitration. This is already defined due to the time association with the DCC command, only the addressed decoder provides the ACK.
  • It must be very fast. Reason for this is the optimization of the track output. Typically, a DCC command station will be repeat commands several times and later on, the command will be send in the general refresh cycle. Repeats at the beginning must have at least another package between. If you would like to be able to skip the first repeat after a succesful acknowledge, the acknowledge must be arrived within the command between.
    Example: Loco LX will be new addressed.
    Command sequence without ACK: L1L2L3LXL4LXL5LXL6L7 L8L1L2and so on
     
    Command sequence with ACK: L1L2L3LXL4L5L6L7 L8L1L2L3and so on
    ACK for LX:     ⇑         
    It should be noted, that the ACK message must have also arrived at the software layer of the DCC output. Therefore, the ACK message may no longer delayed in software FiFo's or similar.

Achieving this low latency with a bus protocol is quite difficult, especially with connected bus bridges (Bridges + Gateway). And that's the reason why a access-free open-collector-ring was implemented (data to be transmitted is very small: about 200 baud)