I’m programming a locomotive that when reset to defaults (short address 3), it works fine. However, when I give it a long address it always runs in the same direction, regardless of setting forward or reverse. Checked cv29 (value of 38), fiddled with a few other values with no change. I’m flummoxed.
You need to provide the manufacturer, approximate date of manufacture, and locomotive type, and the particular decoder model and maker.
To my knowledge there is nothing in the general DCC standard that would enable this behavior; the decoder alone sets the DC polarity to the motor that determines its rotation. If the code ‘set’ to determine this is “per spec” I think you have a specific decoder fault – the interesting thing then perhaps being whether it’s a hardware problem or firmware…
That is truly weird. I have nothing to offer here, but I am bookmarking this thread to see if anyone comes up with the answer.
Rich
Try disabling DC in CV29. Try 34 as a value and try again.
After doing the factory reset, does the problem occur after you just add the long address or have you made other CV changes as well. I would test the locomotive after each CV change. That would give you an idea as to which change is causing the directional problem.
Another possible problem is if the long address has ever been assigned to an MU. If it has, the loco will take its direction from the lead loco in the consist.
The “reverse direction” value in CV29 (adding 1 to the existing value) has nothing do with forward or reverse signals from the throttle. That change to CV29 just reverses the polarity output to the motor and connected lighting functions. It makes forward into reverse or vice versa.
CV29 is a red herring here.
It probably isn’t relevant but my MRC Tech 6 won’t drive some dual mode decoders in reverse direction when delivering power in its DC output mode. The direction switch on the powerpack has no effect. I’ve always thought that’s a curious phenomenon.
By analogy then maybe your dual mode decoder is seeing a DC signal as if the throttle is sending a DC power signal to address 00?
Disabling DC mode in your decoder might be worth experimenting with.
It would help to know the brand and type of decoder as well as the type of DCC command station.
It is a curious problem. The usual suspects would seem to be CV29 and even CV19.
How many throttles are you using? Could be an addressing problem.
Tell us more.
Rich
Adding 1 to CV29 if it already has an odd number value is going to have a ripple effect. If the 0 bit already has a value of 1, it will flip to 0 but also add 1 to the number 1 bit which could affect the number 2 bit and so on. To change the direction, you add 1 if it has an even number and subtract 1 if it has an odd number.
Thanks. Another mysterious aspect of CV changing clarified.
I use the little charts and deduced erroneously.
What little charts?
Having been a mainframe programmer for most of my working life, I had to learn the nuances of both binary and hexadecimal arithmetic. That became less important over the years, but it was still a good thing to know.
One convention of mainframe programming that seems to have carried over to decoder programming is the method of addressing bits and bytes. It is done as a displacement which means the first bit in a byte (the right most one as you observe the binary number) has a displacement of zero. The second bit has a displacement of 1, the third bit has a displacement of 2, and so one for all 8 bits of the byte.
It seems that each bit in CV29 affects a different function, so adding a number to one bit can change the value of the next bit to the left which can change the value of the next bit to the left and so on. Bit 0 is the one that controls direction and that is the only one you want changed when reversing direction. That’s why you add 1 to an even number and subtract 1 from an odd number.
The OP may have a Broadway Limited Paragon 3 decoder. I’ve had a similar issue with about a third of the P3s installed in my recent BLI locos. In one case after replacing the decoder twice I gave up and installed an ESU decoder. BLI service tried their best but the silly thing still would not cooperate.
After a reset (a physical hard reset using the on-board, inaccessable rubber button) the engine would perform fine but any attempt at changing the address would scramble its poor little brain. The result would be limited, sporadic movement in forward and in reverse the engine would run at top speed, also moving forward forward with no control.
We’ll have to wait to hear back from the RF&P Dispatcher in Richmond.
Over — Out…
Good Luck, Ed
The more I read about issues with BLI locomotives, the less impressed I am with their quality control. These issues are inexcusable in high end locos. It’s one thing to produce an occasional lemon, but there shouldn’t be problems that are so common.
The problems seem to be confined to their proprietary decoders that began with Paragon 2, but really became an issue starting with Paragon 3. I have several Paragon decoder equipped locomotives, steam and diesel, that are just fine.
Rich
Who knows why the decision was made to treat CV29 as a multi-function CV. But, it really isn’t all that complicated in the greater scheme of things.
Early in my career, I was a programmer and then a systems analyst. Back in the day, you needed to understand bits, bytes, binary and hexadecimal arithmetic.
Let’s delve into this a little more.
There are 8 bits in CV29 (zero through seven). The decimal value of each bit is an even number except for the decimal value of bit 0 which is an odd number of 1.
For example, the decimal value of bit 1 is 2, and the decimal value of each succeeding bit is double the decimal v
I had a practical application of CV29 when I added a pair of P1K C-liners to the roster which I wanted to run as an AA set. When I want to permanently pair locos together, I just assign both of them the address of the lead unit rather than create unique addresses for both and MU them. This was the first time I paired A units together so one would have to run backwards if I didn’t want to run them elephant style. That meant reversiing bit 0 in CV29. I put a LokSound in the lead unit and a LokPilot in the trail unit. When I put them on the programming track and read the value for CV29, it was 50 for both units so I had to add 1 to the trail unit for a value of 51. A value of 50 in decimal converts to a binary number of 110010. Working from right to left, we have a 1s in the columns for 2, 16, and 32 which added together yield 50. Adding 1 gives a decimal value of 51 which converts to binary 110011. Had the default value been 51, I would have had to subtract 1 in order to reverse the direction without changing the value for other functions. If I added 1 to binary 110011, it would have converted to binary 110100 so not only would I have changed the direction, I would have changed the functions in bits 1 and 2 which are the 2nd and 3rd bits from the right.
I know I don’t need to explain this to Rich but it’s a primer for those who either were never taught binary arithmetic or had it so long ago they had forgotten.
I just went back through the thread and this sounds like the most likely answer. Analog mode is controlled by the third bit from the right which is the fours digit in a binary number. You want that digit set to 0. A decimal number of 38 converts to binary 100110. You want the third digit from the right set to 0 so entering a decimal value of 34 in CV29 sets the byte to a binary value of 100010.
Locos running in analog mode have direction determined by track polarity as opposed to engine direction. I’ve noticed that when I get a DC engine. Before installing a decoder, I first test it in analog mode by setting the address to 0. It moves in the direction dictated by track polarity. It doesn’t matter which way the engine is facing.
Speed steps are set incorrectly. You have to set the speed steps 14/28/127 at the command station so it knows how to send the bits. Also make sure CV29 is set correctly and you can read from the decoder on the programming track (to make sure it’s a viable decoder)
The problem is that people are confusing bitwise adds with decimal adds, as if the purpose was to increment or decrement an actual representation of a number.
Most of these multiple CVs are in the form of positional flags, like the sliders in DIP switches. The idea of ‘adding 1’ to change a particular value ‘from zero to one’ as if you were sliding a DIP switch up is attractive as a simple analogy, but as noted if you try to ‘add’ that 1 positionally in binary you get carries, the risk of two’s-complement negative numbers, etc. that very few people trying to program CVs want to know about.
What they need to realize is that when they add or subtract numbers that are ‘powers of two’ to the decimal representation of a CV, they are flipping just one specific corresponding bit in the binary representation… just that one DIP switch controlling a particular function. That’s the magic in going between ‘34’ and ‘38’, for instance – you aren’t so much “adding four to a number” as you are changing ONE positional digit in the binary byte without changing, or shifting, or affecting or whatever any other digit in it. And now you understand why just changing that one digit is the purpose of the exercise.
The way to deal with CV29 is to read its value on the programming track. No guess work that way.
Rich