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.

[Artucas]

Thank you for the answer Eliot. I took a quick look and maybe it was what i was looking for. I am voting up your question for now, will mark this as an answer in a few days if i won't find anything better :)

[Hung Bui]

Actually it's not the same. On our DFU library, we sending data from Android side (central side), using write command. What Artucas asked for actually the opposite way, sending data from nRF5 to Android.

But I don't see any problem there. The data rate from BLE is pretty slow, around 128kbps max. You should have no problem store them in a buffer and update to a file concurrently.

[Artucas]

Yeah i know it is not the same, but i am looking at that example and trying to reverse it and to reading instead of writing :) Thank you for your comment Hung Bui. I'll mark this as answered as soon as i achieve this.

[Artucas]

Well i have done some test on my android device and i have a question know, i won't make another post because i think these two are related questions actually. If for the peripheral devices i set MIN_CONN_INTERVAL MSEC_TO_UNITS(7.5, UNIT_1_25_MS) and MAX_CONN_INTERVAL MSEC_TO_UNITS(40, UNIT_1_25_MS) , the speed i get with my android device (Samsung galaxy J5) is about 3.2 kB/s . If i set both MIN_CONN_INTERVAL and MAX_CONN_INTERVAL to MSEC_TO_UNITS(7.5, UNIT_1_25_MS) then the speed i get with the same device is 8kB/s. It is actually still two times less than the maximum of 16kB, if my device supports 6 packets per connection event, correct? So does this actually mean, that my device supports maximum 3 packets per connection event? And another question, how does master actually choose the connection parameters, i mean, why when i set 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 get smaller throughput than then if i set both to MSEC_TO_UNITS(7.5, UNIT_1_25_MS)? I mean i am forcing this way the central to use 7.5ms connection interval, right? But is this appropriate? I mean, definately not every device can support 7.5ms connection interval, so i'd like some clarification on this, what i am doing wrong here, or it is just that i reached my device physical limitations and how does central decide what connection parameters to choose?

[Eliot Stock]

OK, what I'd do next is find out what connection interval is actually being used. You can do this by setting a breakpoint or adding logging in on_ble_evt() when it gets the BLE_GAP_EVT_CONN_PARAM_UPDATE event. Or just set up Wireshark with the Nordic dongle and sit the dongle in the middle between peripheral and central and have a look at the packets. I think maybe the central ends up dictating this, but it's been a while since I looked at it.