DCC Decoders for Motor Cars

This thread is for keeping track of good DCC decoders to use in Motor Cars, or any other car that has motor, but few or no functions, as is often the case at in the middle of an EMU or a bullet train. I'll keep this list updated as people report in.

 

[table]

[/td]

DE22x2

DE25x0

M1

MX620

LokPilot micro v3.0 DCC

73400

Silver Mini

DCX75D

Z2

DCX74zD

DZ125

Gold Mini

EM13

Manufacturer

NGDCC

NGDCC

TCS

Zimo

ESU

Uhlenbrock

Lenz

CT Elektronik

TCS

CT Elektronik

Digitrax

Lenz

Kato

Price

$32

$23

$32

$60

$55

$46

$45

$43

$35

$33

$25

$60

$22

Height

1.9mm

2.4mm

3.43mm

2.5mm

3.5mm

2.4mm

2.8mm

1.4mm

2.79mm

2.6mm

2.86mm

2.8mm

?

Width

9.3mm

11.6mm

9.12mm

9mm

9mm

7.5mm

9mm

7.2mm

6.6mm

7mm

8.7mm

9mm

?

Length

29.3mm

24.4mm

14.4mm

14mm

13.5mm

10.8mm

11mm

11mm

12.95mm

9mm

10.6mm

11mm

?

Total Area

272.49mm²

283.04mm²

131.328mm²

126.0mm²

121.5mm²

81mm²

99mm²

79.2mm²

85.47mm²

63mm²

92.22mm²

99mm²

?

Functions

2

0

2

2

2

2

2

2

2

4

2

2

0

BEMF?

◯

◯

◯

◯

◯

◯

◯

◯

◯

◯

◯

◯

◯

Fancy Momentum?

✕

✕

◯

◯

◯

✕

◯

✕

◯

✕

✕

◯

✕

Transponding?

✕

✕

✕

✕

✕

✕

✕

✕

✕

✕

◯

✕

◯

RailCom?

✕

✕

✕

◯

◯

✕

✕

✕

✕

✕

✕

◯

✕

Max Current (cont. total)

500mA

1000mA

1300mA

800mA

750mA

600mA

500mA

1000mA

1000mA

1000mA

1000mA

500mA

1000mA

Max Current (peak total)

2000mA

3000mA

2000mA

2000mA

[td]

800mA

2000mA

2000mA

2000mA

1250mA

800mA

1500mA

[/table]

 

BEMF

Back EMF (BEMF) is a method for regulating the motor speed for smooth low-speed operation, and maintaining constant speed up and down inclines. It works by inferring the motor's speed by measuring the amount of feedback generated by its rotation—called back EMF—and adjusting the voltage up or down to maintain a constant speed. This feature is critical for low-speed operations, including smooth acceleration and deceleration from and to a full stop.

 

Fancy Momentum

All the decoders surveyed offer basic linear acceleration and deceleration, but some manufacturers go a step further. TCS offers 3-step acceleration and deceleration curves for non-linear momentum. This feature is nice for simulating smooth and realistic-looking station stops and starts.

 

Lenz and ESU offer a feature called "constant stopping distance", which, when active, varies the deceleration term to bring the model to a stop within a fixed distance, regardless of the speed of the model. This is great for automating station stops, because you will know the distance from the station throat to the stopping point, but you might now know just how fast a model is traveling when it enters the station throat.

 

Bidirectional Communications

 

RailCom and Transponding are two different systems of bidirectional communications over DCC. Normally, DCC is a one-way signal: From the command-station to the decoder. There is normally no method for DCC decoders to respond. RailCom and Transponding are methods for the decoder to send a response to the command-station. This is really useful for automated control of a layout, but is not a necessary feature to implement basic block occupancy detection, although both methods require a block occupancy detector detector to work. I won't get into a discussion of the advantages or disadvantages of each system; you can read more about those elsewhere on the Internet.

 

RailCom is Lenz's semi-proprietary standard. RailCom responses can be detected by a Lenz LRC130 RailCom detectors and reported to a computer via the Lenz LRC135 RailComBus USB adapter.

 

 

