Feature: Add support to the library for detecting layouts in an extended advertisement
Maximvdw opened this issue · comments
Currently the library supports detecting specific layouts in the advertisement and scan response data.
This issue is a proposition to add support to perform non-legacy scans for extended data.
This issue is related to a stackoverflow question: https://stackoverflow.com/questions/69691154/does-android-beacon-library-support-extended-advertisement-packets-from-bluetoot
I think a good starting point here is to provide an example of a proposed extended advertising beacon format, describe how it differs from existing iBeacon, AltBeacon and Eddystone formats, and what specific benefits or capabilities the format enables.
Would the library api need to change, or would it work the same way? What is a proposed example of its use with the library API?
An extended advertisement itself can contain the same type of data as a legacy advertisement. I.e. you could send an AltBeacon or Eddystone-UID over an extended advertisement and a parser would still be able to see it as a beacon. So in that sense, the extended advertisement is a layer below the legacy advertisements. As a matter of fact, from a transmitting point of view you can even send legacy advertisements within an extended advertisement PDU that can be picked up by BLE 4.2 devices.
The big difference however is the capabilities the underlying layer offers. LE Phy Coded offers a larger line-of-sight range and also a larger range indoors (some reading material https://blog.nordicsemi.com/getconnected/tested-by-nordic-bluetooth-long-range). In addition, an extended advertisement (as the name suggests) offers a larger size of payload without requiring a scan response.
So how does it differ?, well its mainly not the format that is different - just how it is transmitted. You can send AltBeacon and Eddystone formats in an extended advertisement with some added benefits like longer range. The data size can be used to offer multiple services.
For example: You can have a beacon that transmits an Eddystone-UID, Eddystone-URL and Eddystone-TLM frame which would be a use case for smart devices that are 1) uniquely identified 2) have telemetry data and 3) have a public/local URL where you can control it.
The API would not change, you can perhaps add additional flags to a parser to indicate if its only for an extended advertisement - but this is not a requirement since the type of data can be the same in a legacy advertisement (just the size would differ, but this is handled by the layout). Internally, the way of scanning would be changed for BLE5 capable devices. An extended scan can pick up both legacy advertisement as well as extended ones.
EDIT: In addition, it is my personal believe that future devices will make use of long range BLE for beacons. Since 2021, more cheap microcontrollers have come out that support BLE5 which would offer beacon finding over longer ranges
Supported channels for legacy BLE PDUs
