is a shorter ADV format possible for Eddystone-url?

[Pranavgulati]

i couldnt help but notice that the Eddystone UUID (0xAAFE) appears twice in one ADV packet, once in the "Complete List of 16-bit Service Class UUIDs(GAP-0x03)" and again in "Service Data"(GAP-0x16)

Also,since the Eddystone UUID will remain fixed in both the fields, i wanted to know as to why was it so crucial to have a redundancy in the data transmitted. Did it ease programming on the receiving side ? Could we have by any chance saved 2 or more bytes of ADV data ?

I understand doing it now may incur significant costs but this is just my curiosity

[adriancretu]

Not a Bluetooth history expert by any shot, but I'm pretty sure it has to do with how data is encapsulated in EDR format, if you have the patience to dig through the 1000-pages spec/annexes. You can't just put a service uuid and its data and be done with it, but instead, just like a procedural language, you first declare them and then, optionally, define them. Plus, there's likely tons and tons of hardware that expects and requires all kinds of service UUID in this way, so they can filter them instantly (best example: all iOS devices - possibly the main answer to your question), and it's easier for embedded code in hardware to parse these. Plus, it has to be backward compatible, and fields that are recognized should be skippable (via the length prefix) - hence this is why it's the way it is and will forever be (at least for today's BLE standards).

Just my 2 cents.

[scottjenson]

I had the same question @Pranavgulati ! If you can get rid of the ServiceDataList you'd actually save 4 bytes count, param, service id (2 bytes) The practical answer is that for some OS stacks, they key off the ServiceDataList. So in order for is to be found on as many platforms as possible, it was included. I was frustrated by this as we'd live with this for a long time and future OSes wouldn't require it. Fortunately, with BLE5 coming and it's longer adv packets, this 4 byte savings is much less of a problem.

[mashbridge]

Yup. The really short answer is reliable sighting over many versions of Android and iOS BT stacks. (Were we only concerned w/ Android we'd have been more compact.)

[Pranavgulati]

@adriancretu in a case where the ServiceDataList was omitted and only the ServiceData was directly provided with the UUID in the beginning, the hardware parsing this ,could actually still skip reading the data and only read uptil the UUID without hampering performance. the iOS devices and the other tons of hardware that have it this way probably do this because the BLE4 spec told them to, so then the question becomes as to why did the spec want to first declare the service and then define it in the first place , why would we favour being procedural rather than ensuring max efficiency and lower TX/RX time.

@scottjenson i agree with you if the BLE4 spec started off by saving us these 4 bytes, it would be enough for me to conform to Eddystone for RF24BLE which would have made atleast the Eddystone-Url service work on a barely 1$(retail) module

Thanks a lot for the insights, just makes me think how a nuance in the spec affects millions of devices

[adriancretu]

Well, "performance" might mean different things when we're talking about efficiency. The way iOS implemented it and the Bluetooth spec (see Volume 3 / Part C / section 11.1) tells us, is by having the complete list of services in a single field of the advertising data.

This way you can optimize battery consumption by only looking for this field alone, instead of having to parse entire ADV record. You also know it can only occur once. In terms of micro-processing power this can be a huge deal, but yes, you trade that off with more memory usage - the never-ending dilemma of programming, but read the name of the spec - Bluetooth Low Energy, not Bluetooth High Efficiency.

If you want a non-redundant protocol I think Bluetooth itself is not the best place to look at, given all this bureaucracy.