Motor replacement for 1997 Atlas GP 40-2

[peteski]

The 9V battery is for giving the decoder basic functionality test (assuming DC mode is enabled). It provides pure DC voltage which is compatible with decoders. I always have a 9V battery handy on the workbench just for this type of test. I would still be interested how the latest installed decoder behaves if you tried this  type of DC power.

Also the odds of multiple decoders being defective (especially if they worked for a while) are pretty low. I suspect there is something else going on.

[tehachapifan]

I may have identified the issue! The motor leads are exposed to the possibility of contacting the frame in the top opening when you, say, put the shell back on. The areas indicated below must be wrapped in Kapton tape.

[DWS3]

Tehachapifan,

Thanks for looking! Unfortunately, they were wrapped in kapton tape when the problem occurred. Much of the kapton tape originally applied (to include the motor leads) was removed so I could take these pictures for TCS when the decoder stopped working. They wanted to see the installation to help troubleshoot before I sent it in for warranty service.

D.W.

[tehachapifan]

The motor leads were wrapped in Kapton, or the frame was wrapped where I indicated? The reason I ask is, this area is big culprit for shorts. I can see no reason to have to remove the Kapton tape from the frame for photos, as it should not obscure the view. Kapton tape wrapped around the frame area I pointed out would be more trustworthy (for lateral contact), in my opinion, than if the tape was wrapped around the motor leads (a motor lead might still catch the underside or corner of the frame bar if the tape doesn't extend down far enough or comes loose).

[DWS3]

They were both wrapped - the frame and the wires. I initially planned to use shrink tubing on the wires but the kapton tape seemed to give more "flex" when I taped the slack wires inside the loco.

D.W.

[jjb62556]

Did you have tape between the moter contacts and the frame at one time. I know it can get tight in that area. one touch...puff.

[DWS3]

I did but since several folks have mentioned that it is a common spot for frying decoders, I am starting to think that maybe the tape I had slipped just enough that perhaps it caused a short. It is a mystery and I'd love to be able to keep using the motor I have, since it has little run time on it and would make it a lot easier to speed match with it's twin for some yard switching.

This is also my first TCS decoder and n-scale keep alive ( I also model a bit in HO and G scale). I'd love to see the performance gains in n-scale that I did in HO, even with all hand laid and powered track.

D.W.

[peteski]

As I mentioned earlier, I would make an educated guess that the chances are 99.9% that the motor is fine.
Also, while decoders usually have the motor driver circuit protected against shorts, that does not protect against shorts of the motor output to the track power.

While nothing to do with this problem I'm not a fan of TCS (or Digitrax for that matter) decoders. I had some issues with TCS (buggy firmware). Digitrax has weird BEMF implementation and their FX lighting effects are terrible when using LEDs.  Nowadays, with the prices much more competitive, I much prefer ESU brand. ZIMO is also very good but both, being German and Austrian, have some English documentation shortcomings.  But this is just a personal choice considering the features and capabilities of each brand.

[DWS3]

Interesting. I picked TCS for this engine partly because a lot of folks indicated they really liked the smooth motor control. Since I don't use sound decoders in n-scale, I figured ESU was overkill. I also wanted to be able to try one of the n-scale keep-alives and figured having both be from TCS would be a good start. I also had trouble determining to what level I could program an ESU decoder without their stand alone programmer. Up to this point I've used either the NCE system or DecoderPro with great success.

D.W.

[peteski]

ESU LokPilot out-of-the-box is just like any other decoder.  Change few CVs as needed and off you go.  You would only need LokProgrammer to update the decoder's firmware (which is a great feature). Decoder Pro (if you use it) makes ESU programming (like function mapping, speed tables, etc. much easier than doing it manually one CV at a time, but hat is true for any decoder Decoder Pro handles.  Price of ESU's LokPilot (no sound) decoders is now comparable to domestic brands.  They are also quite small, which is plus for N scale.

As I mentioned, it is a personal preference, but I got burned on TCS Z2 decoders and they always seemed to have higher price than other domestic manufacturers (Made in USA? thing?)

[DWS3]

Success!

I received a new M1 decoder from TCS, as the first one was shorted out. Still not sure how that could have happened but apparently it did. In any case, the new decoder, keep alive, and LED lights are installed and after about 20-30 minutes of running, everything seems to be working! Now I am starting to make adjustments to BEMF, speed tables, etc to get it to run the way I like. Ironically, it actually seems to run a little better without BEMF, especially at lower speeds. I am assuming that is because the keep alive helps on any dirty track spots but I do need to clean the track a bit since it's been sitting for a couple weeks.

When I first got into n-scale back in the early 2000s, I was amazed by DCC and how much had changed since I ran 0-27 scale as a kid. Now, 25+ years later, hand laying track, keep alives, LED lights, DecoderPro and the new N-possible couplers have made it even better. I was seriously considering moving to HO for good but now will likely continue to experiment in both scales with layouts better suited to the strengths of each scale.

Thanks again to everyone for all the assistance. I would still be interested to know if the newer Atlas motors will fit with minimal fuss in the early DCC ready frames but at this point, the original motor seems to be working just fine.

D.W.

[peteski]

D.W.
BEMF is a decoder feature which tries to keep the motor's rpm constant regardless of the load using feedback from the motor. It has nothing to do with power delivery from track to the decoder or brief dropouts traveling over dead/dirty spots on the track.

BEMF can also be difficult to tune properly. If you think your model runs better with it disabled, then just turn it off.   You might notice a difference though when pulling a heavy train.

I'm glad you got the problem resolved.  If decoders kept getting damaged then I do suspect that the something (like the motor leads) were getting shorted to the chassis which has the DCC voltage on it.

[DWS3]

Peteski,

Yeah, I've always used BEMF on my engines but not sure if I really needed it, especially since I don't have any grades. In this case, it may just be some slightly dirty track. I've only built a 1' x 6' switching layout with hand-laid track so far, so I may continue to make tweaks as the layout grows. I am considering a two-level design to create more staging space.

In any case, DecoderPro makes it so easy to change CVs and then see how it changes the engines performance that I'm just trying new things. In the past, I used the NCE cab to change things one CV at a time while writing it all down on paper so I knew what I had changed. DecoderPro really is a game changer when it comes to easy DCC programming!

D.W.

[MILWcoastdiv]

Hi D.W. 

Is the keep alive a worthy investment in your opinion?

Thanks,
Mario

[peteski]

Hi D.W. 

Is the keep alive a worthy investment in your opinion?

Thanks,
Mario

While the question was addressed to  D.W. I'll give you my take.  Kato 6-axle all-wheel-pickup with wheels which do not seem to get dirty as fast as other brands, and fairly heavy chassis, if you gave good track-work and keep it clean, a keep-alive should not be required for fault-fee running.  But if you like a belt-and-suspenders approach, then yes, add a keep-alive.

Also  "keep-alive" seems to have become a rather nebulous generic term.  Which one do you have in mind?  A small one which keeps the model (and sound) going for less than 0.25 seconds, or what I call "conventional" keep-alive which will have the model run for a second or more with no power coming from the rails?