Transponding is Digitrax's proprietary standard for bidirectional communication, and is currently only implemented in Digitrax decoders and Kato decoders designed by Digitrax. Transponding responses are detected by a Digitrax RX4 detectors, which must themselves be attached to a Digitrax BDL168 block occupancy detector. Transponding events can be communicated to a computer via the Digitrax PR3 LocoNet USB adapter.

 

Maximum Current Ratings

The current rating of a decoder tells you the largest load you can connect to the decoder. Each light, motor, speaker, etc., draws a certain amount of current; attaching too many will cause the decoder to overheat and perhaps even die.

 

A manufacturer often lists two or more different current ratings. A current rating is either a continuous rating or peak rating.

 

Continuous Total Current is the total amount of current that the decoder can supply for all functions combined over an indefinite time period. The sum of the current draw of all lamps must not exceed this amount. This may limit the number of lamps or other loads you can attach to the decoder.

 

Peak Total Current is the total amount of current that the the decoder can supply for all functions combined for short bursts. This is particularly important for motor decoders, where the stall current of the motor (the amount of current the motor draws when it is stalled or locks-up) must be less than this number.

Edited February 7, 2014 by Martijn Meerts

Great thread!

Don - I have a question, in an earlier thread you were one of the first people I know that got the Kato EM13. As I recall there were some problems, would you recommend that decoder? It looks very easy to install and price wise might be the least expensive on the list.

The EM13 is…well…adequate. I don't know that I'd recommend it, but I also wouldn't recommend against it, as it does have its niche (cue drums).

 

Pros: Inexpensive, in new Kato models it's completely hidden, offers Digitrax Transponding if that's your thing.

 

Cons: Very minimal feature set (no 4-digit addressing!), no CV read-back even in service mode (on the programming track).

 

Here's my original, if rather terse, review of the feature set of the EM13

http://www.jnsforum.com/index.php/topic,26.msg770.html#msg770

I guess whether a decoder is adequate or superior is down to personal taste a lot. For example, I think the Lenz Gold (and the new version of the Lenz Silver) are superior, considering they do exactly what I want, and for what they can do, I don't think they're that expensive (especially not the Silver.) Digitrax decoders might be great and much better than Lenz (just as an example, I don't know much about Digitrax), but Digitrax is hard to get in Europe, so for me it wouldn't be a superior decoder until they find some european distributor.

 

Maybe we need an "Excellent" or "Great" or something in the list to distinguish between adequate and good decoders ;)

I guess whether a decoder is adequate or superior is down to personal taste a lot. For example, I think the Lenz Gold (and the new version of the Lenz Silver) are superior, considering they do exactly what I want, and for what they can do, I don't think they're that expensive (especially not the Silver.) Digitrax decoders might be great and much better than Lenz (just as an example, I don't know much about Digitrax), but Digitrax is hard to get in Europe, so for me it wouldn't be a superior decoder until they find some european distributor.

 

Maybe we need an "Excellent" or "Great" or something in the list to distinguish between adequate and good decoders ;)

 

Probably so. The list as is is a starting point for a discussion.

 

While I agree that the Lenz Gold Mini is an amazing decoder generally, I'm not convinced it's the best possible decoder for installation into motor cars. It could be smaller (fewer functions) and cheaper (lots cheaper). What the Digitrax and TCS decoders lack in features they make up for in price. I just haven't seen a decoder that—to me—strikes the right balance for the motor car of an EMU.

 

People will disagree :D

 

So, perhaps I should avoid ranking them, at least beyond a basic sufficient/insufficient classification scheme? Or maybe a more multi-dimensional ranking system so that readers can pick and choose based on their personal preferences? That sounds better, actually.

I've updated the information above to be consistent with this post on my blog:

http://akihabara.artificial-science.org/dcc/dcc-for-motor-cars/

 

I've left the editorializing out this thread, and reserved the recommendations for my blog :D

...

 

RailCom is an open standard developed by Lenz and adopted by the NMRA as a Recommended Practice for DCC. That is, it is now an official, if optional, part of the DCC specifications. RailCom responses can be detected by a Lenz LRC130 RailCom detectors and reported to a computer via the Lenz LRC135 RailComBus USB adapter.

 

