开云体育

Is there a straightforward way to send a specific speed step (i.e. 0-28 or 0-126) instead of a throttle value 0.0 to 1.0 to a throttle? I can't seem to find a place in the code where it will let me do that... My apology in advance if this is a stupid question.

I'm using?jmri.jmrit.automat.AbstractAutomaton
...
self.throttle.setSpeedSetting(1.0)

Thanks,

-Erich

Erich,

I once tried this approach:
/g/jmriusers/topic/19531335#131532
And this worked for me.

Klaus


Am 20.07.2018 um 23:43 schrieb Erich Whitney:

Thanks Klaus!

I was thinking along these lines as my workaround. I'm messing about with speed tables and I want to make sure I can select each of the 28 entries in that table. I will try the scaling approach, but I need a way to verify the actual value being sent to the decoder. There's also the issue of how the decoder does the mapping but that will have to be an experiment...

-Erich

Here's an illustration of what I'm trying to do...

Below is a table I made of JMRI Throttle Speed settings that are mapped to the 126 speed steps. What I want to know is what JMRI Throttle speed value do I pick so that I'm exactly selecting one of the 28 speed table entries in the decoder and not one of the ones that the decoder is interpolating? You can see from the example, there's four choices of the 128 step table that maps to '1' of the 28 speed steps. Which one does the decoder use?

JMRI Throttle Speed	28 Speed Step	128 Speed Step
0.0000	0.0000	0
0.0079	1.0000	1
0.0159	1.0000	2
0.0238	1.0000	3
0.0317	1.0000	4
0.0397	2.0000	5
0.0476	2.0000	6
0.0556	2.0000	7
0.0635	2.0000	8
0.0714	2.0000	9

Hi Erich,

I'm not a JMRI designer and I haven't picked through the Java code to see how it translates the floating value 0 to 1 into DCC speed steps.

Could you not just pick a floating value in the centre of the 28 speed step mapping in your example?. Would that not give a good chance of always mapping to the same 28 speed step?.

You don't say what DCC system you have but if JMRI supports monitoring of the DCC commands for your command station you can see how the floating point values translate into speed steps. Or have you already done this in order to produce your example?.

If you have a compact roundy test track with an optical position sensor and fast feedback bus maybe you could write a script to accurately time a reliable loco to check how the JMRI speed value maps to loco speeds. However I've found track cleanliness/loco mechanism variations can be quite pronounced.

Regards

Nick

Am 22.07.2018 um 11:31 schrieb nicholas murphy via Groups.Io:

I'm not a JMRI designer and I haven't picked through the Java code to see how it translates the floating value 0 to 1 into DCC speed steps.

Here might be the appropriate Java code:




Klaus

Dear Klaus,

Many thanks. I've already had a quick look through the code but I will have a deeper look.

Thanks to you I've now can set the speed step type of the DCC to 28 while using AbstractAutomation.

Snippet from Jython code (the Class init part):

# get loco address. For long address change "False" to "True"
??self.throttle = self.getThrottle(5001, True)? #? LONG address 5001
# set speed mode to 28 steps ?
??self.throttle.setSpeedStepMode(28)


Many thanks

Nick

Klaus, thank you! This helps a lot!!!

This is the nugget that was eluding me:

int value = (int) Math.ceil((steps - 1) * speed);

I think for the purpose I'm trying to achieve, I can set the throttle to 28 steps, use this to get the speed values that map to those and then when I'm done playing with the speed table, resume 128 speed step mode for smoother operation.

-Erich

Erich, Nick,

Thank you both for your replies.
I am glad that I could help.

Klaus


Am 22.07.2018 um 14:41 schrieb Erich Whitney:

I have finally confirmed the JMRI throttle behavior by using a Digital Logic Analyzer and DCC parser (Saleae Logic Pro 8 running a custom DCC Low Lever Analyzer with a python High Level Analyzer used to decode the packets).

Here's the data I found:

NMRA DCC PACKET SPEED STEPS
Numerator	Speed	28 Speed Step Mode (S-9.2)			128 Speed Step Mode (S-9.2.1)
		01DCSSSS	Dec	28 SpdStep	Data Byte	Dec	128 SpdStep
0.0	0.000	60	0	STOP	80	0	STOP
1.0	0.036	62	4	1	86	6	5
2.0	0.071	72	5	2	8a	10	9
3.0	0.107	63	6	3	8f	15	14
4.0	0.143	73	7	4	93	19	18
5.0	0.179	64	8	5	98	24	23
6.0	0.214	74	9	6	9c	28	27
7.0	0.250	65	10	7	a1	33	32
8.0	0.286	75	11	8	a5	37	36
9.0	0.321	66	12	9	aa	42	41
10.0	0.357	76	13	10	ae	46	45
11.0	0.393	67	14	11	b3	51	50
12.0	0.429	77	15	12	b7	55	54
13.0	0.464	68	16	13	bc	60	59
14.0	0.500	78	17	14	c0	64	63
15.0	0.536	69	18	15	c5	69	68
16.0	0.571	79	19	16	c9	73	72
17.0	0.607	6a	20	17	ce	78	77
18.0	0.643	7a	21	18	d2	82	81
19.0	0.679	6b	22	19	d7	87	86
20.0	0.714	7b	23	20	db	91	90
21.0	0.750	6c	24	21	e0	96	95
22.0	0.786	7c	25	22	e4	100	99
23.0	0.821	6d	26	23	e9	105	104
24.0	0.857	7d	27	24	ed	109	108
25.0	0.893	6e	28	25	f2	114	113
26.0	0.929	7e	29	26	f6	118	117
27.0	0.964	6f	30	27	fb	123	122
28.0	1.000	7f	31	28	ff	127	126
-1.0	-1.000	61	2	ESTOP	81	1	ESTOP

NOTE that for 28 speed step mode, there's an offset of 3 between the speed step and the value in the packet. And for 128 speed step mode, there's an offset of 1.

On a related note, I also found and fixed the problem with using throttle.setSpeedStepMode() The argument to this has change.

Instead of using 28, you need to use jmri.SpeedStepMode.NMRA_DCC_28
Instead of using 128, you need to use jmri.SpeedStepMode.NMRA_DCC_128

I hope this saves someone else a bunch of time trying to figure out...
--
Erich Whitney
Black Cat Model Railroad
Derry, NH