I have a pair of Stewart A-B FTs with NCE decoders in them. Recently, the lead unit seems to slow. Been over it several times for wiring or other such issues, with nothing really found amiss physically.
In the course of checking various CVs I’ve discovered it has a knack for changing its own CVs. I’ll set CV5 to 180 and it changes it to something like 89 or 1. Set CV6 to 90 and it comes back after a run around the layout main set to 255. No wonder it doesn’t run right. It can’t remember how.
I know from accidentally getting conflicting settings like into these CVs this leads to peculiar behavior, so I suspect I’ve found the problem. What I can’t figure out is what causes this or how to stop it?
Would locking the decoder keep it from changing the CVs like this?
Or should I give up on this decoder and return for repair/replacement? Warranty is no longer a question, as it’s several years past that.
They’re D13 something or others. I’ll have to take a look again to confirm. I just want to be sure it’s the decoder and not something else if I do end up sending it back. I can’t think it would be something else, except the FT still has it’s factory light board, etc which might make it possible it’s something else.
Even if the thing is sitting on the programming track, it acts deranged. I can set CV5 to 180, set CV6 to 90, and then go back to CV5 and it says 5 or some similar value just seconds later. Then I go back to CV6 and it’s at 255. Never seen or heard of anything like it.
From your description, I’d guess you have a very early NCE D13 decoder that was not covered with shrink wrap to prevent it from touching metal. The latest iteration is the D13SR (Silent Running) that is fully protected with shrink wrap.
Open up your model and make absolutely sure no part of the decoder can touch metal if it does not have shrink wrap around it.
The documentation for the newer D13SR decoder lists the range of possible values for CV5 as 0-255, with the factory default of 255. CV6 default value is 127, and possible range is 1-255.
I purchase D13SRJ decoders in bulk packs of 10 per and have never had a single defective one after installing something around 40 in various locomotives for club members.
There’s just one decoder, because the standard Stewart FT is a powered A and dummy B.
CV29 = 2, so should be in the factory speed table.
I’ve always been leery of the decoder lock, fearing I’d get it locked permanently. I shows CV15 and CV16 = 0, so it is currently unlocked. The NCE docs says if they are not equal, then “decoder programming is locked and it will not program (except CV15) or read.” So I guess this means that I wouldn’t be able to determine of CV5 and 6 are changing, except by how the loco is acting, which is kinda obvious.
Yep, they came naked, so that was a potential issue. I’ve applied Kapton to the decoder and checked it carefully each time I’ve had the shell off. I suppose it’s possible there a tiny piece of a strand of wire captured under the Kapton at just the right spot to make it wacky, but not toasty, but that seems unlikely.
Like you, my experience with NCE is good. I’ve probably got 40 or so of their decoders in service. Other than sound, I depend on NCE for most apps. Never had an issue I didn’t cause myself, but this is strange.
Sorry for the confusing wording. Normally this A-B pair is mated with another A-B to form a 4 unit lashup. The other decoder seems to work fine. It was when I noticed the rear units pushing the front ones that I discovered the problem. So ignore any previous reference to the good decoder in the other unit I made.
CV29 always confuses the heck out of me. I let my PowerCab do the translation. It’s supposed to be set-up with “540” for the long address. Should something other than “2” be in CV29? Maybe that’s part of my problem???
The decoder has been in the unit for maybe 4 years now. The issue is quite recent. It worked fine for years.
Well, I’ll take your word for that. Can someone convince my decoder it shouldn’t be there?
BTW, that was after doing a factory reset (CV30=2) again today. At least I hope I’ve been doing that right or that could be the only contribution I made to the mess I’m aware of. Since I do run it as part of a consist, I reconsist it with it’s mate (541) when it goes back on the layout. Maybe that’s why it seems to respond to it’s road number, as it is consisted under “540”. Command station is a NCE PowerPro.
Anyway, I’m going to doublecheck what long address is in it. IIRC, I have been resetting the long address after each factory reset…
You don’t have to take my word for it. If you go to the link and enter the conditions that you want, a calculated value will be presented to you.
If you reset the decoder, then the value in CV 29 will be equal to 2, at least until you change it to something else. This is because the default address for most out of the bag decoders is 3. 3 is a short address, so CV 29 has to equal 2 for it to operate on this address.
If you did reset the decoder, I don’t see how it can run on the long address unless you also reset the long address after the decoder reset.
So far as it running with the mating 541 unit, it shouldn’t do that unless you also went through the consisting process after you did all your decoder resetting. This is because the decoder reset would also make the consist CV, CV 19, revert to its default value of zero.
One other thing you should do is browse through all your other consists in the command station and see if you have the 540 unit in more than one consist. If you have been reconsisting the 540 with the 541 without deleting all the other consists you had them in you will confuse the command station when you try to pick one of the units to run.
EDIT: As an additional note, after you did the decoder reset I would have expected the value to be found in CV 29 to be equal to 6. This is because I would expect that the decoder be defaulted to be able to run on DC (analog)
If the decoder has worked fine for years, chances are good that it is still working OK. Something just seems screwed up as the result of faulty programming.
CV29 is a multi-function CV. It controls loco direction, speed steps, cab address, and some other functions. The following is a brief summary of the functions:
Bit Value Bit ON Bit OFF
0 1 Reverse Forward
1 2 28/128 14
2 4 DC on DC off
3 8 Railcom No Railcom
4 16 Speed Curve No Speed Curve
5 32 Long Address Short Address
6 64 ------------ ------------
7 &n
I think I have all that pretty much covered. I’m religious about resetting the long address, so CV29=2 should NOT be happening. It probably was, for whatever reason, but I was resetting to the correct long address (which would account for it running under the consisted “540”).
I’ve also found CV29=38.
Where the problem is creeping in seems to be whenever I reverse the consist or the power is interrrupted. I had them both running, but 540 was running a little ahead of 541. So I shut down track power on 540 and let 541 catch up. Then when I put power back on the track, 541 was ready to go. 540 just sat there. I think that was the time it went to CV29=38.
Now that I have that small tidbit confirmed as a cuase, but maybe not the reason, this makes me wonder if whatever it is also affects my 6 P2K F units with QSI sound. I’ve found that shutting down DCC causes most or all of them to also lose their long address. Which is a PITA, because some of them are alsmot always in staging where it’s hard to get to them.
Could this be some sort of weird command station issue? Maybe entirely separately issue, but the correlation at least piques my interest.
No it shouldn’t, but that was luck of the draw. I just reset, re-long addressed and reconsisted 540 all over again. Set it and 541 running a few feet apart and let them loose on the main. 2 or 3 laps later, they’ve coupled together, because 541 catches up with 540 as it gradually starts slacking. Removed 540 to the programming track. This time CV29=154???
It’s like a box of chocaltes. You never know what you’ll get.
Whatever happens thus also happens when it’s just running along, as well as when stopped or direction is reversed.
This is a correct statement as far as it goes. However, if he makes multiple attempts to consist those two locos and doesn’t go into the command station and delete any existing consists that might contain those two units, there will just be a lot of decoder confusion as the command station tries to figure out exactly which consist is being called up when he selects loco whichever. We’ve had a lot of issues down at the club with people not knowing what they’re doing. On occasion browsing through the consists we’ve found consists containing only one unit, multiple consists with the same units, and the same unit in multiple consists with other units. That got so bad that for our open houses I’ve had to go into the command station and limit the range of cab numbers that can perform consisting.