This document is deprecated. Please see http://old.openlcb.org/trunk/specs/index.html for more up to date information.
A common message consists of several parts:
Node ID Number of the Source node (SID)
Message Type Indicator (MTI)
In some cases, the Destination Node ID (DID)
In some cases, a P/C Event ID (EID)
Message content, as defined by the particular message type
Each OpenLCB wire protocol will define local representations for each of these components. This may involve replacement (e.g. using a shorter "Alias" token for the node ID number), reordering, and/or specific representations that differ from the common ones, but in all cases it must be possible to translate from the wire protocol message to a complete common message using only locally available information.
By convention, multi-byte quantities in OpenLCB are represented in big-endian order. The most significant byte is sent first, and stored at the lowest address. This is the same as Ethernet and the common internet protocols, but not the same as the Intel x86 architecture.
Reserved quantities must be created with a zero value unless otherwise specified. When processing a message, any reserved quantities must be ignored unless otherwise specified. When transporting a message, reserved quantities must be transported unchanged. The zero value sometimes indicates a non-initialized value.
A node ID number is 48 bits. Number ranges will be allocated to individuals or organizations upon request. A detailed mechanism for kinds of delegation has been separately proposed.
The common Message Type Indicator (MTI) is a 16 bit quantity.
Each specific MTI has a specific defined content documented elsewhere, but there are a few general points.
Messages are variable length. The specific wire protocol is responsible for carrying length information as needed.
If the message carries a destination address, that destination node ID (destination address) is the first part of the message content. The form of a Destination Node ID is defined by the particular wire protocol, but must be mappable to the full Node ID of the intended destination.
The common Message Type Indicator (MTI) is a 16 bit quantity. Note that specific wire protocols may remap this.
The most-significant 5 bits are reserved as 00110; nodes must send and check that value.
The next 7 bits are used to indicate the message type.
The top two of these are used to form static priority groups. A 0 bit is considered to have more priority (can be processed first), a 1 bit less priority (can be processed later). The MSB makes a larger statement about priority than the LSB of these two. Priority processing is permitted but not required. The priority group bits are part of the overall message type.
The next bit is reserved as 0; nodes must send and check that value.
The lower four bits indicate a specific type.
The following bit is reserved as 0; nodes much send and check that value.
The 2nd from-least-significant bit indicates that this message carries a destination node address (DID) when set to 1. Setting 0 means that the message is globally addressed. If a Destination Node ID (DID) is present, it is located at the start of the message content. The form of a Destination Node ID is defined by the particular wire protocol, but must be mappable to the full NID of the intended destination.
The next-to-least-significant bit indicates this message carries a P/C Event ID field when set to 1. Setting 0 means that the message does not carry a P/C event ID. If a P/C Event ID is present, it's at the start of the message, except after the Destination Node ID, if present.
The least-significant bit when set to 1 indicates this message carries a flag byte after the DID and/or EID determined by the above bits. The low bits of that byte can be relocated in CAN messages, see the definition of the CAN wire protocol.
We've chosen to allocate bit fields to make decoding simpler; if possible, aligned on nibble boundaries to make it easy to read as hexadecimal numbers. Note that, as a special dispensation for CAN, higher priority messages (MTIs with lower numerical values) may pass lower priority ones; this must be taken into account when designing protocols.
MTI layout:
Field |
Reserved (send and check) |
Message Type |
Reserved (send and check) |
Destination ID flag |
Event ID flag |
Flag byte flag |
---|---|---|---|---|---|---|
Size & location |
5 bits 0xF800 |
7 bits 0x07F0 |
1 bit 0x0008 |
1 bit 0x0004 |
1 bit 0x0002 |
1 bit 0x0001 |
Value(s) |
0b00110 |
See below |
0b0 |
1 means Destination ID present, 0 means not present |
1 means Event ID present, 0 means not present |
1 means flag byte present, 0 means not present |
Message Type field (7 bits) layout:
Field |
Static priority groups |
Reserved (send and check) |
Specific type |
---|---|---|---|
Size & location (within 7-bit field) |
2 bits 0x60 |
1 bit 0x10 |
4 bits 0x0F |
Value(s) |
0b00 to 0b11 0b00 goes first, 0b11 last if priority processing is present |
0b0 |
See spreadsheet for values & meanings |
Specific values are allocated and documented in a separate worksheet. We keep them in just that one place to avoid conflicting updates.
The standard CAN MTI field is 12 bits in the header (messages without destination address) or one byte in the data segment (addressed messages). Since CAN frames only carry 8 data bytes, a 1-byte MTI short form will be used at first. The possibility of longer MTI values has been reserved.
This is SVN $Revision: 4142 $