Apple

I had similar approach as Zach's.

But Zach's estimation of time sounds incorrect:

Total time = ( 130 * 1024 /20Byte ) * 0.1 second = 665 second = 10 minutes,

which matches our experimenter ( transfer 200 KB takes us 15 minutes)

On iOS 6.0, the connection interval is about 30 ms, so you can transmit four write w/o

response in every 30ms, it takes about

(200*1024/(20*4)) *0.03 = 76 second to transfer 200KB

On iOS 7.0 of some devices (iPad Air), there is an iOS bug that only allows one write every 30 ms,

if you still send four writes every 30ms , it will data lost

I filed bug to Apple and later confirmed that it is fixed in iOS7.1

From: email@hidden
Date: Thu, 24 Apr 2014 10:07:33 -0400
Subject: Re: Data loss during BTLE repeated write with CoreBluetooth on iOS
To: email@hidden
CC: email@hidden

On Fri, Apr 18, 2014 at 3:02 PM, Nick Brook <email@hidden> wrote:

I have reported these issues as rdar://16607279 and rdar://16607347 but I wondered if anyone here has any advice on these issues.

What I’m trying to do:
Send 100KB to a BTLE peripheral in 20B chunks on a write without response characteristic. Data transfer is bounded by start and end values written to a write with response control characteristic

Write control start
On write response, write 20B chunks in a loop to the write without response characteristic
When all data is sent, write control end

Code for sending data:

NSInputStream *is = [NSInputStream inputStreamWithURL:self.updateFile];
uint8_t buffer[OTA_MAX_BUFFER]; // 20B buffer
NSInteger bytesRead;
NSInteger totalBytesRead = 0;
[is open];

while((bytesRead = [is read:buffer maxLength:OTA_MAX_BUFFER])) {
totalBytesRead += bytesRead;
if(totalBytesRead > OTA_MAX_DATA) {
[self writeUpdateControl:ATPeripheralUpdateControlCancel];

[self failUpdateWithError:ATPeripheralUpdateErrorDataTooLarge];
return;
}
[self.peripheral writeValue:[NSData dataWithBytes:buffer length:bytesRead] forCharacteristic:self.updateDataCharacteristic type:CBCharacteristicWriteWithoutResponse];

}
[is close];
if(totalBytesRead == 0) {
[self writeUpdateControl:ATPeripheralUpdateControlCancel];
[self failUpdateWithError:ATPeripheralUpdateErrorCouldNotReadFile];

return;
}
#if logDebug
NSLog(@"Wrote OTA data, %ld bytes", (long)totalBytesRead);
#endif

What happens:

Monitoring the data sent by iOS with a packet logger, large chunks of data are not sent. Approx 2KB is received by the peripheral
At the moment the control end characteristic is sent, writes on the write no response data characteristic is halted and no more packets are sent. A CBUnknownError is thrown for the control characteristic

IIRC you can only perform 4 writes within a connection interval. If you're writing this 100kb data within a loop and using write without response then this may explain why you're a large amount of your data isn't being sent. You may be trying to send it all too quickly.

Workaround:
Looking at the packet logger data, duration between successful 20B packet writes is 75ms, so adding a pause of 100ms between write calls allows all data to be sent

Pausing for another 1s after last write before control end results in successful write

Here's a solution that has worked well for me:

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

This takes about 75 ~ 90 seconds to reliably send 130kb for us.

Hope this helps,

--
@zachdennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

_______________________________________________ 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