Re: Data loss during BTLE repeated write with CoreBluetooth on iOS

Subject: Re: Data loss during BTLE repeated write with CoreBluetooth on iOS
From: Spero Koulouras <email@hidden>
Date: Tue, 29 Apr 2014 07:59:32 -0700

Here is a clip from a packet trace taken during an over the air download between our peripheral (CC2540-based) and the TI Multitool running on iOS 7.1.1 on an iPod Touch. The was a data transfer of 126976 bytes taking 68 seconds for an effective transfer rate of about 2KBps (16kbps).

The empirical evidence shows an effective "window size" of 4 messages. The master is able to send the next block 334 microseconds after receiving and ACK from the slave. If there is no ACK within ~26ms a block is retransmitted. The trace shown below is representative of the entire 126KB transfer.

For source code see the TI OAD Profile (oad.h, oadtarget.c, oadtarget.h) in the CC2540 SDK which is free to download.

NOTES:

1. Our device implements the "stock" OAD profile. We have not done any performance tuning.

2. This is TI's MultiTool from the app store, unmodified

3. Trace taken with a Frontline BLE Analyzer

4. Writes by Master to handle 41 (UUID 0xfc2) contain the payload blocks with monotonically increasing block id's starting at 0. The total BLE frame size is 44 bytes

5. The upload begins with 9 consecutive writes, BUT, frames 8244-8247 are resends of 8246.

6. As of frame 8248, blocks 0-5 have been written once and block 6 retried three times.

7. The slave starts sending notifications in frame 8248 of BLE frame size 28. Each notification contains a block id ACK starting at 0. Frame 8248 ACKS frame 8232, 8250 ACKS 8234 and so on.

8. As the Master receives these notification it sends out a new block. At frames 8260 and 8271 there are resends occurring with relative long delta times (26ms)

8,232 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.029205 4/29/2014 6:56:05.406671 AM 50656556(S)

8,234 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000693 4/29/2014 6:56:05.407364 AM 50656556(S)

8,236 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.029307 4/29/2014 6:56:05.436671 AM 50656556(S)

8,238 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000693 4/29/2014 6:56:05.437364 AM 50656556(S)

8,240 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000693 4/29/2014 6:56:05.438057 AM 50656556(S)

8,242 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000693 4/29/2014 6:56:05.438750 AM 50656556(S)

8,244 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000693 4/29/2014 6:56:05.439443 AM 50656556(S)

8,246 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000693 4/29/2014 6:56:05.440136 AM 50656556(S)

8,247 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.026535 4/29/2014 6:56:05.466671 AM 50656556(S)

8,248 28 Slave Handle Value Notification 41 Unknown UUID [0xffc2] 00:00:00.000463 4/29/2014 6:56:05.467134 AM 50656556(S)

8,249 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000334 4/29/2014 6:56:05.467468 AM 50656556(S)

8,250 28 Slave Handle Value Notification 41 Unknown UUID [0xffc2] 00:00:00.000463 4/29/2014 6:56:05.467931 AM 50656556(S)

8,251 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000334 4/29/2014 6:56:05.468265 AM 50656556(S)

8,252 28 Slave Handle Value Notification 41 Unknown UUID [0xffc2] 00:00:00.000463 4/29/2014 6:56:05.468728 AM 50656556(S)

8,253 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000334 4/29/2014 6:56:05.469062 AM 50656556(S)

8,254 28 Slave Handle Value Notification 41 Unknown UUID [0xffc2] 00:00:00.000463 4/29/2014 6:56:05.469525 AM 50656556(S)

8,255 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000334 4/29/2014 6:56:05.469859 AM 50656556(S)

8,256 28 Slave Handle Value Notification 41 Unknown UUID [0xffc2] 00:00:00.000463 4/29/2014 6:56:05.470322 AM 50656556(S)

8,257 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000334 4/29/2014 6:56:05.470656 AM 50656556(S)

8,258 28 Slave Handle Value Notification 41 Unknown UUID [0xffc2] 00:00:00.000463 4/29/2014 6:56:05.471119 AM 50656556(S)

8,259 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000334 4/29/2014 6:56:05.471453 AM 50656556(S)

8,260 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.025219 4/29/2014 6:56:05.496672 AM 50656556(S)

8,261 28 Slave Handle Value Notification 41 Unknown UUID [0xffc2] 00:00:00.000462 4/29/2014 6:56:05.497134 AM 50656556(S)

8,262 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000335 4/29/2014 6:56:05.497469 AM 50656556(S)

8,263 28 Slave Handle Value Notification 41 Unknown UUID [0xffc2] 00:00:00.000462 4/29/2014 6:56:05.497931 AM 50656556(S)

8,264 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000335 4/29/2014 6:56:05.498266 AM 50656556(S)

8,265 28 Slave Handle Value Notification 41 Unknown UUID [0xffc2] 00:00:00.000462 4/29/2014 6:56:05.498728 AM 50656556(S)

8,266 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000335 4/29/2014 6:56:05.499063 AM 50656556(S)

8,267 28 Slave Handle Value Notification 41 Unknown UUID [0xffc2] 00:00:00.000462 4/29/2014 6:56:05.499525 AM 50656556(S)

8,268 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000335 4/29/2014 6:56:05.499860 AM 50656556(S)

8,270 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.000693 4/29/2014 6:56:05.500553 AM 50656556(S)

8,271 44 Master Write Command 41 Unknown UUID [0xffc2] 00:00:00.026119 4/29/2014 6:56:05.526672 AM 50656556(S)

Spero Koulouras (408) 874-6331

On Tue, Apr 29, 2014 at 3:00 AM, Tom "Tyris" Graham <email@hidden> wrote:

We're using long on device -> phone, but short (20) on phone -> device.
Have you tried using withResponse? It's possible that withResponse is causing iOS to slow down its sends based on confirmation of the received data.

I'm afraid my bluetooth LE knowledge is rather lacking; so at most I'm only really able to provide you with anecdotes about my own experiences.

On 29 April 2014 19:36, Nick Brook <email@hidden> wrote:

Are you using a long characteristic (>20 bytes)? Perhaps the iOS buffer is limited by number of writes not size, and so will send successfully if writing more data fewer times.

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

_______________________________________________
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

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>)
	>Re: Data loss during BTLE repeated write with CoreBluetooth on iOS (From: "Tom \"Tyris\" Graham" <email@hidden>)

Prev by Date: Re: iBeacon changes from 7.0 to 7.1.1
Next by Date: Re: Data loss during BTLE repeated write with CoreBluetooth on iOS
Previous by thread: Re: Data loss during BTLE repeated write with CoreBluetooth on iOS
Next by thread: Re: Data loss during BTLE repeated write with CoreBluetooth on iOS
Index(es):
- Date
- Thread