Menu
▾
▴
1 Attachments
#994 Add LocoNet Ping functionality.
Attached is a patch that adds a "ping" functionality over LocoNet. It is best used with two computers, one generating the pings, and one set to reply to the pings, however there is also a "OneWay" mode that may be useful with only a single machine. I've used this for troubleshooting bad components by starting a ping and them moving a second computer to various points on the loco net to see where the packets are reliably received.
Patch includes a new LocoNet menu item that brings up a new panel to control the ping packets. It also includes a patch to the LocoNet monitor to properly display the ping packets in the monitor. No documentation, I'm simply unsure of where or how I would add it.
I have a couple of issues with this patch right now. First it is a bit old, like a year, and I'm suspect of other changes to the code base that might get messed up by this older patch. Second issue is absence of help documentation about how to use it correctly.
Also a minor one that it seems to be creating an op-code that isn't documented (at least I didn't see it). But the lack of help and age are the real big ones. If help pages were provided I'd suggest we add this to the 3.12.* series and see how things go.
-ken c
Given I've never added help text before I don't have the foggiest idea where to start on the documentation side. Could you point me in a direction, an example, or something?
I can get it updated to the current tree easily and resubmit.
It does create a brand new op-code. As far as I know there is no mechanism to do this officially, that is there is no master table published by DigiTrax (or anyone else) of all assigned op codes, no person to ask for an assignment. I picked one that I was both pretty positive was not in use today by anyone.
While not a great answer, I actually would like to suggest the JMRI decoder logic is the closest thing to an official list of op codes. It seems like pretty much everything has been reverse engineered and is decoded in that logic. Since there is code with this patch to decode these messages, if there ever was a confict it would show up when someone tried to add the decode logic for the conflicting device and appropriate action could be taken (like giving this ping a new op code).
I have diagnosed multiple faulty components with this code, and in that sense I personally find it insanely useful.
Leo,
When I read the write up I too was concerned over 'making up' an op code.
Given the cases where the tool has use, I'd say you should try to directly
talk with Digitrax about the idea. If they would 'create' the op code, then
we'd have the blessing of a correct value. Support for the idea would then
be able to follow.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
This connectivity diagnostic could easily be done by injecting an
arbitrary sensor response message from an otherwise unused sensor I'd
address and looking to see if it arrives, with the 2-way ping pong simply
picking 2 sensor addresses...
I'd suggest a second attempt at this, with a UI for picking the sensor Ids,
ping back on/off and delay/notification choices - without creating a new op
ode.
John
On Monday, November 2, 2015, Ken Cameron ken_c@users.sf.net wrote:
Related
Patches:
#994Format (for reply, request is similar) is 0xB2, <IN1>, <IN2>, <CHK>.
<IN1> is a 7 bit sensor address, 1 bit always zero.
<IN2> is 4 more bits of sensor address, 1 bit of aux/switch flip, 1 bit of data, 1 bit of reserved, 1 bit always zero.
Basically, 11 bits (2048) of space, plus the aux/flip switch (4096 “sensors”), each with a single bit of data and one bit reserved.
Problem #1: All sensor numbers are “valid”.
I use this to troubleshoot N-Trak layouts, where potentially any sensor is already in use locally on a module. Those sensors may control things like turnout motion, so if the code were to pick a turnout and send data it could potentially cause a receiver to take action based on it, like flip a motor back and forth causing physical damage. The user would have to take care to insure the only ID’s used were completely unused on the network.
Problem #2: No space for a sequence number.
There is only 1 bit of data, so there’s no way to store a sequence number to look for out of order replies. Even co-opting the reserved and always zero bits would provide only 4 total bits, or a 16 count sequence space.
Depending on application these may not be an issue. For a home user that can pick a known unused sensor address and has no unusual components which might generate out of order messages, neither are likely a big deal. But to troubleshoot an ad-hoc layout at a train show #1 will be an issue, and #2 has proven useful as I found at least one device that reorders messages under some circumstances.
FWIW, if I was going to co-opt an existing code, OPC_PEER_XFER (0xE5) appears to me to be a better choice. It’s already defined as a peer to peer message. One could be sent in one message, then one back in the other. It has 8 data bytes, more than enough to store what is needed. However, I have a different worry here. Our knowledge of this is fully from reverse engineering, AND these messages are used to program some peripherals. It would be pretty bad to accidentally select a pattern that reprogrammed some hardware just because we didn’t know it existed!
Now, back to my choice. I chose a variable op code that is currently unused based on the following thoughts:
1) The code is, as far as everyone knows, unused.
2) Variable length op codes should only be processed if they are the right length. Not only would someone have to use the op code, but also select the same length to collide.
3) By using a “long” string of data, even if the op code and length matched, it’s probably unlikely the rest of the data would decode into something useful.
4) Op Codes, historically, are assigned “bottom up” in their respective number spaces, so I chose top down, in an effort to make it least likely to conflict.
Obviously the best choice would be to get an official op code assigned. I have no objection to that, but I neither know how to do that, nor am I going to make an attempt to do that. I can explain why offline, if anyone cares.
I think they are all less than perfect answers.
--
Leo Bicknell - bicknell@ufp.org
PGP keys at http://www.ufp.org/~bicknell/
You can use the "blessed by digitrax" SV2 protocol that layers on top of
OPC_PEER_XFER; its addressing mechanism make it easy to ensure you have a
unique src/dest to play with.
If you really want sequence numbers, then this is probably the right
building block to use.
-John
On Mon, Nov 2, 2015 at 2:04 PM, Leo Bicknell lbicknell@users.sf.net wrote:
Related
Patches:
#994Now this is interesting! I see the SV2 protocol appeared in August, I had missed that. From a quick browse of the API that looks like the right place. I'll take a new stab at an SV2 implementation.
Sent from my iPad