Multiple packets per connection interval - s132/IOS

[Chris]

Target - NRF52832 populated on a custom PCB using SDK 14.0.0 and s132 5.0

Background - end device will be used to send logged IMU data to the cloud via a smart device, 2-3mB expected to be sent at a time

Looking for a bit of help to increase the throughput using an IOS master (or really any device, but I'm currently using an iphoneSE). I'm running a lightly modified version of the peripheral ble_app_uart example - no UART functionality is now used, I am simply sending dummy data to evaluate throughput. Data length is successfully negotiated to 182 bytes. Connection interval is confirmed at 30ms. I am sending 182 byte packets (using ble_nus_string_send) upon every receipt of BLE_GATTS_EVT_HVN_TX_COMPLETE. Reviewing a log of packets received on the iphone (using lightBlue), I am predominately seeing a packet sent every ~30ms, with occasional packets separated by a few milliseconds. This results in a functional throughput of about 7kB/s.

I expected (hoped) that I would see multiple packets received within that 30ms window.

My questions:

1. I've read that the connection interval can be dropped to 15ms with iOS devices - can you provide guidance with regards to the best way to complete this. I attempted to negotiate after a connection was made (using ble_conn_params_change_conn_params), but the 30ms interval was maintained. I understand that it may be better to stick with a longer connection interval given the bigger packet size (and assuming I can get to 6 or 7 packets per interval), but if I am limited to fewer packets per interval, a shorter connection interval would be better.

2. What might be limiting me to 1, occasionally 2, packets per interval? Should I be attempting to send more frequently than waiting for BLE_GATTS_EVT_HVN_TX_COMPLETE?

Any help appreciated, I have searched, and turned up a number of good threads that have helped me get this far, but I think I've hit a bit of a wall.

-Chris

[Hung Bui]

Hi Chris,

If you have a look at this presentation, you can find information about the 15ms firmware update mode and the estimated through put on new iOS (v11.x I assume) (page 119).

We found some tricks that might be useful for you:

• Try to request connection parameter update with both max and min interval to 15ms

• Try not to request MTU, but let the phone does it, we got 247 bytes MTU.

• Request data length extension (DLE).

• Request 2Mbps.

We tested with an iPhone 8 iOS 11.1 and got ~300kbps at 1Mbps and 650kbps at 2Mbps

However, I'm not sure about the iPhone SE if it supports those 4.2 features and 5.0 features.

You can have a look at our image demo here for your reference (the demo is without the first two "tricks" I mentioned above)

Bellow is the main.c I modified to have it optimized for iOS, MTU request is delayed for 2 seconds to let the phone requests.

main.c

[Chris]

Hung- Same result. If I modify the code to count the number of NRF_SUCCESS returns while "loop" = 1, and then I write this number to an array (length = 100) when NRF_ERROR_RESOURCES is returned, if I breakpoint on the array index rollover at any point during data transmission, the array is filled with "1" at every location. This is with sending the "asdf" array as-is, and with the byte count dropped to 20. Tested on both an iPhone SE and Samsung S7. Are you able to replicate/test on your end?

Based on these results, it seems like you cannot call ble_nus_string_send again until BLE_GATTS_EVT_HVN_TX_COMPLETE is received.

My understanding was that consecutive calls to ble_nus_string_send (sd_ble_gatts_hvx) would queue up packets in the buffer, and therefore would enable multiple packets per interval (if connection time allowed). What is the proper way to do this?