DCC Addresses Causing Odd Behaviour

[SRman]

Has anyone experienced odd behaviour, or items becoming non-operational simply because of a particular DCC address?

I have experienced this twice in all the years I have been using DCC.

The most recent one was only fixed today after causing me some frustrations over the last few days. It is a Bachmann class 419 Motor Luggage Van (MLV) in London & South East 'Jaffa Cake' livery (not that the livery has any direct effect here). I pulled it out of the stock drawers for a photograph, but when I went to drive it and turn on the lights, using my NCE Power Cab, it was totally unresponsive. This unit has a Lenz Silver+ 21 pin decoder installed.

I tried reading the decoder, but that just came up with errors.

I tried resetting the decoder several times, with mixed success leaving the default address as 3.

I cleaned the wheels and tried again. Programming stopped after I selected short address 8 (for unit 9008). After that it would not read or write when it got to the long address (wanted to set as 9008).

I tried swapping decoders for another Lenz Silver, with exactly the same results. 

I dismantled and reassembled the model several times, looking for poor connections, loose wires, or anything that might cause problems. All was OK, and I put a blanking plug in and tested on DC, where it ran perfectly with the headcode lights also illuminating correctly.

Inserted the decoder again and nothing useful occurred. No lights, and one flicker of movement, then nothing at all.

Reset the decoder and left it on address 3 and it all worked properly.

This time, I left the short address as 3 and programmed the long address as 9008, and it all worked perfectly, lights and all. Intrigued now, I tried putting short address 8 in, and sure enough, it stopped working. Reset the decoder again, left it at short address 3 and long address activated as 9008 and it worked.

The previous occasion I struck anything like this was with a friend's Heljan Hymek D7093, with a LokSound v3.5 and Howes' sounds. It absolutely refused to work with address 7093. Programming addresses either side of that worked fine, as did short address 93.

I cannot see how it is possible for the locomotives circuits to block a particular address - the fact that this occurred with two separate decoders in my MLV's case seems to indicate this.

Can anyone explain these anomalies, or relate similar experiences, please?

[charliepetty]

Yes that can happen.    Charlie  (Legomanbiffo Team)

[RFS]

Yes I've had something similar. A pair of Bachmann 4-CEPs with Lenz Silver21+ decoders running in multiple (independently as a Traincontroller "train-set" not as a DCC consist) came into the main station. The rear unit was slowing down as normal but the front unit clearly wasn't as was in a runaway state of some sort. When the second unit stopped the first unit started dragging it along the track causing quite a lot of noise so I had to hit emergency stop.

 

After restarting I found the first unit effectively dead. Assuming the decoder had failed I put it on the programming track and eventually got it to reset. On address 3 it worked OK but I could not re-address it to its normal address of 7113. In the end I gave up for that session and left it till the next day whereupon I was able to re-address it correctly. It then appeared happy again and has worked perfectly ever since. This was 2 years ago so I don't know what the problem was. Perhaps the decoder overheated and therefore partially shutdown?

[SRman]

Thanks guys, so it isn't just me! 

RFS, I did consider there might be a short somewhere causing the decoder to shut down, but working on address 3 proved that wasn't the case.

What really got me was the fact that the same thing happened with two different decoders (albeit both the same type), indicating that there was some incompatibility with the MLV's circuits but only on that particular address.

Weird!

[34theletterbetweenB&D]

20 hours ago, SRman said:

...Can anyone explain these anomalies, or relate similar experiences, please?

I have had fifteen years of fitting all sorts of decoder choices to all sorts of mechanisms for friends, and have seen a couple of 'address unavailables' and several runaways of various types, after the  'good install' has been confirmed on programme track.

 

Pretty sure it is interaction between the decoder and components on the mechanisms. Where it has been possible to remove all electronic components on the mechanism the problems 'go away'. The first clear indication I saw of this was on a small Bachmann model, on which the decoder would 'lock in' to speed step 20 and only cutting the power would halt it. I could hear something emitting a singing note when this runaway happened. Removing the two wire wound inductors in the motor supply wires eliminated the problem. 

 

[SRman]

Now that's interesting, because I noted similar coils under the PCB on the MLV. As a matter of routine I remove any accessible capacitors (one remains in the MLV because I cannot get at it without dismantling the motor assembly even further than I already went, two were removed), but I only remove and bypass those coils where a more drastic solution is needed, such as hard-wiring. As such, none of my N class 2-6-0s have those coils any more. In fact, they don't even have PCBs any more!

