Atlas GP38 with Intermittent DCC Troubles

[Dwight in Toronto]

I know that I’ve reported this problem here once before, and that Peteski and I had a bit of discussion on it, but I couldn’t find the earlier topic so decided to start anew.

I purchased this N scale Atlas GP-38 new, and equipped it with an ESU 58751 dcc/sound decoder in March 2023, so just over a year ago.  Since then, I’ve had maybe four or five instances where the loco just stops running.  Horn, bell, prime mover and lights remain functional, but there is no fwd nor rev motion whatsoever, irrespective of speed step setting.

I hastily captured the symptoms in the attached short video (apologies for it being quick-&-dirty).  As the segment starts, I have removed the shell, the loco has been placed back on the rails, and the motor has been given a tiny tweak to get things going again.

Note how:
a) the loco is (reluctantly) in motion, in that it is very slow/jittery/rough-running
b) slow, erratic operation persists, regardless of speed step or direction (I pan over to show speed step 28 on the NCE PowerCab)
c) I demonstrate that sound & lights work normally
d) I bring it to a stop, switch to reverse, but I need to finger-flick the motor to get it going again

As soon as the video ended, I performed the following “fix” routine:
- move loco to workbench, unsolder orange & gray wires from motor tabs
- connect one end of alligator clip jumpers to motor tabs, other end to variable DC power supply
- motor immediately spins up & down effortlessly on DC, fwd & rev
- resolder the orange & gray DCC wires back on to the motor tabs
- place loco back on the rails … full, flawless DCC operation is fully restored

The loco will henceforth continue to run properly and reliably, for several weeks or months, until such time that it once again just inexplicably stops dead in its tracks.  At which point I once again repeat the whole procedure.  As I say, this is maybe the fifth time in just over one year.

As I mumble at the end of the video - I just don’t get it!

Anyone?

/>

[peteski]

Which components (if any) have you replaced?  First suspects would be the motor or the decoder?

Didn't you have very similar problem with a Kato loco? Wasn't the motor faulty?

[jagged ben]

BEMF interacting with something off about the motor?

[peteski]

BEMF interacting with something off about the motor?

Good point.  Disabling BEMF (bit 0 in CV49) would be good to try.

[DRGW5349]

Since you have corrected the connection from decoder to motor, I would suspect that the wheels are to blame. Many of the Atlas runs have poor plating on the wheels and will oxidize rapidly.

[jagged ben]

Since you have corrected the connection from decoder to motor, I would suspect that the wheels are to blame. Many of the Atlas runs have poor plating on the wheels and will oxidize rapidly.

Based on the video I thought something like that, but it doesn't fit with his description that temporarily disconnecting the motor and running DC through it, without cleaning wheels, makes the problem go away ... for a while.

[Dwight in Toronto]

Thank you to all for your suggestions.

Yes, Pete, you followed along intently when I had an equally perplexing problem with a Kato ES44AC equipped with an ESU 58741.  I ended up replacing both motor and decoder on that one.  The motor later proved to be fine; I have yet to revisit the decoder and experiment further.

On THIS one, I haven’t replaced anything.  Every time I ‘boost’ the motor with straight DC, the loco resumes normal DCC operation for a fairly lengthy, but indeterminate length of time.

I did what you suggested - turned off BEMF.  The loco is no longer speed-matched to its brethren, but it is running fine. 

Re: other suggestions - I can attest that this is not a dirty track/dirty wheels problem.

Normal running has resumed; I guess time will tell.  I will update if/as/when anything untoward reoccurrs.  In the meantime, it would be great to here if any others have anything to share.

[peteski]

I would keep running it with BEMF disabled and see if the problem returns or not.  As for speed matching, do  you run it in multi-unit lashups?
If not, just try to play around with CV2, 5, and 6 (or the 28-step speed table). I think you should be able to get it close  to the speed you were used to with BEMF enabled.

I still wonder if there is a (conductive) carbon build-up between the comutator segments causing problems.  DC throttle just puts out brute force DC signal, so  the motor runs ok.  But PWM driver and BEMF circuit measuring the voltage generated by the motor is affected by the build-up.

Unfortunately the motors used by Kato and Atlas hide the commutator from view (and from cleaning).  I have resorted to  either trimming some plastic from the plastic end of the motor, or removed one of the brushes and clean the gaps through the brush holder opening (not an easy task).

