Wayne Roderick, 3rd Division, PNR, NMRA (life)

12/13/98, rev 01/16/07

With the obvious success of Digital Command Control (DCC), thoughts of many control oriented model railroaders have turned to the next step in getting rid of the "copper mines" under the layout. We struggled for 20 years or more to achieve a "standard" for individual control of several trains on the same track. There were many successes, but no one system achieved the status of a "standard" until recently. With the "standard" comes multiple vendors and the advantages of competition resulting in lower prices and better performance.


The key to getting rid of our copper mine, just like reducing cars on the freeway is to "ride the bus (or buss)". That's what DCC does- The cab commands ride the power bus on the rails to reach each loco. Just like a City mass transit system, the various buses can get a bit confusing. Fortunately an ad hoc group of modelers have been building a glossary of terms, much of which we hope the NMRA will adopt. Lars Lemberg has a very good Glossary of Model Railroad Terms. BUS (or BUSS)- A set of wires that distributes power, commands or signals around the layout.

Almost immediately we get into the arguments of how many differant buses are required to serve the model railroad cabs, panels, turnouts, signals, communications et al, and the technical details of each. I expect to occasionally toss my two cents worth into the debate.

I've monitored and occasionally participated in discussions with an ad hoc group of technical minded modelers working on the LAYOUT CONTROL BUSS. IMHO too many of them tended to think too much from the computer science viewpoint rather than the model railroad viewpoint. The TSL was in need of an LCB now and blue sky thinking wasn't going to do us any good so I abandoned them, posted this page, and went looking on my own. Knowing nothing of computer networking but having some insight into industrial data systems might be an advantage. :-)


Three data buses, plus phone/voice and video if desired. I will not address the phone/voice except to say that market offers a wide variety of telephone, and radio communication systems for our train operators and dispatcher. We do not need to re-invent it. Video is a very specialized wide-band system that is unlikely to find a significant place in any but the biggest and "far-outest" railroads.

In the block diagram below, I've shown a very simple DCC system (green) as it exists today (1998) and then added the Future LCB (red) and CAB (cyan) busses as I envision them. As this debate developes, this diagram may be altered, but please remember- this is MY position and may not reflect the consenus of any working group. I've made no attempt to show any of the current proprietory systems.

Block Diagram, Local Control Bus


A proposed glossary defines three "sub-busses" as part of the DCC system. The only bus STANDARD in the DCC system exists between the Command Station and the track Track Buss: A buss which connects a power station to a track segment.This is a pair of heavy conductors that can carry several amperes of current. The glossary defines a control bus, Control Bus: A buss which connects a command station to its power stations but does not provide a standard. The vendors typically use a TTL compatible signal that is not further processed except to boost the power before sending it on to the track. The glossary also defines the CAB BUS as part of the DCC system, but provides no standards or recommendations. We will treat it separately

For the small railroad, the DCC system may be entirely adequate to control a few accessories as I've shown. It's generally agreed that a separate Power Station (also called Power Booster) is a wise idea so that a problem or derailment on the track does not kill control of the switch or accessory that might be related to the problem.

The DCC standard is in place- It's a good piece of work- leave it alone. Some folks feel they want feedback from the loco for various reasons- I see no justifiable need for it and will not get into it. If you want to bring data from the layout accessories then move onto the LCB.


The NMRA definitions for purposes of DCC are: Cab Buss: A buss used to connect all types of Cabs, except Wireless Cabs to a Command Station. Wireless Cabs are indirectly connected to a Cab Buss via their companion Wireless Cab Base. and Bi-direectional Cab Buss: A Cab Buss which allows the Command Station to send information back to Cab display devices in addition to allowing the Cab to send locomotive control information to the Command Station. The Command Station is of course a DCC device. You've probably already looked at our walkaround cab system on this site and know that our ancient (1978) design easily moved from the old Automatic Cab Control to modern DCC with no hardware changes. That is a powerful demo' of the anti-obsolescence that exists if your cab bus is independant and functionally oriented. There are some strong opinions that the CAB bus should be included in the LCB and I'd probably have no problem with that if it didn't compromise the ability of the CAB bus to stand alone on a layout without LCB.

