I'm trying to get my DCC loco(s) to perform similarly to my DC switchers. I have three switching puzzles on my trainboard (think Inglenook) and I've had fun running these on DC often with the throttle fixed at about 10% and simply using forward/reverse input over uncouplers to run the whole thing. Now I get that this is not very prototypical, but as a game, it keeps it snappy and fun. I have a UWT-50 on order and would like to get similar performance from (at least) one of my DCC locos. Right now using my Zephyr, if I pull a similar maneuver as above, there is a built-in ~1/4 second of deceleration/acceleration to zero speed/switch directions. I have checked that DCC CVs 3 and 4 are set to zero. I have read about CVs 23/24 which are described in the context of consists, so I don't know if they play a part here. So essentially, I am trying to program a zero-delay throttle on a DCC loco. Are there any other items I should be looking into? Factory-programmed items that perhaps need to be zeroed out? All input and discussion is appreciated. Thanks.
It's not your command station but rather your decoder. What brand and model is the decoder? IF it's Digitrax (since you are using a Zephyr), try setting CVs 55, 56 and 57 to zero. Those are BEMF CVs and they often make your loco behave "less instantaneously".
it -might- be the decoders, but if all your DCC locos [more than just one] are slow starting and stopping, just might be your controller ... it's doubtful if several locos would use the same make and model of decoder time to do some trouble shooting ...
I adjusted 55 & 56 to 0, no change in behavior. There is no 57 on this decoder. I have one other loco switcher that exhibits the same micro-deceleration when stopping or switching directions. I also have another (Atlas I think) that stops and reverses _immediately_ just like DC behavior, so 1) it's not the controller, 2) there must be some other setting or 3) it's just decoder-specific.
dc and dcc is two different animals one is computer type control you can not get that quickness from dcc as you could dc at least i dont think so with dc you have instant power and with dcc you have lag time.
Hi Sidney, Thanks I do understand the differences, but the fact is they are both electrically controlling a DC motor. If the DCC system simply changes its voltage output immediately instead of gradually, it can behave exactly the same. As I mentioned above I have one DCC loco that performs exactly like my DC locos on start/stop/reverse, so I'm past the "can it be done" question. I think now it's "can it be done on any decoder" or do manufacturers bake in their own specs in this area.
BEMF enabled would not delay throttle response. Back Electro Motive Force is the voltage generated by the motor spinning (like a generator) when it is not being driven by the decoder. The BEMF Decoder option is one where the decoder attempts to ensure the motor runs the same speed regardless of load (within limits), like cruise control on an automobile. The decoder uses the BEMF voltage to determine how fast the motor is spinning, and therefore how fast the loco is going (ignoring wheel slip.) Decoders generate the variable voltage to drive the motor using Pulse Width Modulation (PWM), where (generally) full-voltage pulse widths are varied within a fixed pulse period, resulting in an average voltage that changes with the pulse width. During the off-time between pulses, the decoder can sense the BEMF voltage from the motor to determine motor (and proportionally, loco) speed, assuming the drive wheels are not slipping.
Just an update, I have been testing/experimenting using an Engine Driver throttle up until yesterday, when I received my UWT-50E. This has dedicated buttons when in yard mode that allow flicking from forward to reverse with two preset speeds, useful for the type of operating I'm trying to do. When used with my Atlas switcher, it works like a charm, with predictable movement allowing the reflexes to switch directions appropriately for successful coupling/uncoupling operations. When I tried it with my other two DCC locos, the remaining latency between input and engine response is still too much to be usable. Moving from forward to reverse with one of them sometimes seems to "forget" the reverse part after it decelerates to zero, and the delay for a full reversal (with CV3/4 at 0) is still close to a full second.
Were you able to see what decoder is in the loco? Still sounds like a decoder CV situation to me. What do you use to read/write with the decoders. If you aren't using DecoderPro I'd suggest trying it. Very hand to use and free, Sumner
I didn't have a dedicated PC near my layout, and last week I was poking through the CVs by hand with the Zephyr. Since then I've resurrected a DCC++ I was playing with and connected it to my primary PC with JMRI so I can see the sheets. I confirmed what I'd done before (all CVs 3&4 to 0) and the CV 55/56 changes I tried. I haven't yet confirmed the decoder model numbers...
If you haven't done it so far I would convert the DCC++ to DCC++EX. Easy to do with the DCC++EX auto-installer. It is much more forgiving programming decoders with JMRI and DecoderPro. 308 errors have been a thing of the past for me and if one does run into a decoder that is hard to program the other options ( HERE ) usually make it easy to fix. Thanks for keeping us up on your progress with this. I'm sure it will probably help someone else, Sumner
I am running DCC++ EX, just lazy typing on my part. The debugging info is interesting, I'm not sure if I have the necessary terminal as a result of what I already installed?
Curious have you run the same locos using DCC++EX and a phone throttle running EngineDriver or the Apple equivalent? Sumner
I was working on getting my EX working on a dedicated programming track I'm using. I just finished that so I can now program and see immediate results. I have a wifi phone throttle and a UWT-50, but I'm not using either of those here - just JMRI. I can see how the starting voltage would work. That could take some trial and error. Maybe I can find some videos on that topic to save me some steps.
So, you are using the JMRI GUI throttle? What kind of computer (i.e. performance, OS, etc.) is running JMRI, and what version of JMRI are you using? Does the JMRI GUI response seem fairly snappy otherwise? Have you tried different USB ports to plug your Zephyr into? Is your Zephyr a recent model with the built-in USB interface? (I'm not that familiar with Digitrax systems, so I don't know when or which model got the USB interface built-in, or what USB spec it supports (USB 1.x, 2 or 3). For reference, I use a Pi SPROG 3 on a Raspberry-Pi 4, and throttle response is pretty snappy from Engine Driver on my phone. When I'm running the JMRI GUI, it is via VNC on my Windows laptop over WiFi, so that adds a little latency to the GUI (not enough to be bothersome in general, but if I were running the GUI throttle it might). Oh, I also have my Pi set up to connect to my Google WiFi router, rather than hosting its own WiFi network. That made a small difference (for the better) in both convenience and performance.
Yes, I'm ruinning JMRI GUI, also just using the arrow keys (rather than mouse) to control it in this testing scenario. Before I answer all the specifics, consider the logic that I have one of my three DCC locos that works _perfectly_ with both the test track setup (DCC++ EX w/ JMRI throttle) and my layout (Digitrax Zephyr, LNWI, UWT-50). If any one of these components were contributing to the problem it wouldn't be loco-specific. The latency I'm describing is not from the input to the reaction of the locos. It is how the locos are reacting. On my DC locos and my working DCC loco, if I switch from forward to reverse while the loco is under power, it immediately reverses with an almost imperceptable stop (~ <.1 second). On my two problematic DCC locos, with CVs 3 and 4 (accel/decel) both set to 0, when I switch from forward to reverse, there is still a perceptible decel/stop/reverse accel pattern that takes ~.5 second in total. Right now I'm considering contacting the encoder manufacturers directly somehow. However I am at a stage in model railroading where I have made enough mistakes in the past to know that I can turn a perfectly good loco into a trashed loco just by taking a body part off wrong. I have done it all successfully in the past as well, but I don't personally know these brands build methods and am not sure it's worth the visual to try to get them apart just for that one look.