OpenLCB Common Message Format

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:

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.

Node ID Numbers - NID

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.

Message Type Indicator (MTI)

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.


The common Message Type Indicator (MTI) is a 16 bit quantity. Note that specific wire protocols may remap this.

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.

CAN considerations

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.


Site hosted by

This is SVN $Revision: 4142 $