Users may want to be able to identify a specific board (node) to a configuration tool. We refer to this as an “ident” operation, similar to the way that a pilot presses the “ident” button on a plane's transponder to light up the proper echo on a traffic controller's screen.
This note is a working draft proposal.
A user wants to use a configuration tool to configure a new input on node A, located under the far end of the layout. He presses button on the node, and the tool learns which node (specifically, the Node ID). The tool then lights an indicator on the board to confirm that it's found the right one.
A user walks from module to module on a modular layout, pressing buttons. A configuration tool sees the sequence of button presses and checks it against the expected module-to-module connections.
We standardize on emitting the global event 0x 01 01 00 00 00 00 FE 00 to indicate an “ident”.
For nodes with blue and gold buttons, we recommend that pushing both of them (briefly!) at the same time send an ident. On release, the node should not be left in specific blue/gold programming state.
We recommend that configuration tools reply to an ident global event with a configuration protocol “indicate” method. This will tell the user that the tool has seen the user identification of the node.
There are (at least) four ways of doing this, each with advantages and disadvantages. In this section, we discuss those briefly to explain why we picked the protocol described above.
One way to provide an “ident” capability would be to define a node-specific EventID that nodes produce to identify themselves. For example, reserving 0xFF,FF in the lower bytes, with the NodeID in the upper bytes, would give a unique indication that an ident button was pressed.
The identification messages need to propagate across the entire LCB. P/C Events are the OpenLCB general mechanism for doing this.
Makes the event address space a lot less orthogonal.
Don't want every node to emit “produces” and “consumes” messages for general event IDs, so would have to build that into routing as a special case (this is an issue just beyond this use of generic EventID signaling). That's a lot of special case entries.
We could define a global eventID that indicates “ident”; the source ID in the message then provides the information needed to track down the source.
Small footprint, stays orthogonal.
Requires the global eventID space be implemented, specifically in routers and gateways. That's a single range, though, so it's only one entry in any routing tables.
Requires central allocation of the specific EventID, but this only needs to be done once.
A specific form of configuration message within the configuration protocol can be reserved for this.
The configuration protocol already has a “confirm” mechanism to signal the proper board by e.g. lighting a light. Being able to send a message back via button push, so that the configuration tool can get positive confirmation of the right board, would be useful.
The configuration protocol already has a “confirm” mechanism to signal the proper board by e.g. lighting a light. Being able to send a message back via button push, so that the configuration tool can get positive confirmation of the right board, would be useful.
This is the only one of the four that might be able to handle multiple idents at the some time, e.g. during modular layout setup, by using the original configuration message to specify a particular return message. But it's not at all clear how to do overlapping idents in the same node.
Since the configuration protocol is point-to-point, the node with the button press needs to find out where to send the message. It's not at all clear how to solve this. It's not practical to first communicate with all nodes so they know you want to hear when their button is pressed.
A specific OpenLCB message type could be defined for this, with a specific MTI. This could then be specified to propagate as needed.
Can specify it exactly, without compromise.
MTIs are eventually a scarce resource.
Another special case in code. This is not an incredibly large issue, as simple nodes need only emit a fixed message, and routing nodes just pass it through.
The Blue/Gold configuration method is already using a single press of each button for normal operation. Multiple presses of the blue button are used to index to a particular producer or consumer. A double press of the gold button (gold, no blue, then gold again) teaches a new unique event. A long press of both buttons does a “factory reset”. A long press of the blue button removes any learn reservations.
That leaves either a short press of both buttons at the same time, or a long press of the gold button. Long presses aren't as good for something as routine as “ident”, so the short double-press is preferred.
Site hosted by
This is SVN $Revision: 1692 $