computer control for model railroads: srcpd & spdrs60

Even as a boy I already dreamed of controlling my model railroad with a computer. At the time I had a Schneider/Amstrad CPC 464 with Z80 CPU, 3 inch floppy drive, and a whopping 256kB (yes, KILO-Byte) memory. I thought about using the Centronics printer port to hook up a bank of relais to control switches and semaphor signals. Little did I know...


Fast forward 25 years. Computer-controlled model railroads are pretty common these days. I still love the idea to have a computer control train movements for background traffic, or when I just want to show off my layout. However, it's so much more fun to actually run a train and do stuff with it, while a computer takes care of background traffic tasks.

Over the last two weekends I hooked up the Intellibox via serial port to an old Dell Latitude laptop (which happens to have a fantastic 1600x1200 pixel display), installed the brand-new Debian 5.0, srcpd, and spdrs60.

srcpd is a middle-layer program that hides the mechanics of connecting to the model railroad and provides a generic TCP interface and protocol ("Simple Railroad Control Protocol").

spdrs60 is a graphical UI that is modeled after a Siemens control tower design commonly installed in the 1970's and 80's in Germany ("SPurplan DRucktasten stellwerk bauart Siemens 60").

Taken together, the photos show the result: I have computer control of my layout, including track occupancy feedback. The screen shows the tracks in hidden staging and the ramps leading to it, including the temporary return loop at the top of the ramp. Occupied tracks are illuminated with red indicators.


At the very top of the panel, just pass the bypass switch, spdrs60 shows a train making its way up the ramp, and if you look closely in the upper photo, it's the blue/beige BR151 with a short freight train in the background.
Staging tracks 3 and 4 are currently empty. Track 2 is also illuminated in red, indicating a train. In the upper photo we can barely see it's a BR86 steam locomotive with a gravel train. Finally, track 1 on the computer is still grey. When I took the photo, I didn't configure the feedback sensors for track 1 yet, so the computer doesn't yet show that track 1 is occupied by the red BR216 with a passenger train.

So far, so good. Under ideal circumstances it all works nicely. I control trains from the Intellibox, and the track illuminations on the computer screen change accordingly. I can even "fly blind" and start and stop trains in the right places with only looking at the feedback on the computer screen (not quite the point of this, but a necessary pre-condition for automating control of hidden staging).

However, I ran into multiple problems, particularly with srcpd and how it interacts with the Intellibox:

• srcpd (at least in version 2.0.12) has a bug that causes it to crash whenever it receives a locomotive status change (INFO GL) for a loco whose id is in the range srcpd is trying to keep track of. Work-around is to set the GL range to 0, so srcpd doesn't try to keep track and report on loco status changes. Very unfortunate since I will need that functionality.
  
• The Intellibox serial line control of srcpd tries too hard to be smart. E.g. it attempts to auto-detect line speed, even though there is a speed setting in the configuration. As a result, if srcpd happens to crash and starts up again, its attempts at auto-detection will yield garbage sent to the Intellibox, which can cause the train last controlled by the Intellibox to get a command to run and cause havoc on the layout. The only work-around I know for this, is for srcpd to be started only once after the Intellibox is powered up, or power-cycle the Intellibox after a srcpd crash. Annoying. I might try to change the code so it does all this smartness only when I configure an "auto-detect" line speed, which I won't :-) just open the darn serial port at 19200 bps and be done with it.
  
• The Intellibox spontaneously rebooted twice while experimenting with this, and sometimes shows "=0=" instead of the speed or decoder protocol setting for locos. A power-cycle gets rid of the "=0=" display. I'm not quite sure what this stands for and how to get rid of it without power-cycling.
  
• spdrs60 has no "intelligence" for train movements. The raw SRCP protocol needs to be either controlled programmatically, or with typed SRCP commands which is not hard by annoying. The syntax is similar to common ASCII based Internet protocols like SMTP or HTTP. In other words, spdrs60 is useful as a control panel for train movements, but it can't implement an automated control system for the staging tracks. However, I do like the openness and flexibility of the srcpd approach.
  

Railware is so much cooler than this. sigh.

Yesterday, I came across JMRI which is a different, and apparently quite mature open source software that also supports the Intellibox, at the expense of the generic SRCP middle layer. The UI is substantially more bare bones than spdrs60 and seems to be harder to set up, but JMRI might address some of my problems. It also provides Java libraries I could use for extending functionality, so I'm going to experiment with it next.