The construction technology of the TSL CAB BUS using power hungry TTL and an unbalanced data line is primitive, but I stand by the funtional technology and would re-use it until shown something much better. Today I'd probably scrap the wired CAB and transmit from it via infra-red or UHF radio and receive data at the CAB via a single rf channel serving all cabs.

Today, the CAB bus is usually defined by the maker of your DCC system and one end of it connects to his Command Station. You'll use his cabs whether you like it or not. We do need a standard here, but I'm not ready to address that one yet, because ours is not broken, so I'm not in a hurry to fix it.


LCB: A buss that carries control and data information to and from layout accessories. The term "layout accessories" reminds me of the Lionel catalog of years past- it's quite descriptive and included just about everything except the trains. All the wonderful electric gadgets that enhance our model railroad fun like turnout motors, animation, signals, occupancy detectors, control panel buttons and switchs (other than cabs). A digitally coded BUS for this purpose is yet to be standardized, although several folks have implemented their own versions. The Teton Short Line does not have such a critter- yet (1998). The list of layout devices that we may attach to our LCB is long, some sending, some listening, and others sending and receiving. Some initial thoughts among the informal group beating this around included things like audio/voice, video and horrendous bandwidths largely driven by the computer industry networking technology. Granted, the hardware for these networks is plentiful and cheap but the purpose is usually to connect a few "high power" computers to each other in an office, building or campus complex. This is not what the model railroad needs. Many pioneers out there have developed their LCB systems and I'm sure I would have also if I'd have started the TSL much later. I do have one advantage (VBG)- I've had a lot of experience with model railroads and virtually zilch with networking.

