Core Bluetooth - scanning for extended advertising issues

I'm also curious to see if someone can comment on whether there are any devices which support extended advertising and can point to some example that shows this. At the 2019 WWDC they claimed it could but I have yet to see an Apple device that does...

From 2019 WWDC:

Advertising extension is a Bluetooth 5.0 feature. It essentially improves upon three main points for advertising. The first is it eases the congestion on the three advertising channel by sending a smaller payload on the advertising channel, then jumping to the more spacious data channel to transmit a much larger payload. Up now from 31 to 255 bytes, and the transmission rate itself can now be in LE 2 Mbps. Core Bluetooth will support extended scan this year.

This means that we can scan now for the extended advertisements that I've just mentioned, but we will only scan for our extended advertisements that are transmitted in LE 2 Mbps.

So, if you're developing an accessory, your accessory must also support extended advertisement with LE 2 Mbps. We now support extended advertisement payloads up to 124 bytes. This is four times the amount of advertisement data that an accessory can send us today. This is again transparent to your application.

You can use the same scan API, scan filters. We would scan for both legacy and extended advertisements. There's a new API for you to programmatically query for platform support, and this is now supported on iPhone XS and the new iPad Pro.

It's not clear to me how extended advertising will work here, since LE 2M is, by specification, supported only in the Secondary Advertising channel (Bluetooth Core Specification version 5.2, Vol. B, Section 2.3, Table 2.3, page 2,871).
Does this mean a peripheral must Advertise a 31 byte packet in LE 1M with an invitation to switch to LE 2M to get the extended advertisements?
Will Apple eventually support coded PHY?

I can verify the 'will it or wont it?' questions in the original post, and answers to date:

Indeed there is support for BL 5.0 Extended Advertising Support in iOS.

The way I deduced this is that I wrote the code in Android, and broadcast advertisements using that from a Samsung 20+, and in my iPhone 12 Pro, I downloaded the nRF Connect app, and was able to receive the Bluetooth 5.0 advertisements there.

Here's the Android code that demonstrated the capability in the Android (the actual extended advertising code is about 30 - 40 lines long), and all of the following variables returned true:

Code Block 
// Android Code
            var IsLe2MPhySupported = bluetoothAdapter.IsLe2MPhySupported;
            var IsLeCodedPhySupported = bluetoothAdapter.IsLeCodedPhySupported;
            var IsLeExtendedAdvertisingSupported = bluetoothAdapter.IsLeExtendedAdvertisingSupported;
            var IsLePeriodicAdvertisingSupported = bluetoothAdapter.IsLePeriodicAdvertisingSupported;
            var IsMultipleAdvertisementSupported = bluetoothAdapter.IsMultipleAdvertisementSupported;
            var IsOffloadedFilteringSupported = bluetoothAdapter.IsOffloadedFilteringSupported;
            var IsOffloadedScanBatchingSupported = bluetoothAdapter.IsOffloadedScanBatchingSupported;

and here is the PHY code (again, Android):

Code Block 
            byte[] bytes = Encoding.ASCII.GetBytes("The quick brown fox jumped over the lazy dog"); // Bytes:  54 68 65 20 71 75 69 63 6b 20 62 72 6f etcetera
            var uuid = new Android.OS.ParcelUuid(Java.Util.UUID.FromString("6bf6b447-63a8-4cea-81bd-15d87f3b3e43"));
            var parameters = new AdvertisingSetParameters.Builder()
                    .SetLegacyMode(false)
                    .SetInterval(AdvertisingSetParameters.IntervalHigh)
                    .SetTxPowerLevel(AdvertiseTxPower.Medium)
                    .SetPrimaryPhy((ScanSettingsPhy)Android.Bluetooth.BluetoothPhy.Le1m)
                    .SetSecondaryPhy((ScanSettingsPhy)Android.Bluetooth.BluetoothPhy.Le2m);
            AdvertiseData data = new AdvertiseData.Builder()
                        .AddServiceData(uuid, bytes)
                        .Build();
            advertiser.StartAdvertisingSet(parameters.Build(), data, null, null, null, new AdvertisingSetCB());

The great thing is that I received the data in the iPhone nRF Connect app, that the Android code advertised: it is reasonable to assume that if the nRF Connect app can do it, that the code exists so that we can write the same functionality ourselves.

So yes, iPhone is capable.

Unfortunately the Apple API documentation is older than when the Bluetooth 5.0 specification was printed, so I haven't been able to replicate the Android behaviour on iOS, however I posted this to both encourage people, and at least to alert people to the proof that they are on the right track.

Does anyone have some actual code?

My understanding is that BL 5.0 will advertise up to 255 bytes, however in the most basic mode, the bytes cannot be changed once advertising begins. The Bluetooth specification does allow another mode to allow the advertised data to be updated, and that is the code that I am in particular looking for.

Just imagine that the latitude and longitude are in the data that are being advertised, and that the device's position is changing ... I'm interested in being able to modify the bytes in real time, as the position changes!

Kind regards!

I believe the reply from anthony@HarrisonOfTheNorth.com brings one important fact, and I will add another one - only very recent models of iPhone devices seem to have the Bluetooth 5.0 features active (at least at this point).

I was hoping that Apple will step up and extend the Core Bluetooth API and documentation with everything needed to properly implement all features, ideally including not only LE 2 Mbps but also LE long-range.

Is there any good way to reliably look this up using the Bluetooth SIG Launch Studio ICS details published for every device? For the iPad Air example, Declaration ID: D034810 describes that device, and the referenced QDID: 115456 for the Controller subsystem and Low Energy Link Layer has the extended scanning feature selected/checked. However, per the OP, that device does not support extended advertising when programmatically asking iOS about it. I assume this means the Host subsystem (iOS) doesn't support it, but the Controller subsystem (radio hardware) does (?)....

When trying to find an equivalent feature in the Host subsystem, I am not finding what I would expect given anecdotal evidence from anthony@[site].com in the previous comment.

Anyone been able to verify if iOS 15 has any underlying support for Coded PHY?

The world of BLE 5.x is strange:

• Apple

  • I believe iPhone's above 8 have to capability to scan for "Advertising Extension" - someone correct me if I am wrong (I only have a iPhone 8 on my desk for testing)
  • iOS15.x still doesn't have Coded PHY for long range (Also it seems very hard to place permanently in the background)
  • Setting an "Advertising Extension" with coded PHY at an interval of say 5 seconds does not eat into the battery life (tested on an Android over a 24 hr period) - well it is BLE after all...

• Google

  • Pixel phones can't scan for "Advertising Extension" with Coded PHY- seems like a long running bug and its even in the newer gabeldorsche code base
  • Most other newer Android phones can scan for "Advertising Extension" with Coded PHY
    • Eg. phones OnePlus 7 and above, Galaxy Tab A7, Galaxy S10 and above, Xiaomi Poco X3 NFC seem to be working fine with Coded PHY scanning.
  • Android "Adverting Extension" transmission (including Pixel) is working on all devices (well from the last 2-3 years)

With this situation its impossible to write an App across platforms that can trigger our product at longer range ;-)