Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uri Data Length and semantics #6

Closed
schilit opened this issue Nov 29, 2014 · 9 comments
Closed

Uri Data Length and semantics #6

schilit opened this issue Nov 29, 2014 · 9 comments
Assignees
Labels

Comments

@schilit
Copy link
Contributor

schilit commented Nov 29, 2014

Hi @rgrover

BLE_API / services / URIBeacon2Service.h includes the definitions:

    static const size_t MAX_SIZEOF_SERVICE_DATA_PAYLOAD = 27;
    static const size_t MAX_SIZE_URI_DATA_CHAR_VALUE    = 48;

However Uri Data must be between 0 and 18 bytes in length.

URIBeacon2Service.h also treats Uri Data as unencoded but it is already encoded and should be treated as an opaque type.

@rgrover
Copy link
Contributor

rgrover commented Nov 29, 2014

Thanks for pointing this out. I'll fix this shortly.

@rgrover
Copy link
Contributor

rgrover commented Nov 29, 2014

Why is the encoded URI data restricted to 18 bytes when you can go up to 21?
ADV payload can be up to 31 bytes.
4 bytes for the service UUID: Type + length + 16-bit UUID
6 bytes of header for the URI data: Type + length + 16-bitUUID + flags + power

@schilit
Copy link
Contributor Author

schilit commented Nov 29, 2014

The case of the missing bytes!

See the Figure below. The missing bytes are from the AD Flags (AD Type 0x01).

Is mbed broadcasting flags? CSR firmware forces the flags in the ADV packet.

The thing is that some central devices care about them and some don't. We've seen versions of Android/iOS discard ADV packets without flags (though I'd have to dig up which).

Robin Hayden was going to propose that missing flags default to 0... which is reasonable but right now it doesn't seem to be widely adopted in scanners.

Figure

@rgrover rgrover self-assigned this Nov 30, 2014
@rgrover rgrover added the bug label Nov 30, 2014
@rgrover
Copy link
Contributor

rgrover commented Dec 1, 2014

Why is the service UUID duplicated?

@rgrover
Copy link
Contributor

rgrover commented Dec 1, 2014

Hi, AD flags aren't needed. Mbed doesn't add them. Secondly, Advertisement payload can be up to 31 octets long. Lastly, you shouldn't be duplicating the Service UUID.

You should be able to add another 7 bytes to your max URI data length!!

@hugovincent
Copy link

@rgrover are you sure that's true for all versions of Android and iOS? If I recall correctly, Scott said these were added for compatibility with either iOS (something to do with detecting tags from a background process) or older versions of Android.

rgrover pushed a commit that referenced this issue Dec 1, 2014
@rgrover
Copy link
Contributor

rgrover commented Dec 1, 2014

I'm not sure about all version of Android/iOS. Even if we need to keep AD flags, there's some more room in the advertisement payload, and there's also some redundancy. You could certain get a few more URI octets out of the payload.

@schilit
Copy link
Contributor Author

schilit commented Dec 1, 2014

As mentioned above, AD Flags is necessary for some devices, else packets are filtered. We can revisit this and see exactly which devices.

Why is the service UUID duplicated?

I assume you mean why is there both a AD Service UUIDs and AD Service Data? AD Complete List of 16-Bit Service UUIDs is needed in order to background scanning on iOS.

@schilit
Copy link
Contributor Author

schilit commented Dec 1, 2014

31 - 3 (AD Flags) - 4 (AD Service UUIDs) - 4 (AD Service Data header) - 2 (Flags, TX Power) = 18

JayBeavers pushed a commit to JayBeavers/ble-api that referenced this issue Mar 19, 2016
Author: Rohit Grover
Uri Data must be between 0 and 18 bytes
ARMmbed/ble#6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants