Skip to content

Update UniqueIdentifierS&TN #186

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
bobjacobsen wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Update UniqueIdentifierS&TN #186

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c65ab0a
updated UniqueIdentifierS&TN
bobjacobsen Jan 16, 2026
3e1c5b4
fix mode Unique ID TN typos
bobjacobsen Jan 16, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file modified drafts/UniqueIdentifiersS.odt
View file
Open in desktop
Binary file not shown.
Binary file modified drafts/UniqueIdentifiersS.pdf
View file
Open in desktop
Binary file not shown.
Binary file modified drafts/UniqueIdentifiersTN.odt
View file
Open in desktop
Binary file not shown.
Binary file modified drafts/UniqueIdentifiersTN.pdf
View file
Open in desktop
Binary file not shown.
77 changes: 64 additions & 13 deletions drafts/generated/UniqueIdentifiersS.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,7 @@

Unique Identifiers shall be allocated using one of the mechanisms in this section.  When additional
allocation methods are defined, the Unique Identifiers defined by those additional methods shall only
provide allocation ranges that do no overlap with existing allocation ranges.  Ranges that are not
provide allocation ranges that do not overlap with existing allocation ranges.  Ranges that are not
explicitly allocated are reserved for future use unless otherwise noted within this document.

5.1 Overview
Expand All @@ -55,12 +55,14 @@
04 * * * * * OpenLCB Individual Unique Identifiers allocated by
automatic requests
05 * * * * * OpenLCB Specifically assigned ranges by request
06 * * * * * OpenLCB Locomotive control systems (deprecated, may be
reassigned in the future)
06 * * * * * OpenLCB Locomotive control systems
07 * * * * * OpenLCB (tentative) RFID and NFC messages as events
08 * * * * * OpenLCB Temporary individually Unique Identifiers leased
by automatic requests
09 * * * * * OpenLCB Long (16-bit) NMRA DCC manufacture identifiers
09 * * * * * OpenLCB Long (12-bit) NMRA DCC manufacture identifiers
‍0A * * * * * OpenLCB Locally-Allocated Identifiers
‍1* * * * * * OpenLCB Devices originating RailCom® and Bi-Directional
Communications1
FF * * * * * OpenLCB Reserved, indicates an error (example:  reset
non-volatile memory)

Expand Down Expand Up @@ -137,9 +139,18 @@
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Organization Comment
NMRA members may, but are not
required to, use their NMRA
03 00 Membership Number * NMRA membership number to self-assign
membership number to self-assign
Unique Identifiers.  The least
significant byte is self-assigned.
The most significant nibble (upper
03 00 Membership Number * NMRA 4 bits of Byte 3) is 0x0 for
regular NMRA members, 0x8 for Life
Members with an “L” preceding their
membership number, and 0x9 for
Honorary Life Members with an HLM
preceding their number. The number
used here shall not include the
separate family code.
MERG members may, but are not
required to, use their MERG
03 04 Membership Number * MERG membership number to self-assign
Expand Down Expand Up @@ -197,12 +208,21 @@
06‍ 01 00 00 00 00 - 7F OpenLCB be used to control all DCC short and long
address locomotives. All other values are
reserved.
DCC long (14-bit) address Valid byte 5 and 6
DCC long (14-bit) address. Valid byte 5 and 6
values are 0 to 10239 logically or’d with
‍06 01 00 00 C000 - E7FF OpenLCB 0xC000, consistent with DCC conventions. Byte 5
is the most significant byte and byte 6 is the
least significant byte. All other values are
reserved.
DCC basic accessory decoder addresses. The value
is formed from the 9 AAA AAA AAA and two NN bits
‍06 01 00 01 0000-07FF OpenLCB defined in the NMRA DCC packet address. Valid
byte 5 and 6 values are 0 to 2047. All other
values are reserved.
DCC extended accessory decoder address with
06‍ 01 00 02 0000-07FF OpenLCB 11-bit decoder addresses. Valid byte 5 and 6
values are 0-2047. All other values are
reserved.
06 02 * * * * OpenLCB TMCC.
TMCC 2-digit address. Valid byte 6 values are 1
06‍ 02 00 00 00 01 - 63 OpenLCB to 99, all other values are reserved. Address 99
Expand Down Expand Up @@ -265,16 +285,19 @@



