My colleague, Darryl, came by my office at the end of the day on Friday. He’s been following my thinking about control systems for steam locomotives, and is considering doing some inventing of his own. His ideas have more to do with counting ties and trying to keep automated trains from running into each other. However, it was more fun to kibitz with him for 20 minutes than it was to finish cleaning out my inbox.
Being a software development manager, my office is rather full of whiteboards, so we sketched out what the system for the knob-free-throttle (I’m calling it the handheld backhead) should look like.
Essentially, the design moves most of the smarts up to the server. There we can use not only the inputs from the handheld backhead, but inputs from other elements of the layout, and indeed feedback from the motor (I think) to drive the signals to the decoder via the DCC Command Station.
The only difficulty is that decoders have gotten too smart. We’ve never had much capability in the command stations — really all they do is transform throttle inputs into DCC signals. So, as decoders have become more and more capable, they have begun to take on more intelligence themselves, making it ever more convenient to convey realistic locomotive behaviour automatically.
On my ESU LokSound decoder, for example, whenever the engine starts to move, it sounds like the cylinder cocks are open for a couple of revolutions. Wouldn’t it be better if I had to open the cylinder cocks and remember to close them? Engineers don’t open the cocks on every start, but only if the engine has been still long enough for condensation to form in the cylinders; so, while I like this detail, it is as inaccurate as an extra row of rivets.
I believe my decoder also chuffs louder if it senses a heavier load. However, it should chuff louder when I open the regulator and throttle. If it senses a heavier load without the regulator and throttle, the engine should slow down and ultimately stall.
The most glaring example of this over-intelligence is the headlight (so to speak). Real engines don’t automatically extinguish or dim their headlight and turn on their backup light when they are reversed. That is a conscious decision by the engineer, and in my case, the engineer would have had to get out and light the dang thing by hand. I’m fairly certain nobody would ever have thought to make reversing headlights if some clever boffins hadn’t figured out how to arrange diodes and resistors so that the rear lights worked on a DC layout! Here DCC is modelling a model — the same kind of thinking that yields caricature model railroads.
Even momentum is misplaced at the decoder. How can the decoder tell how much throttle and lap is applied, and thus how quickly the engine should speed up? The decoder also doesn’t know how much brake is applied. Momentum without these inputs is always constant, and trains slow down and speed up either at the same rate, or at the whim of the driver. Neither is accurate.
In most cases, the smarts can be turned off. However, one day you may find yourself unwiring a whole bunch of decoder logic because you want to move that function to the engineer or fireman’s handheld backhead. When that happens, won’t you wish the decoder hadn’t been as smart in the first place?