George,
can you verify two things for me?
1) What's your command station setting?
2) What does the Loconet Slot Monitor say about the speed step mode?
(You don't happen to have a DCC protocol analyzer to verify what's actually happening on the tracks, do you?)
I believe what you see is intentional for Digitrax command stations in 28 speed step mode. For Uhlenbrock Intellibox it shouldn't be. And I have no idea about the DR-5000.
You could try switching the command station configuration to one of the Intelliboxes and see if that helps. Or your python code could use the 's' command to set the speed step mode to 128:
The reason we do this: The Loconet protocol always uses speed settings 0-126. But for 28 (and 14) speed step mode, the translation from loconet speed to track speed is... weird. Apparently (I never verified), a loconet speed of 0-15 will cause a Digitrax command station to send 0 to the track, and 16 will cause a Digitrax command station to send speed 1 to the track (in 28 speed step mode).
So to have a reasonably linear translation from WiThrottle speed (or JMRI throttle speed) to track speed, we distort the loconet speed. For Digitrax command stations in 14- and 28 speed step mode.
Hope this helps,
Heiko
toggle quoted message
Show quoted text
On 10/24/24 17:06, George Hofmann via groups.io wrote:
JMRI v5.6
ED v2.37.187
CS DR5000
Linux Mint 21
Some time ago I wrote a Python program that acted as a throttle, communicating with JMRI. It worked fine but recently I noticed an anomaly when commanding very low speed steps. Then I verified that the same behavior is observed when using Engine Driver. So I'm thinking that the issue is on the server side.
The problem is that when incrementing speed steps by 1 (out of 128) the actual speed step sent to the command station jumps from zero to 16 as soon as the request changes from 0 to 1. It remains at 16 until speed step 6 is requested at which point it changes to 17. Subsequent steps upward result in expected behavior, i.e. monotonically increasing by one although off by 11 with respect to what is requested. In the reverse direction the commanded value sticks at 16 as I step down from 6 to 5, changing to zero only when zero is requested. If I were in 28 step mode then the first step would be 16. So it looks like the system acts like it's in 28 step mode for the first step and then 128 thereafter.
The behavior can be observed by monitoring Loconet as shown below. The request was being changed by one each time in this example.
The requests for values 2 through 5 don't even show up.
07:29:40.806: [A0 02 10 4D] ?Set speed of loco in slot 2 to 16. /Request SS 1 of 128 (from 0)/
07:29:46.336: [A0 02 11 4C] ?Set speed of loco in slot 2 to 17. /Request SS 6/
07:29:47.343: [A0 02 12 4F] ?Set speed of loco in slot 2 to 18./Request SS 7, etc./
07:29:48.370: [A0 02 13 4E] ?Set speed of loco in slot 2 to 19.
07:29:49.212: [A0 02 14 49] ?Set speed of loco in slot 2 to 20.
07:29:51.265: [A0 02 15 48] ?Set speed of loco in slot 2 to 21.
07:29:53.471: [A0 02 14 49] ?Set speed of loco in slot 2 to 20.
07:29:54.959: [A0 02 13 4E] ?Set speed of loco in slot 2 to 19.
07:29:55.970: [A0 02 12 4F] ?Set speed of loco in slot 2 to 18.
07:29:56.954: [A0 02 11 4C] ?Set speed of loco in slot 2 to 17. /Request SS 6/
07:29:57.827: [A0 02 10 4D] ?Set speed of loco in slot 2 to 16. /Request SS 5 (lower values ignored until 0)/
07:30:02.515: [A0 02 00 5D] ?Set speed of loco in slot 2 to 0. /Request SS 0/
A JMRI throttle in 128 step mode works properly. Of course in that throttle I can specify 128 ss mode directly and the Loconet log verifies that state. When using ED I don't appear to have the option of specifying 128 ss mode. I guess the server has to infer it. The log shows 28 ss mode, even though ED is sending 128 steps and the server seems to figure it out when I get to step 6. But still the log doesn't show 128 ss mode at that point.
Clues would be appreciated.
Thanks
George
--
eMails verschl¨¹sseln mit PGP - privacy is your right!
Mein PGP-Key zur Verifizierung:
