Re: Data loss during BTLE repeated write with CoreBluetooth on iOS
Re: Data loss during BTLE repeated write with CoreBluetooth on iOS
- Subject: Re: Data loss during BTLE repeated write with CoreBluetooth on iOS
- From: Nick Brook <email@hidden>
- Date: Sat, 26 Apr 2014 20:14:31 +0100
* Use write without response as it's much faster than waiting for a
response on every block of data sent
* send four blocks, then sleep for a tenth of a second, and repeat until
all data is sent.
* send the block index with your data so your BTLE device can determine if
it receives any blocks out of order
* have your iOS app subscribe to notifications on a "restart sending at
block N" characteristic
* if BTLE device receives any block out of order have it notify "restart
sending at block N" which your iOS app is listening to, this will allow you
to have the iOS side backup to the index requested by the BTLE device.
"In-order sequencing is guaranteed by the lower layer.”
So if packets are out of order, surely that’s a bug with CoreBluetooth?
Does it specify somewhere in the docs that you should only perform 4 write operations every 30ms? Surely this should be handled more gracefully by the framework, for example like peripheralManagerIsReadyToUpdateSubscribers: on CBPeripheralManager:
When a call to the updateValue:forCharacteristic:onSubscribedCentrals: method fails because the underlying queue used to transmit the updated characteristic value is full, theperipheralManagerIsReadyToUpdateSubscribers: method is invoked when more space in the transmit queue becomes available. You can then implement this delegate method to resend the value. |
_______________________________________________
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