Jump to content

DCC Decoders for Motor Cars


Recommended Posts

Hello KenS,


Thanks for acknowledgement in your web.  It is a very interesting site.


Now, I want to introduce you to a Japanese blog.  It is not mine.  It is relevant to this topic.  It is the blog of using Kato decoders in other brand of car.  You can visit the blog here: http://blogs.yahoo.co.jp/okiraku_dcc/folder/536322.html


For example, if you use DC then the head light and tale light operate automatically depending on the DC current.  If you want such simplicity in DCC then why not use the decoder especially made for this purpose, FL12?  I can buy them in Akihabara for just 1,200円.  Just US$14 is cheaper than Digitrax decoder.  The form is convenient for placing under seating insert.


Here is an installation for Tomix 300 Series Shinkansen:



  • Like 1
Link to comment
Martijn Meerts

The bulk of the cost of many decoders is in their (lack of) size .. The smaller a decoder, the more expensive it gets, especially when you start adding many of the features that most decoders have nowadays ..


The Kato decoders make sense in Kato trains prepared for them, even though some will give you headaches because they don't work. I don't see any reason to install Kato decoders in other trains though, especially not the motor decoder which is huge ;)

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


That wasn't what I said, but perhaps I said it badly.


Per the NMRA page you cited "When the values in CV15 and CV16 are equal, all CVs in the decoder can be read or written."  There's also a description in RP-9.2.2. (as of the 2007 edition) that defines the recommended function, which is only to prevent writing (still depends on them being equal to allow a write). Digitrax clearly implemented their version (as you noted) which is a superset of the standard version of locking.


My experience was that if I set CV15=1 and CV16=1 the decoder remained locked.  It was only unlocked by setting both to 0.  That's a violation of the NMRA spec and the original proposal. I had to set both to zero to enable reading/writing. Setting both to 1 (or 0 or anything else) should unlock it. 


By default, on the EM13 both are zero, so merely clearing CV54s disable bit won't lock the decoder, you also need to change at least one of the two lock CVs.  There's an implication (but not a clear statement) in RP-9.2.2 that only CV15 can be written when the decoder is locked (CV16 is supposed to be set once, beforehand, to lock it, then you set CV15 to match to perform an unlock).


However, my EM13 is still being a little flaky, so it may have other problems or I may have just shot myself in the foot in some other interesting manner. I haven't fully figured out how lock works on the EM13 yet.

Link to comment
Nice link E6.


Wish other companies would make an inexpensive decoder like the Kato decoders.


You can use the Digitrax DN135 with resistor 1k 1/4W connected to the motor wires.  It is just US$15.

Link to comment

