Apple

On 24 Apr 2014, at 15:50, email@hidden wrote:

* 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.

I thought packet order was guaranteed by the Bluetooth stack, from https://en.wikipedia.org/wiki/Bluetooth_protocols#Logical_link_control_and_adaptation_protocol_.28L2CAP.29

"In-order sequencing is guaranteed by the lower layer.”

Yeah I think you're right. The sequence numbers and NESN should be ensuring packets are sent/received in order.

So if packets are out of order, surely that’s a bug with CoreBluetooth?

That could be. I'd bet that we were a bit overly cautious early on when we saw issues and were still ramping up on Bluetooth. It was more likely a misunderstanding on my part that led to that implementation than a bug in CoreBluetooth.

Does it specify somewhere in the docs that you should only perform 4 write operations every 30ms?

Not that I'm aware of. When using the CC254X family it is the maximum you'll get since there is an 80 byte limit on user data that can be transmitted per a connection interval, AFAIK. So if you're sending the 20 bytes per packet then you get 4 packets. We are using CC2540/CC2541 chips so it's been applicable in my situation.

See verified answer from TI employee here: http://e2e.ti.com/support/wireless_connectivity/f/538/t/208288.aspx

Also, this is mentioned in the study on BTLE using TI CC2540: http://www.mdpi.com/1424-8220/12/9/11734

Additionally, in Nordic's forums their employees have also mentioned that in their experience Android devices seem to be limited to ~4 packets per interval although some of the nordic chips can support more than that. Reference: https://devzone.nordicsemi.com/index.php/how-do-i-calculate-throughput-for-a-ble-link

I'm not sure what the iOS limit is. Based on additional discussions in this thread it sounds like you've done more digging there than I have so I'll refer to what you've seen.

To clear up any confusion, it seems the packets per connection interval is limited by either CoreBluetooth implementation or the chip in use, whichever is worse. Using smaller packet sizes may allow for more packets per connection interval (like in the case of the TI CC254x chips which are limited to 80 bytes per connection interval) but you can't achieve more data throughput.

As with everything, YMMV, test and find a combination that works well for your ecosystem of chips and devices.

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.

Maybe this comes into play when your iOS device is acting as the peripheral but I don't see where this method comes into play when your peripheral is a not an iOS device. I'm testing with iOS as central and CC254X devices as peripherals. Or maybe I'm missing what the connection you're seeing.

References:
	>Re: Data loss during BTLE repeated write with CoreBluetooth on iOS (From: Nick Brook <email@hidden>)