So at this point we have no idea what the loco’s motives are.
3 Likes
So true
A problem with the decoder itself normally wouldn’t result in an indication of there being a short. It could indicate a problem has developed in the wiring going to or from the decoder.
However, I notice that the NEC N14SR is an N-scale decoder. It could be that it simply can’t handle the motor of an On30 engine, even just a trolley car. I know I made the mistake of fitting an N-scale decoder into a small HO diesel switcher. It runs for a few feet, then stops because it is overheating. I’ll need to remove it and replace it with an HO decoder.
1 Like
Yes, I tried running on cab number 3 after the reset. I tested the lights on cab 3 to make sure I could control them as well, and could. Sorry, I should have included that information.
1 Like
Yes, the same actions occur with the body removed and the decoder not pinched/squeezed.
1 Like
Does it run on DC? I can’t find confirmation that it’s dual mode in the spec sheet but it should be to be NMRA compliant, which is specified. Make sure it’s not a pulsed DC transformer but that would be my next trouble shooting step -
Also, do you hear a seized motor whine when you increase the speed? Or is the motor silent?
1 Like
That probably rules out the next thing I was going to mention: if there is a broken trace or bad joint in the motor-control circuitry on the board.
If you have a multimeter, you could check to see if the decoder actually feeds modulated voltage to the motor pads. (We know the connection from the pads through the motor is good because of the jogs.)
Now might be the time to find someone with a decoder tester, or a hobby shop that has one and would test at a fair price. Without seeing the specific decoder schematic (and I won’t hold my breath waiting!) I don’t think narrowing down the cause further is going to involve “user-serviceable components”…
1 Like
So, here is what we know so far.
You have an On30 streetcar with an NCE N14SR decoder, a 4 function, 1 Amp rating, 1.25 Amp peak. From what I read, an On30 street car typically draws less than 0.5 amps.
The streetcar used to run, but now it doesn’t although you can still control the lighting. The streetcar has not been run in 2 years.
Your DCC command station is an NCE Power Cab.
On the Power Cab’s Programming Track, you have reset the decoder, using CV30=2, and CV19=0 so no consist in memory. The locomotive slightly jerks forward with each programming step such as the loco address.
The locomotive will not move on either the short address or the long address. The short address should be 3, not 03, not 003.
Other locomotives are running.
You say that “After posting I noticed that sometimes the system would act as if there is a short when I placed the loco back on the track”. What makes you conclude that it acts as if there is a short?
I would agree that the jogs on the Programming Track indicate power to the motor, but the Programming Track is designed to protect the decoder by using low voltage. So, that doesn’t necessarily mean full power to run the streetcar on the mainline. From my experience, I don’t think the motor or its connections are bad, but do we really know for sure?
Exactly my thought. I long ago purchased an NCE Decoder Tester just for these reasons.
Here is a photo of the decoder.
https://ncedcc.zendesk.com/hc/en-us/articles/201306245-N14SR-5240131
My logic is based on the fact that even the low-voltage ‘confirmation pulse’ is making it all the way through the motor, and actuating it enough to move the locomotive. That establishes to me that everything from the motor pads out is ‘good enough’ to take drive power… if it were available.
I don’t know how this decoder generates the ‘jog’ pulse internally, and it would be interesting to know if we were concerned with troubleshooting SCRs or other internal motor-controller components to determine where the problem is. The thing of value for the OP is to tell him that we’re at the point where replacing the decoder, not further ANALytical procedures, is the sensible next step forward.
Has anyone found the stats for that decoder to let him know if it is safe to drive that “On3 motor”? He can easily determine what the actual amp draw of the thing is at various applied voltage, and I wonder what sort of ‘underfloor heat sinking’ he would need – perhaps just a copper plate and some strategically-placed thermal paste – to get a small decoder to ‘live’ in there.
1 Like
Aside from the crudeness of that response, if he replaces the decoder, what then if the same problem persists?
What I mean by that response is that further troubleshooting would be ‘anal-retentive’ of us to engage in, since I doubt he is interested in reflowing portions of the decoder board and finding the SMTs or other devices that may have failed.
If he tests the motor (and its transmission to the wheels, which I do not see as a major troubleshooting concern here) he can rule that out as a problem.
If he measures the current draw on variable DC under a reasonable range of losds, he can decide what replacement decoder he should try… including Qthe same type he has with better cooling arrangements.
He could also try desoldering or demounting the motor terminals, attach a suitable small can motor (or other load like Mel Perry’s 1157-in-a-socket) and see if there is actually modulated power getting out of the decoder in response to throttle actuation before he replaces it.
He could always set up another decoder ‘on the bench’ and jumper the motor terminals to his trolley motor leads. That would catch a prospective ‘still does the same thing’ in minimum time. But I think the likelihood of that is slight, given the other evidence we have seen and the deductions we have made from that so far.
2 Likes
Yes, trying it on DC is a good idea. Almost all decoders made in this century are dual-mode so can run on DC. If it runs on DC, then something is wrong with the decoder…although I see the instructions say “Brake on DC feature assists automatic train control”? Not familiar with that.
https://ncedcc.zendesk.com/hc/en-us/article_attachments/200278869
Have you tried reading the CVs from the decoder to make sure they are correct? The slight movement of the engine when programming the decoder really just means the decoder received a signal pulse from the programmer. It doesn’t guarantee that the new CV setting actually worked. Maybe read CV1 and make sure it’s really 003, or try changing CV1 to 003 via Programming On the Main instead of the programming track, then try to run it on ID 003.
1 Like
My understanding, possibly defective, was that the ‘jog’ signals that the processor in the decoder has accepted the programming change, not just ‘received’ it. That is not just a matter of semantics: it would indicate (again) that the problem here is with part of the motor-control circuitry in the decoder, very specifically – and that there won’t be a workaround that doesn’t involve some kind of microsurgery on the device.
If he is unequipped to do that, or not interested, why are we continuing to troubleshoot exactly where (in the stuff he doesn’t care about) the actual fault on DCC might be? I do not think that ‘DC compatibility’ means that the decoder simply reverts to DC passthrough to the motor when ‘correct’ (I.e. non-PCM) variable DC is detected, but if so, since the ‘thinking’ part of the decoder still seems to be operating, that function might “work” without demonstrating anything more than we already know via the existence of the ‘jogs’.
1 Like
That is simply a feature on many NCE decoders that allow braking if trackside circuitry is used as part of automatic train control. Normally, CV27=0 unless the user wishes to enable the feature. Since the OP reset the decoder, CV27=0 should be in place but it never hurts to check. I have experienced a few instances where a decoder reset has not completed taken effect.
I agree with this. According to NCE, it is simply an acknowledgement pulse.
NCE decoders recognize 3 as a short address. There should be no leading zeroes when using a short address. 03 and 003 indicate a long address. When an NCE decoder is reset to factory default, CV1=3.
Regarding the comments about being sure the address (CV1) is correct, I have tested this by turning the light on and off on the loco. So I am sure that I am addressing the loco when trying to run it as the light is being controlled.
I do not have the facilities to reflow a decoder.
It seems there is some question as to whether the slight jog when programming the decoder is the decoder itself telling the loco to move or a result of power being sent in a different way. Note that the jog is in both directions. Forward then back (or back then forward, I have not paid close attention to the direction.) I took this to mean the decoder was controlling the motor, but again, this seems to be a question here.
The motor is moving free. I can manually spin it without any effort when no power is applied. I cannot find specs on the motor. Here is a link to the replacement motor block, but I have not been able to find just the motor itself.
I have not yet had a chance to pull out the DC transformer and test.
1 Like
Deleted
That is good, so the motor isn’t binding. But the issue remains, is the motor receiving sufficient power to move normally?
Are the wheels clean?
Power pickup wires secure?
What about this?