My New Erie Lackawanna PA #857 conflicts within the Zephyr's tiny brain with my Chicago Northwestern Dash 8 #8507. Both move at the same time etc. etc.
I know I could reassign one of them a shorter designation, but is there a way to have the Zephyr begin to distinguish the minor difference in the CV bits for such close addresses?
Thanks.
857 and 8507 are two different numbers that should not run at the same time. Make sure one is not cionsisted to the other. If not, reprogram the address in each engine to be sure their was not a keystroke error the first time.
You must be doing something wrong. Just for kicks I just programmed 2 different locos to the 4 digit addresses 8507 and 857 and they work perfectly well independently. They are distinctly different numbers, so there should be no conflict. Put your two locos on the program track, go into program mode, in Page mode do a AD4 CV read and see what they say?
Simon Modelling CB&Q and Wabash See my slowly evolving layout on my picturetrail site http://www.picturetrail.com/simontrains and our videos at http://www.youtube.com/user/MrCrispybake?feature=mhum
My guess would be that one of them is miss programed. To which address do they both respond?
Dave
Lackawanna Route of the Phoebe Snow
Ya the Zephyr can handle four-digit numbers (up to 9999 I believe) just fine. My BN SD-70MAC is no. 9580 and it has no problems running it. I suspect one of your engines has the wrong ID programmed into it or the engines are set up as a consist or something.
I would clear the Zephyr's memory (it's explained in the instructions) so it removes any possible consists and then double check both engines IDs.
Nope, sorry guys. There is no error in the programming an no consisting. Each one reads back with its correct address on the program track and I have tried reprogramming the PA.
I will now reprogram the Dash 8.
But you know, I think it may be more likely the decoder than the controller. Maybe the NCE DSR 13s do not discriminate properly.
mfm37 857 and 8507 are two different numbers that should not run at the same time. Make sure one is not cionsisted to the other. If not, reprogram the address in each engine to be sure their was not a keystroke error the first time.
Ahhhhh, now this is interesting. mfm37, you were partly right. CNW 8507 was MU'd .....but not to the PA, but to CNW 8501 also on the track, but uncoupled.
When I cleared the consist for CNW 8507, everything was fine. All locos responded independently to their correct addresses.
So for all you Zephyr owners, this is a little lesson. An MU's loco is susceptible to cross addressing if the numbers are close, even if MU's to a totally different loco.
Maybe - but it's also possible 8501 is/was MU'd to 857, so in the end - 8507 WAS MU'd to 857, just not directly. A consist can be more than just 2 locos, AND a consist can get nested inside another consist - so if 8507 and 8501 were consisted together, and then 8501 was consisted to 857 - you had a nested consist which could control all 3.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
rrinker Maybe - but it's also possible 8501 is/was MU'd to 857, so in the end - 8507 WAS MU'd to 857, just not directly. A consist can be more than just 2 locos, AND a consist can get nested inside another consist - so if 8507 and 8501 were consisted together, and then 8501 was consisted to 857 - you had a nested consist which could control all 3. --Randy
Nope. You know how the Zephyr works. The MU's one shows the MU led lit up. And the lead loco is simply displayed normally.
And the PA was added to the layout just last night. CNW consist was made a month ago and no way any consisting was done with the Dash 8s and the PA.....who would see a consist like than anyway? Am I right?
So, I saw exactly that CNW 8507 was MU'd to CNW 8501. Not the other way around. I thought of your point right away too.
BTW. thanks to all for input (I had to dash off to pick up the little one from school after my ealier post so I forgot my manners.)
Ya the Zephyr can handle four-digit numbers (up to 9999 I believe) just fine.
Actually, the Zephyr and all other Digitrax throttles will only select up to and including address 9983. I've heard a higher address can be accessed using a Decoderpro throttle but haven't tried it.
Martin Myers
mfm37 Actually, the Zephyr and all other Digitrax throttles will only select up to and including address 9983. I've heard a higher address can be accessed using a Decoderpro throttle but haven't tried it. Martin Myers
That's part of the NMRA spec, 9983 is the highest value based on the limits of allowed values for CV17. The difference is in accessory addresses. Most throttles can't select every possible accessory address, but you can access them via a computer program like JMRI.
rrinkerThat's part of the NMRA spec, 9983 is the highest value based on the limits of allowed values for CV17.
Cisco Kid So for all you Zephyr owners, this is a little lesson. An MU's loco is susceptible to cross addressing if the numbers are close, even if MU's to a totally different loco.
With respect, I think if that were the problem, someone would have noticed it years ago. It's more likely the two engines in question were at some point part of a consist that was never broken down, particularly since the problem went away when you cleared out the consists.
One thing that I think can happen that can be confusing is that if you have say engine 200 in a consist with 100, with 100 being the lead engine, it's possible later to sort of over-ride the consist and call up engine 200 and run it by itself. But this doesn't always mean the consist it was in was broken. Later if you put engine 300 in a consist with engine 100, you might find that when you put 200 on the track, all three move at the same time, because 200 is still consisted to 100.
wjstix Cisco Kid So for all you Zephyr owners, this is a little lesson. An MU's loco is susceptible to cross addressing if the numbers are close, even if MU's to a totally different loco. With respect, I think if that were the problem, someone would have noticed it years ago. It's more likely the two engines in question were at some point part of a consist that was never broken down, particularly since the problem went away when you cleared out the consists. One thing that I think can happen that can be confusing is that if you have say engine 200 in a consist with 100, with 100 being the lead engine, it's possible later to sort of over-ride the consist and call up engine 200 and run it by itself. But this doesn't always mean the consist it was in was broken. Later if you put engine 300 in a consist with engine 100, you might find that when you put 200 on the track, all three move at the same time, because 200 is still consisted to 100.
With equal respect, wjstix, nope. That is not the case.
Only CNW #8507 was ever in a consist. It was still consisted with CNW#8501. EL #857 was a brand new entry to the layout on its first run.....not consised or speed matched to anything.
All three locos checked out with the correct DCC address afterwards.
I think it is more likely that this someone didn't notice this some time ago, is that it is not a problem with the Zephyr controller as it is a problem with the NCE DSR13 decoders in all three locos not being as discriminating as they should.
With #857 free of any consist on its first run, and with #8507 still consisted with #8501, both #857 and #8507 received signal from the Zephyr to move, stop etc. etc. ....all commands received by both.
Whatever, it is not a big deal.
I can't help but notice that all of the addresses involved begin with 85. Are you POSITIVE that all the engines have 4 digit addresses enabled in CV29 or that you have not enabled a phantom engine #85 for a consist number?
Probably not really relevant to this discussion, but this week I have been installing a 4 pack of D13SR's into various locos and have been having a devil of a job getting them to program correctly when just using the Zephyr. For some reason in Page Mode, trying to write a 4 digit address, it just does not want to take correctly. It seems to me that the Z and the D13SR's don't play nice together with respect to CV29? When I fire up my PC and use Decoder pro, via the Z's program track, I have no problem whatsoever. So I would concur that it is quite possible to have strange goings on when programing a 4 digit address into a D13SR when using a Z.
Phoebe Vet I can't help but notice that all of the addresses involved begin with 85. Are you POSITIVE that all the engines have 4 digit addresses enabled in CV29 or that you have not enabled a phantom engine #85 for a consist number?
Well, I don't think I have created any phantom #85s, but I will check.
Nevertheless, I think that, because the problem was solved as soon as I cleared #8507 from its consist with #8501, it was that condition of being in a consist that permitted 8507 to pick up nearby addressing.
Now, I don't go setting the addresses by entering CV29 values singly. I address 4 digit locos either with the Zephyr, or through the Zephyr with DecoderPro and my laptop. The controller and software set all teh CV29 values in quick succession automatically. Perhaps they are not foolproof.
simon1966 Probably not really relevant to this discussion, but this week I have been installing a 4 pack of D13SR's into various locos and have been having a devil of a job getting them to program correctly when just using the Zephyr. For some reason in Page Mode, trying to write a 4 digit address, it just does not want to take correctly. It seems to me that the Z and the D13SR's don't play nice together with respect to CV29? When I fire up my PC and use Decoder pro, via the Z's program track, I have no problem whatsoever. So I would concur that it is quite possible to have strange goings on when programing a 4 digit address into a D13SR when using a Z.
I don't think this is the same issue, but just my two cents to you:
You might see if installing a programming track booster helps you. I use one. Nevertheless, I have programmed over half of my 96 NCE D13SRs with the Zephyr with no problem even before I got the booster. I use them in all but 15 or so locos.
Traditionally the decoders that give your problem are those cheap Lenz 100s that Bachmann uses.
But every layout, programing track is different. Perhaps you have some kind of drain or connection issue that is robbing the programing track of its juice or connection.
Cisco KidOnly CNW #8507 was ever in a consist. It was still consisted with CNW#8501. EL #857 was a brand new entry to the layout on its first run.....not consised or speed matched to anything.
I don't have a program track booster and never needed one. The Lenz 1000's just need a resistor across the track in my experience to program OK. Besides, in my case the program track is the same when I am using the Z or Decoder Pro, so the current to the track is not changing, just the method of addressing the decoder. There has been a thread on the Yahoo Digirtrax group that discusses the occasional and almost random problems that occur with the NCE decoders when trying to program direct with the Zephyr. This is no biggie to me as I use Decoder Pro as my main programming tool. It just struck me as potentially relevant that the NCE decoders do seem to have a quirk when programming directly from the Z.
simon1966 This is no biggie to me as I use Decoder Pro as my main programming tool. It just struck me as potentially relevant that the NCE decoders do seem to have a quirk when programming directly from the Z.
This is no biggie to me as I use Decoder Pro as my main programming tool. It just struck me as potentially relevant that the NCE decoders do seem to have a quirk when programming directly from the Z.
Yeah, isn't that weird?
Of course, Decoder Pro is not doing anything on the layout except tell your controller what to do. It tells the Zephyr what values to send. So the Zephyr is always programing the decoder no matter what other software is involved.
But I imagine the microsecond timing of the DecoderPro signalling the Zephyr might be just that much different/ slower/ precise, whatever! that causes the Zephyr to enter the values more accurately.
Cisco Kidsimon1966 This is no biggie to me as I use Decoder Pro as my main programming tool. It just struck me as potentially relevant that the NCE decoders do seem to have a quirk when programming directly from the Z. Yeah, isn't that weird? Of course, Decoder Pro is not doing anything on the layout except tell your controller what to do. It tells the Zephyr what values to send. So the Zephyr is always programing the decoder no matter what other software is involved. But I imagine the microsecond timing of the DecoderPro signalling the Zephyr might be just that much different/ slower/ precise, whatever! that causes the Zephyr to enter the values more accurately.
I used plenty of D13SRJ's and didn't have any trouble setting addresses with my Zephyr. I will say most pof them were probably set from my DT400, since once I got the 400 I rarely touched the Zephyr other than to run a third loco or, if the 400 was connected at the rear UP5 right next to the Zephyr, I'd hit the track power button ont he Zephyr after turnign it on instead of using the power button on the 400.
The only things that would not take an automatic address were QSI, even with the verbal response turned off, the Zephyr sent out the 3 CV values faster than the QSI decoder could accept them. Somethign I noticed just doing a QSI Revolution-U install - the Rev-U had no problem workign on the Zephyr program track - even readback was fine! So QSI 'fixed' something from their OEM decoders. I could read and write any CV< even write a 4-digit address, with no problems, right ont he program track.