Kato’s EM13 DCC decoder (29-351) is a specialized decoder used for the motor car in an EMU/DMU model or other “DCC Friendly” models made by Kato. DCC Friendly (the English term is used even in Japanese, rendered as “DCCフレンドリー” or “DCC furendorī”) isn’t the same as “DCC Ready”, and it is a phrase used by others to simply mean that a model is relatively easy to convert to DCC. But when Kato uses it, the phrase means “will accept Kato FR11, FL12 and/or EM13 decoders”. And the models that do so are primarily Kato’s N-scale Japanese prototype models: commuter trains, limited express trains and Shinkansen (bullet trains). They also use it in some steam locomotive models, including the American-prototype GS-4.


There’s a lot to say here, so I’m going to break this up. Today’s post will be about the decoder itself, and to an extent is merely recapping things I’ve said before. The next post will likely involve more investigations of the EM13 function, before I get into the actual details of CV programming for my trains (which could be a third post). While my focus is on the EM13 today, I’ll also say a few things about the other two decoders. I also have a Kato DCC Decoders page that summarizes the functionality with tables of CVs and other useful reference material.

The Kato Decoders

Kato’s EM13 decoder is a very simple zero-function motor decoder. It’s not designed to control even a headlight, which makes it a rather poor choice as a locomotive decoder, but a perfect fit for a motor car in the the middle of a multiple-unit train. In most installations the decoder works by sliding into a prepared cavity, causing one side of its two prongs to contact the brass strips carrying power from the wheels, and the other side to contact the brass tabs on the motor. The photo at the top of the post shows the motor side, and the two pads (left) that contact the motor. The photo below shows the side that contacts the pickups.


EM13 Track Side

In a multiple unit train, the decoder will be used in conjunction with a pair of the FL12 (29-352) decoders, which are specialized two-output decoders for the headlight and taillight. These work in the same manner as the EM13, sliding into a slot between brass contacts. Kato also makes an FR11 decoder designed to work with their interior lighting kits (it’s a replacement for the LED unit in that kit). I’ve never used an FR11, as they’re expensive and unnecessary: the non-DCC light kits work fine on DCC, as long as you don’t want to turn the lights off.

I’m not going to say much about the FL12. It’s a very simple decoder. While it supports Extended (four digit) addresses, it doesn’t appear to support Advanced Consisting or any light functions other than the basic F0F headlight/taillight directional control and use of F0 to turn the head/tail light off (or at least I haven’t been able to get any of them to work). Kato’s documentation indicates that you can remap the function from F0 to F3 or F5 via CVs 61/64, although I can’t imagine why you would. It also claims to support transponding, although I doubt a LED light alone is sufficient output load for that to work.

I’ve been using the EM13 and FL12 decoders for several years, but only in their most basic configuration. The time has come to upgrade a number of my trains to DCC, and as part of that I want to configure the EM13 to enable a variety of features. Kato’s documentation on just what is supported is a bit sparse, so I’m doing a bit of investigating before I define my preferred configuration.

I usually work on decoder programming through JMRI, using its “advanced” programmer to drive my Zephyr via a LocoBuffer-USB, which provides a nice simple interface to programming decoders, much better than punching buttons on the command station. There are a few places this breaks down. In particular, JMRI identifies these decoders (based on the very limited manufacturer and version CVs) as Digitrax decoders of the FX³ family, and while they’re made by Digitrax, there are a couple of places where they do things differently from the usual models, and a couple of things that need to be programmed using the ‘single CV” programmer. I’ll go into more detail on that when I come to discussing programming.

JMRI also has a set of Kato decoder definitions in the latest version, but these appear to be based on incorrect information and so they have problems as well.

Note: I use the programming track to program the Kato decoders in general. Digitrax prefers “Paged” mode rather than “Direct” mode, although both seem to work fine.

Kato Japan has a Japanese page about the decoder (there’s also an English version) and Japanese instructions are included if you buy them in Japan or from a Japanese shop (I don’t read Japanese, so that’s not much help).

What the supposedly more-authoritative Japanese site gives for specifications of the EM13 are:
- Current 1A, peak 1.5A
- Supports:
-- Decoder Reset
-- BEMF
-- Transponding

The info on the FL12 only notes that its two function outputs are limited to 125mA each.

The English instruction sheets (perhaps translations of the Japanese ones that come with the decoders in Japan) are available as PDFs on Kato’s website (see the accessories page). These add a bit more detail:

For the EM13 they note that:
- It is a Digitrax decoder (reading CV8 gives 129, Digitrax’s ID)
- Decoder reset uses the Digitrax method (write 8 to CV8)
- Extended Addressing (up to 9983) is supported
- CVs 2-6 can be used for a basic speed table
- CV57 can be used (in the range 0-15) for BEMF

