BMMECNYC One year an no email from BLI.
One year an no email from BLI.
Rich
Alton Junction
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.
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.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
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.
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!
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.
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.
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?
Isn't CV29 where the 28/128 speed step data is stored? Have we tried setting CV 29 to 35 for reverse direction operation?
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
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.
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.
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
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.
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.
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 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.
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.
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.
BMMECNYC rrinker Hmm, something else to try, when it only runs backwards in 128 step mode, is that with the headlight on or off?
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.
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.
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.
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.
DigitalGriffin richhotrain If it is a decoder programming flaw, and even if it occurs only when the value of CV18 is 63, I have a hard time imagining how that could occur.
richhotrain If it is a decoder programming flaw, and even if it occurs only when the value of CV18 is 63, I have a hard time imagining how that could occur.
If it is a decoder programming flaw, and even if it occurs only when the value of CV18 is 63, I have a hard time imagining how that could occur.
Too bad that BLI did not indicate whether the problem occurs with throttles other than NCE ProCab.
Good sleuthing guys.
Here is BLI's response. I did not expect technical solution immediately, but they appear to be working on it.
Hi Andrew,This is Joe in the service dept.I believe you spoke to Curtis yesterday on the phone regarding an E-Unit that runs backwards if you enter long address 6207 or 5695 (or when CV18=63) while running in 128 speedsteps.We were able to duplicate that issue and escalate it to our software engineer.When new code gets written and a new revision for that decoder is available we will send you an Email.In the meantime, the only workaround is to not use those specific address numbers (or run in 28 speedsteps - but I realize this is probably not a viable option at a club).Thank you.-- Sincerely,BLI Service DepartmentBroadway Limited Imports, LLC9 E Tower Cir Ormond Beach, FL 32174Phone: (386) 673-8615 Fax: (386) 673-8080
As we are dealing with assembly (most likely) the programmer of the PIC or CPU could have failed to properly clear/set a register that was reused by the speed calculations.
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. Go ahead, try it, set CV29 up for 14 speed steps instead of 128. If you DON'T push the 28/128 button, the loco will behave oddly. But switch to 128 - it will work fine, even with CV29 saying use 14SS.
So there are going to likely be two different "packet decode" sections in the decoder's firmware. One for the 14/28 mode, and one for 128 mode - so it's entirely possible for a program bug to be in the 128 step code and not in the 28 step code, so it all works perfectly fine in 28 step mode. There isn't a seperate subroutine for every value of CV18, there is just one, that reads the DCC packet on the rails, and then compares the address portion of that packet to the value in CV18 (and 17) to see if the packet is addressed to itself or some other decoder.
Hmm, something else to try, when it only runs backwards in 128 step mode, is that with the headlight on or off? If on, what about if the headlight is turned off, or vice-versa? F0 state is only part of a 14 speed step packet, but it would be curious to see if somehow when in 128 mode the decoder is somehow running part of the 14 step code.
In the early part of my career, I was a software programmer and, later in my career, I wrote several sophisticated programs to be used in my financial planning practice. So, I have some experience with programming and how a program is constructed.
It seems to me that a subroutine would be dedicated to the 28/128 button. When the 28/128 button is toggled to 128, the subroutine would be referenced, controlling the movement of the loco forward and backward in response to the Direction button.
I cannot imagine that with each changing value in CV18 a separate subroutine would be referenced for the 28/128 button. That would be highly inefficient coding.
So, how did CV18=63 lead to the flaw when the 28/128 button is pressed?
I wonder if something else is going on here.