Control Bus

Summary

As a summary of my latest post, I was explaining there are several digital communication systems to send orders to trains (DCC, Selectrix, Motorola,...). All them are based in a Central Station that, with the help of a Booster, modules the electric current to send commands to the mobile decoders installed inside the locomotives. But DCC is by far the most common and widely used at least in N gauge, despite it isn't the best nor the most versatile.

Later we saw, because of the lacks of functionality of DCC, new feedback buses used to send back information to the Central Station from the Feedback Modules. An example of those buses are RailCom and  S88, but nowadays they are completely old-fashioned.

And before talking about the different elements that compose a digital layout, I think is mandatory to talk about the Control Buses. The election of the Control Bus is the key for a new installation. It acts as a backbone or central nerve system interconnecting all components together. That means, all components must be compatible with the Control Bus. So it's a restrictive selection and it will restrict us in the range of digital components that we can connect to the layout.

Distinct buses used in model railroading

Everybody jumps into digital world buying first of all the Central Station, but most people select it taking into account just visual characteristics like how many throttles it has, or if it has color screen, or tactile, ... when all this things (throttles and panel screens) are not really part of a Central Station. Also functions like the possibility of creating routes or move trains in an automatic way are evaluated, when again those functionalities shouldn't be in charge of the Central Station. The better approach for me would be to evaluate the compatibility with the different buses in the market, and therefore with the existing software and electronic components like feedback modules, output modules, servo management modules, sound modules, ... of course other characteristics like how many locomotives can drive at the same time or the current power should be also evaluated.

What is a Bus?

But before that, what is a Bus? Taking the definition from wikipedia: "a bus (from the Latin omnibus, meaning 'for all') is a communication system that transfers data between components inside a computer, or between computers. This expression covers all related hardware components (wire, optical fiber, etc.) and software, including communication protocols."

It means a Bus specifications covers and explains not only the physical medium used (cable, radio, WiFi, fiber optics, ...), type of connectors (USB, microUSB, SubD9, RJ12, ...), supported topologies..., but also the communication protocol, message formats, type of commands available and everything referred to the software and programming part.

Keys to select a Bus

There are dozens of distinct Bus in the market, and many manufacturers designed its own bus like an industrial secret, without sharing the specifications so only they can build peripherals and modules and become your only possible supplier, setting the prices they want. Of course these are the ones we have to avoid first.

Second, there are also other kind of Bus being created openly by groups of users, completely the opposite example than before. But in many cases all the hardware must be constructed by our own so you need a deep knowledge of soldering, isolating boards, electronics and programming. Usually it's a cheap but very complicated solution.

And the third big group of Bus we have to avid are those based in old-fashioned technology. As I see it, any kind of bus not based in a Peer to Peer architecture (see Peer to Peer information). In this kind of architectures or topologies Peer to Peer (more known as Networks, better than Bus) doesn't exist the figure of "master component" and "slave component", so all at the same time can send and receive information, produce or consume information, or be "master" and "slave" at the same time. The way of connecting the components (topology) is normally also very flexible:

So despite the communications with locomotives will be for sure DCC, the connection and dialog with the rest of components of the layour (PC, outputs, feedback modules, sound, lighting, ...) will be done through the Bus. That's why is so important the bus election over the central station, throttle or any other component.

My suggestion

I don't want to finish just here, without any specific advise or Bus recommendation. I know it's a personal election based in many factors like our skills (are we able to construct our electronic components?), likes (do we want to program our modules) and of course budget. But if I have to recommend a bus not knowing the particularities of a person I would suggest Loconet by far because it has all this characteristics:

• It's a Peer to Peer type Bus
• Very flexible form the topology side, it can be connected very simple in line, or using hubs and combine star and tree. 
• The Bus is property of one manufacturer (Digitrax), but on the other hand specifications are public. Everybody can access to them and build and program they own modules and devices.
• Supporte by multiple manufacturers. You are not restricted to Digitrax, also Uhlenbrok, Digikeyjs, Fleischmann, ...) make central stations, modules, throttles and all kind of devices for Loconet. 
• DIY (Do-it-yourself) possible. If you like to program, and/or build and/or solder your own electronics, there's plenty of information to make your own digital system's components and shops to buy pre-made boards.
• Arduino compatible. For me that's a personal must. It exists a Loconet shield called GCA185 that you can build or buy here, done by Giling Computer Applications. With this you can easily program your own throttles, fast clocks, outputs/input modules, sound modules, .... whatever!!!!

