Forgetful Decoder.

[Tiddles]

Now this has happened before and is not exclusive to Bachmann.

I have a Bachmann American Sound Value loco.

I changed the address to 4449 plus some of the sound a lighting CV's.

Have not ran it for a few months, maybe nearly a year. Went to run it to find that it has reverted back to address No.3. Although the other CV changes have not changed.

[Bufferstop]

Did you give it much use between setting the address and leaving it unused? it's common to EAROM (electrically alterable ROM) when used in many devices not just decoders. It's as though the changes take time to become permanent, It used to be a common failure in modems etc set up by school technicians at the end of term to revert to factory settings over the holidays! I think it sulks because no one has talked to it for a couple of months.
(As good as any other explanation I was given)

[Bigmet]

... It's as though the changes take time to become permanent...

Wish I had a better explanation!

Very early advice in my DCC adventure from a most helpful German retailer in Koln: if a decoder 'fails' in some way but shows no evidence of physical damage such as burned components, and doesn't immediately respond to a reset, don't bin it. Keep trying a reset every time you use the layout, it probably will recover. Great advice, I have several decoders, one now over 20 years old, which have been through this and operating reliably ever since.

My DCC 'troubles' knowledge base as follows:
Some decoder and system combinations have decoder setting losses when the DCC system is powered on or off while connected to the layout. They reset OK. Fit an isolating switch in one of the layout power feeds and use it.
Some decoders are apt to address loss and other problems if exposed to 'Address 0' operation. They reset OK. Don't expose decoders to 'Address 0'.
Some decoders don't like regular exposure to system trips, such as when attempting the 'coin test' to determine where the layout wiring is deficient. They reset OK. Fix the layout wiring so that any short circuit on the rails instantly causes the DCC system to trip.
Some loco electronics can interact with some decoders causing temporary malfunction. Rip out the junk and all is well. (There's an increasing load of electronic junk in RTR OO models, some intentionally designed to only work well with 'our brand' decoder IMO. GRRR.)

Lightning strikes can leave problems, even if the system wasn't plugged in to the mains supply the large electric field changes can make a muck of decoder settings: a rarity fortunately, which I have only seen once.

[Richard08]

It, at least partly, depends on what the controller 'remembers'. The Lenz system uses values for CVs for a particular engine remembered in the controller as first port of call, looking at the engine if it's not already in memory. Decoders appear to be mostly FPGA devices which will only guarantee their current state being remembered as long as power is applied occasionally, over time without being refreshed (electrically) what is stored will become effectively random - at which point a well designed device will revert to defaults, which appears to be the case with the OPS decoder.

[Bigmet]

I have a model that has been off the layout at least 10 years. Now the trick will be finding it and then seeing if the address (cabside number) is still correctly stored on the decoder. (My Lenz system has had at least one and most probably two resets to clear the address memory since that loco was last operated.)

[Bigmet]

And no trouble at all, entered the address on the handset and off it went; haven't checked in detail but the acceleration rates were very extended which is the way it was originally set up, so 'operation as expected'. (Lenz Gold decoder, installed 2007, last operated 2009; how time flies as you grow older, that's 14 years in storage unused, rather than the 'ten' that popped into mind without real thought.)

Sad aspect; inevitably thought of the late Lou, for whom this loco had to be present on my layout when a visit occurred. (The loco has a planned destination, another friend with the LMS bug has a layout building.)

[Tiddles]

I am using a Gaugmaster Prodigy Advance2.

It dose say to switch off the base unit before switching off the mains power. I mostly remember to do that.

The loss of memory has only happened a couple of time and with different manufactures.

The sound and lighting changes are the same as when last used, its just the address.

[Bigmet]

...It does say to switch off the base unit before switching off the mains power. I mostly remember to do that...

This is very much your choice, but I would want to eliminate any need to remember the procedure.

The classic method used on safety critical machinery access is the interlock. For our need that can be accomplished by making access to the DCC system's mains power connection dependent on the track connection to the DCC system being broken, and that's how mine is set up. Many ways of skinning this particular cat, depends on your own preferences.

[RAF96]

My layout room sockets are under the bench so I use three remote control switches set to the same address to power up the layout and my PC and a bench top power strip for such things as soldering iron, work lamp , etc from a single button press. At days end I press the off button and it all shuts down. Not had any problems with amnesiastic decoders. I had some very old Hornby decoders that would reset at most every power cycle, intentional or otherwise, so I guess any failing is in the decoder design.

[Bigmet]

And I have now confirmed that my trouble with the Sonic A5 was all due to the decoder, a Zimo MX618N. Following the hot motor becoming evident it became 'forgetful' and CV2 went awry among other settings, after a month of correcting CV's it lost its address, was reset and reprogrammed, and started malfunctioning again. This time 'no go' happened much more swiftly, and no reset was possible, never before seen so many fault codes while attempting resets!

I 'rotated' two MX618Ns which were trouble free in other models into the A5, both perfect, and then installed the last unused MX618N, and the A5 has run with this for two months, accruing twenty hours running time without any problems. So there it is, first time ever that I have had a Zimo decoder fail, from what must now be fifteen years purchases. Must get around to finding the invoice to exercise the three year guarantee, and sending it back for replacement or refund as the retailer decides.