[Dwight in Toronto]

I quite often/most-times run two of these Atlas sound-equipped GP’s lashed up with a Kato LokPilot-equipped B unit.  I’ll re-establish speed-matching later today.

It seems odd to me that, on those rare occasions where this loco has just randomly given up the ghost, it was running along at a pretty good clip in a consist.  One would think that, if it were carbon build-up, the inertia of the flywheel(s) would instantly carry the commutator right on past any trouble spot. 

FWIW, I looked at my notes on this loco … the last time it acted up was March 22nd, and the time before that was March 11th.  Not that it means much, since running time between events is highly variable - sometimes it might run a dozen hours in a month, other times it might be packed away for a month or more.  Hmmmm - do ESU decoders track-&-store cumulative running hours?

As I say, at this writing it is again performing just fine.  I guess all I can do is continue to accumulate operating time, and see what happens.

[Dwight in Toronto]

Whelp, spoke too soon.

Had the problem loco doing ovals on my test loop, and it suddenly pooped out, barely stuttering along with that characteristic super-slow, jittery dithering, just as shown in the video clip. 

At least now we know that turning off BEMF did not help nor hinder. 

I might temporarily stick a spare LokPilot on that chassis and see what happens.  If the problem disappears, fingers can point to the 58751 sound decoder.

[peteski]

Yes, trying another decoder is a good idea.  It is really strange that you have 2 locos (from different manufacturers and with non-identical motors) having the same problem.  I believe they also use different model decoder (but both are from ESU).

[Dwight in Toronto]

Yes Peter, strange indeed. 

Just a comment - I don’t much like the Atlas N scale chassis, and the way that the ESU ‘drop-in’ board mates with it. 

First, the OEM motor lead contact method just looks “iffy” to me (ie - there are two contact patches on the bottom side of the decoder board that need to precisely and lightly press down on the two small, curved, factory brass motor leads (sort of a gentle spring-induced contact design).  To me, this approach just looks prone to being hit-or-miss, so to avoid potential problems I prefer to straighten those motor leads, put Kapton tape on the inside surface of the frame in the vicinity of the straightened leads, and directly solder the orange & gray wires from the decoder.  That removes any doubt as to whether or not the motor is getting any ‘juice’.

Second, I don’t like the friction-fit where the track power segments of the decoder board mate with the squeeze-slots on the chassis.  There are very small barbed brass clips that slip on to the decoder tabs, and then get forced into the slots on one frame half, after which the other frame half also needs to be aligned and squeezed back together.  The only upside to this is that board-to-frame conductivity is pretty darn good and assured.  The bigger downside is then having to put the trucks back in, then the insulating pins, then the retaining nuts & bolts.  In other words, having to take the entire chassis apart to troubleshoot and/or change out a lightboard or decoder represents “could-be-better” engineering.

On the other hand, and in my experience, Kato frames readily accept decoder boards with a true drop-in design … basically pull back & lift out the old board, then press down & push the new board forward into the frame slots.   No need to split the chassis into its two halves.

Anyway, I’m blabbering … I’ll provide updates as I dig deeper.

[peteski]

I agree that the Atlas' design of the light-board/decoder is not optimal, and could be unreliable.

But the twitching-armature issue doesn't seem like it is due to bad contact. At lease not the contact with the frame halves because you stated that while the motor twitches, the sound and headlights are uninterrupted.  That includes speaker connections which are similar to the motor contact and located next to those motor contacts.

When the loco misbehaves (and you have the shell off), have you tried pressing down on the decoder board in the area of the motor/speaker contacts?  If those were iffy, pressing dwon should make the motor run smoothly.

Also, over time Atlas used multiple frame design in those locos.  Seems that the latest version is similar to Kato in the fact that the decoder can be slid in and out without loosening the frame halves (which can't be loosened due to the screw-less design).

http://spookshow.net/loco/atlasgp3840.html

[Dwight in Toronto]

Peteski - yes, I’ve tried pressing down on the decoder to see if there was any possible looseness that might be overcome.  But no, no improvement.

That more recent Atlas frame design looks to be superior for sure.

[Nick Lorusso]

Dwight,
What is the voltage to your rails on DCC?