I don't want to state Loconet is the best option, just my recommendation knowing no details about the final user. That's the option I have despite if I would start again from scratch, may be I would choose C-BUS because I like to construct all my electronics.

But as I want this to be usefull, from now on I will talk just about DCC and Loconet combined, which seems the best option at least in a short/medium term.

History of Digital Systems

I would like to write some useful articles for those who want to step into the digital world of model railroading. It's not my intention to create the ultimate guide to digital systems, nor to cover all technical aspects and all kind of details. There are millions of much better pages out there and really specialized in concrete buses, wiring, lighting and each one of the different aspects of the digital railroad modelling world. My intention is just to create an introduction to that, and easy way to step into with no fears, so people used to analog layouts or completely novices feel safer and more confident to move to DCC world.

Iberama 570

Analog layouts and systems are quite old, with many years of experience, and nowadays there is no one inventing new things: one transformer for each aisle circuit, one train can move in each of these circuits, push buttons to change switches, electrical switches to light traffic lights and activate or deactivate current in a section... and some automation more or less complex (but simple) using relays, diodes or passive components. That would be the most common scenario for analog layouts.

More or less all problems or doubts have one good answer or way to solve them, and the number of elements and ways to solve it are really reduced in comparison to a digital system. Like said before, in analog you use simple electronic components like diodes, relays, switches, resistors, .... not much variety (taking as an example a simple or common layout). And you can mix easily components or products from distinct vendors.

Componentes electrónicos (fuente Wikipedia)