...

 

I just thought I'd post this update as, to my knowledge, the NMRA has not adopted either Transponding or RailCom as a standard or recommended practice.

 

Cheers

 

The_Ghan

While it's not adopted, they're clearly working towards RailCom and it's a draft RP. Recommended Practice RP-9.3.2, which was reissued this May (26 May 2012) defines the "Communications Standard for Digital Command Control Basic Decoder Transmission", and makes copious reference to RailCom. The document, which is bilingual German and English, appears to have been authored by Lenz.

 

The new document replaces the much less specific 2003 draft RP.

 

There's a page on Lenz' site that describes RailCom and which notes they've donated the patented technology to the NMRA.

 

As an "RP" I'm not sure there's really a line between draft and adopted, except that manufacturers are going to be reluctant to build hardware until they're sure it's not going to change any more, so taking the word "draft" off the RP will be a big boost to RailCom.

While it's not adopted, they're clearly working towards RailCom and it's a draft RP. Recommended Practice RP-9.3.2, which was reissued this May (26 May 2012) defines the "Communications Standard for Digital Command Control Basic Decoder Transmission", and makes copious reference to RailCom. The document, which is bilingual German and English, appears to have been authored by Lenz.

 

The new document replaces the much less specific 2003 draft RP.

 

There's a page on Lenz' site that describes RailCom and which notes they've donated the patented technology to the NMRA.

 

As an "RP" I'm not sure there's really a line between draft and adopted, except that manufacturers are going to be reluctant to build hardware until they're sure it's not going to change any more, so taking the word "draft" off the RP will be a big boost to RailCom.

 

As I become familiar with the way the NMRA does business, I can say that, unfortunately, that doesn't mean much. It just means there is at least one person left on the committee who hopes something will come of it, and has some energy. But I can pretty much guarantee that the Board of Directors, who must sign off on any document to make it official, won't touch it with a 10 foot pole. Too many legal thorns on that one now.

Hi KenS,

 

Thanks for the update.  I won't bother to reference this post in the other threads as you've already placed pointers back to here.

 

It is an interesting proposition that NMRA has, to adopt a proprietary product as a standard.  Actually, it's not proposed as a standard, but as a Recommended Practice.  But we both know that the effect is the same: product endorsement.  I happen to be a Digitrax user, but would be equally alarmed if Transponding was the proposed recommended standard.  Competition is good.  RailCom is good.  Transponding is good.  Both work slightly differently but perform the same basic function of reporting back the identity of a particular train. 

 

I can certainly see an advantage of the extended packet protocol of RailCom for bigger scales, particularly live steam.  RailCom has the ability to report percentages of fuel, water, sand, battery level, etc. in live steam.  Knowing these, it can search for appropriate filling stations.  It can report the actual speed of a consist.  But I don't know how these things would help us N-scalers, or any other scale that is rail-powered.  Indeed, DCC can run happily without Transponding or RailCom at all.  Software like JMRA and TrainController use RailCom and Transponding only to confirm the identity of a consist.

 

Digitrax has combined occupancy detection with signalling, but I presume Lenz has something similar.  As we all know, there are also other developers who have occupancy detection and signalling that works for DC, AC, and DCC.  So the NMRA has probably quite rightly avoided the subject.

 

It's a pity that Digitrax and Lenz can't sit down to work this out together and make both products work for the future.

 

BTW, Lenz has only released the technology to NMRA.  As I understand it, RailCom is only available to other manufacturers through the payment of royalties.  Once one technology has been endorsed over the other do you think the royalty payments will come down?  I think not.

 

I'd be interested to know what the Cap'n thinks of this and it's effect on Rail Stars.

 

Cheers

 

The_Ghan

ESU has added various RailCom features to the ECoS recently, they're actually working together with Lenz on it now. The recent addition was RailComPlus, which allows you to just put a DCC train on the track, and the ECoS will immediately recognize the loco, and where needed assign it an address.

 

