Discussion of "deprecation" for the 06.*.*.*.*.* unique ID space

[bobjacobsen]

There's a comment in section 5.1 of the Unique ID Standard that says use of the 06.....* unique ID space reserved by section 5.8 is "deprecated, may be reassigned in the future".

We should discuss whether that's still an appropriate comment, as there are devices that use the DCC part of this space now.

[crosland]

I would like to use them for reporting DCC addresses from RailCom detectors.

[atanisoft]

I suspect it should have the "deprecated" tag dropped since it is currently in use for locomotive addressing (various protocols).

For RailCom detectors I thought there was a namespace defined through the working notes for such case? Or perhaps it was the occupancy events with payload which defined it, I can't remember off hand.

[bakerstu]

RailCom defines a 44-bit unique ID field that can be (optionally) deployed by the decoder manufacturer. It consists of a 12-bit manufacturer ID and a 32-bit serial number. It is similar in concept to OpenLCB Unique Identifiers in that every decoder world wide should have a unique RailCom ID.

While not all RailCom enabled decoders have this unique ID, it is required in order to implement certain features, particularly automatic logon.

One thought was that the 44-bit unique RailCom ID should be in the same address space as the 48-bit OpenLCB unique ID. In this way, if the decoder is "discovered", it already has a unique ID that is compatible with the 48-bit OpenLCB unique ID. This ID could also be used for its "virtual" node representation.

The argument against having a unified address space is that it would take up ~1/16 (6.25%) of the usable 48-bit address space. That's a lot to dedicate to one feature. I have argued that the "trains" are one of the most important aspects of model "railroad" layout control, and therefore taking up 6.25% of the address space for one of the most important aspect of layout control might be justified.

[dpharris]

Good argument. How many manufacturers are there going to be? 12-bit = 4096. Could we shave some off that number -- after all the NMRA only dedicates 8-bits? Maybe we can dedicate 0-256 for now, and leave room for expansion? Ie soft-dedicate 1/16th, with 1/64th hard-dedicated at the moment. Of course, we will find out that the allocations of manu# are not consecutive. David

…

On Mon, Nov 24, 2025 at 2:37 PM Stuart W Baker ***@***.***> wrote: *bakerstu* left a comment (openlcb/documents#183) <#183 (comment)> RailCom defines a 44-bit unique ID field that can be (optionally) deployed by the decoder manufacturer. It consists of a 12-bit manufacturer ID and a 32-bit serial number. It is similar in concept to OpenLCB Unique Identifiers in that every decoder world wide should have a unique RailCom ID. While not all RailCom enabled decoders have this unique ID, it is required in order to implement certain features, particularly automatic logon. One thought was that the 44-bit unique RailCom ID should be in the same address space as the 48-bit OpenLCB unique ID. In this way, if the decoder is "discovered", it already has a unique ID that is compatible with the 48-bit OpenLCB unique ID. This ID could also be used for its "virtual" node representation. The argument against having a unified address space is that it would take up ~1/16 (6.25%) of the usable 48-bit address space. That's a lot to dedicate to one feature. I have argued that the "trains" are one of the most important aspects of model "railroad" layout control, and therefore taking up 6.25% of the address space for one of the most important aspect of layout control might be justified. — Reply to this email directly, view it on GitHub <#183 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEDQSXPPGQCVXU4FHWYSZD36OCELAVCNFSM6AAAAACMX5YQFKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNZTGAYDSOJXGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bakerstu]

@dpharris Up until recently, the NMRA actually dedicates 16-bits to the manufacturer ID. After some discussion with the team developing Automatic Login, the NMRA and RailCommunity agreed to drop this down to 12-bits. The 8-bit (non-extended) address space is actually fairly saturated, so yes, I do think having only 8 bits is a long term issue.

...now, could we make some agreement with the NMRA/RailCommunity to start the first "extended" address with the top four bits being 0x1, and then allocating only 41-bits of OpenLCB address space to RailCom (reserving the other 3 MSb)? Then only actually lock them in based on how the need for Unique Identifiers evolves over time? Perhaps.

[bobjacobsen]

On Nov 24, 2025, at 8:26 PM, Stuart W Baker ***@***.***> wrote: ...now, could we make some agreement with the NMRA/RailCommunity to start the first "extended" address with the top four bits being 0x1, and then allocating only 41-bits of OpenLCB address space to RailCom (reserving the other 3 MSb)? Then only actually lock them in based on how the need for Unique Identifiers evolves over time? Perhaps.

If that can be done, I think it addresses the concern about the fraction of the Unique ID space being used by RailCom. It would only require 1/16th of the full Unique ID space only in the case of more than _two thousand_ manufacturers with defined RailCom IDs. Should RailCom be that much of a success, the space use will be well-justified. Bob — Bob Jacobsen ***@***.***

[dpharris]

On Tue, Nov 25, 2025 at 3:31 AM Bob Jacobsen ***@***.***> wrote: *bobjacobsen* left a comment (openlcb/documents#183) <#183 (comment)> If that can be done, I think it addresses the concern about the fraction of the Unique ID space being used by RailCom. It would only require 1/16th of the full Unique ID space only in the case of more than _two thousand_ manufacturers with defined RailCom IDs. Should RailCom be that much of a success, the space use will be well-justified.

Agree. David Message ID: ***@***.***>

…

[bakerstu]

It would only require 1/16th of the full Unique ID space only in the case of more than two thousand manufacturers with defined RailCom IDs. Should RailCom be that much of a success, the space use will be well-justified.

Two Points:

1. We need an agreement from the NMRA that the extended ID's will not be "random" beyond address bit 8. This is probably achievable, but needs to be captured in the DCC standard(s).
2. RailCom manufacture IDs are the same as DCC manufacturer IDs, there is no distinction in the standard or protocol.

It is very likely that the second set of 256 DCC manufacturer IDs will take much longer to hand out than the first set 256 DCC manufacturer IDs. This is because the NMRA has changed the process of handing these out. ...so I think this could be a good solution if we want to pursue a unified OpenLCB and RailCom unique ID space.

[kiwi64ajs]

Wow, having a unified DCC Decoder and LCC Address space for what I would agree is an essential part of the hobby (Loco Control), and is worth allocating ~1/16 (6.25%) of the usable 48-bit address space to achieve it in a convenient way without a translation or mapping layer. Alex

…

On 26 Nov 2025, at 6:48 AM, Stuart W Baker ***@***.***> wrote: bakerstu left a comment (openlcb/documents#183) <#183 (comment)> It would only require 1/16th of the full Unique ID space only in the case of more than two thousand manufacturers with defined RailCom IDs. Should RailCom be that much of a success, the space use will be well-justified. Two Points: We need an agreement from the NMRA that the extended ID's will not be "random" beyond address bit 8. This is probably achievable, but needs to be captured in the DCC standard(s). RailCom manufacture IDs are the same as DCC manufacturer IDs, there is no distinction in the standard or protocol. It is very likely that the second set of 256 DCC manufacturer IDs will take much longer to hand out than the first set 256 DCC manufacturer IDs. This is because the NMRA has changed the process of handing these out. ...so I think this could be a good solution if we want to pursue a unified OpenLCB and RailCom unique ID space. — Reply to this email directly, view it on GitHub <#183 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5Y53PFSUSM7ZYLI5IQ6GT36SJABAVCNFSM6AAAAACMX5YQFKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNZWHAYTOOBQG4>. You are receiving this because you are subscribed to this thread.