Digital world is not more complex (I think it's easier). A good example for me would be in telephony: modern smartphones aren't more complex to use than and old and analog one, if you use it just as a telephone!!! But as it has a lot more of functionality, options, vendors, operative systems, firmwares, connectivity, .... seems more difficult.

Same thing happens in digital railroading, and besides that it's still an immature market with no big standards set (just DCC as you will see or the ones from Digitrax manufacturer). There are lots of vendors, new brands every day, every one makes it's own systems not compatible with others trying to be the first setting a big standard, ... It's normal for someone starting to have so many doubts!!

And to start in a proper way, I think the better is a bit of history to know where one of the big standards called DCC come from.

If you read something about digital systems in railway modelling, for sure these three letters appeared everywhere: DCC (Digital Control System). Many times it's used in wrong way to talk in a general way about any digital train control system. But strictly speaking, it's the NMRA DCC; a communication protocol defined by NMRA (National Model Railroad Association) in 1993 which defines the communication system to send orders to the locomotives at both physical and electrical level. It defines a central station that, in conjunction with a booster, modulates the track current to encode digital messages at the same time that delivers current to the rolling stock. Inside locomotives a small chip (called Decoder) is installed in order to decode and understand those messages and act to the orders. So, here we have a bit difference in front of analog systems: digital tracks are always feeded with current, it doesn't matter if locomotives are moving or not. That also means more that one locomotive can be in the same section and it's not needed to create aisle sections for each locomotive. Because the orders to start, break or turn on the lights are sent personalized for each locomotive. Later on the different components of a digital system (central station, booster, decoder,...) will be better explained.

There are other protocols or digital systems to command trains like Selectrix (created by Döhler & Haas, bidirectional and based in a big industrial standard from Siemens) or Motorola, but now a days DCC is the leader of the whole market despite is the worst protocol ever thought. Yes, you read well. The ones who designed this protocol hadn't a wide view nor future vision, and created this protocol completely unidirectional, just from the central station to the locomotives. So you can send commands to the trains, but trains cannot answer any kind of information. Knowing this fact, you will easily understand later why you need a programming track to setup the decoders where locomotives have to move the motor to send acknowledge signals to the central station, or why you can configure a locomotive in the normal track but you cannot read the current configuration values.

So, with this protocol or system we were able to move locomotives, but we also wanted to command switches and lights. That's why a new kind of decoders appeared, called "static decoders" in front of "mobile decoders" (the ones installed inside the trains). Static decoders are connected to the rails' current and receive DCC commands to turn on/off switches, lights or any other device.

But not after a long period of time, the need of receiving information appeared. In order to automate the control of the layout from a computer software it was needed to know the occupancy of each section of the layout using any kind of sensor (consume sensors, reed contacts, light barriers....).

That's why in 2007 the NMRA included to the DCC norm a new extension called RailCom (developed also by Lenz and other manufacturers). They could have extended the already existing DCC to create a new bidirectional and compatible one, but again failed creating a parallel communication channel, and again unidirectional, from the sensors to the central station or directly to the PC. So you need to double the meters of wire needed in a layout for both unidirectional channels:

Fuente: Wikipedia

Here in Spain Railcom didn't become popular, but its competitor S88 from Märklin (a really similar systems for feedback modules) is still in use and widely used. The "boxes" connected to the physical sensors and sending the occupancy signals are called "feedback modules". So a common digital installation (I said common, not modern) is composed by the Central Station and booster, of course a throttle to set the speed and direction of locos, mobile decoders installed inside locomotives, stationary decoders to command switches and lights, and feedback modules to send occupancy detection signals to the main system (usually a PC).

Just to finish this brief review, DCC has an extra problem: as static decoders (those controlling switches, lights and outputs generally speaking) are connected to the track current, consumption can grow easily to be forced to buy another booster, which is an expensive element.

To solve that, and relatively new in this world, appeared the Control Buses. Static decoders and feedback modules as they are known until this time disappear, and everything (called just input or output modules) are connected together to a single communication line (bus) that shares completely all messages and information of all elements of a layout.

In next posts I will talk about Control Buses and a modern digital system approach using them as I understand this digital world.

NEW ARDUINO LIBRARIES VERSION FROM MRRWA!!!!

A new version of MRRWA libraries has been released!!! Before making a brief summary of the project, I post directly the address to download them:

http://sourceforge.net/projects/mrrwa/

The main change I saw is in Loconet part, including an implmementation for LNCV config. And it is just perfect for my projects, so I can setup my programs from the Intellibox, Uhlenbrock PC software or Rocrail directly using this LNCV protocol. There is no need to dismount the Arduino when it's in place under the layout and connected, nor connect a USB cable to it for configuring or setup the application parameters.

Some review until this point:

Some months ago I posted some musings about Arduno used in a railroad layout and how to connect it to a Loconet network. I showed how to use a cheap GCA50 board to make an interface to connect Arduino to a Loconet network using the standard Giling Computer Applications connector that provides both loconet and power to feed the Arduino:

http://www.clubncaldes.com/2014/06/loconet-interface-for-arduino.html

After that, a first prototype shield was designed and built by Peter Giling, called GCA185, which you can buy here: http://www.phgiling.net/

http://www.clubncaldes.com/2014/06/arduino-loconet-shield-gca185.html

At this point, I did a program to turn Arduino in a Sound Module for ambient sounds in a station. It was able to be governed by a remote control (for analog users) and also to be configured to play a sound for each function key of each train or even detect a train stopped in a detection section to reproduce its announce. Here and here there's all the information.

But I wanted to implement a configuration protocol through Loconet to avoid dismounting the Arduino or connect a USB cable in order to configure it. I did it using the same GCA50 protocol, and copying its functionality but in an Arduino board. But that was not enough for bigger or different projects and programs.

Next step was implementing the LNCV protocol. That's the protocol used by Uhlenbrock to setup all his hardware and modules, but as everything from Uhlenbrock the information is strictly confidential. Rocrail was also implementing this protocol and I started looking at their source code. But suddenly a new version of Loconet Libraries for Arduino has been released, with LNCV protocol already implemented!!!!

BRAVO, BRAVÍSSIMO for MRRWA guys!! Congratulations and thanks so much to share your work!!!