ESU LokPilot V4.0 Micro Slide-In - Throttle Response Latency?

[C855B]

Since TCS doesn't make a slide-in yet for the new Atlas chassis (SD35 and C630), I picked-up the new LokPilot for the two I have.

After installing and programming the decoders - I prefer no momentum, setting both to 0 - in test running it was evident there was a 1/2- to 3/4-second delay between throttle changes and execution. To make sure it wasn't the control station, I tried an older C630 with a TCS AMD4. The TCS responded immediately, as expected.

These are my first ESU decoders, so I have to ask if this is characteristic. Or, given the rather overwhelming option table for ESU, did I miss a CV (or several) that influences this? I am using JMRI DecoderPro, and nothing jumped out at me on the motor settings page that would indicate a response delay.

[woodone]

Some ESU decoders have a delay on start- about 2 seconds. I have not read the manual on LokPilot so I am unsure the Pilot has that feature.
I know the the LokSound select and the V 4.0’s do.

[C855B]

Well that's frustrating, then. Consist-incompatible with other decoders. I did notice in the JMRI "read.me" for v4.0 there was, in so many words, advice asserting "screw everybody else including our previous practice, we have our own way of doing it now." Helluva sales pitch.

[Mark W]

You can disable the start delay.  It's purpose is so that when consisting with ESU sound equipped units, the sound ramps up before the locomotives moves. 


Sometimes ya gotta cut old cars loose to get the train moving forward.

[woodone]

I have used an ESU LokPilot micro nano which has the delay feature. You have to hit F8 to enable the delay.
This is so when you are running a Sound decoder equipped loco and with a micro nano in an consist.
Hitting F8 starts the sound in the sound equipped loco and enables the LocPilot to have the delay so they match.

[C855B]

What I'm observing is not a 2-second start delay, it's latency in executing any throttle change, just under a second. However, I did a shotgun change of most of the "advanced" parameters, turning off anything I knew I wasn't using... and guess what, the latency went away.

Tomorrow I'll have a chance to diagnose it a little tighter. I have a hunch.

[woodone]

What you may be seeing is the acceleration rate set too high. I have seen Tiimes of up to 20 seconds to go from stop to what ever you have set for a top speed.

[peteski]

What you may be seeing is the acceleration rate set too high. I have seen Tiimes of up to 20 seconds to go from stop to what ever you have set for a top speed.

Assuming that acceleration=momentum then Mike stated "I prefer no momentum, setting both to 0".

[woodone]

Yes, I saw that. I did not see what he was using to program? JMRI may not touch the default?
A LokSound programmer shows the stop to top speed in the motor settings, so if he took them to zero with the LokSound I don’t know what he is ( or was seeing).

[peteski]

Yes, I saw that. I did not see what he was using to program? JMRI may not touch the default?
A LokSound programmer shows the stop to top speed in the motor settings, so if he took them to zero with the LokSound I don’t know what he is ( or was seeing).

I suspect that he just set CV3 and CV4 to zero.  I doubt he has a LokProgrammer while only taking one ESU decoder for a test spin.

[C855B]

I suspect that he just set CV3 and CV4 to zero.  I doubt he has a LokProgrammer while only taking one ESU decoder for a test spin.

Correctamundo. I use JMRI DecoderPro for this stuff.

Found the problem - multiple decoder modes are enabled by default, "Selectrix" being the biggest contributor to the latency. I turned off Märklin/Motorola, Selectrix, and RailCom, so it is now responding like a real decoder. We don't need anything other than NMRA DCC. All the settings of concern were on the JMRI "advanced" tab. That also happened to be where the start delay for sound compatibility is located, and default is 0 (none).

My hunch was correct - the latency is attributable to mode detection, a problem I encountered when doing similar stuff for a living. When you have all possible protocols enabled, there is a decision process to parse which control system is sending the command, is the command complete, and does it pass error-checking. Plus, if one of the protocols is multi-packet, things are going to be held-up until there is enough data for the decision tree.

Sound decoder users and folks running a lot of momentum are typically not going to notice this, but it is something to keep in the back of your minds when mixed consists are having control response issues.