5.11 Long (16-bit) NMRA DCC Manufacturer Specific
5.11 Long (12-bit) NMRA DCC Manufacturer Specific

Manufacturers shall ensure uniqueness for identifiers they assign.  Long (8-bit) NMRA DCC manufacture
Manufacturers shall ensure uniqueness for identifiers they assign.  Long (12-bit) NMRA DCC manufacture
ID's are assigned out of this pool.  Some of the DCC manufacture ID's are called out specifically in the
table below as an example and to draw attention to their existence, but they are assigned in accordance
with their corresponding DCC manufacture ID.

Note that, given that Long DCC IDs are defined as 12 bits long, values other than 0x0 in the upper four
bits of Byte 2 are reserved to the OpenLCB group.

Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Organization Comment
Manufacturers who have been assigned a
Long DCC Manufacturer ID code may, but are
12 bit Long DCC Manufacturer ID code may, but are
09 Self-Assigned DCC Manufacturer not required to, use this range.  These
DCC ID IDs are defined within the NMRA
standard “S-9.2.2 Appendix A, DCC
Expand All @@ -294,9 +317,29 @@
creation of locally-allocated identifiers.  For example, a club might allocate EventIDs from this range
with subfields that identify the type, location and function served by each EventID.  Selecting Unique
IDs and Event IDs from this range will ensure that installing new globally-unique hardware and software
will not cause conflicts with the locally-allocated IDs.
will not cause conflicts with the locally-allocated IDs. It will not guarantee that moving nodes between
model railroads using this range, e.g. on modular railroads, will not cause conflicts.

5.13 Devices originating RailCom® and Bidirectional Communications

5.13 Reserved Unique Identifiers
The RailCommunity’s RailCom Standard and the NMRA’s Bi-Directional Communications Standard define a
44-bit range for communications.  The most-significant 12 bits of this is a RailCommunity and NMRA
manufacturer identifier number.  This range is a 44-bit allocation for the originators of those
communications.

As of 2025, the RailCommunity and the NMRA are allocating manufacturer identifier numbers with an upper
four bits of zero.  When/if those identifiers expand to have non-zero bits in their upper four bits,
more of this range will be allocated for those identifiers.

Byte 1 Byte 2 Byte 3 Byte 4 ‍Byte 5 Byte 6‍ Organization Comment
10 * * * *‍ *‍ RailCommunity and NMRA Initial allocation for RailCom and
Bi-Directional Communications
11-1F * * * *‍ *‍ OpenLCB Reserved for expansion of RailCom and
Bi-Directional Communications



5.14 Reserved Unique Identifiers

All other unique identifiers not specifically discussed in this Standard shall not be used until the
Standard is revised to permit their use.  Additionally, the following table identifies Unique
Expand Down Expand Up @@ -344,10 +387,18 @@

5.10 Temporary Assigned by Software at Runtime

5.11 Long (16-bit) NMRA DCC Manufacturer Specific
5.11 Long (12-bit) NMRA DCC Manufacturer Specific

5.12 Locally-Allocated Identifiers

5.13 Reserved Unique Identifiers
5.13 Devices originating RailCom® and Bidirectional Communications

5.14 Reserved Unique Identifiers



----------------------------------------------------------------------------------------------------

1 The NMRA uses “Bi-Directional Communications” and the RailCommunity uses RailCom to refer to the
ability of a DCC decoder to return communications to a detector.  Note that RailCom is the registered
trademark of Lenz GmbH in Germany.
55 changes: 43 additions & 12 deletions drafts/generated/UniqueIdentifiersTN.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -140,6 +140,10 @@
to allow a little more headroom on group membership numbers; this space can be reclaimed later if
needed.

Note that the member number is meant to be used as a binary number, not a BCD-coded value.  For example,
an NMRA member with a number of 1029 would use Unique Identifiers in the 03.00.00.04.05.* range, not the
03.00.00.10.29.* range.

