Decoder reading problem

[AW]

A mate of mine has recently acquired his first DCC (and sound) fitted loco. It's an O gauge loco, acquired second-hand, and fitted with a Zimo MX699KS decoder. He also bought a new Prodigy Advance controller a few months back. He's completely new to DCC so I'm the on-site tech support.

 

Went round his place a week or so ago, and got the loco up and running OK. All working fine - eventually - except for one thing. We can't get the controller to read back from the decoder. We're using a dedicated program track, and I've had a meter on the track which is normally dead (as intended I believe), but does show power when the controller is asked to read data. So nothing wrong with the wiring that I can see.

 

We've managed to write to the decoder, on the program track. No response from the loco (no motor pulse or similar), but subsequently trying the loco on the main track indicates that changing the loco address seems to be working. But it won't read.

 

The Advance doesn't throw an error when trying to read, it just returns either a random number (when asked for the long loco address via "Adr"), or more often just 0000 for the address and 000 for any CV number I've tried. Again no physical response from the loco when attempting a read. I have a Prodigy Express of my own, so took that round, but it came up with the same result. I also took round one of my own OO gauge DCC locos plus a bit of OO track, and was able to read back from my loco just fine using my mate's Advance. Also worth noting is that the bloke that sold my mate the loco says he's had no problem reading the decoder, although he uses a different controller - although I don't know what make.

 

Anyway, I don't think there's anything obviously wrong with the Advance, and the limited tests I've been able to do suggest that it's the specific combination of controller plus decoder that's the issue. Unfortunately he only has the one O gauge loco with a decoder at present, so I'm unable to check whether it would work with a different O gauge loco. Anyone got an idea why this combination might be problematic, or won't work?  Or has anyone successfully read back from a similar O gauge decoder (whether Zimo or something similar like a Loksound XL) using a Prodigy?  I'd assume that should be possible, but it would be useful to know that someone has done this.

[Crosland]

I had to tweak the SPROG firmware to enable it to handle large Zimo decoders (specifically an MX695, which looks similar). It was specific to the way the SPROG senses the current at start up and then discriminates the programming acknowledge pulses. I doubt the prodigy advance works the same way as the SPROG but it could well be something related to these decoders and the Prodigy.

 

Having said that, the fact that you don't get the usual motor pulsing is odd. Is it a particularly efficient coreless motor in the loco? It might not be drawing enough current for the Prodigy to see the acknowledge pulse. The classic bodge in this case is a resistor across the programming track. Choose something that, for the Prodigy programming track voltage, gives a standing current of, say, 50mA, and experiment from there.

 

Andrew Crosland

[ELTEL]

May I suggest a phone call to John at YouChoos may be worthwhile.

 

Eltel 

[AW]

Thanks to both for the responses.

 

Further info has come to hand since my original post. My mate has acquired another loco from the same source, fitted with the same type of decoder. No real surprise that this exhibits the same behaviour, runs fine but the decoder is unreadable by the Prodigy (returning random loco address values, or more often zeros). At least that rules out an issue with the specific decoder in the first loco - not that I thought this was likely. Also it transpires the guy who sold my mate the locos was able to read from the decoders no problem, albeit using an ESU ECoS apparently. No idea whether that was reading on programming track or main, a quick look at some ECoS primer videos suggests you can use both with that controller.

 

I phoned John at YouChoos this morning. He was as helpful as he could be without having the equipment in his hands to test. One suggestion was that a firmware update might help, if it was out of date. But of course it's hard to know what the current version is without being able to read the decoder - catch 22 there. No magic bullet I'm afraid, and we don't have the kit to do a firmware update ourselves. So the decoder(s) would have to be sent away for this.

 

Apropos the motors. Both locos are Heljan Class 40s, with separate motors on each bogie. Googling didn't turn up any info about the specs for these motors, my original instinct was that the motors - and fairly beefy capacitors built into these decoders - might need more power than the Prodigy can deliver on a programming track. Am I understanding the resistor bodge correctly, i.e. it goes across the programming track rails so in parallel to the loco, rather than in series (i.e. between the controller and programming track)?

 

Ultimately as neither loco and controller are mine the decision about how to proceed is not mine. But I'll feedback if there are any developments.

[WIMorrison]

You may have looked at the manual for this decoder, if not, might be worth a look.

 

MX-large-scale_decoders_EN.pdf

[Harlequin]

The "beefy capacitors" ring alarm bells straight away, don't they @Crosland?

 

The capacitors could supply all the power needed for the acknowledgement motor pulse with just a relatively slow recharge trickle afterwards. Maybe the Advance is not sensitive enough to detect that, whereas other controllers are (eg. ECoS).

 

You'd expect to see many reports of that if it really were a general problem with these decoders (which there don't appear to be) but there are lots of variables that could combine to make this case unique.

 

So it doesn't quite add up but possibly worth exploring further.

 

Edited May 23, 2023 by Harlequin

[WIMorrison]

These beefy capacitors are fitted by Zimo as shown here

 

 

