Add support for extended (>31 byte) BLE advertisements.

[tannewt]

Tested with:

import adafruit_ble
from adafruit_ble.advertising import Advertisement

radio = adafruit_ble.BLERadio()
a = Advertisement()
a.complete_name = "This is a really long name that can only fit in extended."
print("len", len(a.complete_name))
radio.start_advertising(a)

while True:
    pass

extended=True must also be passed to start_scan.

For you @ntoll

[ntoll]

@tannewt it has been almost 20 years since I did any proper C/C++ coding so I'm definitely not qualified to comment on the C code 🤦‍♂️, but thank you for making these changes 👍 . As soon as they land I'll take the latest build and test with the adafruit_radio library.

Question: is there a way to discover if the device is only BLE 4.x (i.e. not extended advertisements) which I could use to ensure the correct check on the length of the message is used in the adafruit_radio library? Alternatively, do the boards upon which you expect the adafruit_radio library to run all support BLE that does support extended advertisements -- in which case, I could safely assume 254 bytes not 31 bytes, right?

[tannewt]

All of the nRF52840 boards support extended advertising. If a board doesn't then it will throw an exception when passed an advertisement that is too long. (255 is the nordic limit rather than the BLE one I believe.)

Builds are available for PRs if you click the latest green check on a commit and look in the top right for the "Artifacts" drop down.

[ntoll]

Related... adafruit/Adafruit_CircuitPython_BLE#33

[dhalbert]

Since extended advertisements are not receivable by peers that don't support this part of Bluetooth 5. I think invisibly switching extended advertising could be confusing ("why isn't the scanner seeing my advertisement?"). There could be a flag permitting extended advertisements, default False.

On the other hand, this is at the _bleio.Adapter level, so presumably the coder knows what they are doing.

I do think any extended advertising provided by adafruit_ble should not be done invisibly, but should be a specific class or flag to an advertisement constructor.

[Currently there merge conflicts, btw, so I won't review right now]

[tannewt]

@dhalbert Are there specific devices you are worried about? iPhones have had BLE 5 since iPhone 8 and iPhone X in 2017. Looks like Google pixels have had them since Pixel 3. I enabled it automatically so that our devices have the best option between them by default.

[dhalbert]

We have four iPhone 6S's in our family :). I don't think we are that unusual.

[ntoll]

For what it's worth, I imagine the clientele of Adafruit are mostly tech savvy and, assuming the differences between BLE4 and 5 and how that effects advertisement length are well highlighted, they'll probably welcome the opportunity to upgrade their iPhones. ;-)

[dhalbert]

Just to be clear, I am not objecting to this PR, but I do think some awareness of creating extended advertisements should be visible in the BLE library.

[ntoll]

I understand, and completely agree with your concerns. 👍 🤗

I think that if there is a flag that either switches on or off extended advertising, libraries higher up the stack (such as the one I've been working on) should be able to detect the state of such a flag in order to adjust accordingly.

In any case, this is going to be very very cool and thanks to you both for your efforts in building this so others (like me) get to do fun stuff with wireless communication. 😄

[tannewt]

I just ate lunch and think we should add length checking to Advertisement. Then, subclasses like AdafruitRadio can set extended_supported=True when initing the superclass.

[dhalbert]

@ntoll Rather than detecting whether extended advertising is on or off, I'm just saying that libraries that include code that might want to use extended advertising should allow that to be turned off. So for instance, it's great if the radio library can use extended advertising, but it would be good to be able to ask the radio library not to use extended advertising, in case one side can't deal with it.

As an example, I have a BT 4.0 dongle plugged into my host computer. I could write a radio library that ran on the host, but I'd want to make sure the radio side on the CPB doesn't attempt to send advertisements I would never see. So there should be an arg on the CPB side of the radio library that suppresses use of extended advertising, and throws an appropriate error if the data string is too long, etc. Am I missing something here?

[dhalbert]

I just ate lunch and think we should add length checking to Advertisement. Then, subclasses like AdafruitRadio can set extended_supported=True when initing the superclass.

👍

[ntoll]

@tannewt 👍

@dhalbert I think we're reflecting the same intention but I need to sleep so probably mangling it. I don't think you're missing something, I'm merely missing clarity of expression. ;-)

I'm happy to use whatever solution you come up with for flagging this feature, and definitely appreciate your work and engagement with this. 👏

[tannewt]

@dhalbert just merged in the latest code. (Almost didn't realize it was my PR. :-) )

[dhalbert]

I just ate lunch and think we should add length checking to Advertisement. Then, subclasses like AdafruitRadio can set extended_supported=True when initing the superclass.

@tannewt So I can accept this and we need a PR to the BLE library? I think that's what you mean.

[ntoll]

OK... once this lands I'll make sure the radio library has a flag (as @dhalbert suggests) to stop using extended advertising with the assumption that the programmer / user knows what they're doing. As always, I'm ears wide open for suggestions, constructive criticism and ideas. 👍

[tannewt]

@dhalbert Yup, think so!

[dhalbert]

👍