Receiving large amount of data in android via BLE

[Artucas]

Hello everyone, recently i was trying to figure out the best way how to send a large amount of data from ble peripheral to the central (Android device in this case) and thanks to great posts here i found the answer. Now im also doing the part for the android device and since i couldn't find any example here, maybe someone who understands Android could share what is the best way to receive the large amount of data? How to manage the data stream that is coming from the peripheral device if its total size will be someone near 100kB?

Edit: 2016-11-21

So i ran some tests today and this is what i get. When i connect with my phone i see that connection parameters are as follows: initphoneparams.png. When i use MIN_CONN_INTERVAL MSEC_TO_UNITS(7.5, UNIT_1_25_MS) and MAX_CONN_INTERVAL MSEC_TO_UNITS(40, UNIT_1_25_MS) i can see connection params update request after connection has been actually established: paramsupdate2.png. If i force both MIN_CONN_INTERVAL and MAX_CONN_INTERVAL to MSEC_TO_UNITS(7.5, UNIT_1_25_MS), i am also seeing conn params update request after establishing the connect: paramsupdate1.png.

Both ways you can see that i get connection parameters update response accepted (one packet below than the one i am looking to the data).So i can be sure that my device did update connection parameters, correct?

No for the question that i had to check? Is there a way to see in the software how much packets does actually my peripheral send in one connection interval? Or i just have to look at the times that packets are received and calculate how many packets was send in a certain time? Because looking at the times i would say that when both min and max connection interval is set to 7.5ms i am seeing 2 - 3 packets in one connection event, but that number is not consistent. I also see a packet loss. If i set min connection interval to 7.5ms and maximum connection interval to 40ms, i am seeing 2 packets per connection event. Could you watch through my wireshark logs and confirm that what i am seeing is correct?

So am i really seeing the limitations of my central device here? I also want to ask, if i set min connection interval to 7.5ms and maximum connection interval to 40ms, does that really guarantee maximum throughput for every central?

And also what will happen if i set both connection interval to 7.5ms and maximum connection interval to 7.5ms on my peripheral, but my central does not support this value? Will peripheral just drop the connection? And here are my wireshark logos. max40min75.pcapng and max75min75.pcapng.

Sorry for bad naming also, but the first one is with max conn interval 40ms and min conn interval 7.5ms. Second one is with both min and max conn interval equal to 7.5ms

[Eliot Stock]

I'd start with Nordic's DFU library for Android:

github.com/.../Android-DFU-Library

Find the classes in there that send the application/sd/bootloader image over the air from central to peripheral. You have the reverse situation: you'll be reading from a characteristic repeatedly, not writing, but perhaps you can turn their code around a bit.

100 kB / 20 bytes per characteristic read = 5,120 reads. It'll take a while.

[Hung Bui]

Hi Artucas,

How did you find your number of packets per connection event from the log ?

What I can see in your log, is that with max40min75 you got 37,5ms as the actual connection interval, and you have 6 packets per connection event (check the number of packets on same channel) and with max75min75 you have 7.5ms as actual connection interval and you have 3 packets per connection event.

So actually you have higher through put with the 7.5ms min=max setting. Note that if the central has more than 1 connection, setting your connection at 7.5ms may affect other connection as the radio is occupied quite a lot.

Some central will reject your request of 7.5ms min=max. In that case, the best way is to automatically increase the max value (say +5ms) and try again until you reach the value that the central accept. The connection won't be drop if the central reject the request, unless the peripheral does it itself.