The TL;DR of my question... Why is the Digitrax loco going so slow when I do an "advanced consist" ???
Beware of the Digitrax CV57 advanced consist bug...
Digitrax decoders have the advanced consist BEMF in CV57 set to 0 which makes the motor non-responsive to throttle when in advanced consist.
Set CV57 from its default value of 5 (0000 0101) to a value of 85 (0101 0101). The low nibble (yyyy in the xxxxyyyy byte) controls non consist BEMF. The high nibble (xxxx in the xxxxyyyy byte) controls BEMF in advanced consist and needs to be set to the same value used in the low nibble.
This is not a problem on Digitrax systems because they use their simple consisting which they call Universal consist. It fails in CV19 NMRA standard advanced consist which is used for more prototypical operation. This is why I avoid Digitrax decoders like the plague and go for more reliable SoundTraxx motor decoders (more reliable than Digitrax, TCS, and NCE motor decoders)
Consist BEMF is turned off by default (0000yyyy) in Digitrax decoders which is why they appear to stall or be unresponsive when put into advanced consist. This is fixed by setting the high nibble of CV57 to match the low nibble. Basically set CV57 to a value of 85 (0101 0101) instead of the default value of 5 (bit pattern 0000 0101).
Simple Universal old style consist doesn’t use CV57 so it’s not a problem with Digitrax decoders running on a Digitrax system, but becomes a problem when running Digitrax decoders in advanced consist on NCE and other systems. If you don’t want to set CV57 correctly on the Digitrax decoders, then run simple old style consist on non Digitrax system. Better solution is go with non Digitrax decoders like SoundTraxx or ESU.
——-
So you set CV57 values to:
102 == is a BEMF setting of 0110 0110 in binary. Basically BEMF set the same for consist and non consist operation. OR
85 == is a BEMF setting of 0101 0101 in binary.
As along as the consist BEMF (high nibble, left 4 bits of the byte) matches the non consist BEMF (low nibble, last 4 bits of the byte), the loco will run the same in consist as it does alone.
——-
CV57 Value ------- xxxx yyyy
Default of 5 ------- 0000 0101 (Advanced Consist doesn't work)
Change 102 ------- 0110 0110 (both the xxxx and yyyy are same, things work)
Change 85 ------- 0101 0101 (both the xxxx and yyyy are same, things work)
xxxx advanced consist BEMF
yyyy baseline non consist BEMF
https://www.facebook.com/groups/122689518379245/posts/1472592313388952/
I spend all day speed matching these two Atlas SD-35s. Locomotive 6025 (lead locomotive in the one video, outside loop locomotive in the other) has an ESU LocSound5 decoder . Locomotive 6018 (trailing locomotive in the one video, inside loop locomotive in the other) has a Digitrax DN163A0 decoder .
When you watch the first video, you can see that I have gotten the two locomotives nicely speed matched. In that first video, You can see that I used the Engine Driver feature to do the consisting. (So it's not really consisted as far as the command station or the locomotives are concerned... Engine Driver does all the work and just sends the same speed command to two different locomotives, And in this case tells one to go forward and one to go backwards)
When you watch the second video, I have used "advanced consisting". (I set CV19 to 10 for the front locomotive, and 138 for the rear locomotive). You can see that when I set the advance consisting, the DigiTrax locomotive speed is drastically reduced (by like 3/4s ) ....
So can anyone give me some guesses/some things to look at as to why the DigiTrax locomotive is so much slower when I turn on advanced consist. (FWIW, the DigiTrax locomotive has CV23&24 set to 0 ... And CV57 set to 5, which from the documentation tells me that "no speed compensation is used when the decoder is in Advanced Consist" ) PS: for the second video I moved the one locomotive to the inside track because I didn't want the other locomotive to make the full loop and slam it in the rear before I got a chance to finish pointing out the issue. I could have just as easily filmed everything on the inside loop or on the outside loop doesn't really matter, and result is still the same
Video of the issue available here: (if you don't do facebook) https://photos.app.goo.gl/fWyxmRQ2JZanktcf8