Re: BLE packet loss
Re: BLE packet loss
- Subject: Re: BLE packet loss
- From: Mark Palatucci <email@hidden>
- Date: Mon, 27 Aug 2012 17:39:43 -0700
Hi Aleksandar,
I am having the same issue and I was just about to post this to the forum when I saw your message.
If I call peripheral:writeValue multiple times in a row, then after about 30 writes, I will start to experience packet loss. If I turn on the "CBCharacteristicWriteWithResponse" key for writeValue, then I will get the callback, "didWriteValueForCharacteristic". For the first 30 writes or so, this callback gives no error, but then I will receive errors with code = 0 and the messages are dropped. Unfortunately, this error code doesn't appear documented in the CoreBluetooth docs, but this is the NSLog:
2012-08-24 12:12:21.703 RushHour[1611:707] **didWriteValueForCharacteristic: @<CBConcreteCharacteristic: 0xa97b60>, Error: @Error Domain=CBErrorDomain Code=0 "The operation couldn’t be completed. (CBErrorDomain error 0.)"
Now this is really a bad behavior and arguably a bug in the CoreBluetooth API. I wrote a message queue layer that will queue up messages, and then send them to CoreBluetooth one at a time: specifically, it will send the first message, and it will send the next message through a dispatch_async after getting the didWriteValueForCharacteristic of the previous one.
Unfortunately, this doesn't fix the problem - waiting for the callback before sending the next message had the same failed behavior. Our guess is that CoreBluetooth is calling this callback after it hands the message to the lower level portions of the messaging stack, and not when message actually goes out. We believe this because it still appears there is an overflow of some lower level - and that's why the write fails. To deal with this, we had to explicitly add a delay to each additional message through a dispatch_after.
I really think this is a bug in the API because:
1) the App layer shouldn't have to create it's own queue and put specific timing information to ensure delivery or that lower-level OS buffers are being drained.
2) CoreBluetooth returns that a write was successful before it has really occurred. Even though the callback is called, the lower-level buffer may not actually have space, and the next write may fail.
3) there is no way to query the CoreBluetooth API to determine if a write is possible
4) If a write fails, it fails with an undocumented error code=0.
I'm filing a bug on problem - right now we're dealing with this by doing a dispatch_after with a small (~30ms) delay, which works for our application but makes me nervous. The alternative is to just resend the message if the write fails, but this also makes me nervous because the error code is undocumented, and it's not clear what the state of the CoreBluetooth framework is...
Advice from the Apple folks on the best way to handle this given the CoreBluetooth implementation would be most appreciated.
-Mark
On Wed, Aug 22, 2012 at 2:18 AM, Aleksandar Mihailovski
<email@hidden> wrote:
Hi,
We've been testing the max data transfer from the iPhone to the BLE device (int this case csr1000) and noticed that if we send a lot of packets in a short time interval packet loss occurs (which is to be expected).
My question is, does this happen because the iPhone is unable to send the packets or does the receiving side is unable to handle all those packets in a short period (one packet is 20 bytes).
Also, is there a way to test this (like a BLE sniffer application that can be used with the CSR USB dongle) ?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden