diff --git a/drafts/UniqueIdentifiersS.odt b/drafts/UniqueIdentifiersS.odt index d14f5c9d..85a6db1f 100644 Binary files a/drafts/UniqueIdentifiersS.odt and b/drafts/UniqueIdentifiersS.odt differ diff --git a/drafts/UniqueIdentifiersS.pdf b/drafts/UniqueIdentifiersS.pdf index 5e0aed38..a826f851 100644 Binary files a/drafts/UniqueIdentifiersS.pdf and b/drafts/UniqueIdentifiersS.pdf differ diff --git a/drafts/UniqueIdentifiersTN.odt b/drafts/UniqueIdentifiersTN.odt index e88a984e..ac0271a5 100644 Binary files a/drafts/UniqueIdentifiersTN.odt and b/drafts/UniqueIdentifiersTN.odt differ diff --git a/drafts/UniqueIdentifiersTN.pdf b/drafts/UniqueIdentifiersTN.pdf index 139a0f80..1eb761dc 100644 Binary files a/drafts/UniqueIdentifiersTN.pdf and b/drafts/UniqueIdentifiersTN.pdf differ diff --git a/drafts/generated/UniqueIdentifiersS.txt b/drafts/generated/UniqueIdentifiersS.txt index 792e3a37..46084475 100644 --- a/drafts/generated/UniqueIdentifiersS.txt +++ b/drafts/generated/UniqueIdentifiersS.txt @@ -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 @@ -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) @@ -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 @@ -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 @@ -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 @@ -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 @@ -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. diff --git a/drafts/generated/UniqueIdentifiersTN.txt b/drafts/generated/UniqueIdentifiersTN.txt index 1eda09e4..06bacfdc 100644 --- a/drafts/generated/UniqueIdentifiersTN.txt +++ b/drafts/generated/UniqueIdentifiersTN.txt @@ -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, @@ -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. @@ -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 @@ -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 @@ -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.