search

openlcb / documents

The OpenLCB specification: standards, recommended practices and other documentation.
3 stars 7 forks source link

Working Note on the DCC Detector Protocol #91

Closed bobjacobsen closed 5 months ago

bobjacobsen commented 1 year ago

This is a new Working Note on the DCC Detector Protocol.

This has been discussed on the OpenLCB development list. It also has been (partially) implemented.

I think it's appropriate to put this document in the "drafts" directory so that it can be made more widely available.

balazsracz commented 1 year ago

We should call this file as a basename of DccDetectorWN to be consistent with other files we track in this directory. Otherwise LGTM.

We also discussed the assignment of detector unique IDs from a well-known address range, in order to support the currently unserved use-case of a program like JMRI being able to recognize detection messages without configuration. I have to go back to the mailing list archive to read up on what was proposed.

bobjacobsen commented 1 year ago

I've corrected the names.

bobjacobsen commented 1 year ago

We also discussed the assignment of detector unique IDs from a well-known address range, in order to support the currently unserved use-case of a program like JMRI being able to recognize detection messages without configuration. I have to go back to the mailing list archive to read up on what was proposed.

Would it make sense for these to be of the form 0x01.02.(some uniqueID)? That's what's proposed for the Location Services protocol. These messages could be told from those because these are standard PCER and those are PCER with payload.

bobjacobsen commented 1 year ago

On second thought, I think that using that two-byte prefix is not a good idea. That would give four remaining bytes to make a Unique ID, and we don't have a way to manage allocation of those to manufacturers, etc. I think this protocol just has to live with not being self-identifying at this point.

atanisoft commented 1 year ago

@bobjacobsen Could it be possible to allocate a new top level namespace (say 0x10.XX.XX.XX.XX.XX) which can be used for "well-known" range? This would allow up to five bytes of payload (one of which could be used for MFR ID). It may also be possible to extend this from simply 0x10.... to 0x1X where X encodes the type (which would limit to 16 types) or expand it to be 0x1x and 0x2x prefix?

balazsracz commented 1 year ago

Our plan was to allocate two 12-bit ranges for manufacturer assignment, 24-bit to assign within the manufacturer for unique detector, 16 bit for the DCC address by the detector. This is total 53 bits. So we need an 11-bit fixed prefix.

I think we even discussed what that prefix should be, but I can't quite remember now. We considered two possibilities, like 06.8x / 06.9x and 06.6x / 06.7x. I could be wrong with the numbers though.

-- Sent from my mobile device

atanisoft commented 1 year ago

I think we even discussed what that prefix should be, but I can't quite remember now. We considered two possibilities, like 06.8x / 06.9x and 06.6x / 06.7x. I could be wrong with the numbers though.

This sounds somewhat familiar to me as well. 0x06.xx is barely allocated so your proposed ranges look doable I think. (06.00 to 06.04 are allocated today)

dpharris commented 1 year ago

There is also 0x07 ... http://registry.openlcb.org/uniqueidranges

David

On Mon, Oct 23, 2023 at 7:18 AM Mike Dunston @.***> wrote:

I think we even discussed what that prefix should be, but I can't quite remember now. We considered two possibilities, like 06.8x / 06.9x and 06.6x / 06.7x. I could be wrong with the numbers though.

This sounds somewhat familiar to me as well. 0x06.xx is barely allocated so your proposed ranges look doable I think. (06.00 to 06.04 are allocated today)

— Reply to this email directly, view it on GitHub https://github.com/openlcb/documents/pull/91#issuecomment-1775309531, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEDQSRDAQHZKB44UCXWD7DYAZ4DJAVCNFSM6AAAAAA4SD4X4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZVGMYDSNJTGE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

bobjacobsen commented 11 months ago

This has been sitting for a while, and the existing coding it now in use.

I'm not in favor of coming up with a separate allocation mechanism for 12-bit manufacturer ranges. I think that's much more work than it's worth.

I think we should merge this as a draft WN so that it's possible to link to it.