Closed warasilapm closed 9 months ago
Do you have a screenshot of this?
Pinging @philips77 as well.
Sorry for the blocking out of yet to be released information.
Essentially, our device currently has a 1-byte multiplexer at the start of any manufacturer specific data field. The 0x1e
multiplexer and its data is sent in the periodic advertising data after the advertising flags field. There is also a manufacturer specific data field with a multiplexer of 0x1f
which is sent as part of the scan response data before the device name field. In previous versions of iOS, the 0x1f
and its data was concatenated onto the end of this string in both our developing mobile application and the nRF Connect app (which I use for reference when developing the firmware side). In iOS 16.4.x, however, this no longer seems to be the case and only the MSD field from the periodic advertising seems to be passed up to the application.
Interesting. I also feel humbled that you're using nRF Connect for reference :)
Apple definitely has been making changes to the BLE stack since iOS 16, like 16.0 and 16.1 I think (or maybe 16.1 restored previous behaviour?) were heavily enforcing their recommended connection parameters, as the Mac does. They must be working on something BLE related, maybe LE Audio? But they haven¡t done any sessions on Bluetooth since 2019 I think. You can use nRF Connect for Android to verify your manufacturer data changes, then. The API on that side of the pond provides better access and you shouldn't have these issues, if one is available to you. Or, you may try to run nRF Connect on an Apple Silicon Mac - not sure if this filter will be applied there or not.
Luckily we hadn't run into any iOS BLE related issues up until 16.4 despite the changes they're making. Our Android app has been working just fine but, realistically, if iOS doesn't allow us to use this kind of approach, only supporting Android isn't really an approach we can use. I guess I will have to design around this for now?
So I decided to try putting both of our multiplexed MSD fields in the periodic advertising packet and it looks like iOS only returns the second one in the order of the advertising packet itself. Very strange.
Hi, i would like to add my thoughts. nRF connect indeed does not show scan response data, only manufacturer data from advertisement data. I installed another app on iOS called ble hero and it shows all the data concatenated together as intended. Attaching screenshots for confirmation
@primus192 I'll try to ask tomorrow if any of our nRF Connect SDK samples can easily reproduce this. Do you know of any sample I can use to test? I trust your word that we're missing the Data, I just need some firmware that I can run to write the code that's missing :)
We think we've fixed this for version 2.7.2, so I'm going to mark it as close for now. Let us know if you still find this issue after 2.7.2 ships.
In previous versions of iOS, the manufacturer specific data fields in the advertising data and scan response data appears to have been concatenated together. However, in iOS 16.4, only the MSD in the periodic advertising data is displayed.
Was there a change to the BT API in iOS that needs an update to the app to be made or is this a bug in iOS 16.4 specifically?