OpenLCB Example: Modular Clubs and OpenLCB

Modular clubs and their inter-club meets present the most complex use case for OpenLCB. This note describes some of the things they'll want to do, and how OpenLCB can bring it about.

Goals and Requirements

Large layouts...

Made of individual modules, and various levels of subassemblies: multi-module yards, club layouts, etc.

Throttle controls across entire layout...

Reduce required coordination... Organizations like FREMO are using CAD tools, etc, to design layouts for large meets. Connecting to those, in a flexible manner, is important.

Desired Uses of OpenLCB

Within a module

Between Modules

Discussion

Central idea: OpenLCB is a base for implementing solutions. How to do that need not be specified, particularly at first.


Spanning CAN between modules to reduce cost; provides way to create smaller module groups for e.g. club running, etc. Universal address space means you can just wire as needed, limited only by length and traffic.

Communicating events

Assignment of Node, Event IDs ensure uniqueness, no overlaps or collisions.

Use of FREMO membership ID space, or perhaps establish subspaces by club, by region, etc, to do actual assignment.

Events within modules can just be configured in the usual way, without worrying about ID collisions.


To connect modules, a modular group could define standard “Interface Events” to e.g. tell one module's signals that a train is approaching, or is occupying the next block ahead; to allow control from other locations. Easy to document these interface events at the same time as mechanical dimensions, etc, for overall planning. For example, 0x1001 in the low-part of the EventID could mean “Track one occupied east end”, 0x1002 could be “Track two occupied east”, with others for the west end of the module, conveying signals status for look-ahead, etc.


Must have a way to match up the events produced by one module with the events consumed in the next. There are a couple of ways that this could be done:

Central monitoring

Use of e.g. Ethernet for backbone connecting all individual segments (as many as needed) to PCs. This removes distance limitations, etc.


Routing protocols have to make it possible to pull all traffic onto backbone. Not really a bandwidth issue, Ethernet speed gets higher and higher all the time, more of a management issue.

Local Configuration

Consider a modular meet at which N clubs bring together their sections of layout. Further, consider that each section is configured with a common CAN OpenLCB segment. They would like to connect the segments into a single OpenLCB CAN segment, configure the interface eventIDs, and operate. Central PC tools can do the configuration, but how about doing local (button-based) configuration? Blue/Gold and similar global message methods can only be used one-at-a-time on the connected layout.

One way to fix this is to put a 4PDT switch in the middle of each CAN segment. This could be in the middle of each module, or only one per segment. Set one way, the CAN network is continuous. Set the other way, it's divided into two segments, each with a terminating resistor.

Now, connect two segments, each split in the middle by setting the switch. Those can be configured using e.g. blue/gold, then the switch set back to normal operation.


Site hosted by

This is SVN $Revision: 721 $