Hello!
I'm working on a mobile app that communicates with a peripheral via Bluetooth with security level 2 in a customised way, as there are also other communication protocols used.
We use a bluetooth service with a specific UUID that has a write characteristic for sending data to the device and a notify characteristic for receiving data from the device.
After connecting for the first time, a pairing prompt appears after successful connection and subscribing to notifications.
When all is set, that is notifications are enabled, a handshake is performed and a communication session is established. There can be only one session for a bluetooth connection.
So I have two questions:
- Regarding the pairing, is there any way that I can know the result of the pairing, so that I could start the handshake after it is accepted? What could be the best approach here? Asking because I noticed some instability on first connection (peripheral ignoring handshake).
- After disconnecting using Core Bluetooth, the system maintains the connection for some time before actually disconnecting. When opening the app shortly after killing the previous instance, it gets connected very quickly as it reuses the existing connection. The problem is, however, that the device wouldn't accept the new handshake and it is pretty much impossible to reuse previous session. In our use case we need a new BLE connection for each session. Is there any way I could forcibly disconnect from the device or enforce a new connection (not a reused one)? What might be the best approach here?
The way I handle it now is by using retrieveConnectedPeripherals and if the device is found to be connected, I use scanning. If the device is advertising then we know it's not connected. Other than that we could also poll retrieveConnectedPeripherals and wait. But obviously it is not optimal, as the user has to wait longer than ususal.
Other than that retrievePeripherals is used for getting the peripheral, if the app once found it during scanning.
I saw this post describing similar issue, is it the only solution to implement API for disconnecting on the peripheral side?
There really isn't an API to force a disconnection from the application level, as the CoreBluetooth API is quite abstracted from the controller level, so the the solution suggested in the other post (sending a command to the accessory for it to close the connection) is all I have in my box of tricks (as it was also I, who suggested that in the other post).
The retrieveConnectedPeripherals trick could work, but I believe it will suffer from the lag between the framework and the HCI, which is what I think you were referring to about the longer wait.
As for detecting the result of the pairing request, there also isn't a way to detect how that went. But you would know if the pairing was completed if you tried to read from a encrypted characteristic and was successful.
If you tried to access the encrypted characteristic right after connection, if the device are not paired, that will trigger the pairing procedure. If the pairing is successful, you will be able to access the characteristic. Otherwise, it will fail.
And that tells you the result of the pairing.
Argun Tekant / DTS Engineer / Core Technologies
