Thanks Don. I am learning a lot about how to screw up when using Digitrax throttles and tips on how to avoid or insure against doing so. I appreciate that and I now see how easily things can go sideways.
But the erratic loco behaviour described in my original post was definitely caused by incorrect CV settings in the loco decoder. I know that because setting CVs back to the correct settings fixed all the problems and the loco ran perfectly. This happened twice, both times unexpectedly and each time with different behaviours so I presume different CVs and/or values. So the question remains - has anybody experienced CV values on a QSI Quantum version 7 decoder changing unexpectedly? How could this happen during normal operation?
I have experienced random speed changes and surges myself with my digitrax system. Turns out I had a decoder programmed to both the jump port AND the DCC throttle creating conflicting commands on speed.Make sure your jump ports are set to address 0.I think it was Randy that suggested this fix.
Don - Specializing in layout DC->DCC conversions
Modeling C&O transition era and steel industries There's Nothing Like Big Steam!
Thanks for clarifying that Randy. Good to know.
I now recall I read about the Digitrax powerup commands in the PSX-AR manual (PSX-AR is an autoreverser and static DCC decoder). The most recent version allows a jumper to be installed to prevent any problems with Digitrax but earlier versions would treat the whole series of power up commands as programming instructions if the program/operate jumper was in the programming position. The result was random changes to decoder addresses and no response to legitimate programming instructions.
The initial commadns a Digitrax command station sends out on power up are only queries for stationary decoders so that the system can potentially get the current status of the layout (like turnout positions and occupied blocks). It has nothing to do with track packets and mobile decoders.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
I will do that. However since the self re-programming seems to happen randomly and resulted in two entirely different behaviours, I am not sure preventing operation in DC mode is the answer. Restricting to DCC only with CV29 is good insurance though and eliminates one whole area of potential mayhem. Thanks.
Do not blame your DCC system. I can think of two possibilities:
I would change CV29 to reflect that the decoder is set to 'NMRA Digital' only and retest. If a decoder sees something non-DCC, it can revert to DC mode, and full speed run-away operation is typical. Getting rid of the 'analog/DC' option should cure that issue for now. If you are still having wierd things happen, it is time to replace the decoder(as your other engines have no problems).
Jim
Modeling BNSF and Milwaukee Road in SW Wisconsin
No loose wires or foreign objects. When the problem first occurred I had the same thought and removed the shell, checked continuities from each wheel to decoder board while wiggling things. I also changed both keep-alive capacitors as the bucking appeared like an intermittent supply. However, no change. I then did a factory reset and everything ran perfectly.
Were you able to fix your QSI loco which became unresponsive? I ask because a factory reset on QSI is more complicated than most. CV50=255, CV49=128, CV56=113 IN THAT ORDER. Alternately, you can reset with a magnetic wand but I bought used so had no wand or indication of where on the loco to wave the wand.
I had a defective crossing track, and one of my QSI locomotives went over it and shorted. The decoder became unresponsive after that.
You may have a loose wire or other bad contact inside your locomotive or in the trucks, which would also explain the jerky behavior. Shorts can do bad things to decoders. Take off the shell and look for loose wires or odd things like track spikes, screws or other bits of metal that don't belong there.
It takes an iron man to play with a toy iron horse.
A locomotive (Atlas Gold Series MP15DC) with a factory installed QSI Quantum version 7 sound decoder seems to spontaneously reprogram itself. I am using a Digitrax DCS51 DCC system. This is an older loco and decoder (firmware build date 2009) which I recently bought used.
This happened twice. The first time, the loco ran as if there were dirty patches on the track, surging forward and then stalling or crawling before surging again. Other locos with different decoders worked fine on the same track. This was fixed by resetting to factory defaults.
The second time, the loco would accelerate to top speed and stay there for any throttle setting above zero. This time I investigated individual CVs before resetting and found several related to motor control (and lighting options) had been changed (I use JMRI Decoder Pro so just did a "compare" under the CV tab). Programming those back to their original values fixed the problem without a full factory reset.
I have read that Digitrax controllers send multiple commands when first turned on and am wodering whether these might be causing the QSI decoder to re-program itself. However, I don't have any such problems with other makes of decoders.
Has anybody else had this experience? Any and all suggestions and ideas welcome!