• State Not Answered
  • Replies 19 replies
  • Subscribers 73 subscribers
  • Views 11193 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 117714
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    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.

  • 0 in reply to Eliot Stock

    It's various from central to central, some central prefer a connection interval. Some central won't accept your request of both max and min interval to 7.5ms. It may reject the connection parameter request. Note that you need to send the connection parameter request, otherwise the central won't know ab what you want (yes you have the preferred parameters but as far as I know, not many centrals really read and use it).

    As Eliot all ready suggested, you can try to use a sniffer and have a look. It's important that you can get more notification in one connection event. It can be 6 or even more if you use longer connection interval and with certain central. Many central only support 4 packets per connection event. Make sure you call the _hvx() command as much as possible till the buffer is full, and call again when you have TX_COMPLETED event.

Reply
  • 0 in reply to Eliot Stock

    It's various from central to central, some central prefer a connection interval. Some central won't accept your request of both max and min interval to 7.5ms. It may reject the connection parameter request. Note that you need to send the connection parameter request, otherwise the central won't know ab what you want (yes you have the preferred parameters but as far as I know, not many centrals really read and use it).

    As Eliot all ready suggested, you can try to use a sniffer and have a look. It's important that you can get more notification in one connection event. It can be 6 or even more if you use longer connection interval and with certain central. Many central only support 4 packets per connection event. Make sure you call the _hvx() command as much as possible till the buffer is full, and call again when you have TX_COMPLETED event.

Children
No Data
Related
Terms of service