Bluetooth AD packet format

[Vudentz]

Packet format is always:

AD length (1 byte)
AD type (1 byte)
AD data

[Vudentz]

@gabrielcox ^

[gabrielcox]

@Vudentz
Thanks for commenting

Length = 0x1E
Type = 0xFF
Data =
< mfg code=0x0002 > (as required for Type=0xFF)
< ADApp=0x0D > (we're now within mfg 0x0002 data-space format)
< ADCounter=XX >
< ODID Message >

I'm not sure what problem we're pointing out. Is it the fact that we used "AD App" and "AD Counter" as the names for these fields?

[Vudentz]

@Vudentz
Thanks for commenting

Length = 0x1E
Type = 0xFF
Data =
< mfg code=0x0002 > (as required for Type=0xFF)
< ADApp=0x0D > (we're now within mfg 0x0002 data-space format)
< ADCounter=XX >
< ODID Message >

So the AD itself is not part of the message diagram? Perhaps it is worth adding ad you are doing even with flags, etc.

I'm not sure what problem we're pointing out. Is it the fact that we used "AD App" and "AD Counter" as the names for these fields?

I guess I would put them inside the message block and remove the AD from it, it might be a good idea to add the ad length and type otherwise the frame is incomplete.

[gabrielcox]

AD Len/Type is in there -- it's just called AD Flags:
byte[0]=Len(1E), byte[1] = Type(FF)), Bytes [2,3]=0x0002 (LittleEndian).

I looks like I should break those flags apart to be clearer for the reader.

Thanks for the feedback.

Also, I want to encourage others reading this to comment on anything that seems unclear. It can only serve to improve the document quality.

[SandeepSwaraLinkTechnologies]

I think I understand what you are going for here, though it seems like you are using the term "flags" incorrectly which leads to some confusion in your explanation.

In the Bluetooth core spec, "flags" refers to a specific AD type, while you seem to be using the term "flags" to mean the length byte, the AD type byte, and the two company identifier bytes.

The actual flags AD type is used for a device to declare certain properties, specifically related to the LE discovery mode and whether BR/EDR is supported. All of the AD data types are detailed in the Bluetooth Core Specification Supplement, and the "Flags" type is specified in Volume A, Section 1.3 of the document.

The "Manufacturer Specific" AD type (0xFF) is a completely different AD structure than the flags structure, and it is described in Volume A, Section 1.4 of the same document. I would recommend correcting the terminology to be consistent with terminology used in Bluetooth specifications.

On a separate note- I see that you are using 0x0002 for the company identifier bytes, which is the assigned identifier for Intel. It might be possible for the Open Drone ID project to get its own Vendor ID assigned by the Bluetooth SIG, though you probably would need to contact the Bluetooth SIG since the Open Drone ID project is not a traditional company that would apply for Bluetooth SIG membership.

[pzboyz]

On the company identifier issue, Yes any SDO can ask BTSIG to assign it an identifier, see link below for details.

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

[SandeepSwaraLinkTechnologies]

Scott- that link actually contains 16-bit UUID assignments for SDO’s. UUIDs are different than company identifiers, which can be found here:

https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers/

I did some searches for other SDOs (eg “Thread”, ”Airfuel”) in the company identifier list and couldn’t find any assigned. I’m not sure how this issue has been addressed by other organizations, or if it has come up.

[pzboyz]

Yes my mistake I should have explained in full, That will give you a UUID which you can use as a Primary Service UUID. And you can use that with the AD Type called 'Service Data', so you would have to change the specification from using the' Manufacturer Specific' AD type to the 'Service Data' AD type.

[SandeepSwaraLinkTechnologies]

@pzboyz - The "Service Data" AD type seems slightly inappropriate here since the application is broadcast-only and doesn't actually contain a GATT service with an assigned UUID. With that said, though, the core spec supplement doesn't say that the device has to contain the service; it just says "The Service Data data type consists of a service UUID with the data associated with that service," so I'm not sure that there's a better option here.

@gabrielcox - Do you envision this spec evolving in the future to support some connectable functionality?

[gabrielcox]

How's this for a documentation change?
Please indicate your opinion on the proposed doc update:

[gabrielcox]

On the SDO ID, I attempted to get an SDO ID for OpenDroneID.org. Because it is not a legal entity (LLC, corporation, etc), the SIG will not assign it an ID. Now I'm looking to get one for ASTM -- unfortunately, this will take a bit longer. For now, the 0x0002 + 0D will be managed as unique within the (Intel) 0x0002 namespace.

[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