Decoder Address reads as 16383

[djconway]

I am unpacking locomotives that have been stored for a while, some as long as 5 years.  All with Digitrax decoders, some hardwired (DZ121, DZ123) and the others with drop in replacement boards (DN146A0, DN163A2 and others.  These locomotives are stored in their original boxes in a larger polyethylene boxes. All locomotives were running fine before being stored.  (I'm finally getting moving on the layout and am getting stuff out to run some trains.)

Of the locos tested 4 have been Atlas, 1 is an Inter Mountain and 1 is an ER Shark.

What I am seeing is that when I use JMRI to read the 4 digit address it returns 16383 and the locomotive will not operate, nor will setting CV8 = 8 reset the decoder.  Further attempts to read individual CV's (1, 2, 3 ... 128) all show a value of 255. 

Not all locos stored in the same box exabit this behavior but enough have that I am concerned.

1- Could this be an issue with how I am storing the locos?
2- Could there be a problem inherent with Digitrax decoders?
3- Could this be static electricity damage?

Is anyone else seeing this sort of thing?

[EL3632]

I have had this happen occasionally, things to check first are for dirty wheels/track, and shorts in the decoder. That at least identified most of the problems I had.
Alternatively, if you do find the decoders are dead, the Intermountain F unit decoder type with no motor tabs is a perfect fit for the ER Shark, I soldered wires between my motor and the decoder.

[peteski]

I norder to generate stating electricity there has to be either friction betoweem static generating materials, or separatation of those matrials (another form of movement).  If the models sti still, there wwill nto be any static generated.

Decoders are highly integrated complex computing devices. They have hundreds of thousands (or even millions or billions  in sound decoders) transistors in very small packages. Their programming it stored in Flash memory.

The problem you describe (the decoder "loosing its brain" or failing can be causes by many different things.

It could just have failed when it was powered up after long storage.
It could have been affected by static electricity while it was still operating (before storage). Damage from static electricity can show up some time after the zap occurred.
Even  cosmic rays might have damaged the delicate circuitry.  Unlikely, but possible.

What you experienced is not some rare occurrence. It can happen more frequently than you realize.    Sometimes only some memory locations are corrupted, and the reset procedure (or reinstalling the firmware on decoders that are capable of that) will restore their functionality. But sometimes the failure is fatal, and the decoder has to be replaced.

[svedblen]

Decimal 16383 is hex 3FFF and decimal 255 is hex FF, i.e. both numbers are all binary ones. To me that looks more like a general problem i.e a problem with JMRI, the wiring or the the DCC controller rather than a problem with the individual decoders. Does the decoder readout work for any other locos? Just guessing here.

[djconway]

The controller / JMRI are working on 80% or more of my locomotives, 93 tested so far 7-8 of this failure. The one in question is one that I noted wasn't working right 4 years ago.

I fired off a help request to Digitrax, let's see what they say.

One additional interesting thing is that some of these locos run on DC

Well Digitrax's answer was less than stellar -- Clean the wheels - wipers and decoder contacts. ( no change )
Looks like I'll be looking into different decoders for replacements.

[John]

The first thing I would do is try to reset the decoder on the mainline .. using the throttle .. of course you need to take the rest of your locomotives off .. sometimes, older decoders need a little more oomph .. then try to read back using the throttle ..

 btw .. what command station are you using?

what is your interface?  locobuffer, PR 3, etc

is the track completely clean on your programming track


after you try all that ..

get some aligator clips, -- take the shell off the loco, put an aligator clip on each half of the locomotive .. the other end of the clips, hook up to the outputs of the booster . then try to do the programming ..  were trying to eliminate all the mechanical parts between the decoder and the programming track

[peteski]

Decimal 16383 is hex 3FFF and decimal 255 is hex FF, i.e. both numbers are all binary ones. To me that looks more like a general problem i.e a problem with JMRI, the wiring or the the DCC controller rather than a problem with the individual decoders. Does the decoder readout work for any other locos? Just guessing here.

He mentioned that reading any CV from the bad decoder results in reading 255 (0xFF).   The 16383 value is probably derived by the JMRI reading 255 from both long address CVs.  Since not all the bits in the "high" address CV are utilized (0x3F uses only 6 bits), the JMRI calculates 16383.

Djconway, what happens when you try to read a long address when you remove that defective loco from the track?  I suspect you will still see 16383.

While not directly related to this problem, here is some interesting info about DCC addressing from a DCC guru.
https://sites.google.com/site/markgurries/home/technical-discussions/decoder-addressing/address-confusion

[djconway]

Djconway, what happens when you try to read a long address when you remove that defective loco from the track?  I suspect you will still see 16383.

When I read a known good locomotive JMRI and the DT400 controller return the proper address.  In this case I tested 2 Atlas Alco C-628 locomotives, one with the Atlas "Dual Mode" decoder and the other with a Digitrax DN163A0.  Atlas decoder reads and operates as expected, the Digitrax decoder loco reads as address 16383 on JMRI and 6383 on the DT400 controller.

I am using a Digitrax Super Chief 5 amp controller connected to a PR3 interface used in the "loconet" mode.
I have a test loop of track that I can select DC - DCC - DCC-Program via 3 DPDT toggle switches.  This configuration allows me to test run a loco on DC or DCC or to set the test loop to be a programming track.  (I'll try to post a diagram)

I'm not new to DCC - my first DN93 install was in 1997 and it still runs today.

[djconway]

I have had this happen occasionally, things to check first are for dirty wheels/track, and shorts in the decoder. That at least identified most of the problems I had.
Alternatively, if you do find the decoders are dead, the Intermountain F unit decoder type with no motor tabs is a perfect fit for the ER Shark, I soldered wires between my motor and the decoder.

I wound up hardwiring a DZ126 in place of the specified DN142E2 decoder, but thanks for the reply.

[djconway]

The first thing I would do is try to reset the decoder on the mainline .. using the throttle .. of course you need to take the rest of your locomotives off .. sometimes, older decoders need a little more oomph .. then try to read back using the throttle ..

 btw .. what command station are you using?

what is your interface?  locobuffer, PR 3, etc

is the track completely clean on your programming track


after you try all that ..

get some aligator clips, -- take the shell off the loco, put an aligator clip on each half of the locomotive .. the other end of the clips, hook up to the outputs of the booster . then try to do the programming ..  were trying to eliminate all the mechanical parts between the decoder and the programming track

Haven't tried programming CV8 on the main on the offending locos - I'll give it a try. Neither JMRI or the DT400 were able to reset the decoder.
I have a Digitrax Super Chief (DCS200) connected to a set of 3 DPDT switches that allow me to select DC - DCC - program to feed to my test loop. (I'll post a drawing later) and a PR3 operating on Loconet.

[djconway]

I want to thank everyone that has replied, your ideas have been helpful.

We may not have solved the problem, but it gives me ideas and things to try.

[John]

I want to thank everyone that has replied, your ideas have been helpful.

We may not have solved the problem, but it gives me ideas and things to try.

I've run into similar problems in the past .. those were the things I tried .. I eventually ended up replacing the decoder a couple of times ..

your setup is similar to mine .. except I don't run DC anymore .. let us know what you eventually end up finding

[peteski]

When I read a known good locomotive JMRI and the DT400 controller return the proper address.  In this case I tested 2 Atlas Alco C-628 locomotives, one with the Atlas "Dual Mode" decoder and the other with a Digitrax DN163A0.  Atlas decoder reads and operates as expected, the Digitrax decoder loco reads as address 16383 on JMRI and 6383 on the DT400 controller.

I am using a Digitrax Super Chief 5 amp controller connected to a PR3 interface used in the "loconet" mode.
I have a test loop of track that I can select DC - DCC - DCC-Program via 3 DPDT toggle switches.  This configuration allows me to test run a loco on DC or DCC or to set the test loop to be a programming track.  (I'll try to post a diagram)

I'm not new to DCC - my first DN93 install was in 1997 and it still runs today.

I understand you can read other locos fine (and that you have been dealing with DCC for decades) .  I was just curios what JMRI woudl show when the bad loco was off the track and you tried to read the address (after you already tried to read the defective loco's address).  I wonder if JMRI woudl error out when there was nothign on the track, or woudl it show that bogus address again.

If it errors out with the track empty that means the bad decoder is still alive and responding (with bogus data) to the JMRI's CV read commands.  Knowing this woudl not fix the problem, but it woudl have been interesting to find out.

[djconway]

I understand you can read other locos fine (and that you have been dealing with DCC for decades) .  I was just curios what JMRI woudl show when the bad loco was off the track and you tried to read the address (after you already tried to read the defective loco's address).  I wonder if JMRI woudl error out when there was nothign on the track, or woudl it show that bogus address again.

If it errors out with the track empty that means the bad decoder is still alive and responding (with bogus data) to the JMRI's CV read commands.  Knowing this woudl not fix the problem, but it woudl have been interesting to find out.

With the loco removed from the track two error mssages are displayed -- No locomotive detected (301); No acknowledge from locomotive (308)
JMRI knows there is no loco.

[peteski]

With the loco removed from the track two error mssages are displayed -- No locomotive detected (301); No acknowledge from locomotive (308)
JMRI knows there is no loco.

So that decoder is seriously wounded (but not dead).  In order for the JMRI to communicate with it, its microcontroller (its computer "brain") has to be running its programming (firmware).  Maybe since all the CV values come back as 255, the internal Flash memory (or part of it) that stores those CV values went kaput.  Not fixable, but it is good to at least try understand the failure. That could also explain why the reset does not bring it back to life. This is the first time I have seen a decoder behaving this way.