search

opendroneid / specs

The Open Drone ID specification
http://www.opendroneid.org
30 stars 6 forks source link

Bluetooth AD packet format #2

Closed Vudentz closed 5 years ago

Vudentz commented 5 years ago

Packet format is always:

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

Vudentz commented 5 years ago

@gabrielcox ^

gabrielcox commented 5 years ago

@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 >

image

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 commented 5 years ago

@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.

image

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

gabrielcox commented 5 years ago

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 commented 5 years ago

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