Update UniqueIdentifierS&TN #186
Conversation
| 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. |
There was a problem hiding this comment.
The top three address bits shall NOT be inverted.
There was a problem hiding this comment.
Added text on this
| 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. |
There was a problem hiding this comment.
The top three address bits shall NOT be inverted.
There was a problem hiding this comment.
oh and this might be worth adding a comment to the TN as well. In the DCC packet encoding the top three bits are inverted (they say "in 1's complement form"). We use the native and meaningful address bit, not the inverted version.
There was a problem hiding this comment.
Added text here and in the TN
| 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 |
There was a problem hiding this comment.
Fixed multiple places
|
|
||
| 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 |
There was a problem hiding this comment.
44-bit device identifier called UID.
| 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 |
There was a problem hiding this comment.
allocation for the devices with UID.
| 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 |
There was a problem hiding this comment.
I don't really know how to interpret this provision in code I write.
Code I write today runs in the future. How should this code know whether it is okay to translate a manufacturer id of say 257 to 0x11 01 xx yy uu vv?
I see two ways forward
- remove this comment altogether and actually assign all of 0x10-0x1F
- we could also say something like "values for the 12-bit area in byte 1 and 2 that are not assigned by the NMRA as a DCC manufacturer ID are reserved by the OpenLCB group." This means that if my code encounters a DCC decoder with a given number as manufacturer ID, it is reasonable to use that manufacturer ID in this purpose.
There was a problem hiding this comment.
I went with your 2nd bullet, saying that values that don't correspond to assigned manufacturer IDs are reserved to OpenLCB
|
|
||
| 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 |
There was a problem hiding this comment.
Manufacturer
(this seems to be a common typo, would you like to do a search for the word "manufacture" in the entire doc?)
There was a problem hiding this comment.
Done. There were quite a few!
| 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 |
There was a problem hiding this comment.
conflicts with -> conflicts when
There was a problem hiding this comment.
Done. Also fixed a spelling error on that line.
| 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 |
|
|
||
| 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 |
There was a problem hiding this comment.
this does not match the S, which says 11-1F is held back?
There was a problem hiding this comment.
I used the terminology you proposed below, where we allocate the whole range but reserve the values that don't correspond to assigned manufacturer IDs
2 participants
Several typos corrected
Clarified 0x0A Locally Allocated range
Removed "deprecated, may be removed in the future" from the Locomotive Control section
Changed long NMRA ids from 16 to 12 bits
Defined a 44 bit range for Devices originating RailCom® and Bi-Directional Communications
Defined a range for DCC basic accessory decoder addresses
Clarified the range for DCC extended accessory decoder addresses
NMRA member numbers updated to handle special membership numbers:
Clarified that e.g. NMRA numbers are meant to be converted to hexadecimal, not used as BCD
The changes should have no negative impact on any existing implementation. An earlier draft was discussed on the OpenLCB groups.io list; comments made there have been included in this version.