I have a riddle for you all. I have two brand new Athearn Gensis F9s (DCC ready), an A and B unit. The F9A has a new Digitrax SDH-186MT decoder and the F9B has a new DH-166MT decoder. I installed both myself. I’m running both engines off of one DT400 throttle. The F9A acts very strange. It runs well by itself but if I put the F9B on the tracks it acts very strange. If I start the F9A first it will run and I can adjust the F9B, but the F9A will not react to throttle adjustments until I stop the F9B. If I start the F9B first, the F9A will not start or react to the throttle.
If that isn’t weird enough… it seems this is the only engine that it reacts to like this. I took the F9B off the tracks, and tried running the F9A with other engines on the track. No problems! I tried another engine, no problems. I put the F9B back on the track, same issue.
I may have cross programed (programed in ops mode) the engines at one point, as one was on the track and I may have had the other number in the programming feature. The engines numbers are close together. However I reprogramed (CV8=08) both engines and still have the same issue.
Do I have a faulty decoder, engine, or a different problem altogether?
Sounds like some how they got set up in consist with the b unit as lead. Possible when they were possibly cross programmed. I would just make sure they were not in consist, then redue the programming from start maybe factory reset first
I have reset both decoders (CV08=0008) and I’m still having the same issues. I even consist them again and un-consisted them to see if that would reset. Right now both decoders are factory settings, so default to address 03. I am running them at the same time off of one throttle, and the same thing is happening. Once I put the B unit on the track, the A unit goes “whacky”. Does anyone have other suggestions?
Are you running a Digitrax system ? Sounds like maybe your system may be full of entries. Try deleting (dispatching) all the recent addresses that have been entered into the system. Once it is full, strange things like that can start happening when you try to add a new engine. Instructions to clear the slots …
Thanks for the suggestion, I just tried that and no change. I have a DB150 for my command station and it has been a long time since I released addresses. This is the weirdest problem, as the F9A acts normally with any other engine on the track. But if the F9B is on the rails with a throttle setting, either direction at any speed. The F9A is unresponsive to any throttle changes, if it is moving it stays moving at that same speed… if it is stopped it won’t move. This is becoming very frustrating.
I also tried running the F9B with a different engine on the track, it had no affect. So it is only the F9A that is having an issue.
Any one else starting to think corrupted decoder. Like the firmware on it became distorted? The only other thing I could think of trying would be a completely different road number. In the a unit. A very different number and see if it still happens. If it did, I would at that point get a new decode. Just where I would go with this
I will try a different address. I was thinking the same thing that it could be a defective decoder… but the real riddle is why is only affected by one engine? If I take the F9B off the track then the F9A acts normally. It is one of the craziest DCC things I’ve ever seen.
Worth a shot NILE. I hadn’t thought of it until you mentioned it, but I recall reading here about someone having an issue with a decoder (Paragon 2?) that was tied to the specific engine number. Something to the effect of assigning the decoder the number on the side of that particular engine would alter programming on the decoder, or something like that. Let us know what you find out.
If the F9A and F9B were consisted at some point, check the value of CV19 in each decoder to be sure that it has reset to zero. It sounds like a consisting conflict.
While you are at it, check the values of CV21 and CV22.
Mike, your memory serves you well. You are likely recalling the infamous Broadway Limited E7A runs backwards only in 128 speed step mode thread. Even more weird, it only happened using the long address 6207 and only on the Paragon 2 decoder.
It probably isn’t related, but for the time it takes to try…
I never would have guessed that one particular locomotive number would screw up any decoder until that previous thread showed it was possible. Thanks for finding that thread Rich. Proves I’m not losing my marbles![(-D]
My thought would be one of the decoders is bad. My other suggestion would be, since youve reset both to factory with no improvement, try putting “like decoders” in both units. Such as an nce dasr or d13sr or even 2 esu lok pilots, lok sound decoders. These are just examples of course because I dont know which decoder those locos take. I would also send the 2 digitrax decoders you have back to digitrax and let them check them or fix them. They are under warranty I would assume so they should repair them for free.
Whatever you decide, my suggestion would be to use the same decoders from the same manufacturer in any permanent consist lashup like an AB, ABA or ABBA setup.
Anything is possible here, but I am having a hard time concluding that it is a decoder problem or a conflict between two decoders. Both are Digitrax decoders, one (SDH-186MT) is a sound decoder (F9A) with 21MTC interface and the other one (DH166MT) is a non-sound decoder (F9B) with 21MTC interface. That is a “typical” setup for a two-loco consist with sound in the lead loco and non-sound in the trailing loco. I might be more inclined to think that the decoder could be the problem if both decoders were identical.
NILE has done a thorough job here of describing the problem. The F9A only goes “whacky”, to use NILE’s term, when the F9B is “on the tracks”. Something is apparently amiss when the two F9s are running together on the layout. That tells me that it is a programming conflict of some sort. Consisting? Addressing? I think it is a CV issue.
If it is a consisting issue, I would check CV19, CV21 and CV22. CV19 is the Advanced Consist Address. The value of CV19 should be set to zero if the two locos are not intended to be in a consist. CV21 and CV22 are Advanced Consisting Controls. The values of these two CVs should be set to zero if the two locos are not intended to be in a consist. I would check them and not assume that a decoder reset (CV8=08) had set them to zero.
If it is an addressing issue, any numbering conflict should be resolved by running both locomotives on the short address 03. NILE says he has done this. Even so, I would check the value of CV1 on each loco. I would also check the values of CV17 and CV18 (the long addresss) on each loco just to see what values are present in those CVs.
This may all be a waste of time, but I think that it is worth the effort at this point.
Thanks for all the recommendations. The F9A engine number is 770 and the F9B is 777. I reset both of them to default. I set the F9B to 777 and I set the F9A to 7000 just to be different. I had the same results, the F9A still would not respond to the throttle if the F9B was in motion.
I started seeing how these engines responded to other eninges, and weird responses. It is just these two eninges. I also reset CV19, CV21, and CV22 to 0 on both engines. That did not change anything.
I am using a DB150 command station/booster and I did recieve a “Slots Full” message. I tried to reset my command station by putting it in OP mode, setting Switch 36 and pressing “c”.
I’m getting to the point where I think the decoder in the F9A is just “loopy”, any other thoughts?
Oh well, so much for CVs being the issue. Do you by chance have a spare decoder that you can try in the F9A? If you do, don’t even bother putting the shell in place. Just test another decoder. That is going to be a real bummer if that sound decoder in the F9A is defective.
From a quick re-read of the prior posts, it looks like he’s said a couple of times that the A unit works OK by itself, but not when the B unit is on the track - but (unless I missed it) he hasn’t said that the B unit works OK when on the track by itself.
Even though the system has been cleared of consist set-ups, it still sounds like there’s some problem there with consists. That’s the only way one engine being on the track could affect another engine; they’re either in a consist or have the same long or short ID or have one of the consist CVs with same entry.
It can be odd, I use CVP for my layout but an old Zephyr for break-in runs and programming on a circle of track separate from the layout. I recently was trying to program a decoder to ID 104, and found to get it to work I had to program it as long address 0104 to get it to work, even though 127 or lower is supposed to be a short address. I’ve also had decoders where I’ve changed say the long address but the short address stayed 03 and my DCC system only recognized the short address.