There is also this useful information in the manual

 

 

[AW]

Thanks again for the additional suggestions.

 

I had already read the decoder manual, and seen that CV112 option. I tried that, at least I think I did having had to work out the correct value for the CV to switch bit 1 on. Hard to be sure that writing it worked though, given the lack of physical response from the loco, and not being able to read it back (catch 22 again here). Anyway it had no effect on the day. I'll try this again at the next opportunity, this time programming it on the main rather than the program track.

 

Regarding the caps, I did ask John (at YouChoos) whether there was a way to disable them temporarily, lest they may be in-the-way so to speak, using a CV setting. There is indeed a CV (153) that affects the cap behaviour, but as he points out the manual is somewhat ambiguous, and rather implies it's the amount of stored energy fed back to the motors that's being set - rather than actually reducing the energy that they store in the first place.

 

And in regard to the general behaviour of these decoders, I couldn't find any reference to common read problems with them either - albeit that they won't be as widespread as OO gauge ones of course. John couldn't offer any fundamental reason why they couldn't be read either, although I did discover the existence of programming track boosters for the first time while Googling around the problem (their existence suggesting that decoder reading isn't as robust a process in practice as it is in theory). Prodigy controllers aren't some completely niche brand either, which is why I was hoping that my original post my uncover someone who's actually used this particular combination of decoder and controller, to see if they had the same problem.

 

Not sure when I'll next be able to try any more experiments, probably next week at the earliest though.

[AW]

Apologies for the very belated update on this problem, reading the date of my last post it's been much longer than I thought. I've been to my mate's a few times over the last couple of months, but my time there has been focussed on more pressing matters to do with layout construction and various rolling stock issues.

 

Anyway, on the matter in hand. Since my last post my mate has acquired a couple of new sound-fitted locos, this time (by chance) with Loksound XL decoders in them. Turns out that his Prodigy Advance has no problems reading CVs from these Loksound XLs on the program track. It returned the correct loco address consistently, albeit without any visible motor pulse. Hence the issue seems to be specific to the Advance and Zimo MX699KS (and family?) decoder.

 

This week I did finally get the chance to try the CV112 option again with a Zimo fitted loco, this time with better prep about the value to use. No joy there though, one of his locos did at one point return the correct loco address, I thought I'd cracked it. But it only returned that value once, and in repeated tests produced a variety of other apparently random values, pretty much as it did first time round. So I'm pretty stuck here, fortunately it isn't a complete showstopper as the locos do work, and programming blind on the main seems to work - at least with values that are easily verifiable by experiment, like the loco address.

[peterm1]

On 25/05/2023 at 07:43, AW said:

Thanks again for the additional suggestions.

 

I had already read the decoder manual, and seen that CV112 option. I tried that, at least I think I did having had to work out the correct value for the CV to switch bit 1 on. Hard to be sure that writing it worked though, given the lack of physical response from the loco, and not being able to read it back (catch 22 again here). Anyway it had no effect on the day. I'll try this again at the next opportunity, this time programming it on the main rather than the program track.

 

Regarding the caps, I did ask John (at YouChoos) whether there was a way to disable them temporarily, lest they may be in-the-way so to speak, using a CV setting. There is indeed a CV (153) that affects the cap behaviour, but as he points out the manual is somewhat ambiguous, and rather implies it's the amount of stored energy fed back to the motors that's being set - rather than actually reducing the energy that they store in the first place.

 

And in regard to the general behaviour of these decoders, I couldn't find any reference to common read problems with them either - albeit that they won't be as widespread as OO gauge ones of course. John couldn't offer any fundamental reason why they couldn't be read either, although I did discover the existence of programming track boosters for the first time while Googling around the problem (their existence suggesting that decoder reading isn't as robust a process in practice as it is in theory). Prodigy controllers aren't some completely niche brand either, which is why I was hoping that my original post my uncover someone who's actually used this particular combination of decoder and controller, to see if they had the same problem.

 

Not sure when I'll next be able to try any more experiments, probably next week at the earliest though.

CV 153 sets the time in tenths of a second that the motor runs when no current is available. I always set mine to 20 = 2 seconds. If you do that I'd recommend that you set CV111 to 1: this means that when CV153 comes into play, the loco will stop dead after 2 seconds, rather than going to the setting in CV4 which can lead to a collision. Sorry about going off topic a bit, but thought it might be helpful.

[John Clitsome]

I've had this problem over several yrs. If a cap (stay alive) is fitted the Prodigy won't read back but if I disabled the cap ( a right faff) all was well.

 

Gave up in the end and bought a Sprog and separate software from John at YouChoos. No problems now.

[RvSwol]

Many CV can also be changed through POM. Programing on Main. That the decoder does not respond via Prog. Could be that the voltage is too low. If I use a zimo MX
ULF the display always shows 11.2 volts 2 amp.
Or rather 11.2 volts is the lowest working voltage with a max of 2 amp. Try a higher voltage ( 17 volts and power i.v.m. the UPS capacitors.