As the MLV is now working properly, I'll leave well alone, but if it plays up again, I'll remove the coils and replace with straight wire and see if that makes a difference.

I have six different MLVs, all with Lenz Silver+ 21 decoders, and this one was the only one that has played up.

[RFS]

Perhaps this is related to the problems I've had in the past with my 2-EPBs which share much of the electronics with the 4-CEPs and MLVs. I have 4 of them and quite simply they will not run properly with Lenz 21pin decoders. They can be very erratic especially when running in multiple. In the end the solution was a different decoder, and for these the Zimo MX634 and MX638 run these units perfectly.

 

The 4CEPs can also exhibit the same behaviour but only very mildly and I could only reproduce the problem in to 2 out of 6 units. The problem was overcome by the simple expedient of ensuring the lights are on. In fact, just having the head code lights on is enough. However, not seen any problem at all with my 2 MLVs or 2 Thumpers which have always had Lenz decoders. 

 

I did have a similar problem with a Hornby class 31: initially ran extremely well with a Lenz Standard+ but after a while became erratic like the 2-EPBs. Again a Zimo MX600R fixed that issue. I'm sure it's something to do with interference being generated by the model's internal electronics but I've never got to the bottom of it. 

[SRman]

You seem to have had a far worse experience than I have with the Lenz decoders in Bachmann units, Robert (RFS). I have standardised on the Lenz decoders in all of the Bachmann Southern Electric units - six MLVs (as mentioned earlier), seven 4 CEPs, five 2 EPBs, and two out of three 2 H DEMUs (the third has an ESU LokSound). Of those, only this one MLV has played up, so maybe I have been lucky with the combination I chose ... or maybe I just haven't hit the 'unlucky' numbers for each of these units.

Incidentally, with the MLV that prompted this topic in the first place, trying to turn the lights on exacerbated the problem. The lights would flicker momentarily, then the decoder would play dead again.

[RFS]

Indeed I had one unit that became so bad it wouldn't run properly with any other decoder such as the Hornby Sapphire. It would be running quite happily and all its lights would go off for 2-3 seconds and come back on again but the motor never missed a beat. At first I tried cleaning the wheels but found it would not respond when power was applied to the trailing bogie. Yet when running it would pickup power OK from that bogie, just not the DCC signal. I could lift the power bogie and then try to stop it but it would not respond even though the motor kept running.  In the end I concluded the problem was the PCB and bought a replacement from Bachmann. Since then it's been fine.

 

I feel sure there is some component/circuitry on the PCB that's generating interference on the DCC signal and that Lenz decoders are more sensitive to that. With 3 of these units I have removed all the capacitors and chokes,  but it's not a simple job as you have to completely dismantle the coach to do that. Took about an hour to do each one, but sadly did not resolve anything. 

Edited July 29, 2019 by RFS

[Steven B]

On 28/07/2019 at 12:20, SRman said:

This time, I left the short address as 3 and programmed the long address as 9008, and it all worked perfectly, lights and all. Intrigued now, I tried putting short address 8 in, and sure enough, it stopped working. Reset the decoder again, left it at short address 3 and long address activated as 9008 and it worked.

 

You need to be careful what mode your DCC command station is in; Whilst you may be attempting to control address 8 your controller may be commanding long address 8, rather than the short address 8 expected by the decoder.

 

Short Address 8 and Long address 8 are not the same thing!

[SRman]

Hi Steven: I am absolutely certain I was programming short address 8: The Power Cab always asks for a short address value, then a long address value in that order, then one has to press enter to move on, or 1 to activate that address. I also repeated the steps quite a few times during the process of trying things then resetting the decoder.

To use the address 8 as a long address on the tracks, one has to select loco 08 and press enter, which then displays an asterisk to indicate a low-numbered long address has been selected. The Power Cab/Power Pro systems can address 1 to 127 as short addresses, and 0 to 0127 as long addresses.

Edited July 29, 2019 by SRman

[RFS]

In my case it would work on address 3 but not respond when address 7128 was set. Do not believe the problem has anything to do with command stations and is a decoder issue. 

[RAF96]

MLV has proven problematic with various decoders. Some work, some won’t. My diagnosis is a dodgy pcb.