CAN Wire Protocol

CAN bus (ISO 11898-*) provides a very convenient transport medium for OpenLCB on a specific module or layout. This section defines a specific wire protocol for transporting OpenLCB™ over CAN bus.

Common OpenLCB messages need to be translated for transport via CAN 2.0B frames because of the limited CAN frame sizes and to take advantage of CAN interface features such as filtering on the header bits.

The adaptations include

Note that these adaptions must be possible in standard CAN components, e.g. bridges and computer adapters must not require customization to operate with OpenLCB. This provides a stringent requirement on protocol design, in that OpenLCB CAN cannot require specific timing, deliberate creation of error cases or specific error handling.

Physical Layer

The physical layer of OpenLCB-CAN is 125kbps CAN over twisted pair wiring. The NMRA is attempting to define a common physical layer for use across multiple implementations, and that may in turn define the physical layer of OpenLCB-CAN.

For more information, see the separate Common CAN Platform document.

Link Layer

OpenLCB common messages are converted, to the extent possible, to single CAN frames via a one-to-one mapping.

The translations include:

Design decisions:

Header content and sizes (Nominal decisions shown, 29 bit header):

The order of these fields is chosen to get proper priority and access disambiguation via CAN's standard mechanisms.

Bit 0

Bits 1

Bits 2-16

Bits 17-28

Priority: 0 high, 1 low

Frame Type

1: OpenLCB Message

0: CAN Control Message

Variable Field

Source NID Alias





Solo top bit

Top bit of 6th nibble from right

3 bits lower bits, then three nibbles

Right-most three nibbles

The "Variable field" has different meanings depending on the "Frame Type" field. CAN control messages are identified with a Frame Type bit of 0, to ensure high priority.

Document no-seven-1-bits-in-top-11 limitation to ensure future selections don't violate it.

Throughput and Temporarily Deaf Nodes

OpenLCB requires that CAN-attached nodes be able to handle the full frame rate on the CAN bus. There is no guarantee that frames for a given node will arrive with non-zero time between then.

Some nodes are not always able to process frames. For example, the node may cease processing for a short time while writing non-volatile memory. Higher-level protocols, e.g. configuration write datagrams, have mechanisms built in to prevent overrun while writing configuration memory, but there could be multiple activities going on in parallel that will result in frames arriving while the node is not processing.

Short outages can be covered by CAN hardware buffering, so long as the node will eventually catch up even at full arrival rate. Outages long enough that frames are lost due to e.g. buffer overflow require node to broadcast that it's back up if hardware detected frame lost. This is because tehre could have been frames of some form that modified the OpenLCB node state, which are now lost (e.g. drop alias, CIM/RIM in absence, or even higher level events)

CAN-specific Control Messages and Interactions

These are identified by the Frame Type bit being 0. They are formatted as shown in the following table:


Variable Field

Check ID (CIM) message


where MMM is the message sequence number, 0x7 to 0x4 (to give priority to messages later in the process)

and NNNN,NNNN,NNNN is the 12-bit Node ID section being checked

Reserved ID (RIM) Message


Mapping Reset (MR) Message



All others

CANid assignment

The common message format uses full 48-bit node ID numbers to identify originating nodes and in some case destination nodes. CAN frames use 12-bit local "NID alias" for these to save space in the limited-size CAN payload.

The standard Verify Node ID Number interaction can be used to get the full 48-bit NID from a node for translation. At power up each node must obtain a alias that is locally unique. Gateways will also have to obtain unique aliases for remote nodes they are proxying on to the segment.

Proposed algorithm, in rough form:

Note that there is no requirement that this alias be consistent from one run to the next. More detail is on a separate page.

CAN-specific messages

Most CAN frames are one-to-one or many-to-one equivalents of common OpenLCB messages.

A few additional messages are used for CAN-specific purposes.

Check ID Message - used as part of the ID allocation.
Reserved ID Message - used as part of the ID allocation.
Mapping Reset - indicates that the local alias in the source address field may no longer be associated with the same NID, and mapping tables should be reset.