Other groups have defined mechanisms to ensure that their node numbers or equivalent constructs are
uniquely assigned. They may have non-technical reasons for wishing to use those same mechanisms to
assign OpenLCB unique identifiers. Ranges of OpenLCB Unique Identifiers can be assigned to these groups,
Expand Down Expand Up @@ -281,13 +285,13 @@
disseminated into use by nodes that could become unaware of a lease expiration and reassignment, Unique
Event Identifiers are not to be assigned out of this range.

2.5.11 Long (16-bit) NMRA DCC Manufacture Specific
2.5.11 Long (12-bit) NMRA DCC Manufacture Specific

When it became known that the long (16-bit) NMRA DCC manufacture ID space would not fit within the
When it became known that the long (12-bit) NMRA DCC manufacture ID space would not fit within the
unassigned space of the Manufacture Specific region described in section 2.5.4, this region was reserved
to be assigned to DCC manufacturers with a long (16-bit) DCC manufacture ID.  Because all short (8-bit)
DCC manufacturer IDs can all be represented as valid long (16-bit) DCC manufacture IDs by having the
most significant of the long (16-bit) DCC manufacture ID set to 0x00, those manufacturers with a short
to be assigned to DCC manufacturers with a long (12-bit) DCC manufacture ID.  Because all short (8-bit)
DCC manufacturer IDs can all be represented as valid long (12-bit) DCC manufacture IDs by having the
most significant of the long (12-bit) DCC manufacture ID set to 0x00, those manufacturers with a short
(8-bit) DCC manufacture ID have two 24-bit allocations assigned to them without having to explicitly
request any additional allocation.

Expand Down Expand Up @@ -318,12 +322,33 @@
no new node brought to the layout with properly allocated Unique IDs and Event IDs will conflict:  No
new node will have IDs that start with 0x0A.

This does not resolve conflicts with a locally-allocated node is taken to another layout with
locally-allocated Unique Ids and Event IDs.  The 0x0A prefix is not intended for e.g. modular layout
groups.  It is intended for independent clubs and home layouts that want to create their own allocation
system for use only on their layout.
An example club coding might  be:

* Use byte 2 to code a location on the layout

* Use byte 3 to code a sub-location such as the west-bound end of the location

* Use byte 4 to code the particular device type, such as signal, turnout, etc.

* Use byte 5 to code the specific device, such as the signal number within the location

Note that this is not a recommendation for allocating unique IDs.  The recommended  allocation system is
defined in other sections of the Standard and Technical note.  

2.5.13 Reserved Unique Identifiers
Use of the 0x0A allccation does not resolve conflicts with a locally-allocated node is taken to another
layout with locally-allocated Unique Ids and Event IDs.  The 0x0A prefix is not intended for e.g.
modular layout groups.  It is intended for independent clubs and home layouts that want to create their
own allocation system for use only on their layout.

2.5.13 Devices originating RailCom© and Bi-Directional Communications2

OpenLCB is reserving the allocations from 0x12.*.*.*.*.* to 0x1F.*.*.*.*.* so that they can be reclaimed
for other purposes should they not be needed for manufacturer IDs at some point in the future.  The NMRA
and RailCommunity are doing the first allocations of manufacturer IDs with the top 4 bits of zero.
Discussions are underweigh (2025) to request that they use a one in the top four bits for when they need
to extend that range.

2.5.14 Reserved Unique Identifiers

For error detection, we permanently reserve all identifiers that start with either a 0x00 or 0xFF value.
OpenLCB implementations should, but are not required to, treat it as an error when any of those are
Expand Down Expand Up @@ -385,11 +410,13 @@

2.5.10 Temporary Assigned by Software at Runtime

2.5.11 Long (16-bit) NMRA DCC Manufacture Specific
2.5.11 Long (12-bit) NMRA DCC Manufacture Specific

2.5.12 Locally-Allocated Identifiers

2.5.13 Reserved Unique Identifiers
2.5.13 Devices originating RailCom© and Bi-Directional Communications2

2.5.14 Reserved Unique Identifiers

3 Implementation Information

Expand All @@ -398,3 +425,7 @@
----------------------------------------------------------------------------------------------------

1 See the Event Identifiers Standard and Technical Note

2 The NMRA uses “Bi-Directional Communications” and the RailCommunity uses RailCom to refer to the
ability of a DCC decoder to return communications to a detector.  Note that RailCom is the registered
trademark of Lenz GmbH in Germany.