Central is getting error reponse for write request if Peripheral respond back a little late

Question

I have been using CoreBlueTooth framework to communicate between BTLE iOS devices and I see a strange behavior. Here is what I am doing:

iOS device 1 (Peripheral): Expose a writable characteristics.
iOS device 2 (Central): Scan for the writable characteristics and write data into it.
iOS device 1 (Peripheral): Receives write request. Wait for some time to acknowledge the receipt of data.
iOS device 2 (Central): Get a callback on the below delegate and received the mentioned error.

Issue: Here if I respond back to the write request in few seconds by calling the API [iPeripheral respondToRequest:iRequest withResult:iStatus] then it all works fine and I get a success on my Central. But if I take some time, even if my Peripheral has not responded to the write request, I get error response back.

Is this some kind of connection loss in few seconds or the known CB framework behavior, any idea?

- (void)peripheral:(CBPeripheral *)iPeripheral didWriteValueForCharacteristic:(CBCharacteristic *)iCharacteristic error:(NSError *)iError 

Error Domain=CBErrorDomain Code=0 "Unknown error." UserInfo=0x183a6d70 {NSLocalizedDescription=Unknown error.}

Both my Central and Peripheral are running on iOS 7.0.

When you say "if I respond back to the write request in few seconds", you're referring to step 3, on the peripheral side, correct? — cbowns
@cbowns Yes. If I execute step 3 immediately then it all works fine. — Abhinav
@cbowns Its just human negligence. When I receive the data on Peripheral, I throw an alert to user to which user will either press "Accept" or "Ignore". If user takes time to respond then somehow error is responded back to Central by framework. — Abhinav
Gotcha. You'll probably want to restructure that, given this issue, to have a separate characteristic on the peripheral that reports back the user's choice. — cbowns

Etan Etan · Accepted Answer · 2013-10-26T11:35:21

I also observed this problem when I had deadlocks in my code and couldn't respond in time ;-) The way I observed it, iOS responds with an automatic error request with an arbitrary error code if a request is not answered within 10 seconds. I have not found a way to change this, but it makes sense from a protocol perspective.

In Bluetooth Low Energy, a central can only send a single Characteristic Value Write Request at a time. After it has sent this request, it cannot send a different Write Request unless the first one is responded to. Therefore, it is crucial to always respond to requests as fast as possible.

In the comments, you mentioned that you are waiting for user input to affect the result code you want to send to the central. I guess "Success" if the user confirms in the UI that an operation should be started, and an error code if the user denies that. This is not the way an LE based protocol should be designed. It's like blocking the UI thread until an operation is finished, just from the other side. You are effectively blocking the BT communications until a blocking operation (waiting for user input) completes.

A different design would be to send a write request to the other phone, responding immediately with a "Success" error code to indicate that the request was received and the popup is displayed. Then, send a Characteristic Value Indication with the user's choice from the peripheral to the central.

There's one small caveat if you target iOS 6: indications don't work nicely in many cases (reentrancy bugs etc, best not touch them). There, you should send a Read Request from your central and return the user's choice in this read request if it's already available. Again, don't block while giving the answer, sending back a "user is still choosing" value back if the answer is not yet ready.

Single rule: Answer requests as fast as possible. It's the way, Bluetooth LE is designed to work.

Central is getting error reponse for write request if Peripheral respond back a little late

3 Answers