Bond to iOS

[Elena]

Hi

I've been able to include Device Manager to bond my peripheral to Master Control Panel, but testing with LightBlue runnining on an iOS 8 iPadI'm having several weird issues.

Everything is apparently correct, until I power off my peripheral or disconnect and reconnect the iPad. Looks that the connection context is not found on the table of previously bonded peripherals. In order to debug the problem, I've included several traces in device_manager_peripheral.c. What I'm detecting is these two issues:

1. The iPad address is changing: When connecting to my peripheral, sometimes the Bluetooth address changes. This could be a problem to look into the table of previously bonded peripheral.

2. The Bluetooth address I save into the bond table is different to the Bluetooth address. Example: When connecting the iPad to my peripheral, I look into the bond table for address 76 173 40 225 245 77. But when linking (or bonding), the address I save into the bond address is 120 130 205 114 224 60. I made the bond procedure in LightBlue by trying to read or write a encrypted characteristic (BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM).

These two problems don't happen in Android or Master Control Panel. So, what's the problem? What's makes iOS so special? Any suggestion??? :-(

Thanks in advance.

Cheers,

Elena

Update: Tags update

[Nikita]

Are you using Master Control Panel for Android or some other application for your tests?

[Elena]

No. I'm using BLE Scanner and B-BLE for my tests. But anyway, I'm not able to see the device advertising from the Android Bluetooth options. When I'm not using the Whitelist (i.e., when no bonded devices are stored), I can see the device advertising from these tools and from the Android Bluetooth options. By the way: I'm using a Nexus 4 and a Motorola Moto G. Thanks again.

[Nikita]

I don't know for sure but maybe it's just different implementations of device discovery functions in iOS (?LightBlue?), Windows (Master Control Panel) and Android (BLE Scanner/B-BLE). When you set your advertising flags to BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED it means that device will have not discoverable discovery mode (BLE_GAP_DISC_MODE_NOT_DISCOVERABLE) that only tells central that it shouldn't consider this device as discovered, but it's up to central application to actually decide either to use this device and show it to you or not.

Maybe Android applications follow the Bluetooth specification and don't show you device with BLE_GAP_DISC_MODE_NOT_DISCOVERABLE flag and iOS/Windows application don't follow specification and show it to you.

You can read about it in Bluetooth 4.1 specification in "9.2.2 Non-Discoverable Mode".

[Elena]

Thanks for your reply. Maybe you're right, but the flag BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED is also selected when using BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE or BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE. I've been trying different combinations of flag in adv_params.fp and AdvertisingInit, but about all of them, or don't work in iOS, or force a reset (probably they're incompatible). :-(

[Nikita]

but the flag BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED is also selected when using BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE or BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE

No, when you set flags like this:

BLE_APP_AdvertisingInit(BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED);

It means this:

BLE_APP_AdvertisingInit(BLE_GAP_DISC_MODE_NOT_DISCOVERABLE|BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED);

because BLE_GAP_DISC_MODE_NOT_DISCOVERABLE == 0x00.