I am using the PR3 to test the locomotives. And I have never had an Altas factory installed NCE decoder ever work out of the box. So my solution was simple. I do not bother buying any more Altas locomotives ever again. Wasted too much money replacing the pathetic NCE decoders.
Reminds me that I need to move my belt sander like yours over to my work station and use it more when building turnouts. Have fun with the building and hope by the time you see this the last 5 (for now) are done. Sumner
I am doing the same thing. It is not what you think though. NCE firmware is the definition of Mediocrity. Every other decoder I have from Soundtraxx, MRC, Lenz, Digitrax, TCS, ZIMO and ESU work fine. The MRC are in the Athearn Challengers, and they work fine and also respond to the PR3. At least Atlas is now using ESU decoders for their Gold Series, not sure what the others are since I am not a fan of the Atlas locomotives because of the unreliable design on connecting to the motor leads. It is ridiculous that after all this time they can not seem to do better than a hope and a prayer the motor leads will contact the DCC boards at the right place and do not change over temperature.
AFAIK, railcom-enabled decoder incompatibility with non-Railcom DCC command stations was due to command station spec ambiguity and/or violations which were exposed by railcom, not the decoder or railcom itself. The mass failure of older decoders could be related to adoption of early, ill-developed, lead-free solder processes, or just poor long-term memory retention.
The new SD9's have the wheel wipers and motor hard wired with micro plug for the board. I like the new design and it looks to be heavier than the split frame units. That said one of my Gold series ESU with sound has failed. It started out without motor control, yet I still had light and sound. Then the sound quit. I think it ran for 5 minutes. I will try to warranty it, but I had to move the decoder to another unit to see if the decoder was the issue. Fingers crossed they still fix it.
WOW! And I thought I was the only one who was exasperated with Atlas's motor leads design. I got two SD35's that have befuddled me to no end.
I have gotten to the point I toss the ones that are troublesome in the trash. And because of all this nonsense,I have not purchased an Atlas locomotive in several years. I can not decide which is worse, the IM Frame rot or the Atlas motor lead nonsense.
Current status, all UP locomotives were tested as of last night, and only 2 bad decoders in that bunch of 115 locomotives. In process now is my Norfolk Southern, heratigate to my family that worked on that railroad. It is another big box full of locomotives. Just one failure that was expected, an Atlas SD60 with a factory NCE decoder.
I need to build one more turnout and I can move to the garage workbench to lay track and wire. This will be the Indio end of staging. 10 tracks. This mounts above the benchwork where the red tool box is.
With UP finished with only 2 failures, 126 good, took care of all my Norfolk Southern with 1 bad decoder out of 127 and moved on to Southern Pacific. So far only one bad decoder on SP. Next up is CSX!
Well the end is in sight! All that is left is the box with the BN and BNSF locomotives. It is full to the top of the box so it will take a while to get done. No appreciable increase in decoder failures thus far. Well I need to stop stalling and get to it!
I just recently looked at a handful of locomotives that “didn’t work” and found that the decoders were fine, but the data saved in them was not what was expected. All were older units, most had TCS decoders, with a few NCE and Digitrax. I was able to use JMRI and Decoder Pro to reset them, then reprogram the decoder to the cab number. I’m guessing it’s a problem with the memory chips not holding their settings. One I looked at was supposed to be 3823 and the decoder read 3827. In reality that is only one bit different than what it was supposed to be. A binary 7 looks like 0111, and a binary 3 looks like 0011, so while not off by much, it’s still off. So before condemning the decoders check them to see if the data didn’t get corrupted from non use.
Massey, my testing was just to see if the decoders were still alive or dead. I saw several units come up with the wrong number, like you. On those units that came up with the wrong number, I just had JRMI reprogram them. Then run them for a bit.
Well the bulk testing is done, only 2 of 140 BNSF locomotives need new decoders. 2 Kato GE C44-9W's need new decoders. So that is all there is except a few switchers in things like the Navy set, the MOW and Pearl Harbor sets that came with locomotives. But that is a handful. So the numbers are 35 locomotives out of 1445 need replacement. or 2.4221% failure. That still seems rather large.
Well I started trains in the mid 1990's, started DCC in 2004. Many of those had a Digitrax DZ143, they were highest of the failures. My first DCC locomotives were Kato F units with Lenz Silver Mini's done by a woo woo woo (thought I would save you the trouble) shop on the East Coast. When the board replacement locomotives came I switched and did those myself as much as possible. As for how long the may have stood, well the ones here were to be sent to my place in Arizona soon. But all in all, like many things COVID stopped all the train shows locally. That is where I ran most of the stuff here. Eventually it will all end up in Arizona, along with me.
Very good point. Early, non-volatile RW memory did not have the data retention reliability we take for granted today. That's why it often included parity, if not EDC (Error Detection & Correction) bits. I'm assuming your 3823 & 3827 numbers are in hexadecimal, not decimal. It is best to designate the base for a number when not expressed in decimal, to avoid confusion. For example, 3823 decimal is 0xEEF whereas 3827 decimal is 0xEF3, a difference in more than one bit location.
