CV4 Deceleration

[Mihai]

I've been doing some tests lately with a Brawa V100 equipped with a ESU LokSound v3.5. What I was after was the time needed to get from the maximum speed step to a standstill - so the loco runs at speed step 28 then a speed step 0 is set on the throttle and then the time needed for the loco to come to a halt is measured. To my understanding, it's CV4 that controls this behavior, since it will dictate essentially how long it takes to cycle through 2 consecutive speed steps. Using the formula given by NMRA, the time should be CV4 * 0.896. Cross-checking with an older ESU manual (v4.0 doesn't contain the formula) looks to be almost identical (though there's a 0.869 instead of NMRA's 0.896).

 

Hence for the default CV4=11, the computed time should be 9,856. However the measured time is always revolving around 10.91s. Did anyone else come across this ?

[Nigelcliffe]

Don't expect such things to be accurate by the NMRA documentation, regardless of whose badge is on the decoder. 

 

If you want highly accurate stopping of locomotives, then you need the "constant braking distance" feature in decoders implemented by Zimo and ESU (v4 of LokPilot and LokSound).   Lenz also has this feature, but messed up the implementation badly, so I'd say avoid those.    

Or, you need to accurately profile the speeds of each of your locos, turn off the accel/decel in the decoder, and send instructions to the track for each deceleration step, which is what the commercial software TrainController (Friewald) does.

Or, you add spot detectors to the track, which when passed trigger an instruction to the loco to go to a particular speed, and thus slow over a number of detectors to a stop.

Or, if it's hidden track, a spot detector at the end, which when passed, triggers an "E-Stop" to cause the loco to stop dead (the decoder will ignore CV4 and just stop). 

 

- Nigel

[Mihai]

Don't expect such things to be accurate by the NMRA documentation, regardless of whose badge is on the decoder. 

 

If you want highly accurate stopping of locomotives, then you need the "constant braking distance" feature in decoders implemented by Zimo and ESU (v4 of LokPilot and LokSound).   Lenz also has this feature, but messed up the implementation badly, so I'd say avoid those.    

Or, you need to accurately profile the speeds of each of your locos, turn off the accel/decel in the decoder, and send instructions to the track for each deceleration step, which is what the commercial software TrainController (Friewald) does.

Or, you add spot detectors to the track, which when passed trigger an instruction to the loco to go to a particular speed, and thus slow over a number of detectors to a stop.

Or, if it's hidden track, a spot detector at the end, which when passed, triggers an "E-Stop" to cause the loco to stop dead (the decoder will ignore CV4 and just stop). 

 

- Nigel

 

Thank you, Nigel. I'm trying to stay away from the "constant braking distance" feature for now, since I fear it's going to look unrealistic -particularly at high speeds - given the fact that the optical detectors I have setup on my layout (2 / block) aren't located at the same distance from the block's end. But I'll agree sending the external speed step continuously during the braking period is a clever idea ! Yet what I'm thinking is that if the similarly simple equation for CV3/4 doesn't really apply in real-life for big manufacturers, then getting the speed curve function correct becomes next to impossible (if using CV2/5/6). I remember getting a reply back a few years ago from Lenz about their BR66 model containing a small file that given values for CV2/5/6 as inputs, it would compute the speed curve - and it wasn't at all intuitive (eg CV2=1, CV5=20, CV6=10 will not result in an almost straight line, but quite far from it).

 

I'm trying to get feedback from ESU, unfortunately registering on their technical forum this week is currently not available since folks are on holiday. Will update this thread when I get something.