What if I try reseting the decoder and then programming the long address using the CV values instead of the address programming mode? Ive heard of decoders only taking the directly cv defined address before and I wonder if this might be a similar issue.
BMMECNYC What if I try reseting the decoder and then programming the long address using the CV values instead of the address programming mode? Ive heard of decoders only taking the directly cv defined address before and I wonder if this might be a similar issue.
Rich
Alton Junction
Performed system reset. BLI E7A paragon 2 programmed to 6207 still only runs in reverse on 128 speed step mode. I will be contacting BLI monday to determine if there is something special about address 6207.
richhotrainEdit Note: I went through the same procedure described above with one of my Paragon E7A locomotives. Everything performed correctly when assigning the locomotive a long address of 6207, regardless of whether the speed setting was 28 or 128. So, it sure appears to be a quirk with the Paragon 2 locomotive. Hopefully, others with Paragon 2 locomotives will try this procedure to see if the problem is universal when assigning the long address of 6207.
I will also try my other two Paragon 2 locomotives (SW 7 and 4-6-2)
Scratch the manual programming of the address using CVs, that didnt work either. I cannot get to the digitrax cv calculator to confirm the proper CV values.
Try this calculator
http://www.2mm.org.uk/articles/cv29%20calculator.htm
Try long address 5951. That's still 63 in CV18, but a different value for CV17, so see if it's the bit patter of CV18 causing a problem. Use the windows calculator in programmer mode to get different binary values for CV17 and 18 to see if it has a problem only when certain bits are set, which would be a programming bug and there's nothing you can do except use a slightly different address.
I still say it's worthwhile to reset the system.
--Randy
I just tried the Digitrax toolbox and it is giving the correct values for CV17 and 18 - what are you getting?
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
rrinker I still say it's worthwhile to reset the system.
Randy,
I did reset the system, with no change in the behavior with this locomotive. The address works with other decoder brands. Thank you for the suggestion on playing with the bit values to attempt to isolate which CV is causing the issue. I believe this is a good next logical step. Also thanks for the link to the calculator. Also I can access digitrax now, before I couldnt even navigate to the website, however those are the CV values that Rich and I got for Long address 6207. I will continue tomorrow after work.
Andrew
I have one other BLI Paragon 2. Same problem when programmed with long address 6207.
I changed the long address to 5951, as Randy suggested. Same problem.
So, the fault may be in the bit patterns on CV17 and/or CV18.
63 is 011111111 binary so it's either a problem with the lower 7 bits all being 1, or the upper bit being 0.
Try 5952 - that's 64 in CV18, or 10000000
And try 5695, that's just another one with CV18 = 63.
I think we found a bug in the Paragon 2. This sounds familiar, did we already discuss something similar before, a few months or maybe a year ago? I remember some involving bit patterns.
rrinker 63 is 011111111 binary so it's either a problem with the lower 7 bits all being 1, or the upper bit being 0. Try 5952 - that's 64 in CV18, or 10000000 And try 5695, that's just another one with CV18 = 63. I think we found a bug in the Paragon 2. This sounds familiar, did we already discuss something similar before, a few months or maybe a year ago? I remember some involving bit patterns.
Now - who has a Paragon 2 loco and another DCC system to try this? I don't have any - they have yet to release a Paragon 2 loco that I would want. Curious now if this is a Paragaon 2 general issue, or a Paragon 2 compatibility problem with NCE.
Oh yes, how about an address with CV18 = 127,or 255 so 7 or 8 bits are on (compared to 63 with 6 bits on)? 6016 and 6143 would be examples.
rrinker Now - who has a Paragon 2 loco and another DCC system to try this? I don't have any - they have yet to release a Paragon 2 loco that I would want. Curious now if this is a Paragaon 2 general issue, or a Paragon 2 compatibility problem with NCE. Oh yes, how about an address with CV18 = 127,or 255 so 7 or 8 bits are on (compared to 63 with 6 bits on)? 6016 and 6143 would be examples. --Randy
Yes, yes it would. i was getting ahead of myself on bits there. Although there are at least 2 other possibilities to try as well. Or just one, depending on the outcome. 6080 to set CV18 at 192, the inverse of 63.
I haven't heard back from the NCE-DCC forum. I am hopeful that someone there can shed some light on this issue.
I was unable to contact BLI today, I had to work late. I will attempt again tomorrow.
Contacted BLI, they are looking into this issue and said they will contact me with an answer.
BMMECNYC Contacted BLI, they are looking into this issue and said they will contact me with an answer.
richhotrain BMMECNYC Contacted BLI, they are looking into this issue and said they will contact me with an answer. Interesting that they did not indicate any previous awareness of the issue. Rich
Interesting that they did not indicate any previous awareness of the issue.
Not really suprised, you wouldn't test functionality on all 10,000 addresses, that would be kind of expensive. And only 38 of the addresses would cause a problem, so its a 1 in 263 chance that you would test a decoder address with an issue.
BLI also said they would test this on their NCE system and other systems to see if the problem replicates across other DCC systems.
BMMECNYC richhotrain BMMECNYC Contacted BLI, they are looking into this issue and said they will contact me with an answer. Interesting that they did not indicate any previous awareness of the issue. Rich Not really suprised, you wouldn't test functionality on all 10,000 addresses, that would be kind of expensive. And only 38 of the addresses would cause a problem, so its a 1 in 263 chance that you would test a decoder address with an issue. BLI also said they would test this on their NCE system and other systems to see if the problem replicates across other DCC systems.
I gather that you reccommend trying the following addresses as well as further testing: 6015, 6080, and 6143?
Yes, those addresses test different bit patterns in CV18. It looks like any time CV18 is 63, it's a problem. That's 0011 1111 in binary. But the problem could be the top 2 bits being 0, or the bottom 6 bits being 1. So some address where CV18 in binary is 1100 0000 would be a good test, that's 192. Also something where CV18 is 255, or 1111 1111 - does the problem only appear when the lower 6 bits are 1, or if at least 6 bits are 1's. Likewise others I didn't mention, like maybe 0111 1110 which is 126, or 1111 1100 which is 252. Not that this will solve anything, but it is an intriguing weird bug and it would be interesting to know under just what contitions it appears. And hopefully BLI will shed some light on what happens with other DCC systems, to see if it is an interaction between NCE and certain addresses or if it is strictly some strange programming in the decoder. A little comparision between the troublesome bit patterns dn the NRMA DCC packet definitions may also yield some insight into what BLI may have done wrong. What's odd about this is that it happens in the middle of the value range for the CV - I'd more likely expect problems when the CV is at its max or min value, as a simple math mistake adding 1 or subtracting 1 would cause the value to overflow or roll over, resulting in quite unexpected operation. This being at 63 is odd - add 1 and get 64, and it's fine, subtract 1 and get 62, those values work fine.
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.
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.
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.
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.
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.
Don - Specializing in layout DC->DCC conversions
Modeling C&O transition era and steel industries There's Nothing Like Big Steam!
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
Good sleuthing guys.
At least it's reproducible. The most impossible to solve problems are ones that do not happen consistently.
Too bad that BLI did not indicate whether the problem occurs with throttles other than NCE ProCab.
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.