Command Buses

	Home | Products | Distributors | Documentation & Support | DCC | CV Calculators | Links
What is DCC? Getting Started with DCC A Starter System Mobile Decoders Command Buses How DCC Systems Work Making Your Own DCC Components Decoder Installation	General The Command Bus or buses is (are) the infrastructure that ties together the components of a larger DCC system. With a smaller system you may not be aware that it is there; but most DCC systems are expandable. The command bus provides the means for expansion. The NMRA terminology defines two sorts of command bus: The cab bus connects throttles and other user input devices to the command station. This may be wired or it may permit wireless devices to access the bus too (for example infrared and radio throttles). A feedback bus allows points and sensors to report information back to the command station. This is useful for layout automation, where knowledge of train positions and track settings are needed. There are two Command Busses in common use: XpressNET (formerly XBus) and LocoNet. These are quite different from each other and are not interoperable. LocoNet LocoNet provides, through a single cable, both the cab bus and the feedback bus used by Digitrax systems. A simplified version of its specification can be found on the Digitrax page. LocoNet connects around the network using 6 core flat telephone wire and US style RJ12 6 pin telephone connectors. These are daisy chained or star wired as needed to make the set of connections required. To make access points for throttles to plug in, the user can either purchase UP-3 panels from Digitrax, or can make up her own connections using telephone sockets and wire. (These are harder to find in the UK but they are available from suppliers such as Farnell and Maplin). LocoNet is a carrier sensed, multiple access network with collision detection (CSMA/CD). That means that it behaves a lot like old-style coaxial ethernet: Carrier sensed - Devices must monitor the bus to decide it is "safe" to talk;  Multiple access - all devices share the same network segment i.e. all the traffic is visible to all devices; Only one device can talk at a time;  Collision Detection - Devices monitor the bus during talking to see if their message has been corrupted by another message; There is a priority based timing to allow "high priority" devices - e.g. track sensors - to report with higher priority than updates from throttles. If two devices try to talk at the same time, both messages are lost and both have to retry. This happens if they both try to start a message at the same instant and is typically a problem between devices of equal priority. Devices of different priorities - e.g. throttles & track sensors - should not cause collisions with each other. It is a characteristic of CSMA/CD networks that the rate of collisions increases if the network becomes loaded above 25 - 50% of theoretical capability. For good performance therefore we would want a loading in the 10-20% bracket. (note that modern switched ethernet with separate segments broken by switches is different because it breaks up the traffic - the performance of these systems is not relevant) Message Traffic Analysis A commonly asked message is "will the network cope with the loading my layout will impose on it". While there are a lot of reports from people with large layouts who say "yes of course it will", it is not difficult to answer this question scientifically. Firstly, note that messages are prioritised. This means that messages which need to get through more quickly than others can do so. Typically: Messages from handheld throttles are treated as lower priority, because the response time needed is related to how quickly the user can press buttons or turn knobs. Typically a response time of half a second would not be disastrous (generally it will be much faster than this). Messages from track sensors are higher priority, since the response time needed may depend on track distance and train speed. The priority mechanism is needed to minimise message collisions on the network. If a message cannot get through, its priority gradually increases. This means that messages that have been waiting longer are treated more urgently. Messages attributed to throttles and point position changes occur in practice at low rates. The throttles update their settings every few tens of seconds, and every time the speed knob is turned or a button pressed; two 4 byte messages will normally be generated to change one point. However the aggregate rate of these messages is normally quite small. If there are 15 locos in motion at one time, an average of one throttle change for each in a second would be excessive. The total message traffic is likely therefore to be low. There are many examples of layouts with many tens of operators concurrently controlling locos without problem. The number of messages caused by the track occupancy sensors is layout dependent. A large layout might expect 15-20 messages per second from track sensors. These messages are high priority and will gain access to LocoNet in preference to handheld throttles. Each sensor message takes the following amount of time: 1ms "dead time" since the last message on the bus;  a further priority based delay of 360-720us (this gets smaller if the device can't get onto the bus, making its priority higher if the messages has been waiting longer). Let's take the worst case 720us. 4 bytes of data at 600us per byte;  Total time on bus to send one message = 4.12ms, i.e. 243 sensor messages per second possible. So... 15-20 high priority sensor messages occupy 6-8% of bus bandwidth. This is small enough not to need to worry about. Because of the throttle messages having lower priority they would not normally cause packet collisions with sensor messages. You can be confident that Loconet will not be overloaded by packet density on even large layouts.  However.... It is my belief that LocoNet will have an upper limit on the number of devices plugged into it. This is because of electrical loading, not packet activity. The command station applies a 15mA current pullup to nominal 12V onto the LocoNet Data signal; The network will function if the network is loaded down to a voltage of about 5V;  Each LocoNet device is required to have an input impedance of > 47Kohms, and can therefore take a current of 0.1mA at the "minimum" voltage; 150 devices each with this input impedance will take the full 15mA available. This is a simple analysis that suggests that an upper limit of around 150 devices will apply. Digitrax point out that their devices all have a higher input impedance but the specification does allow 47Kohms. My understanding is that some very large railways have run into problems with this and have added additional current sources "pullups" to the Loconet to pull the level higher. My understanding is that this has been successful and a network with at least 300-400 devices should be viable without needed to go further. If that approach does eventually fail, then an electrical bridge between two segments may be necessary. Such a think is possible but as far as I'm aware, none yet exists. XpressNET XpressNET is the command bus used by Lenz and ZTC systems. It is a derivative of the older XBus system to which widespread reference is often made. It is different from LocoNet in several respects. The XpressNET specification is published on the Lenz web page. (To be completed!)
	©CML Electronics Limited 2008 Page Last Modified on: