functions turned on after selecting a loco with some lockable="false" functions

[jmri]

functions turned on after selecting a loco with some lockable="false" functions

[mstevetodd]

@costing ,
Is this with a DCC++ command station? Does it also occur with a JMRI throttle window? Please describe your hardware/software setup, including versions.
EngineDriver doesn't send any function states until a button is pressed, so if an acquire is sending function states, that must be happening elsewhere in the device chain.

[costing]

@mstevetodd ,

I've made a video to demonstrate:
https://photos.app.goo.gl/z1xD14FBtrzQFuYs1.

The connection is like this:

(1) DecoderPro 4.9.1 on Linux Ubuntu 17.04 connected via DCC++ TCP Client / Server to
(2) JmriFaceless 4.9.1 on RPI, connected on USB to
(3) DCC++ Base Station on Arduino + Motor shield

EngineDriver can connect either to (1) or (2). For debugging I've connected it to (1) and did a tcpdump to see what is sent to (2). When selecting the loco the following sequence of commands is sent to (2):

<f 38 138>
<f 38 138>
<f 38 138>
<f 38 138>
<f 38 138>
<f 38 176>
<f 38 176>
<f 38 176>
<f 38 176>
<f 38 181>
<f 38 181>
<f 38 181>
<f 38 181>
<f 38 222 253>
<f 38 222 253>
<f 38 222 253>
<f 38 222 253>
<f 38 222 253>
<f 38 222 253>
<f 38 222 253>
<f 38 222 253>
<f 38 223 7>
<f 38 223 7>
<f 38 223 7>
<f 38 223 7>
<f 38 223 7>
<f 38 223 7>
<f 38 223 7>
<f 38 223 7>

This only happens when selecting it from EngineDriver, opening the throttle in either (1) or (2) doesn't send any packet.

If I set all functions to lockable the following sequence happens on selecting the loco:

<f 38 128>
<f 38 128>
<f 38 128>
<f 38 128>
<f 38 128>
<f 38 176>
<f 38 176>
<f 38 176>
<f 38 176>
<f 38 176>
<f 38 176>
<f 38 176>
<f 38 176>
<f 38 222 0>
<f 38 222 0>
<f 38 222 0>
<f 38 222 0>
<f 38 222 0>
<f 38 222 0>
<f 38 222 0>
<f 38 222 0>
<f 38 223 0>
<f 38 223 0>
<f 38 223 0>
<f 38 223 0>
<f 38 223 0>
<f 38 223 0>
<f 38 223 0>
<f 38 223 0>

So it's not that it doesn't send anything in this case but the net effect is that the loco is quiet.

I've played further with this, if all functions are set to lockable=true and I turn just some lights on in the DecoderPro throttle, when selecting the loco from EngineDriver some sound functions are similarly turned on at random.

Yet another scenario: 2 EngineDrivers (A and B) connect to (2). (A) turns on some lights. (B) selects the same loco. At this moment lights are turned off, some sounds are turned on, but just the previously selected light functions are green in both A and B. Turning them off and back on resets the system to the correct state (just the expected functions enabled in both apps and physically).

This is very puzzling to me as well :) Please let me know what else could help with the debugging.

Cheers,

.costin

[mstevetodd]

@costing
Do you have some way to decode those byte patterns? Nothing like that is coming from ED. The WiThrottle protocol is human-readable characters, like "MT+L5511".
I'm of the opinion the JMRI -> DCC++ connection code is sending something to activate the functions, but this will be very difficult for me to debug as I have no DCC++ hardware.
Someone had both DCC++ and Digitrax hardware available via JMRI, and the same decoders worked fine with the Digitrax adapter, but had this locking lockable issue with the DCC++ path.
First debug step I'd suggest is eliminate the extra hop, and connect ED directly to the RPi.
Then figure out what sort of JMRI debugging is available in the DCC++ connection code and turn that on. I'll look for that tomorrow.

[costing]

@mstevetodd

I've connected ED directly to the RPI, see the last paragraph from the above. The problem is still there.

I'll try to reproduce it with two computers in a similar setup but without a hardware backing, using DCC++ Simulator connection instead. Just to see that the problem can be reproduced and chat intercepted. I'll try to dump the ED chat as well.

The DCC++ commands are documented here:
https://github.com/DccPlusPlus/BaseStation/wiki/Commands-for-DCCpp-BaseStation

So <f 38 [byte]> is for setting F0-F4, F5-F8 and then F9-F12, <f 38 222 [byte]> is for setting F13-F20 and <f 38 223 byte> is for setting F21-F28. (38 is this cab's address).

Cheers,

.costin

[costing]

@mstevetodd ,

I think I have a simple way to reproduce it. On a standalone computer start DecoderPro and add a single connection of type DCC++, System connection = DCC++ Simulator. After restarting you have a DCC++ entry in the top menu from which you can select the "DCC++ Traffic Monitor" that also can log the traffic. I've done this and tcpdump-ed the chat between ED and this DecoderPro. Then I ran the same commands with telnet. The problem appears immediately after the first command:

MT+S44<;>ECFF L Re 4_4 II

The reply is the many lines of loco configuration and in parallel the function set operations show up in the DCC++ traffic monitor:

09:57:23.814: [TX: f 44 128] Function Cmd:
Address: 44
Byte 1: 128
Byte 2: null
(No Reply Expected)

(and then the many more messages just like in the previous listing).

As far as I understand this points to a problem in JMRI so I'll report it there.

Cheers,

.costin

[mstevetodd]

@costing
Can this issue be closed?

[costing]

@mstevetodd
Yes, the ticket is opened on the JMRI's side: JMRI/JMRI#3826

Cheers,

.costin