As I argue against the "computer" buses, like Ethernet, I visualize a people bussing system. Those that move masses of people flawlessly among a few very complex stations (Example: Denver Int'l Airport) are the computer type. On the other hand, the city transit bus moves many independant people among numerous simple and economical stations, sometimes just a bench or a sign on the street corner. The people make errors once in a while and get off at the wrong stop- no great harm done. Didn't even miss their flight. This is the system we need, but our bits of data don't have brains to tell 'em where and when to get on or off the bus, so we do need at least one guide, with some memory, to direct them.

I would be inclined to develope this bus in a manner similiar to my DCC and CAB buses. The key to this is terminating the bus with a "Service Module" (my term) with enough RAM and glue to drive the bus, repititiously repeating commands and gathering information from the gadgets in the field. This Service Module is the Command Station in a store-bought DCC system and the DCC interface device (DCCID)in our do-it-yourself DCC system. In our block diagram above, I've tagged it as "Bus Buffer and Interface Device" (BBID) pending a better name.

Error checking would be minimal or non existant, because unlike the CAB bus, where devices plug in and out, disturbing the bus, the field devices remain attached. If we use a synchonous system or polling, then we don't deal with collisions or need verifications. The bandwidth shrinks enormously permitting the number of gadgets and LCB BUS length to greatly increase.


Dare I try another analogy? A busy executive assistant makes decisions, like our computer, based upon the way I programmed her. She has aides that poll the field (my crew and I are in the field) for data, holds it in their heads (RAM) until she calls upon them, and then sends the her resulting commands out. I want my executive assistant to have three aides i.e. DCC (out only), CAB and LCB. If any one of the three get lazy or obsolete, I can replace him. Oh yes- I can replace the executive assistant too- she's only a computer. No gender offense intended :-)

The three buses, DCC, CAB and LCB have to be integrated because they have information for each other, so now enters the integrating brain. Among other things, I might want her to take your throttle and brake commands from the CAB BUS and simulate a heavily loaded train by issuing the appropriate commands to the DCC bus. I probably want her to issue programming commands to the more complex LCB field devices to initially assign them an address, tell them "what they are" and personalize them, much the same as you do with a DCC decoder.

The service module (BBID) on the end of each bus has RAM that buffers the bus data until the computer of your choice accesses it to read data in or out. This reduces the risk of computer obsolescence, because our vendors will find it attractive to provide the software for the current computer fad.

How do you program the computer if you're not a programmer?? The professional programmer does the work for you, leaving you a friendly screen menu that leads you by the hand describing the gadgets on your railroad and what you want them to do. If the three buses are standardized, the software writers will crawl over the top of each other to offer you the programming.

Is this really possible? Have you used the TSL Freight Manager program and tailored it for YOUR railroad with simple ACSCII (text) files? Have you looked at our ancient Automatic Cab Control (ACC) system that's described elsewhere on this site? It's generic! Again you adapt it to your railroad with a simple ASCII (text) file. If I, a non-programmer, could do it long ago with primitive software tools, just think what a pro' could do today. Shucks- they're doing it now, but it's each vendor for himself. The costs won't tumble like DCC has until the standards are in place.


02/18/03 THE HARDWARE IS HERE! I had a very enjoyable visit with Bruce Chubb a few days ago and he showed me his newest gadget called Super Mini-node, SMINI. As I'm sure we all know, Bruce introduced Computer/Model Railroad Interface, C/MRI, back in 1985 via the pages of Model Railroader. Back then Bruce and I played with many of the same ideas but he brought it to the masses in easy to understand and build form. What is so great about the SMINI? In my opinion, it is the key to the LCB and it is here now- no more far out dreaming! SMINIs can be scattered around the layout riding on a standard RS-485 bus (like 4-wire telephone cable). Each SMINI can switch 48 devices such as switch motors or signal lamps and input 24 lines such as detector outputs or toggle switches in the field. Cost for DIY assemblers is only about a $1 per I/O line. That's pretty hard to beat. A computer that will handle this is probably free and the only other thing you need is a thirty dollar RS232/RS485 interface card. The software is free, but you really ought to buy Bruces books for the total picture.

At one end of the RS-485 bus is our computer that ties the whole world together as we talked about above. The C/MRI software is well proven with years of experience on many large layouts and Bruces manual answers all the questions in easy to understand format. There are some among us that are developing CTC simulations on the computer that is interfaced with C/MRI. One fellow even has his clubs CTC interfaced to the Internet- If I install a copy of his software, sans the logic, on my plain vanilla Windows equipped PC here in Idaho, and we link via the Internet, I can control and see the current display of his CTC board in Florida.


Not quite, but close enough for now. Chubbs SMINI with 72 discrete I/O bit connections can be home assembled for as low as $1/bit in quantities but it's still costing about $2/bit assembled in plug and play form. Today, it's probably the most economical way to go but-- I'm still looking for the $20 module that will have enough I/O to serve the signals switches and local controls for a siding or small OS. This module will probably be built around a PIC or micro with minimal interface, somewhat restricting its application and ruggedness. It'll be a throw-away if you mess up.


C/MRI has proven, along with industry, that the RS-485 data line standard is here to stay for a long time yet. C/MRIs communication protocal has twenty years of success behind it and Chubbs terrific support literature makes software coding relatively painless for us non-programmers.

For more info, I suggest you join the C/MRI group on Yahoo.

Here is the current (2004) configuration of LCB on the Teton Short Line We didn't miss it too far. Because my generic computer has only two serial ports and I needed four systems tied to it, I opted to tie the CAB BUSS into the LCB to save one port. Our Yardmaster had his own PC piggybacked onto the embedded HOST and that took up one port. Sure, we could add extra serial port cards but then our computer starts to depart from the common generic machine. and that didn't seem like a good long term solution.

More info on our C/MRI applications will be found on TSL Computer page

Block Diagram, Local Control Bus

As far as I am concerned, there is no more concern over a STANDARD LCB for the Teton Short Line. I can't imagine outgrowing what we now have. The next expansion phase will simply include one of Bruce Chubbs SMINIs tacked directly on the RS-485 LCB.

12/03/05 It's done! The final node. The 1978 Malfunction Junction control panel has been scrapped and all control routed through an SMINI to and from the host computer.

Teton Short Line Home Page