For the FL12 they note that:
- The two function outputs are limited to 125mA each
- Extended Addressing is supported
- Transponding is supported
- The function can be remapped from F0 to F3 or F5

For the FR11 they note that:
- The function output is limited to 65mA and can’t be used with bulb lighting sets
- The function can be remapped from F1 to F0, F3 or F5
- Extended addressing is supported

And that’s all. Over the years, a number of people have discovered other functions the EM13 inherits from its Digitrax origins. Some of those have been codified in a list on the JMRI site (thanks to JNS Forum member E6系 for pointing this out). However, I think there are some flaws in that list, which I’ll describe after summarizing what it says.

To summarize, that page notes a few additional functions:
- CV9: motor drive frequency (a BEMF variable)
- CV17 (and implicitly 18): Extended Address
- CV19: consisted operation address
- CV57: droop compensation for standalone or consisted operation
- CV61: can configure several options
-- enable transponding (add 2 to enable)
-- support for AC “split field” motors (add 4 to enable)
-- use F5 to disable speed compensation (add 16 to enable)
-- use basic speed table in 128-step mode (add 32 to enable)
-- short-circuit protection (add 64 to disable, but you’d be crazy to do so)
- CV62: low nybble controls FX rate adjust (add values 0-127)
- CV62: high nybble controls lamp keep-alive voltage (add values 128-255)
- CV65: Kick Start value can be set
- CV67: Speed table is supported
- CV105/106: can be set to any value desired by user (these are the NMRA “User ID” CVs)

They also claim CV16 can be set to a value of 1-7 to lock the decoder. That’s not the standard NMRA lock method (which I’ve tried and which does not work) and it doesn’t seem to work in any event.

My own testing confirmed a few things and has turned up some additional detail:
- CV7: version, current models have 51, the same as Digitrax DN1xx decoders
- CV8: not only does reset work, setting CV8 to 9 will reset all of the decoder EXCEPT the speed table settings
- CV9: not yet tested, but it’s a basic Digitrax feature (set to 255 for non-supersonic PWM) and likely works
- CV17/18: Extended addressing works
- CV19 does work on the EM13
- CV66: forward trim works (set to 128 for 100%, lesser numbers to reduce, higher to increase)
- CV95: reverse trim works (ditto above for settings)
- CV105/106: are preserved even over a decoder reset

CV62 doesn’t appear to affect the FL12 (nor do any of the usual remapping or Digitrax special-effect settings seem to work; there’s no way to get Rule 17 headlights, for example, that I can find).

There’s a bit of wierdness I encountered involving CV54 and/or the decoder locking. I’ll detail that below. For now, I recommend not altering CV54.

and a bunch of experimenting has confirmed that many things usually found in Digitrax decoders won’t work on the Kato ones, so while JMRI identifies them as FX³-type decoders based on the manufacturer and version, that’s not really true. I’m sure they share a common code base, but there are clearly a few things added, and several removed.

Working with the Kato Decoders

Actually using the EM13 and FL12 can be a bit of a pain. Even just buying them can be hard. While U.S. dealers sometimes have a few, demand is low so inventories tend to be low also. And Kato’s method of “build a bunch and take a year off” tends to make availability at even Japanese suppliers erratic. The last production was in September of last year, and they’re already out of stock in many places. When they show up, I generally buy several, and have built up a small inventory for my long-delayed conversion project that way.

Installing them isn’t easy either. The FL12 fits into a hatch on the underside of the cab cars, but sometimes it’s really hard to get it in, and positioning is crucial: 1mm off and it won’t work. The EM13 install typically requires removing one of the wheel assemblies and its drive shaft, and getting that back in without breaking it is another problem area.

Once in, fiddling may be required. The niches they fit into are supposed to hold them in good contact with the pickups and outputs. They don’t always do so, particularly on older models, and in some cases you have to use thin shims under the brass pickup strips to push them into the EM13. Newer train models seem to work much better though.

The decoders, at least the EM13, are also fragile. They aren’t wrapped in any kind of insulation, and I’ve received several over the years that appeared non-functional despite extremely careful handling on my part (I know what ESD is and I take precautions). Since U.S. availability is sporadic, many were bought from overseas sources, where returning wouldn’t have been worth the postage even if they’d warranty them, and I just wrote that off as an added cost of using them.

Now all that sounds pretty bad (and I have at least one model where I’ve tried several times, and just can’t make one work), but in general now that I’ve had some practice, I can usually get them to work on a newer model the first time, or at worst with a bit of prodding without actually taking the car apart.

