DCC Compatibility.

[steveprice]

Hi, as a two month newbie I'm wondering, are all makes of decoder compatible with all makes of controller? Or is it hit and miss. Is there a general rule one can apply. I don't want to do anything fancy, just run trains (so we can discount sound for example). Thanks. 

[Oldddudders]

DCC has standards for the basic things within a decoder, but manufacturers are able and entitled to add other features. So by and large, any decoder should respond equally well to any DCC system. People often develop a taste for one decoder manufacturer, and these are not often the cheapest, but brand loyalty is not needed to have a working model railway. 

[smokebox]

In theory you should be able to use any make of decoder in any make of loco using any make of controller, though you may find one or two exceptions in reality.

[KingEdwardII]

21 hours ago, steveprice said:

 are all makes of decoder compatible with all makes of controller?

To first order, I think the answer is "yes". All DCC decoders follow the standards for DCC and should behave in the same basic fashion for a given command from a controller.

 

However, that is very different from assuming that all makes of decoder are equivalent.

 

The very basic functions tend to be the same - like driving a loco forward and back. Anything beyond that can vary widely. Some makes of decoder are much better at controlling the loco motor than others (sensing back EMF, etc). Some makes have better acceleration & deceleration handling than others. Handling of other functions such as lights, sounds etc, can vary between decoders of the same make - for those, you really have to inspect the detailed capabilities described by the maker. This includes the number of functions available and how they operate.

 

Finally there are aspects such as the ability to add a stay-alive, the physical size of the decoder (will it fit in my loco??) to consider - such things vary a lot.

 

Having said all that, you will probably find it easier to choose one or two makes of decoder and stick with that choice. I mainly have Lenz and Zimo. The exact decoder I use partly depends on the loco - what interface does the loco have (8-pin, 21-pin,etc), what size fits the available space, what functions are going to be needed...

 

If you're going to use sound decoders, I advise you to do as much reading as possible for the target loco and the alternative makes of decoder - it ain't a straightforward choice and they come with a hefty price tag.

 

Choosing a controller is a whole different game - there are discussions on here dedicated to that topic and they are well worth reading.

 

Yours, Mike

[johnb]

 My experience is mainly with non-sound chips, but have run some sound locos without any issues. I use an NCE PowerCab and a variety of decoders TCS, Zimo, Lenz, Digitrax in the main. Some DCC manufacturer installed locos Atlas and Bachmann and all work fine for me. As KE11 says above my choice depends on 21pin, 8pin, number of functions, size and price.

I avoid the cheaper ones, having had some issues some years back with bulk buys. Not sure what current prices are, but a couple of years back I usually paid in the region of £20/£25 as I only really need 4function decoders and the layout is simple. I would stress that's what suits me! Others will doubtless differ

[GoingUnderground]

First: The Simple Bit

All makes of DCC loco decoder, and also DCC accessory decoders for operating point motors and the like, that comply with the NMRA standards should work with all DCC controllers that comply with the NMRA standards.

 

If a loco comes as DCC Fitted, meaning the manufacturer has made it with a decoder installed, then that too should work with any DCC controller.

 

Second: The Slightly Harder Bit

However, there are several different standard interfaces used for connecting up a loco decoder to the loco which are used by most of the manufacturers. If a loco has an interface it will be called DCC Ready (meaning Ready for you to install a decoder of your choice with the appropriate interface.)

 

What makes manufacturers use different interfaces across their models is the physical size of the model and hence the space inside, and the extra features such as lights on a model or sound.

 

When buying a loco decoder you need to make sure that it has the same interface as the loco into which you want to fit it. Most loco decoders are available in versions for the different interfaces, and there are some adaptors in case the interface on your decoder doesn't match the interface in the loco. Generally it is better to avoid having to use an adapter as there may not be space for it. Also most decoders are available in versions with just trailing leads so that you can fit a decoder to a loco without an interface.

 

