DCC decoders are too smart

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.

Handheld backhead

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?


17 thoughts on “DCC decoders are too smart

  1. As well as being switched off, the “smarts” can be re-programmed. After all, a dcc decoder is nothing more than small, carefully purposes microprocessor and associated circuitry.

    We are not talking simply about CVs, but altogether smarter things. I am aware that it is possible to do a lot of this sort of thing on Zimo and ESU decodes, but Soundtraxx seem to have largely locked down theirs. I don’t know about other brands.

    As I have mentioned before, a lot of this has been done already by Paul Chetter. It is worth searching his articles in Hornby Magazine (I think this is where he published a series of articles) so that you can build on his progress rather than have to re-invent it.


    1. Hi Simon,
      Thanks for the further pointer to Paul Chetters. There seems to be a good deal more interest in sound correctness in Britain than in North America (although perhaps I simply don’t move in the right circles).

      Hornby Magazine is difficult to find over here; indeed I was unaware of it until I stumbled across it as I was riffling through the shelves of the only decent newsagent in Metro Vancouver for MRJ.

      However spirited Googling turned up some references to Paul back in about 2010 in relation to Zimo. Bingo! The Zimo website press page has all the Hornby articles.


      What Paul demonstrates is how to take advantage of the decoder smarts to play the appropriate sounds as the engine is speeding up or slowing down. However, this — though a nice bit of sound modelling — kind of misses my point. Yes, there should be no blast up the stack as the engine is coming to a stop, but only because the engineer has shut off steam. If the engineer still has the throttle open, while trying to slow down, then it should take longer for the engine to eventually stall against its brakes (if indeed that is what happens), but the chuff should continue as the engine grinds to a halt.

      Decoders may actually be too smart for my scheme. I would have to do more research to understand how to modulate the blast sounds relative to the throttle and reverser settings.

      1. Thanks, René.

        Paul has significantly improved the way sound is portrayed using the in-built smarts, and it is very effective. Hopefully it will give you some pointers to where to start looking.

        Personally, I would be happy with separate levers or sliders for regulatory brake and reverser: this would serve a dual purpose, reversing direction, but also to vary the sound of the engine – just as it would on the prototype – I. Response to the setting. Bell and whistles for me need switches: on/off for the bell, sprung centre-off for the whistle. Everything else I would be happy to control via the touchscreen.


  2. I don’t know the first thing about software programming but would your ideas be easier to implement on hardware such as the “Blue Horse” from Blue Rail or Rail Pro from Ring Engineering?
    They use software updates to change what they do/how they sound and/or effect the engine’s operation. That seems to me like it should translate into the flexibility you need to pull off your handheld “backhead” idea.

    1. The principle opportunity with Blue Rail, Rail Pro or Layout IOE is that the Decoders aren’t yet mature. So we still have an opportunity to make the protocol rich enough to support the command set required for handheld backhead.

      Being able to update the decoder over the air may actually make the opposite more likely, unfortunately. It may depend on how these companies see their value. If it is in hardware, then maybe they will open up the protocol to enable a throttle designer to pair a decoder with the throttle.

      The other thing in the diagram that we would need to think about is the other inputs from the layout. Does the device get those through another Bluetooth connection or through Wifi?

  3. I may be talking about something I know too little about to be able to comment on.

    It seems that somewhere I’ve gotten the impression that Blue Tooth is capable of multiple streams of commands.

    If this is true, would that allow for your need to to combine inputs from both the engineer and the inertia or lack of it in the loco?
    Say I forget to open the throttle sufficiently to climb the hill(or I’m the new guy who doesn’t know the road yet!), the loco begins to climb the hill but stalls because I’m not minding my business and listening to the engine.

    I do have real life experience running a variety of equipment. From that background I can say that operation becomes easier the more you listen to and feel the machine. Obviously we can’t ride inside our scale models but I wonder if what you propose would not require a level of listening that we heretofore have not exercised in “playing trains”?

    DCC decoders use BEMF to smooth out the motor. Could that be used to create the scenario of an inattentive or inexperienced engineer?

    1. I’m afraid I too know too little about Bluetooth to be of much use.
      BEMF enables the system to respond to load on the engine. It can respond by compensating as in those Decoders that smooth out poor mechanisms, or it can respond by providing a cruise control type of response to trains as they go up and down hill. It can also respond by forcing the use of more steam to maintain speed.
      With a handheld backhead, you would not want the cruise control response, but the others are reasonable.
      From an architectural point of view, the mechanism response should be at the decoder. The decision to require more steam should not be.

  4. I like the idea of one “throttle” for each member of the train crew as you’re outlining. I wonder if you could split the decoder in terms of limiting how much of it each crew member could control? (The engineer continues to control the speed and direction but is limited by the fireman’s work.)

    I’m fascinated with where this thread is going. Thanks.


  5. “Well, it’s started,” is what you said as soon as I brought up the topic. You can’t blame me for your slightly over-full inbox. Just like I can’t blame you for what happened on my end of the conversation — a complete redesign of my control system. In theory, it’ll be able to talk DCC now.

    Of course, that’s just theory. DCC doesn’t offer a convenient way to handle tie-counting data. So it’s “DCC-ish” instead. 🙂

      1. Passé? What’s replacing it? I guess everybody’s getting onto the Bluetooth/Wifi bandwagon?

      2. Personally, I’ d like to see BT/Wifi controlling battery powered DCC, with the same protocol between controllers and base station.

      3. I’ve always wondered about this approach to dead rail, so perhaps you can explain it to me. DCC seems to be a protocol that is designed to multiplex signals to many devices over two wires. If you have a wireless receiver in the model, driving a single DCC decoder, why would you need this multiplexing protocol? Indeed, the conversion of the DC battery power to something resembling AC and back to DC for the motor also seems wasteful.

        It seems more efficient to me to have the wireless receiver talk directly to the microprocessor, which in turn controls sound, light and motor functions. You could do it all on one chip.

        As far as I can see, the only benefit of using DCC decoders in this context is that the DCC decoder already exists.

        Either way, I am looking forward to really small powerful batteries so I can start taking advantage of dead rail technologies. There is not much room in my engines for more than a speaker and a decoder. Indeed, even these new keepalive circuits are too big!

      4. Hi René,

        In terms of batteries, they could provide useful weight in the boiler, but LiPo and LiFe cells currently available are being designed for applications where the weight should be as low as possible. I suspect (but do not know) that greater density would be possible, increasing the weight and the electrical storage capacity. But an alternative is to use smaller batteries instead of stay/keep alive units, with a constant current providing a trickle charge to the batteries which is used to power the decoder etc. The benefit here is that enough power for, say, 15 minutes is all that is required, and wiring is simplified: no need to wire up crossing vees, reverse loops, turntable tracks and complicated point work. Power could be restricted to engine standing and servicing areas, or applied to all plain line.

        If I wanted a controller for each engine, then yes, the only reason for using DCC is that it already exists and all I would need is some way of hooking up a decoder to a controller (I presume this is easy, but I do not know how!)

        However, if there are many more engines than controllers, of which there are a few, then some form of centralised control is required to avoid anarchy. This does not need to be a high-powered booster, just a simple microprocessor capable of acting as a command station, connected to a transmitter – a Raspberyy Pi feeding a Sprog II thence a Tam Valley DRS transmitter is a solution I am investigating for my own use. The hand-held controllers link through the command station to the engines.

        This is what systems such as ProCab from Access are doing. If someone came up with a simple BT lite receiver to plug into the 6/8/9/21 pin socket of a decoder, and a transmitter which fitted “across the rails” or direct to the output of a command station (or an all-in-one unit) and which could also accept BT signals from a mobile phone (e.g. WiThrottle) then conversion from 2 rails to wireless control would be easy, and would not result in much redundancy of existing DCC installations: power boosters could be replaced with transmitters to extend the range, but most everything else could be used.

        My personal motivation is that there are some cracking sound decoders with customised settings and recordings, and great use of function keys to provide braking, set the sound and speed curve to match the load of the train, control the whistle, cylinder drain cocks, air pump, etc. These could be combined with tactile controls to achieve a lot of the functionality you are talking about, and retain the command control part of DCC, without using the rails for the control signal and direct power.
        (I am not personally interested in things like turnout control and route setting, as my tastes in railways are for the simpler things, but this would all be possible.)

        I hope that makes sense to you and anyone else still reading!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s