rrinker At least it's reproducible. The most impossible to solve problems are ones that do not happen consistently. --Randy
At least it's reproducible. The most impossible to solve problems are ones that do not happen consistently.
--Randy
Alton Junction
Well, if someone wants to try addresses with every combination of CV18 - so 255 different addresses... that would be the only way to absolutely validate things. If I had a Paragon 2 loco I could try it with Digitrax, might take a week or so, doing a few at a time until I got through it, but since I currently have no layout I have the time for that. Not expecting someone to actually take all that time to try it - one would THINK that now that BLI is aware of an issue like this existing, and acknowledges that they can replicate it, that when they do have a fix they woudl test all possible bit patterns to make sure there isn't some other value besides 63 that causes a problem. Or perhaps the cause will be revealed to be something so obvious that the fix is pretty much guaranteed to work - like they are calling subroutine A when it needs to be subroutine B.
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
I replied to BLI, asking if it was repeatable across all DCC systems that they have, and asking that the service tech forward the link I sent them from this forum thread to the software engineer.
rrinker Hmm, something else to try, when it only runs backwards in 128 step mode, is that with the headlight on or off?
Both, and the directional headlight performs as if the locomotive was told to run in reverse.
BMMECNYC rrinker Hmm, something else to try, when it only runs backwards in 128 step mode, is that with the headlight on or off?
The E7 only has the forward light, and if I recall correctly, it is dimmed in both cases, which is expected for the direction of travel. In the case of the SW-7 I tried, the reverse light was lit and the headlight was dimmed, as you would expect if rule (17?) lighting is setup, also reguardless of the direction selected on the throttle.
rrinker 28 and 128 speed steps use different packets. 14/28 speed steps use the same packet in differnt ways, which is why you have the bit in CV29 that tells the decoder which option to use. 128 speed step packets automatically tell the decoder to use 128 speed steps, the setting of CV29 has nothing to do with this.
28 and 128 speed steps use different packets. 14/28 speed steps use the same packet in differnt ways, which is why you have the bit in CV29 that tells the decoder which option to use. 128 speed step packets automatically tell the decoder to use 128 speed steps, the setting of CV29 has nothing to do with this.
Rich
BMMECNYC The E7 only has the forward light, and if I recall correctly, it is dimmed in both cases, which is expected for the direction of travel. In the case of the SW-7 I tried, the reverse light was lit and the headlight was dimmed, as you would expect if rule (17?) lighting is setup, also reguardless of the direction selected on the throttle.
I started to take up Randy's challenge to test every long address in which CV17=216. Unfortunately, there are 256 such addresses (6144 through 6399). I am able to change the long address POM by changing the value of CV18, while leaving the value of CV17 set at 216. Each change of address takes about 1 minute, so it would take about 4 1/4 hours to test in this manner. I did 20 changes between 6206 and 6225, and only 6207 failed the test.
If Randy will supply me with beer and pizza, I will continue the test.
Edit Note: I have corrected the statement made in this reply. I meant to test various long addresses in which CV18=63 was the constant, but I mistakenly tested long addresses in which CV17 was the constant.
Accuracy of the test may suffer as number of beers goes up, but sure. Just after you are done you need to send me the loco so I can repeat the tests using Digitrax.
I tested some DCC addresses today, here are the results:
DCC Address (CV 17, CV 18)
Checking to see if glitch occurs accross full range of possible CV 18 values of 63
831 (195, 63) Glitch present
9791 (230, 63) Glitch present
Randy's and/or Rich's something about binary theory from above somewhere:
6080 (215, 192) Glitch not present
6015 (215, 127) Glitch not present
6143 (215, 255) Glitch not present
BLI confirmed that this occurs on Digitrax as well by email.
BMMECNYC I tested some DCC addresses today, here are the results: DCC Address (CV 17, CV 18) Checking to see if glitch occurs accross full range of possible CV 18 values of 63 831 (195, 63) Glitch present 9791 (230, 63) Glitch present
In my earlier reply, I misspoke when I related my test. I mistakenly tested CV17 as the constant, not CV18 as I meant to do. I corrected that earlier reply.
richhotrain rrinker 28 and 128 speed steps use different packets. 14/28 speed steps use the same packet in differnt ways, which is why you have the bit in CV29 that tells the decoder which option to use. 128 speed step packets automatically tell the decoder to use 128 speed steps, the setting of CV29 has nothing to do with this. The reason that I brought up CV29 is because CV29 controls the direction of travel, forward or reverse. If a long address such as 6207 results in a reverse travel direction when 128 speed is selected, then the value of CV29 apparently has been increased by 1 even when the Direction button has been toggled to forward. Rich
The reason that I brought up CV29 is because CV29 controls the direction of travel, forward or reverse. If a long address such as 6207 results in a reverse travel direction when 128 speed is selected, then the value of CV29 apparently has been increased by 1 even when the Direction button has been toggled to forward.
Isn't CV29 where the 28/128 speed step data is stored? Have we tried setting CV 29 to 35 for reverse direction operation?
BMMECNYC Isn't CV29 where the 28/128 speed step data is stored? Have we tried setting CV 29 to 35 for reverse direction operation?
No, CV29 has nothing to do with 28/128 speed steps. It DOES switch between 14 and 28 speed steps. The 128 step packets are completely different and the decoder automatically detects them. The inclusion of "28/128" in the description for bit 1 of CV29 is really a mistake, it only switches between 14 and 28. See one of my earlier posts in this thread - you can verify this for yourself.
Randy, I think most of us get that, but what I was saying is that CV29 is apparently not part of this specific problem. It seems more to do with the Direction button or the failure to activate the toggle effect of the Direction button in conjunction with 128 speed steps.
Whatever the problem, the programmer at BLI will likely have a patch in a month or so. (At our company critical patches are usually out < 1 week but I doubt BLI has the resources we do)
There's nothing else to do but wait.
Don - Specializing in layout DC->DCC conversions
Modeling C&O transition era and steel industries There's Nothing Like Big Steam!
DigitalGriffin Whatever the problem, the programmer at BLI will likely have a patch in a month or so. (At our company critical patches are usually out < 1 week but I doubt BLI has the resources we do) There's nothing else to do but wait.
Hence all the bit pattern tests, to see if it was limited to CV18=63=00111111 or other bit patterns caused the same problem. So far it looks like only when CV18=63 is there a problem. That's the sort of info that could help a developer track down the cause of the problem, otherwise is't just a curiousity. It's clearly beyond fixing just by setting CVs.
As part of that intellectual curiosity, I would like to know what caused the error, but that may likely never happen.
It sure does seem like a very obscure programming error to only affect the 128 speed step on a long address in which CV18=63.
One year an no email from BLI.
BMMECNYC One year an no email from BLI.
Well it seems they think they have it fixed. The nice lady on the other end of the phone call seemed to think they fixed it at some point (yahoo likely conveniently deleted their email informing me of such developments, which happens from time to time). She will talk to Joe (see my previous email in post form) and see if the replacement decoders they have will fix the problem. If so, they will send them to me.
Any more issues and the locomotives are getting TCS WOW sound decoders...
That's very good news.
Keep us posted on the outcome.
4 new Paragon 2 decoders should be arriving in the mail today (one for each Paragon 2 locomotive I own).
If they don't work I will likely replace All 4 decoders with TCS Wow sound or Loksound, and return all 8 decoders to BLI.
Just to be sure I'm following...when the engine / decoder is set for 128 speed steps, it runs in reverse of the direction it should, right? So, have you tried at that point reading CV29, and reprogramming that CV to one number higher (or lower) and see what happens? So if CV 29 is 34, change it to 35? If changing one CV has somehow reversed the polarity of the DC power going from the decoder to the motor, I'd think changing CV29 by one number would fix it...or just swap around the wires going to the motor.
wjstix Just to be sure I'm following...when the engine / decoder is set for 128 speed steps, it runs in reverse of the direction it should, right? So, have you tried at that point reading CV29, and reprogramming that CV to one number higher (or lower) and see what happens? So if CV 29 is 34, change it to 35? If changing one CV has somehow reversed the polarity of the DC power going from the decoder to the motor, I'd think changing CV29 by one number would fix it...or just swap around the wires going to the motor.
Stix,
No. That was literally the first thing I tried over a year ago. It only runs in reverse. CV29 has not effect on this problem. On 28 speed steps there are no issues. The problem has something to do with CV 18 having a value of 63. No idea why. It has been confirmed on my NCE system, Rich's system, and I believe Randy's system as well. and both NCE and Digitrax systems at BLI. Of the 10,000 possible addresses, 36 have this glitch.
BMMECNYC wjstix Just to be sure I'm following...when the engine / decoder is set for 128 speed steps, it runs in reverse of the direction it should, right? So, have you tried at that point reading CV29, and reprogramming that CV to one number higher (or lower) and see what happens? So if CV 29 is 34, change it to 35? If changing one CV has somehow reversed the polarity of the DC power going from the decoder to the motor, I'd think changing CV29 by one number would fix it...or just swap around the wires going to the motor. Stix, No. That was literally the first thing I tried over a year ago. It only runs in reverse. CV29 has not effect on this problem. On 28 speed steps there are no issues. The problem has something to do with CV 18 having a value of 63. No idea why. It has been confirmed on my NCE system, Rich's system, and I believe Randy's system as well. and both NCE and Digitrax systems at BLI. Of the 10,000 possible addresses, 36 have this glitch.
I'll attempt to explain my theory a little better.
28 and 128 speed steps use the same setting in CV29. It is up to the decoder to interpret the differences in the NMRA DCC packet to tell if it is a 28 speed step packet or a 128 speed step packet.
The 128 speed step packet is completely different from a 28 speed step packet, 128SS uses the extended packet format. So this can easily explain why the loco worked fine with 28SS but not 128SS - there are different routines to decode and respond to the packets. Now, thre is a type of extended packet that actually encodes a direction, among other possible commands, in 3 bits. The pattern for reverse though is 010, forward is 011. Maybe with soem more digging the error in BLI's decoder will reveal itself, but it wasn't quite this obvious. At issue was CV18 having a value of 63, bit pattern 0011 1111. Somehow this bit pattern for the address was being masked against the wrong part of the extended format packet and makign all speed commands appear to be ones for the reverse direction. A different pattern in CV18, thus a different long address, seemed ok, as did using 28SS so avoiding the extended format packet altogether.Still an interesting puzzle as to the exact cause, but only BLI will be able to determine that as no one else has the source code for their decoders to examine and see where the mistake may be. I AM pretty confident that this is all it is, a slight coding error, perhaps the wrong variable used, or bits transposed somewhere. That is only shows up when CV18 has a specific value, it's easy to see how this could go overlooked in testing. With the way CV17/18 work for long addresses, it's only very specific addresses that end up with CV18 = 63, while thousands of other addresses have a different value for CV18. I can't imagine ANYONE testing every possible long address to validate their code.
rrinkerI can't imagine ANYONE testing every possible long address to validate their code.
It took long enought to go through and test half of the 36 suspect addresses to check for the error. I cant imagine trying to test ~10k address. One would go bonkers.
Decoders arrived in my mailbox today. Might install and test one or two tomorrow. Will let you guys know.