Bluetooth AD type 0x0d is already in use

[Vudentz]

0x0D | «Class of Device»

https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile

Usually Bluetooth beacons use the following types:

0x16 | «Service Data - 16-bit UUID»
0xFF | «Manufacturer Specific Data»

Though these requires extra 2 bytes compared to using a dedicated type, but getting a dedicated type for a beacon spec is probably not something Bluetooth SIG is likely to allow as the AD type domain is rather short (1 byte).

Even with use of Manufacturer Data we still need a manufacturer ID to be added, luckly there exists a way to request UUIDs for Standards Development Organizations:

https://www.bluetooth.com/specifications/assigned-numbers/16-bit-uuids-for-sdos

[Vudentz]

@gabrielcox ^

[gabrielcox]

0x0D is the "app code" -- something we added within the mfg namespace. It's the first byte within the MFG specific data.
The type code is 0xFF (as you described above).

So the AD Flags (onward) looks like this:
....<ad-type=0xff (mfg specific)><app=0x0D><counter=xx>....

It's not clear to me that you can use an SDO UUID as the MFG ID. Do you have any info otherwise? (I would really rather use the SDO UUID than our company code.

Gabriel.

[pzboyz]

You use the SDO UUID in place where you would use it as a UUID for a Primary Service.

[gabrielcox]

sorry, I miss-typed: Current spec for AD is as below. (now including mfgid).

....<ad-type=0xff (mfg specific)><mfgid=0x0002><app=0x0D><counter=xx><ODID-Data...>....

[gabrielcox]

@Vudentz now that you see that 0x0D is within the "mfg data", do you still see this as a spec bug?

@pzboyz We'll take a look at your suggestion.

[Vudentz]

@Vudentz now that you see that 0x0D is within the "mfg data", do you still see this as a spec bug?

Should be alright if it is within the AD payload itself then is up to spec to define... Regarding the SDO UUID that is preferred over Manufacturer data as that needs a manufacturer ID which means each manufacturer would have to advertise with their own ID or fake the ID to be the same (there could be legal implications of doing the later), so I would really recommend doing the Service Data (0x16) with the SDO UUID.

[gabrielcox]

@Vudentz , Agreed. I'm requesting an SDO ID as we speak and will experiment with this. It was not clear to me before that you could get the same single message payload flexibility as you do with mfg specific, but it's clear to me now. We have the existing spec working with TI, Nordic, Android, iOS as it is so we'll just need to validate. I expect it will work fine (and have a better namespace org).

Thanks again for the feedback from both of you (@Vudentz , @pzboyz ) .

Also, if any of you are doing open source implementations (or are interested in doing so), please send me a DM. I run an "early developers" conference call and slack channel and would be happy to promote any OS projects implementing Open Drone ID.

[gabrielcox]

This issue is mostly a duplicate of the previous -- I'll post the proposed doc update for comment.
Please indicate your opinion on the proposed doc update:

[friissoren]

Let's close this issue. A dedicated Service UUID (0xFFFA) has been assigned to the ASTM standardization organization and this has been taken into use in the standard. The Application Code 0x0D = Open Drone ID then makes OpenDroneID unique within that namespace.

https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile/ => 0x16
https://www.bluetooth.com/specifications/assigned-numbers/16-bit-uuids-for-sdos/ => 0xFFFA