A brief note on the selection of size for various fields.
Why 48 bits for a node ID?
That's large enough to make assignment easy, while still fitting in a CAN frame.
Larger is better for assignment, but is a load on hardware and bandwidth. CAN networks have limited packet contents: 8 bytes plus header. The Event ID size is NID size + 16 bits, so an increase in the NID to e.g. 64 bits, unless the Event ID changed, would make CAN packets difficult to form.
48-bits for NID plus 16 more to code node-specific events makes an 8-byte event ID, which CAN segments can handle (if we drop event sequence numbers, which don't yet have a strong justification) once we put the rest of the info into the extended header.
Ethernet MAC addresses (also known as EUI-48 addresses) are already 48-bits long. They could be used, but we'd have to make a node ID even longer than 48 bits to flag which are MAC addresses and which are assigned by other means. So they're not particularly useful.
Node ID ranges have been allocated for manufacturers, organization members, etc in a separate note. We experimented with several ways to pre-assign to individual modelers, without using e.g. a membership number from some organization, without success.
Phone numbers are unique, but require too many digits to use a reasonable range, and there were privacy concerns.
Zip codes (postal codes) have a nice size range, but are certain to result in duplicate assignments.
We decided that it would not be a large burden to ask people to obtain an assigned range from a globally-visible web page.
Why 64 bits for Event ID?
Event IDs are unique IDs with no internal structure, but defining them large enough for an NID plus a 16-bit sequence number makes unique allocation easy by piggy-backing on the NID allocation scheme. Whoever first defines a particular event need only use a node ID under their control (this could be the node ID of a specific piece of hardware, but it doesn't have to be, so long as it's owned by the person or board defining the event), plus a lower 16 bits that they know is unique. This is then guaranteed to be unique across any combination of OpenLCB nodes, gateways, etc, without the person/board doing the definition having to communicate with anybody else. This works even it parts of the OpenLCB are powered off, not yet installed, unreachable due to a missing link, or not even built yet.
16 bits for event number within each NID is perhaps a little large, but 8 bits (256 events per node) is clearly not enough. Since a byte is a very convenient unit, we go with two bytes.
6-byte EventIDs do take up memory. A board with 8 outputs might need 8*2*2 events, for a total of 200 bytes; large on the scale of current low-cost PIC microcomputers. But this restriction is rapidly being relaxed as new components are introduced.
The source CAN NID alias needs to fit completely within the header for arbitration, along with whatever other bits are required.
The headers are 11 and 29 bits, depending on standard vs. extended format.
The other bits that need to be included:
Priority - at least one bit needed to simplify bridging.
Bits for ID disambiguation - the default algorithm uses 8 for data plus 3 to label byte 1-6. A total of 48 bits (NID length) need to be checked, so fewer bits is possible, but it takes more messages at startup. More in header for this would be better.
Command code - not all needed in header, but it has to go somewhere and having at least part of it in the header allows filtering. Having a bit or two to code "simple boards need to watch these" would be particularly useful.
The longest defined payload (assuming 48 bit NID , 64 bit EventID and 1 byte MTI on CAN) is the PCER, MTI+EventID > 8 bytes, so MTI for at least this MTI value has to be in extended header.
The use of 11-bit CAN ID (in the absense of priority bits) would allow standard headers, but only 2047 unique nodes in the reachable OpenLCB installation. (Routing tables would map the external NIDs to the available CAN ID codes; the algorithm to do this would be complex if more than one gateway was allowed to attach to a CAN segment) More are clearly needed, and 16-bits is the next logical break point.
All this leads to an 16-bit CAN ID.
Higher bit rates move more data and reduce latency. But they reduce segment capability in terms of length, node count and robustness against marginal wiring.
OpenLCB CAN frames tend to be large. Eight-byte EventIDs and extended CAN headers combine to roughly 120 bits. (Check that!) 125kbps CAN is then about 1000 frames per second, just a few milliseconds typical latency, and typical inter-frame time of a millisecond.
Raising the rate to e.g. 500kbps raises capacity to 4000 frames per second, and reduces latency by a little more than a factor of four. But it only leaves 250 nsec inter-frame time, which is a tougher constraint for small-processor nodes to meet. They'll need faster processors, more advanced buffering software, and/or more complex/expensive CAN interfaces.
The faster rate also reduces the reliable length of a CAN segment. 125kbps is meant to operate to a limit of 50 to 80 meters, while 500kbps should operate to 30 to 40 meters, roughly 100 feet. That still seems pretty long, but because wiring tends to snake around layouts, it might not be adequate for even a 25x25 foot layout.
What should the recommended maximum number of nodes on a OpenLCB CAN segment? Of course, people will always connect more, but what recommended size properly balances reliability and robustness against the need to build large layouts?
This depends on what rate is specified, and also on the maximum length recommended.
Site hosted by
This is SVN $Revision: 721 $