After more testing, I've decided that the EM13 is properly implementing a superset of the decoder lock functionality per the NMRA standard, however I've uncovered what is likely a bug in my command station (an older Zephyr; I haven't tried this on the DCS100 yet).

Basically how decoder lock works on both the EM13 and a Digitrax DZ125IN I'm currently working on is very similar:

Both default to CV15=0, CV16=0, CV54=64 (64 is bit 6, the "Decoder Lock Disable" bit).  A successful reset restores these values, but you can't reset a locked decoder.

If CV54 bit 6 is clear, locking is controlled by CV15 and CV16.  If they contain identical values the decoder is unlocked, otherwise it's locked. I haven't tested for numbers larger than 2, and Digitrax says this only applying to 0-7 (the NMRA spec doesn't limit the bits). However, the two CVs aren't handled identically (and this confused me for a long time, partly because of a bug I hit).

Note that if CV15 is not equal to CV16 and you set a value into CV54 that clears the bit (like any of the values documented in their manuals) the decoder will lock.  It's a good idea not to touch CV15/CV16 unless you plan to be locking the decoder.  If you just want a decoder ordinal for other reasons, use one of CV105/106, the "User ID" CVs.

When the decoder is locked:
- No CV other than 15 can be written (this prevents a reset too).
- No CV other than 15 can be read.

On the EM13, CV54 can be written on a locked decoder, but not read and I couldn't read or write it on my DZ125IN.

What the NMRA says: (in RP-9.2.2)
Decoder Lock is a "uniform spec" feature, which means that manufacturers are supposed to implement it using standard CV values (if using the standard CVs).

"The Decoder Lock is used to change CVs in only one of several decoders with the same short address (CV1) or long address (CV17 and CV18) that are installed in the same locomotive. Assign a number to CV16 in each decoder (i.e. 1 to motor decoder, 2 to sound decoder, 3 or higher to other decoders) before the decoders are installed in the locomotive. To change a value in another CV of one of the installed decoders, first write the number 1 (motor), 2 (sound), or 3 or higher (other) into CV15, then send the new value to the CV to be changed. The decoders will compare CV15 to CV16 and, if the values are equal, the CV to be changed will be changed. If the values in CV15 and CV16 are different, the update will be ignored."

So, from that, you need to be able to write CV15 when the decoder is locked, but not CV16. No mention of reading is made. And the implication is clear that other CVs can't be written if the decoder is locked.

Digitrax doesn't appear to describe decoder lock in any manual. Their list of CVs calls 15 "Decoder Unlock" and 16 "Decoder Unlock Number" which implies the same meaning as the NMRA. The real documentation is online and says:

"CV16 is used to set the ID number of each decoder installed in the locomotive."

"CV16 can be programmed to a value from 0 to 7 inclusive. This value identifies a single decoder.  A unique value must be assigned to each decoder installed in a particular locomotive so that it can be selectively unlocked for programming later."

"CV15 is used to select the target decoder that will accept programming commands."

That's basically a restatement of the NMRA spec. However there's some additional text that implies that decoders won't respond to a read if locked. That's not part of the NMRA spec, but it isn't in conflict with it either, so it's a valid superset of the standard.

So, proper usage for the EM13 (and any Digitrax decoder) is to:

1. Set the number of the decoder (e.g., 0, 1, 2, 3 up to 7) into CV16.

2. Clear bit 6 of the lock CV.

The decoder is locked. You can do those in either order.

When you want to work with the decoder, write the decoder number into CV15. Note that you must remember what it was, or you can't do this, since you can't read CV16 when the decoder is locked. Since there are only 8 possible numbers (0-7) you can try them each in CV15 until one works.

The bug:

I think this is a bug in my Zephyr, but after attempting to write to CV16 when the decoder was locked, various things stopped working and I had to power cycle the Zephyr to restore it to proper functioning.  Also, those writes to 16 would always respond with an "OK" implying that the write had worked, although it never did if the decoder was locked.


My Zephyr is an old one, bought just after they came out, so that bug may not exist in more recent ones.


And I'm pretty sure it's the Zephyr rather than the decoder, because power to run the decoder isn't present on the programming track between operations, so the decoder ought to reset itself each time, and not only when I power cycle the command station.

Link to comment

Digitrax's original proposal prevent reading when locked. The reason is clear: If decoders A and B have different values in CV X, doing a read on CV X will report—because of the way reads work, that both decoders A and B have the same (lower of the two) values in CV X. So, it is impossible to do an accurate read of a CV that has different values in different decoders, unless the locked decoder shuts its mouth.

Link to comment
Hi everybody

Just get a KATO 10-387, may I install dcc decoder on it? if yes, which and how




Best thing would be to start a new thread on this. Not familiar myself with this particular model, but someone here must be…

  • Like 1
Link to comment

I just finished installing a TCS Z2 in a Kato 117 series (10-419) motor car.   While I've done many installs, this was the first one on a Japanese train.  I have a DCC blog that I posted the installation step by step with photos.


It's at:  http://n-scale-dcc.blogspot.com/


Next, I'll work on the end cars.



Link to comment

The TCS M1, or any other similar sized decoder would also easily fit in the same spot but might be just a bit more visible through the windows.  The price difference between the M1 and the Z2 is not all that much and I use Z2's quite a bit.   This would have been a great place to use a decoder that had one of its function outputs burned out with the motor output still working.

Link to comment
Guest Closed Account 1

Visible through the windows?


Check out a way a lot of use install decoders in the chassis.You grind out a pocket below one drive shaft.

Link to comment

Something bad seems to have happened to the formatting of Capt. Obliv's origional chart. I want to add some dimension details for sound decoders. Mainly as a reference for myself. Hopefully useful for others. 


Doehler & Haass SD10A,  21.2 x 9.1 x 3.4 mm

SoundTraxx TSU-1100, 27 x 10.5 x 5 mm

ESU LokSound micro, 25 x 10.6 x 3.8 mm

Digitrax SDXN136PS, 25.6 x 10.46 x 4.93 mm


I just noticed that the ESU website makes the claim that the LokSound micro is the "World's smallest LokSound decoder". A bit sly and misleading. "LokSound" is their trademark term. That's like saying "Wow, I'm the world's richest me". Woo hoo!

Edited by gavino200
Link to comment

Use looks like one of the forum software updates klobbered the table encoding. 


Ill look to see if I can fix it



  • Like 1
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...