Programming them is also a pain. The load on the FL12 (and FR11) is too low to read CVs usually. You can write them, and get an “OK” when that works. That’s the theory anyway; I’ve had writes fail even though I got an “OK” from the command station. Now I just write each CV three times and that seems to work fairly reliably. I’ve read that hooking a 100 ohm load across the function outputs will allow CV reading, but that’s not very practical in their usual location. I need to build a test jig for the FL12, the way I did for the EM13, but I haven’t yet.

One thing that will work, sometimes, is reading them on the running track (Operations mode). This requires that you know the address, so it can’t be used to discover what address you programmed into one. And it’s not reliable; on my Zephyr it works some of the time. Also, not all command stations support Ops mode reading of CVs. I suspect the higher power here (compared to the programming track) somehow makes it easier to read them, although why that would be the case is unclear.

The EM13 is better. It usually programs the first time, but not always. WIth JMRI, the computer will retry a failed write, and I’m usually able to program even the entire 28-CV speed table in one operation (JMRI is an absolute essential if you want to use the 28-step table). One thing that’s particularly problematic is programming Extended addresses. Trying to do this via a DCC command station usually fails (probably because it depends on writing three CVs, which means there’s a good chance of one write failing). The method I use is to program each CV by hand. This requires translating the address into two 8-bit portions, but there are calculators online for that (see my Kato DCC Decoder page, down at the bottom of the page, for more detailed instructions and links to such calculators).

One thing you can’t do with JMRI is read every CV in the EM13 decoder. It will never work. But with the advanced programmer screens, you can read every CV on one page (usually, sometimes it takes a few retries) and gradually build up a complete list for an old and forgotten model’s decoder settings.

Consisting

One thing I wanted to do with a couple of my trains that have two complete sets of cab and motor cars normally joined into one train was to use Advanced Consisting to control the set as one train, while retaining the option to operate the two parts independently. That’s probably not going to work. You can set a consist address in the EM13 (you can write one to the FL12 also) and if the BEMF really is the standard Digitrax version, it should support tuning the consisted form separately from the non-consisted form. But the cab decoder won’t switch the head/tail lights when the consist address direction changes even if you’ve set it to use a consist address. That’s a big disappointment for me.

However, my command station supports Universal Consisting, where the command station keeps track of which decoder IDs are associated with the throttle. I can still use that, although I lose decoder awareness of consisting when I do, which means I can’t tailor separate BEMF intensities for consisted versus non-consisted trains.

Speed Tables

Speed tables are something else I want to use, and there I seem to be in luck. The EM13 supports both the Basic speed table defined by CVs 2-6 and the 28-CV table (used for both 28 and 128-step operation) in CVs 67-94. It also supports applying “trim” to the speed table, although I don’t know that I have a need for that.

And a Mystery, of Sorts

I had an odd thing happen during testing. I stopped being able to read my EM13 on the programming track. I could write it, and the changes were made (I could tell by running the train). And the decoder continued to work fine. I just couldn’t read it at all, and I’d been having no trouble for hours.

Now it’s possible I overheated it, or damaged it just by doing lots of writes, but even though I’d been at it for several hours, I don’t think I did enough to cause damage. Flash memory should survive hundreds, if not thousands, of writes, and I doubt I did more than a hundred all told. Rebooting the software and command station didn’t help. I’m going to leave it to sit overnight, and see if that changes anything.

But it’s also possible the decoder software just took a dive. I did reset the decoder, but that didn’t help either.

I’d done two things just before the problem occurred. The first was testing the CV54 “switching speed” function. The second was trying (again) to lock the decoder via CV15/16. I’d testing locking several times before, so I don’t think that was the problem. And reversing the lock didn’t fix it in any case. As far as I can tell, none of the Kato decoders implement a lock function.

CV54 is a bit of an oddity. It’s not documented anywhere as implemented on the EM13. Digitrax’s standard FX³ settings document allowed values of 0, 1, 16 and 17 (decimal). I found the default set to 32, implying there’s some other function controlled by this that’s enabled by default (the default value should be 0). However, I tried setting it to 1, which should enable the “switching speed” feature, while leaving torque compensation enabled (but disabling the mystery function). And sure enough, switching speed started working. I then went on to work on the decoder lock, and it was then (about 5 minutes after testing “switching speed” that the decoder stopped being readable).

Switching speed is a handy little function. If you activate F6, the effect is to reduce maximum speed to about 50% of the configured maximum, and reduce the effects of the momentum (accelleration and decelleration) features, making it easier to perform low-speed switching and similar actions.

I’m going to need to investigate more (turning the mystery function back on for one thing), and until then I recommend not using CV54 (or playing around with the lock function), just in case there is some bug that breaks decoders here.

Tags: DCC, Digitrax, Kato, JMRI, Zephyr