I am thinking right now what sort of railroad to buy for my 6 year
old's upcoming birthday. He already has a LIFE LIKE railroad and he
likes it and has a friend who is a huge railroad fan. So there is a
social aspect to this.
What I would really like, is to buy a railroad that can be controlled
digitally by a computer. Preferably a Linux computer as that's what we
have at home (I avoid Windows like the plague due to viruses, scumware
and performance problems and low end user productivity).
So... Would anyone point me a little bit towards the basics of just
how toy railroads are controlled with digital controls and what sorts
of options are out there for controlling them.
Also, if anyone can suggest a starter set, that would be great. I have
money to burn on that stuff right now.
As mentioned - JMRI.
I have just bought a SPROG II USB for controlling and programming of a
very very small DCC layout (1 meter of track - I'm building decoders
into locomotives for different people). I've just started with
DecoderPro ( a part of the JMRI Package) and it seems easy to use.
You need somethig to interface between your computer and your
Yes, it is possible to 'speak' to
a DCC system directly from a computer. I have written a library to
interface to XPressNet, Lenz's 'network' for their DCC system. Lenz
makes a RS232 XPressNet 'box' -- jack the RS232 into your PC and the
other end into the Lenz XPressNet (which should include at least a
command/booster station), and there and you can start sending command
and receiving responses with your commputer. The computer can replace
any number of throttle units. *I* plan to use a RailDriver console to
control trains. Posibly a (Ethernet/Wireless) LAN of hacked laptops
with RailDriver consoles, with a cental (boss/dispatcher) system that
monitors block occupancy, OS sections, and speaks to the DCC system to
actually controll the trains. I believe the JMRI can do this too
(jmri.sourceforge.net), but needs Java installed...
It is also possible to build a DCC system *from* scratch and replace the
'command station' completely with a computer -- all you would need would
be one or more boosters (and decoders).
Command station: generates the DCC command signals from some source (eg
Booster: overlays the DCC command signals on the raw 16-18VAC source
power creating a +/-12V square wave power signal across the tracks.
Decoder: decodes the DCC command signals from the +/-12V square wave
power signal across the tracks and rectifies the power itself and
drives the motor and accessories (lights, sound, etc.). Most decoders
ride in locomotives, but there are also 'fixed' decoders for fixed
accessories (like turnouts or signals and the like).
Throttle units: various fixed and/or hand held units that are used by
operators to communicate to the 'system' relating to things like speed
and other functions relating to operation.
Most vendors sell a Command station/Booster combo unit: a command
station with a booster built in. There are 'home grown' designs out
there on the Internet (Google is your friend!) where you only build a
booster unit (basically a power amp/modulator) and use your computer
itself as the command station side of things. You would build throttle
units that would connect to the computer somehow (lots of serial ports?
WiFi LAN? RS485 (differencial variation of RS232) type 'LAN' (ala B.
Chubb system).). Or the computer just runs the trains itself according
to some program, with little or no human intervention at all.
You *should* be able to use any brand of decoder with any brand of
'system' -- the DCC signaling protocal (what is in the rails) itself is
'standard'. How the throttle units, command stations, and the booster
units communicate amoungt themselves is something else. I.E. brandX
boosters can only talk to a brandX command station and only brandX
throttles can talk to a brandX command station (in general). Lenz has
published an *open* protocal, XPressNet, which is how Lenz's products
talks to each other. Digitrax has published a *proprietary* (somewhat
closed) protocal, LocoNet, which is how Digitrax's products talks to each
other. Both companies sell RS232 (and/or USB) to their 'net converter
boxes/cables -- both 'nets are basically serial networks that operate at
something like RS232 speeds and signal levels, but are bus oriented and
use differential signals (ala RS485 or some variation).
Ignoramus322 spake thus:
Whoa. Back up just a second.
I'd like to take this discussion up one level to a bigger overview
rather than the nuts-and-bolts details that folks have been giving you.
The answer to your question is yes, it is possible to control a DCC
model railroad from a computer. But the unasked question is, how would
this actually work?
The problem is this: while you can build and run a railroad that runs
automatically from a computer, it's slightly more complicated than just
telling the trains what to do. The problem is one of knowing where
things are on the layout. So far, people have given you answers about
how to control the trains, switches, etc., by a computer. But ask
yourself this: how does the computer know where the trains are? How does
it know when to accelerate and brake the trains, so they end up where
they're supposed to be and don't crash into each other, or run through
switches the wrong way?
To reach this level of automation, you not only need the standard DCC
setup, but you need lots of sensors to tell you where things are at any
given moment. This is a non-trivial problem. I don't have detailed
knowledge of this myself, and would be curious to hear what others have
to say about this.
David Nebenzahl skriver:
There are tonnes of occupancy detectors out there that are DCC
compatible. It is just a matte of choosing what system to use.
I'm using MpC (a German program) for DC trains (not DCC), the same
program and hardware can be used with DCC.
Ignoramus322 spake thus:
Think of DCC as a "write-only" system. In other words, you can send
commands to devices (locomotives, headlights, switches, etc.), but you
have no way of getting any feedback from those devices.
As Klaus pointed out, there are sensors you can install, like block
occupancy detectors, but these don't have a very fine level of
granularity. In other words, they'll tell you when a train (a loco, car,
etc.) is within a certain block, but not exactly where within the block
You can improve on this by installing things like photodetectors, where
a beam of light is interrupted when a train passes through it. But it's
still very tricky to correctly interpret this information so you avoid
things crashing into each other.
What you usually end up with is two 'networks': a mostly outbound
network (computer => track) DCC and a mostly inbound network ('track'
=> computer). In some cases, one can partition things so that loco
control is all that the DCC network handles and the 'other' network
handles other things: turnouts, signals, block/OS occupancy. *My*
thought for the 'other' network is the Bruce Chubb CMR/I system. This
uses an RS485 type of network connecting one or more 'nodes', each of
which has a batch of input and/or output 'ports'. There are some other
options available (google is your friend!). The SMINI (Super Mini node)
is ideal as a small 'substation' of I/O: one board with 3 input ports
(x8 == 24 input pins) and 6 output ports (x8 = 48 OC (pullup or
pulldown) output pins). Mount one of these under the table and wire
upto 24 sensors (block/OS occupancy, turnouts state, etc.) and upto 48
devices (turnouts, signals, etc.), run the 5 conductor cable back to a
RS232RS485 converter and connect the RS232 to a second RS232 port
(the first being used for your DCC system) and there you are. If you
need more I/O pins, you can either use a SUSIC (Super Classic Universal
Serial Interface Card), which lives it is own bus backplane which can
be filled with a pile of 32-bit Input and/or 32-bit Output cards. Or
just scatter several SMINIs about the layout and 'daisy-chain' them. I
have a small setup that demostrates this. Uses three SMINIs: One
SMINI is on a section with a pair of back-to-back #8 turnouts leading
up to a double track bridge (merges two single track routes to/from the
double track bi-direction bridge) -- the SMINI manages the turnouts,
signals, and turnout state (will also monitor block and OS occupancy as
well, once I get that far with the layout). The second SMINI is on the
section on the other end of the bridge (and handles the signals and
(eventually) occupancy at that end), and the third SMINI is not on the
'layout', but on a control panel (a control 'tower') and is connected
to the switches and LEDs on the control panel. All of the 'logic' of
the junction is handled by the computer, with the option of either
'local' control: tower is 'manned' and the operator manages turnouts and
signals or central control: tower is unmanned and the central
dispatcher (sitting at his/the computer screen) has control. In theory,
the computer itself could be the controlling agent (eg a software
program playing the role of central dispatcher and/or tower operator).
Robert Heller spake thus:
[snip lotsa good stuff describing model RR I/O for DCC]
In theory, yes. In practice, it sounds like a gigantic migraine
headache, especially cooking up the software to run it all. Definitely a
non-trivial project. (Of course, were *I* to attempt to program this,
I'd be working in super-paranoid mode with lots of error checks, so that
in the worst case the damned thing would just shut down before any
cornfield meets occurred.)
Right. I'd just start with *manual* (human) dispatching, with the computer
performing error checks of various sorts, like strickly inforcing
restricting signal aspects, speed limits, and locking out improper
turnout controls (ie you can't change a turnout state if the turnout is
itself occupied and such like).
David Nebenzahl skriver:
1 detector for the most of the block, and 2 at the end (1 for
deacceleration and 1 for stop)
The whole layout is fully autoamted.
A little more than 1000 meter of H0 track, 65 running units, where
between 10 and 20 is in motion at the same time.