A node must be able to convert traffic on the local CAN segment into the common message format using only locally available information. This may be needed e.g. by a gateway or monitoring program attached to the CAN segment.

All traffic on a CAN segment uses aliases for both Source ID (always) and Destination ID (when the full NID isn't known).

If/when a full NID is needed, it can be obtained by sending a "Verify Node ID Number (Addressed)" message with an appropriate Destination Node ID in local alias form. The reply will eventually come back with the Source ID in local alias form and carrying the full NID in the message content.

Aliases for nodes on the local segment are only valid until an "Initialization Complete" is seen from that alias. Initialization Complete indicates that a node has restarted, and may have another local alias.

Gateways maintain the mapping between remote node's NID and local alias. If they need to break that mapping, e.g. because they need to reuse the local alias due to resource limitations in the mapping tables, they must send a "Mapping Reset" message to force nodes to drop their alias information. "Mapping Reset" is a CAN-specific message limited to the segment, but all gateways on the segment must act on it.

Gateways may not be able ensure permanent validity for alias to remote NIDs. For example, if they have a limited routing table, they may need to reuse local alias. Before reusing them, they have to send a "Mapping Reset" frame to drop references to the old NID, followed by a "Initialization Complete" when the alias is allocated to a new NID.

Map Acquisition

In order to acquire the map between CANids and NIDs, a gateway needs to be able to send a CAN frame requiring "everybody reply with your NID". Much like Ethernet gateway mapping, this needs to return the NID of just the specific CAN-attached hardware, not all the NIDs that can be e.g. reached through a gateway, so it needs to be a segment-specific message defined only at the CAN level. It must not be a OpenLCB common message.

OpenLCB message format

OpenLCB common messages are carried in frames with a 1 in the Frame Type field. They contain message type information and/or address information in the 15-bit variable field, and zero to eight CAN data bytes.

For OpenLCB messages, the variable field is used in three forms:

The variable field is allocated:

Variable Field Bits 0-2

Header Bits 2-4

OpenLCB Format


Variable Field Bits 3-14

Header Bits 5-16

OpenLCB Variable Header Content


0 0 0

MTI & additional information for “simple node” unaddressed messages

0 0 1

MTI & additional information for unaddressed messages other than “simple node” forms

0 1 0

(Reserved, must not be sent or accepted)

0 1 1

(Reserved for long-form MTIs in data area,
must not be sent or accepted)

1 0 0

Destination Alias for datagram message non-last fragment

1 0 1

Destination Alias for datagram message last fragment

1 1 0

Destination Alias for non-datagram addressed messages

1 1 1

Destination Alias for Stream Data Send messages

Putting the destination alias in the header allows filtering on it with common CAN hardware. Putting the Stream ID in the header also allows filtering, and preserves the full 8-byte CAN payload for stream data.

The specific MTI values are being allocated in a separate worksheet (PDF version). In general, the MTI selection is done on the top 8 bits of the variable field. This is mapped to the low MTI byte in a standard format message.

Some MTIs have additional status bits defined as part of the 2nd field. For example, there are two status bits associated with “Consumer Identified” which must be kept in the header since there is no room in the CAN data field. To simplify translation between formats, these are the low bits of the first byte after the MTI in a standard-form message.

Note that messages with Destinations IDs may occur in two forms: with an alias in the header and the MTI in the message; and with a full address in the data field and the MTI in the header.

CAN Controller Filters

This coding has been generated such that simple nodes can use three hardware filters to select only frames that are of interest to them.



Required Value

CAN-specific control messages



OpenLCB format addressed to this node



Other simple OpenLCB format MTIs



Note that whether or not filters are used, nodes must be able to handle all combinations of sucessive frames that the full CAN rate. There is no guarantee that a node will have time for processing between frames that it must handle.

Site hosted by

This is SVN $Revision: 1473 $