Apart from that, RailCom (and transponding for that matter) is only useful as an additional safety measure to make sure a certain train arrives in a certain block.

Two quick points, having just returned from th NMRA convention, and having a chance to talk to folks on the DCC working group.

 

1 DCC was itself originally a commercial product developed by, yes, Lenz in the 1980's. So, this is nothing new in and of itself.

 

2 Lenz is prohibited by German law from distributing royalty-free licenses to its patenets in Europe. I've been told the fees are the minimum allowed by law.

 

the real difficulty lies in patents NOT held by Lenz in the  US, unfortunately. Still not clear on the details, but I'm pursuing the full story still.

The original Marklin digital system was actually designed and built by Lenz as well, and the limitations of that system made them start on what became DCC.

Thanks for the update Cap'n.

 

I didn't know that Lenz developed the original product.  It will be interesting to see if RailCom is adopted as a Recommended Practice.  Would that preclude Digitrax from being adopted as well?  Recommended practice doesn't necessarily imply exclusivity as a Standard might, does it?

 

The relationship between Kato and Digitrax is perhaps what is keeping the pendulum balanced.  Both companies offer great product in my eyes.

 

Cheers

 

The_Ghan

Thanks for the update Cap'n.

 

I didn't know that Lenz developed the original product.  It will be interesting to see if RailCom is adopted as a Recommended Practice.  Would that preclude Digitrax from being adopted as well?  Recommended practice doesn't necessarily imply exclusivity as a Standard might, does it?

 

The relationship between Kato and Digitrax is perhaps what is keeping the pendulum balanced.  Both companies offer great product in my eyes.

 

Cheers

 

The_Ghan

 

Digitrax refuses to license their Transponding technology to the NMRA in a way that would permit competition. They prefer to be the sole curators and gatekeepers on Transponding. RailCom will probably not become an RP, but time will tell. At any rate, at least as far as DCC is concerned, an RP is pretty much a de facto standard. This is not true for other parts of the NMRA standards, but because of manufacturer fragmentation, if you want to maintain DCC compatibility in a product, you'd better hew to the RPs as well.

What's the smallest and least expensive decoder I can use for a motor only application?

 

The Z scale decoder prices are bigger than HO.

What's the smallest and least expensive decoder I can use for a motor only application?

 

The Z scale decoder prices are bigger than HO.

 

Right now, the TCS Z2 is the smallest North American decoder; there are smaller available from CT Elektronik in Austria. Of course, Railstars is working on the very tiny Aegaeon:M (indeed, I am working on the firmware as I type this!), but it is still a few months away from release.

I figured I'd post this here, rather than in the other EM13 thread, since this one is the sticky'd motor-car thread and the EM13 is one of those.

 

