Sonic announce a RTR OO A5 GCR 4-6-2T

[Bigmet]

Mine started to 'misbehave' in the early summer -remember you that, hot it was - and at first I thought the motor might be faulty because it ran hot and then the Zimo decoder's protection chopped the power. However testing it as a DC loco without decoder, the motor barely heated and drew very little current - exactly as when first purchased. Restored the decoder and it began misbehaving, lost its address etc.. It's been replaced and the A5 has been trouble free for the 2 months since.

[Bigmet]

Update, I fitted the A5 with a Lenz standard, hardwired, and it has been going like a train ever since. Let's wait for this year's warmth to see if that's a full cure, I am not expecting trouble as it has run sweetly since this decoder went in, and on DC test before this decoder was fitted.

Meanwhile the Zimo MX618 has been reset and is running my G5, no trouble whatsoever. Why it didn't 'enjoy' running the A5 is a mystery, very similar current draw, nothing I can see or measure to account for it....

[Bufferstop]

the Zimo MX618 has been reset

There's your clue.
I expect the reset routine is the same as many small "intelligent" devices. Part (or all) of the rewritable memory is rewritten by copying a section from the "non volatile" part, the slightest waver in the power supply, whilst it's copying is all it takes to change the state of one or more bits from 0 to 1 or vice versa. It just depends where it happens. Some areas of the memory will give catastrophic events for its functioning and you'll know straight away that something's up, others will have only a slight effect on the functioning and it just misbehaves intermittently. Alternatively it could be caused by airborne interference. A decoder connected through the wheels to a few feet of track is just like a receiver connected to a long aerial any sort of electrical discharge in the vicinity might corrupt its memory. One of the network engineers I used to call in advised that if you were doing a reset to a modem or router always disconnect it from the line, do it just before you go for a break, last thing on a Friday would be best and hope for no thunderstorms in the meantime.
It's surprising what odd things happen to these small devices when left to themselves. I've done a factory reset on a chip, stuck it into a piece of conductive foam, taken it to a new location, fitted it and re-booted only to get the start up message from the installation it was removed from. Translating that into DCC terms, the factory reset might not work and you end up transfering the original problem to another loco. Don't always expect what you do to work first time.

[Bigmet]

I expect the reset routine is the same as many small "intelligent" devices. Part (or all) of the rewritable memory is rewritten by copying a section from the "non volatile" part, the slightest waver in the power supply, whilst it's copying is all it takes to change the state of one or more bits from 0 to 1 or vice versa. It just depends where it happens. Some areas of the memory will give catastrophic events for its functioning and you'll know straight away that something's up, others will have only a slight effect on the functioning and it just misbehaves intermittently.

The decoder in question had several resets while in the A5! And each time it would run normally for a few sessions and then start malfunctioning. (The most frequent malfunction was only going in one direction, sometimes only forward, sometimes only backward, an immediately obvious problem.)

In the G5, trouble free to date since it was reset on installation and then successfully re-addressed to the number on the G5 cabside. There was nothing on the A5 to obviously cause trouble, other than the motor: I had removed the speaker before the decoder went in, but that shouldn't have been in circuit on a silent decoder anyway.

(I may yet examine the A5 motor, early in my DCC journey I had a Bachmann split chassis motor which produced high voltage spikes, and that was something the old Bachmann branded ESU 8 pin lok pilot (available circa 2008-2010) couldn't handle, kept losing its address and reverting to 003, so I relocated it into an early Bach class 24 mechanism which it still runs, albeit with a Hornby NBL type 2 body on it. A Lenz silver decoder had no trouble in the split chassis mechanism, ran it until that particular mechanism wore out and then that decoder also 'moved on'. About a third of my decoders have 'moved on' would be my rough guess.)

...It's surprising what odd things happen to these small devices when left to themselves. I've done a factory reset on a chip, stuck it into a piece of conductive foam, taken it to a new location, fitted it and re-booted only to get the start up message from the installation it was removed from. Translating that into DCC terms, the factory reset might not work and you end up transfering the original problem to another loco. Don't always expect what you do to work first time.

Oh yes! Great advice from a German dealer over twenty years ago: Provided there is no physical damage to a 'problem' decoder, keep trying resets if it doesn't 'take' immediately. One decoder - still in use to this day - needed several resets over the best part of a month before it resumed normal operation. The dealer said he had no information to offer on why this should be, but hey, it's always worth trying.

Edit: And one other thing. Early in my DCC journey, while trialling the available decoders, I had one that wouldn't work on a specific address. Any other four digit address was fine, and no amount of resets were effective in enabling it to accept the 'killer' address. It wasn't that good a decoder so it was going to be sold on anyway, but clearly had some peculiar coding defect.