New Atlas GP7/9 (40 005 3xx series) /ESU 59925 Decoder Issues

[Dupesy]

Well, I agree that there seems to be some sort of compatibility issue, but in this instance ESU LokPilot is just a plain motor-control-only decoder, not like a LokSound decoder. It doesn't require more power than any other motor-only decoder (like Digitrax DZ126 for example). I think there might be something with the Decoder Pro going on, but I'm not really up on that facet of DCC.

Understood.  I have no issue reading LokPilot decoders with JMRI, but I have a programming booster in line.  I do the programming with the ESU decoder; i like the interface better.  I have not tried programming them with JMRI yet.  I've installed several of the ESU 59925 decoders with no issues.

[peteski]

Kinda disagree with you here.  ESU makes a 6-pin connector with extra wires for extra functions, and I plan to use them in my FVM GP60s where the extra function LEDs will be attached to the shell, so the 6-pin connector should still make a nice way to disconnect the shell from the chassis and motor when maintenance is needed.  So it won't be pointless at all.  But yeah, the 6-pin isn't going to make sense for sound so I don't expect to see new models designed for it nowadays.

Well yes, but if you have to solder wires (blue wire), then it is no longer plug-n-play, is it?  And only headlight functions do not  allow for things like rotary beacons or ditch lights.  I am aware of the fact that ESU 6-pin decoders do have the "blue" pad (along with several additional AUX functions) available for a hybrid (plug-in and soldered) installs. I'm also aware that many manufacturers using the 6-pin interface added a 2-diode "blue" circuit on the light board, so they do provide a true blue connection for headlights.

Still,  the 6-pin connector is for only the very basic plug-n-play DCC installs. As you mentioned, no extra functions or speaker connection.  This connector is one of the earliest universal DCC interfaces.  I have an older Minitrix model of a German diesel loco, and it has the 6-pin connector.  That model was made in the '80s, and the connector (according to the enclosed manual) was for installing a Trix Selectrix (standard parallel to DCC) decoder.  That was way earlier than any other manufacturer (especially American manufacturers) included a 6-pin connector on their light boards.

I don't know the specific reasons ESU decided to use E24 connector, but at least for now it's here to stay.  And with the constant advances in electronic circuit miniaturization, I expect that DCC components will keep getting even smaller and more delicate. They will require delicate and precise installs.  However, I also suspect that more and more companies will be offering models with decoders already installed (or as part of the light board), so modelers will not have to fear installing a decoder.

[peteski]

 @rickb773 , a month has passed since last post here.  What was the solution here? Or did you just abandon trying to figure out what was wrong?

[rickb773]

@rickb773 , a month has passed since last post here.  What was the solution here? Or did you just abandon trying to figure out what was wrong?

I just got them back from the Hobby Shop this Saturday (4 weeks). Evidently the engines needing the ESU LokProgrammer work go to a very talented young Tech who only works Saturdays and is sent off to man the sales booth at all their out-of-town week-end conventions. (ESU dealers will set the engine numbers for free!)

He reset the decoder (CV8) and entered the requested engine numbers.
Now they all run: default slow start and low high end.
This is why I would like JMRI access to the decoders to use a log scale run range.

I am having trouble with one of the engines tracking.
The tech told me some of the Atlas engines have this trouble due to the wiring interfering with the trucks.
I have corrected that for 2 of the 3 engines but the 3rd has continued to be troublesome.

My thanks to all those who offered help and tolerated my DCC ignorance.
Special thanks to @EL3632 (Ken at Yankee Dabler) and Lee Ryan at ESU support.

Before the WP & B&O fans get excited, I substituted older Atlas shells onto the new Atlas frames.
Now I'll take a page out of @Ed Kapuscinski 's book and offer the nice new shells (NYC and NH) for sale on old but reliable Atlas non-DCC frames.

Enjoy the video:
https://www.youtube.com/watch?v=HI8k2-R-F3Q

[peteski]

Thanks for the follow up Rick. I always find it very helpful to me (and other people looking at this thread in the future) to know the outcome of the troubleshooting/repair process.

ESU decoders do not require LokProgrammer for programming. The only time it would be needed is if the decoders firmware got corrupted and it needed to be reinstalled.  Something similar (firmware corruption) can happen to other brand decoders but since there is no capability to reload their firmware, they are considered unrepairable.

If resetting the decoder and entering an address fixed it, those are very basic DCC functions (part of NMRA DCC specifications) which every DCC system should be able to perform. ESU included. If you tried to do that using just your command station and its programming  track  (not DecoderPro) , I bet you could have "fixed" that decoder too.

I don't use DecoderPro (JRMI as you call it), but I see plenty of members of the Groups.io LokSound group using it successfully (standalone or in conjunction with LokProgrammer) to keep track of their loco roster and decoder settings. If you have issue with compatibility of ESU decoder and your DecoderPro setup, that likely is something in your setup.

The important thing is that the problem is taken care off. Well, except for that one troublesome loco, but that does seem like a mechanical issue.