I just ran across a really odd bit of undocumented EM13 functionality, or rather documented-but-not-so-youd-notice functionality (it may also apply to the FL12; I haven't tested that yet).

 

My EM13, which has software version 51 (decimal) per CV7, has an interesting feature: the decoder lock feature is disabled by default, but you can enable it. And you may enable it by accident if you follow their documentation.

 

CV54, which is documented to control both the "low speed switching" and "torque compensation" features (it's another register CV where you set bits to turn things on/off) has an undocumented bit.  Set bit 6 (add 64 to the value in the CV) and it disables the CV15/16 decoder lock feature.  And mine at least shipped with that bit set.  If you clear it (as you will by setting CV54 to the documented values) then decoder locking works.

 

And Digitrax's decoder lock, at least in the EM13, is fairly draconian.  Set either CV15/16 non-zero (if CV54 bit 6 is clear) and not only can't you reset the decoder, you can't read any of its CVs either.

 

Which is actually potentially useful.  Lock the two cab decoders, and they'll never respond to any CV changes you make to the motor car decoder (I'm presuming the FL12 works the same way, and I need to test that).

 

This had me pulling my hair out for more than a day after I locked my decoder and didn't realize that's what I'd done.  And I probably never would have figured it out, except the mystery CV54 bit (which I'd noticed, but hadn't understood) actually is documented, but in the tech support entry for CV15/16.

 

BTW, it appears that decoder locking may not prevent all writes to the decoder.  I need to dig into that aspect a bit more.

 

Digitrax: masters of obscure documentation.

Ken:

 

Can you clarify the CV functions a little more?

 

What were you trying to do originally that you stumbled into this?

Digitrax: masters of obscure documentation.

 

Ken,

 

In the beginning I had issues with Digitrax and the documentation but reasoned out the obscurity is for the majorities well being and Digitrax's sanity. Once we realize the documentation is there (but not easy to find) it makes things a bit of a treasure hunt.

 

I only run Digitrax as they have more feature set than the rest.

 

 

oh,  A few years ago I called Digitrax about the EM and FL and he said it was a Kato product that they make period. I took that as some kind of agreement that draws lines in the sand.

 

Anyway this is a good find as it is a form of subnet masking.

 

Inobu

Ken:

 

Can you clarify the CV functions a little more?

 

What were you trying to do originally that you stumbled into this?

 

Basically, I'm trying to figure out what the EM13 (and also the FL12) can and can't do relative to the usual Digitrax decoders, since it's similar but not identical.  There's documentation here, and on Kato's site and in JMRI, but not all of the bits line up with each other. And some may be out of date, since the current decoders seem to have the same software version as recent Digitrax decoders in CV7, and older ones had an earlier version.

 

So I just built up a list of typical NMRA-defined functions, typical Digitrax-defined functions, and known functions of the Kato decoders, and started trying them out to see what worked and what didn't.  I also read every single CV (up to 120 or so) on the EM13 to see if any were non-zero (which is how I found the odd number in CV54).  There are a few other oddities, but they appear to apply to function remapping, and since the EM13 has no real functions I don't think they mean anything.

 

The only real things of interest so far are decoder locking (described in the earlier post) and "switching speed" (F6 drops top speed and reduces the momentum effects, for more precise low-speed control) enabled by adding 1 to whatever value is in CV54 by default. As noted in the other thread I also confirmed that trim (both forward and reverse) work, which I hadn't seen documented anywhere. That's handy if you want a speed table but with reverse at a lower set of speeds than forward.

 

I made a post this weekend on my site with a table summarizing what I'd found so far (this was before I'd figured out the lock function), and I'll make at least one more before I'm done and have worked out what settings I want to use for my trains.  When I get a final table of identified functions, I'll post something more complete here.

 

Inobu: You're right, it's pretty clear that despite Digitrax making it, and doing some things the same as their other decoders (likely a common code base) there are significant differences in the Kato decoders to both the FX and FX3 decoders made by Digitrax.  In particular the function remapping documented by Kato (which I haven't tested yet) is not something I've seen done that way on any other Digitrax decoder.

Edited January 15, 2013 by KenS

Ken, it turns out that the locking behavior observed in the EM13 exactly mirrors Digitrax's original decoder lock proposal (since adopted as part of the DCC standard): http://www.nmra.org/standards/DCC/WGpublic/0305051/0305051.html

I don't think it's an exact match for what you linked, Don.  That says if you set 15=16 for non-zero values, the decoder is unlocked.  But I tried and couldn't replicate that on my EM13.  For any non-zero value in either, even if matching, the decoder locked.

Mr KenS,

 

I looked at your report but it is very complicated.  Could you prepare a summary table of CV settings and also unique procedures?

 

That woud be most helpful.

I don't think it's an exact match for what you linked, Don.  That says if you set 15=16 for non-zero values, the decoder is unlocked.  But I tried and couldn't replicate that on my EM13.  For any non-zero value in either, even if matching, the decoder locked.

 

I don't see that. I do see:

 

 

When the values in CV15 and CV16 are equal, all CVs in the decoder can be read or written.  When the values in CV15 and CV16 are not equal, only CV15 can be written or read.

 

and

 

 

CV16 will carry a number from 0 to 7 inclusive.…

0: Reset value, as shipped

255: Broadcast ID so all decoders can be programmed to the same address at the same time.

 

I do not know what a "reset value" is. But I don't see anything that says if CV 16 = 0, ignore decoder lock.