Third: The Other Slightly Harder Bit

In addition to coming with different interfaces or even with just trailing wires, loco decoders also come in different physical sizes which tends to be an indication of the maximum current handling. So when buying a loco decoder you also need to make sure that the one that you choose can also handle the maximum current draw of the motor in your loco. There are no standards for decoder size or current handling.

 

Fourthly: Accessory Decoders

Accessory decoders also have maximum current handling limits per output. So if you do decide to use accessory decoders to operate your points, make sure that the decoder can handle the current that your point motor is likely to draw. This is particularly relevant for traditional solenoid motors.

 

Some point motors are motor drive stall type, and not all accessory decoders can handle motor drive stall types.

 

You can also use servo motors to operate points, and if you decide to use servos you will need an accessory decoder specifically designed for servos. 

 

Lastly: The Tricky Bit - Connecting anything else.

There are no official standards for how to connect additional throttles, occupancy detectors, boosters and the like to controllers. Instead there are various proprietorial standards, some of which are followed by several manufacturers, such as Digitrax's Loconet also used by Uhlenbrock and Digikeijs amongst others, and Lenz's Xpressnet also used by Hornby and Roco amongst others, whilst some are unique to specific manufacturers such as ESU's ECoSLink which is only used by ESU on their own equipment and on equipment that they make for Bachmann and Piko.

 

Also just because different controllers and add-on units use the same socket never assume that means you can connect them together. There are no standards on what each type of socket can be used for. Always check that the sockets on items that you want to connect together are using the same standard before you try connecting them.

 

 

Apologies for the length of this note. I hope it hasn't been too confusing.

Edited July 26, 2021 by GoingUnderground

[FlightRisk]

I can tell you firsthand that sadly in our loosely regulated hobby, many decoders do NOT follow the NMRA spec. You will find that for running trains on your main track, where the tight adherence to the timing standards is not so critical, any halfway decent decoder will work with any good Command Station. But when it comes to programming and reading and writing CVs, you will have issues if you buy lots of different decoders from different manufacturers because of their poor ACK response design. DCC++EX gets around this by loosening our default tolerances significantly from the specification and having detailed diagnostics that allows you to find out exactly why a decoder isn't working when you get the dreaded "308" error in JMRI. We then make it easy to change the settings even further to adjust to these poorly designed decoders. So you can get almost all of them to work with tweaking.

 

We've been tempted to make a "beware of these decoders" list, but we don't want to get into a war with decoder manufacturers. I imagine many are very small businesses. They don't want to be out of spec, they have just never had anyone test their decoders to the level we have and report the bugs or their misinterpretation of the spec to them.  Two manufacturers have already modified their firmware when we pointed out with scope traces why their decoders were causing users issues. But to be fair, a few of the specs are purposely vague and that leads to a lack of conformity between manufacturers where you could argue either was right depending on how you read the spec.

 

Fred

DCC-EX

Edited July 28, 2021 by FlightRisk
update sig

[Crosland]

I have not come across any decoder that the SPROG cannot program in quite a few years.

 

Apart from the obvious tat didn't even support read back (they know who they are) all the "problem" decoders have been from well known brands.

 

 

[Nigelcliffe]

15 minutes ago, Crosland said:

I have not come across any decoder that the SPROG cannot program in quite a few years.

 

Apart from the obvious tat didn't even support read back (they know who they are) all the "problem" decoders have been from well known brands.

 

 

 

Agreed, as a long time user of Sprog products.  

 

[FlightRisk]

The issue is wasted time, among other things. If the specification says that an ACK signal is 60mA for 6ms, and a decoder pulses only 30mA or for 3ms or 6ms but with dropouts to 0 in that 6ms or pulses for 12ms, it is an annoying problem. For example, having to dumb down our ACK detection to work with the lowest common denominator means that page reads will be twice as long. We can turn that on and off, but having to create exceptions like this isn't the best solution.

 

Fred