Greetings all. Interesting problem. I've set up a consist using JRMI of 2 locos. Both units run fine on their own and I speed matched them in both directions on my test track prior to heading to my local club. Everything looked good forward and backwards, so off I went. Arriving at the club, which uses a Digitrax system, I placed them on the tracks, acquired them individually to start them up and then acquired the consist address to run. Out of the yard I went with around 20 cars in tow. When leaving the yard, there is a couple of friction points as trains have to navigate a few switches coming out of a Y. I noticed that the consist was struggling to pull through this section. In previous years before using DCC this wasn't an issue with these units on larger layouts with grades. After some hands on, I realized that the 2nd unit, 877, was just buzzing and not actually moving. The lead unit, 837, was pulling the dead loco along with the cars. Nice job! I pulled 877 and ran for the rest of the day as the layout doesn't really need 2 locos to pull these shorter consists - it just looks better with 2. Troubleshooting this evening on my test track, the unit behaves the same way - sometimes. In normal operation, which is reversed for the consist, it buzzes and doesn't move and has even tripped the circuit breaker in my Ardunio motor shield. However, if I place it in reverse, which would move it locomotive forward, it is fine. If I run the loco on its own, it operates normally in both directions with no issues. In an attempt to isolate the issue, I added a different unit into the consist and everything works fine, so I know it is for sure the 877 unit. I've removed the unit from the consist and re-added. I've mixed and matched the operating direction in all combos to try and fix or reset. No luck. Behaves the same. My guess when it is buzzing and not moving is that it is attempting to run the motor in both directions, causing the vibration and possibly the system short. The question is, why is it doing this? And why only in consist mode. Thanks for your responses!
I would reset 877's decoder to factory default and see if it still happens before proceeding to troubleshoot more.
So, what happens when you put both consisted locomotives on the layout, but not coupled together, with some spacing between them, then command them as a consist? This should show if they are not speed matched properly, or one is reversed, etc. without them binding (at least until/unless they run into each other). It should show you how (if) they are operating differently when commanded as a consist.
Thanks for the responses. For resetting the decoder, will this reset to "as delivered values" while preserving the sound files, or does it wipe everything? Big Jake, this is how I was testing after I discovered the issue. Locos on track with several inches between. When running consist forward (2nd unit reverse) the lockup occurs. When running consist reverse (2nd unit forward) operation is as expected. And, as stated above, by itself and not in consist, the 2nd loco runs normally.
the sounds will always be preserved on a reset, the settings will be returned to the state last written with a LokProgrammer and the “Write data as default” selected. Most dealers and installers will set the sound projects “default” settings as the new decoder default. if you have a LokProgrammer (or know someone with one), one can restore the sound project by reloading the data (and I would normally rewrite the sound, too). If not, you can read all the CVs with DecoderPro, prior to resetting the decoder, which will give a good baseline to start with, in case the reset screws up the programming. when resetting a LokSound decoder, write CV8=8, then remove power.
Then it sounds like the decoder is faulty. A decoder reset might fix it, but I doubt it. Might be worth a try, but I'm not sure I'd trust it not to do the same thing again, eventually, and likely at the most irritatingly inconvenient moment.
Thanks Rick. I'll give it a go this evening. An additional question to this. I have the settings saved in my roster entry for the loco in JMRI. Is it safe to write those back once the reset is complete or should I assume that those are incorrect and re-configure. it isn't a big deal to do so, I can rename the existing file and manually input the few settings I've modified.
Based on everything you've reported, it should be perfectly safe to rewrite all the CVs (if they have even changed). The behavior is not CV related, at all. But, before writing, you may want to clear any and all consisting info (consist address and the function key response in consist - CVs 19,21,22) by setting those to Zero. Then, test the loco for proper functionality, etc, and only after everything is working correctly stand alone, try to consist again. This is definitely a strange one. Something else to do before decoder reset: go to the Information Tab in JMRI, and do a read page. Please post a screen shot (or type the data) for future reference here (will help us track down exact info and provide other suggestions).
Rick, Well, things are not great. I reset the decoder per your instructions, did a full read and then tried normal operation. The loco will not run reverse, which it was doing previously. In non-consist mode, running the motor revers now also has the buzzing from the motor. Looking online a bit, it seems that sometimes this can happen with these decoders? To verify it wasn't the motor, I ran leads directly to it and ran both polarities. No problems in either direction. My assumption at this point is that the decoder has been damaged somehow. Unless someone has a magic fix, I'll be contacting ESU tomorrow and initiating a return for warranty. What a pain. This decoder (all of mine so far actually) are hard wired into lights and motor due to their age - no circuit boards present. Good news is, I can still run my other 2 converted locos in consist.
Too bad. I have not come across a LokSound decoder with a motor driver issue in one direction only, but it is certainly possible. I assume you’ve checked all the trucks and gears for any debris.
Just a follow up on this. I contacted ESU and the determined that the decoder was defective. Mailed it out to them and they sent a new replacement programmed to my liking. Excellent customer service. The call was maybe 5 minutes. No fuss, no hassle. Now to re-install..
