Is there a way for an (iOS) central to know that a peripheral is advertising with a whitelist?

[mrono]

Hi.

I have a product that acts as a peripheral, and bonds with centrals that are typically smartphones. Normally the peripheral uses a whitelist to only connect to bonded peers, but there is also a way to add new peers.

This generally works well, but there is one scenario that is a bit confusing to our users: To add a new peer the user is supposed to press a button to make the device advertise without a whitelist. But if there is another existing bonded peer, on bootup the device automatically starts advertising with a whitelist. Switching between advertising with or without a whitelist is not the issue though.

If the user forgets to press the button, our iOS app can still see that the device is advertising and offers the user the option to connect. But the connection fails because the phone is not on the whitelist. What I'd like to do is only show the user devices that he could actually connect to. I found this old devzone case: device-still-visible-while-advertising-with-whitelist , which does pretty much what I'd like to do. But it is for Android, and as far as I could tell the flags he used to differentiate are not available on iOS.

So is there any way for an iOS app to know that a given connectable peripheral is not accepting new peers? Or some other way to identify which devices should be visible to the user? There are also legitimate cases where the user might have several units to choose from.

If there is no other way then I guess we could add some manufacturer specific data to convey the status, but I'm hoping there is some other supported way.

[Susheel Nuguru]

Hi Markku

I have checked with IOS senior app developer and he confirms that there is no access to BLE flags in IOS. So unfortunately it is not possible to detect this just using the native flags. 

1) One way like you mention is to add some manufacturer specific data in the adv or scan response packet or

2)  Probably you can add new reminder feature in the IOS app, that when central initiates a connection to the peripheral which is advertising with whitelist (current central not on list) then the most likely scenario is that the user forgot to press the button and the app can give a pop up reminding to press the button on peripheral (to switch off the whitelist). if it is a customer who is anything like me, they will be positively surprised by how smart the app is :D

[mrono]

Susheel Nuguru said:

2)  Probably you can add new reminder feature in the IOS app, that when central initiates a connection to the peripheral which is advertising with whitelist (current central not on list) then the most likely scenario is that the user forgot to press the button

Yes, this could be an option as well.

I'm an embedded guy, not an app developer, so I'm a bit uncertain how this case looks like from the app's perspective. I'll talk to our app guys. But I'll just outline my understanding here, and hope that you can correct me if I'm wrong or have missed something.

When this issue happens, from the central's point of view the connection simply times out right? As the peripheral does not respond to the connection request. So the reminder would be a "best guess" of why the connection failed?

So the logic in the app could be something like the following:

• Scan for our devices, show a list to the user
• the user chooses a device we haven't yet  bonded with (can the app tell this?)
• If connection times out, show reminder to press the button

That could work.

One other option I was thinking of, was to try to use the SCANREQ -filter policy like in this case. So basically refuse to respond to scan requests if the central is not on the whitelist. Could the app detect this? And use it to filter out devices using a whitelist? Our device doesn't need the scan response payload, but I could put something in there for just this purpose if that would work.

[Susheel Nuguru]

mrono said:

One other option I was thinking of, was to try to use the SCANREQ -filter policy like in this case. So basically refuse to respond to scan requests if the central is not on the whitelist. Could the app detect this? And use it to filter out devices using a whitelist? Our device doesn't need the scan response payload, but I could put something in there for just this purpose if that would work.

 This certainly can be used as a hint from the peripheral to the central application (peripheral not responding to scan requests not on whitelist) as a hint that the peripheral is not intending to connect to that central. The app could then choose not to display this device at all. This is definitely an option, but then remains the part where few users still be confused as they cannot just remember that they have not pressed the button just because the device is not visible in the list.

 

mrono said:

So the logic in the app could be something like the following:

• Scan for our devices, show a list to the user
• the user chooses a device we haven't yet  bonded with (can the app tell this?)
• If connection times out, show reminder to press the button

 This matches with my idea of a reminder. Those subset of users who forgot to press the button will be reminded about it without infusing too much of confusion.

[mrono]

Susheel Nuguru said:

This certainly can be used as a hint from the peripheral to the central application (peripheral not responding to scan requests not on whitelist) as a hint that the peripheral is not intending to connect to that central. The app could then choose not to display this device at all.

This is very close to the original idea I had, so if the app can actually do this (detect that the scan request was not responded to), then I think we'll try this first.

But the reminder after a failed attempt is also an option. Perhaps we should implement both of these.

Thank You.

[mrono]

In the end we decided to add the whitelist status to a manufacturer specific data packet and place that into the scan response message.

We found other potential use cases where a few bytes of extra status data could be helpful, so the manufacturer specific data turned out to be the best option.