Serial Numbers/UIDs

[peternewman]

I see you've already mentioned this partly in #2 but given it's important we don't get UID clashes in our space so for now if you're using static ones it would be good to switch to some of the reserved ones here (any of the development blocks are fine):
https://wiki.openlighting.org/index.php/Open_Lighting_Allocations#UIDs

What serial(s)/MAC(s) does the RP2040 chip ship with and I can suggest some ways we could make use of them based on what we've done in the past.

[kripton]

You're right, for now this should be using development IDs.
The RP2040-chip itself has no unique identifier at all. According to RasbperryPi, they are all identical (except tolerances and thus timing differences). However, each Pico board comes with a Flash chip that has a unique identifier (64 bit long). As such, we cannot know if it might clash with the way serial numbers are generated on other boards that use means to generate their serial number.
Sadly, when shorting that flash-unique-id, it's no longer guaranteed to be unique. I was not able to find if there is some kind of meaning to individual bits of the ID (like a common vendor-part).
This is how the unique ID is read from the flash in the pico-sdk: raspberrypi/pico-sdk@620c75b#diff-d85fc31503033b99c1704e8b74d1af2e1c806f2e96f08bcd86b00fe9433c8bb3R69

In the beginning (when the rp2040-dongle was emulating the Nodle U1 board), I had the complete unique ID as a serial number: https://github.com/OpenLightingProject/rp2040-dongle/blob/main/src/usb_descriptors.c#L160 (still current in main branch).
However, since the Ja Rule protocol mandates the PLASA ESTA format (which is not a bad thing), those can no longer be used. I've decided to use the last 4 byte of the board id for now: https://github.com/OpenLightingProject/rp2040-dongle/blob/JaRuleProto/src/usb_descriptors.c#L223, not being aware that the OLA-range was already organized that well!

I can't really think of a proper solution since no matter how we shorten, truncate or hash the 8 byte long unique id of the flash, the result will never be guaranteed to be unique, thus they are not safe to protect clashes reliably.

The only thing we could do is to reserve another range (7a70:40000000 - 7a70:4fffffff) and hope they never collide (it's still 28 bit of "randmon-ness", which should suffice in most cases).

[peternewman]

You're right, for now this should be using development IDs.

Thanks!

I can't really think of a proper solution since no matter how we shorten, truncate or hash the 8 byte long unique id of the flash, the result will never be guaranteed to be unique, thus they are not safe to protect clashes reliably.

Agreed, I guess all we can really do is hope no-one is unlucky. OLE also allows a UID value from flash (e.g. for testing collisions or other purposes), so that could be a possible option if someone did have a clash.

The only thing we could do is to reserve another range (7a70:40000000 - 7a70:4fffffff) and hope they never collide (it's still 28 bit of "randmon-ness", which should suffice in most cases).

For a bit of background see here for more detail of how the OLE UIDs are defined:
https://github.com/OpenLightingProject/ja-rule/blob/0e4bf7bd6e944222f1b64996c93c3ac87a607de5/common/uid_store.c#L46-L59

If you're never planning to do dummy RDM responders, or responders dummying proxy devices, then you'd only need one UID per device, so could avoid the shift. Although it might be good to keep that an option unless memory space is likely to be too limiting.

I'll have a bit of a ponder, but keeping the potential Microchip OUIs and any future ones sequential and chucking this in at 7a70:e... feels like it might make sense.

[peternewman]

Random lsusb serial:
E0C912D24340

I don't know if it gives much hint to the numbering, or if it's truly random?

[kripton]

You're right, for now this should be using development IDs.

Thanks!

Implemented in the JaRule-branch: https://github.com/OpenLightingProject/rp2040-dongle/blob/JaRuleProto/src/usb_descriptors.c#L183 and https://github.com/OpenLightingProject/rp2040-dongle/blob/JaRuleProto/src/usb_descriptors.c#L210

Agreed, I guess all we can really do is hope no-one is unlucky. OLE also allows a UID value from flash (e.g. for testing collisions or other purposes), so that could be a possible option if someone did have a clash.

Yes. At least when I made it that far that I can read & write the flash. Currently, it's the bootloader loading the program and running it. Until now there was no point in storing persistent settings. But yes, I did see the SET_SERIAL command in the protocol and thought the same.

For a bit of background see here for more detail of how the OLE UIDs are defined:
https://github.com/OpenLightingProject/ja-rule/blob/0e4bf7bd6e944222f1b64996c93c3ac87a607de5/common/uid_store.c#L46-L59

If you're never planning to do dummy RDM responders, or responders dummying proxy devices, then you'd only need one UID per device, so could avoid the shift. Although it might be good to keep that an option unless memory space is likely to be too limiting.

I'll have a bit of a ponder, but keeping the potential Microchip OUIs and any future ones sequential and chucking this in at 7a70:e... feels like it might make sense.

Indeed, that source code is a good reading. I was not aware that the JaRule devices can act as an RDM proxy and use those 4 bits for that. Nice idea 👍
And regarding the range, I also had in mind that there should be some space after the current JaRule-ranges in case Microchip acquires more OIDs in the future. I'd be happy with the 7a70:e... range as well :)

[kripton]

Random lsusb serial:
E0C912D24340

I don't know if it gives much hint to the numbering, or if it's truly random?

That's the one form the bootloader, right? I thought the same at first, however it's not what the both of us thought it was: raspberrypi/pico-examples#6 (comment)

What you are seeing there is some kind of revision number of the bootloader and is the same on all Pico boards ;) When the device is running in BOOTSEL mode (= bootloader), there is no unique identification feature :-/

[peternewman]

Indeed, that source code is a good reading. I was not aware that the JaRule devices can act as an RDM proxy and use those 4 bits for that. Nice idea
And regarding the range, I also had in mind that there should be some space after the current JaRule-ranges in case Microchip acquires more OIDs in the future. I'd be happy with the 7a70:e... range as well :)

I suspect there's unfortunately not a huge amount of progress likely to be made with Microchip based JaRule stuff, but equally given this is almost pseudo-random UID allocation given the overflow it's probably still sense to split them up.

Are you interested in that level of flexibility in your device?

That's the one form the bootloader, right? I thought the same at first, however it's not what the both of us thought it was: raspberrypi/pico-examples#6 (comment)

It was some random one off the Internet!

I guess if I load your main branch, I should see my serial there to compare.

[kripton]

Regarding RDM proxy and the reserved bits, I'm totally unsure. I don't have any experience at all with RDM and cannot judge if the dongle should support that. Sure, with a good number of ports, it could be configured as RDM-capable splitter where this feature would come in handy.
On the other hand, it would increase the likelihood of an ID clash (28 bit of uniqueness vs. 24 bit). I don't have a definite answer but my gut feeling tends to go for 24 bit unique id + 4 "reserved" bits for the advanced RDM functionality. Probably won't hurt.

Indeed, if you flash the current main branch (the one emulating the Nodle U1 protocol), you should see the full 8 byte / 64 bit / 16 characters, truly unique serial number.