Apple

All I know for sure is when I write 106KB of data into a 20B write no response characteristic without pauses iOS is sending only 2KB on the air.

On 29 Apr 2014, at 08:26, Tom Tyris Graham <email@hidden> wrote:

In our current implementation we're sending on one characteristic and receiving on another.
We're doing about 200 bytes received in 300ms (so ~670bytes/s or 40kb/m)

Sending is harder to gauge, but sending 160 bytes and then getting a single byte back (ack) takes about ~550ms (that includes the time for our peripheral to deblock the message and respond with an ack). If we compensate for the processing and ack the speed is roughly the same as for receiving.

Supposedly you can send 4 characteristics in a single send which could theoretically improve your throughput significantly, but I'm honestly not sure how this works.

On 29 April 2014 16:47, Nick Brook <email@hidden> wrote:

Thanks for the response.

BLE113 uses TI2541, but using a packet sniffer I found it is iOS not sending the data that is the problem. Using Bluetooth diagnostics I found it gets an error from GattGateway.cpp when the buffer is full, but it is not handled higher up the stack. It is likely the transfer duration is peripheral/use specific as the BLE113 was correctly rejecting the next packet until it was ready, which typically took about 75ms, thus the required pause for ~100ms in my case (I've not tried any closer to 75, but 50 doesn't work). I am therefore pretty sure this is just an iOS CoreBluetooth implementation problem. I reported it as a bug and it got flagged as a duplicate of rdar://16061239. I asked for a suggested workaround and received no response so I guess at this stage the best approach is to simply increase the delay until it works in your use case. Not great!!

Regards
Nick Brook

On 29 Apr 2014, at 00:57, Tom Tyris Graham <email@hidden> wrote:

Hi Nick,
We use BLE to copy files and firmware updates to our peripheral, so we've struggled with getting the throughput up.
One of the very early problems we had was with the peripheral having no fifo on its receive buffer (I think it was the TI CC2540). This was causing it to drop data due to the buffer wrapping if we sent it too quickly.

We're now using a different chip (dual BLE and classic) that doesn't have this problem. From the iOS end we can call writeValue with WriteWithResponse as fast as we need to and we no longer get any data loss.

Regards,
Tom

On 29 April 2014 08:43, Nick Brook <email@hidden> wrote:

After some testing of the suggested 4 writes every 50ms, I can only get it to transfer all data if I do 1 write every 100ms. Any less than that and packets are dropped. This is on an iPad Mini with retina display, iOS 7.1.1, Bluegiga BLE113. 100kb therefore takes over 8 minutes. Perhaps it is something to do with the time taken to handle the data on the peripheral, in my case write to flash.
Nick

On 26 Apr 2014, at 20:14, Nick Brook <email@hidden> wrote:

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

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

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