This note contains discussion on whether OpenLCB needs to define a “Layout ID” for use in e.g. wireless communications.
See also the note on “Wireless Protocol”.
Wireless communications raises several issues for OpenLCB...
CAN, Ethernet: Everything you can reach, you can reach. Wireless is a little more complicated, as you can choose which connection to make, resulting in being able to communicate with different things. E.g. a wireless throttle at a convention has to be connected to a specific OpenLCB communications infrastructure.
Two OpenLCB layouts can coexist on a single CAN segment, Ethernet, as unique node IDs & event IDs separate all meaning. Separately configured nodes will just communicate past each other.
“Layout” is not a defined concept in OpenLCB. Nodes communicate, and different nodes might have very different (overlapping or non-overlapping) domains of communication.
OpenLCB is silent on connection methods, wireless or otherwise: It uses other, hopefully industry standard, protocols. E.g. you pick a particular access point by name when connecting your computer, and then you're connected to something specific.
Alex:
If you have several physical layouts on the same Ethernet and you have to reconfigure one of them, how do you tell just that subset of nodes to reset but have the rest carry on normally? To me this feels like a broadcast address for each layout.
But is there a global reset? Why?
Alex:
To me this kinda feels like selecting power districts at least. What if we are able to have a group of DCC Command Stations that auto distribute DCC addresses somehow (like FREMO does) then how do you discover that and interact with it? … I think we will want some notion of what nodes a layout is comprised of and provide a way to interact with in different ways.
This seems to have identified a reason for a “named group of nodes” construct, which can be used for several things besides “Layout ID”. It's not so much a way to identify which layout to connect to, but rather a way to deal with multiple nodes via shorthand. But what is there to say? It's hard to design a mechanism unless there's some idea of that to use it for. Events already go to all nodes who are listening to them; streams can be sent to multiple nodes who are interested (so far). Is this only needed to force a group of nodes to pay attention?
Site hosted by
This is SVN $Revision: 924 $