Multiple packets per connection interval - s132/IOS

RE: Multiple packets per connection interval - s132/IOS

Hung Bui — Thu, 25 Jan 2018 08:58:25 GMT

Hi Chris,

If you can provide a sniffer trace, it would be easier to check from whom the MTU request is sent. There is also a chance that an iOS update can change the behavior of the phone.

RE: Multiple packets per connection interval - s132/IOS

Chris — Wed, 24 Jan 2018 17:26:15 GMT

Hung- Ah, thanks, that makes sense. On either IOS device, based on what is logged in RTT, the initial MTU exchange upon connection results in a 185 byte MTU, with or without the code commented out that you mention above. Leaving the code in simply results in another negotiation to a 185 byte MTU, Not really a huge deal right now, but it will be good to eventually get to 247 bytes on an IOS device.

-Chris

RE: Multiple packets per connection interval - s132/IOS

Hung Bui — Wed, 24 Jan 2018 16:59:12 GMT

Hi Chris,

Think of the buffer like this, you have 7 buffers. At the beginning they are all free, or at least you don't know how many are free. It's the buffer shared between a write command and a notification. You call sd_ble_gatts_hvx () as many as possible until it's full and you receive NRF_ERROR_RESOURCES.

Calling sd_ble_gatts_hvx again before receiving BLE_GATTS_EVT_HVN_TX_COMPLETE usually won't help. Because the buffer was full before that and usually in one connection event, you can't get the buffer from full to empty (7 packets to be sent). So it's better to just wait for BLE_GATTS_EVT_HVN_TX_COMPLETE before calling sd_ble_gatts_hvx () again.

To achieve 247 bytes MTU on iOS , as I suggested in the first answer, you let the phone request it instead of requesting it from the nRF5. To do that you need to comment out the call to sd_ble_gattc_exchange_mtu_request() inside on_connected_evt() in nrf_ble_gatt.c

RE: Multiple packets per connection interval - s132/IOS

Chris — Wed, 24 Jan 2018 15:01:44 GMT

Hung- Apologies I did not send the actual output, I was too focused on the details. Using an iPhone SE, I hit, on average, 124kpbs with a 182B data length and an average buffer length of 90. Based on the log in either lightBlue explorer or nRF toolbox, packets are being sent at ~15ms intervals, with occasional multiple packets per interval. Based on a quick calc, this makes sense - 182Bytes8bits(1/15ms) = 97kbps, 2 packets per interval is of course double this, so occasional multiple packets per interval would yield a throughput between these two numbers.

With a S7, a ~480kbps throughput is achieved with a 244B data length and an average buffer length around 250. The log file on this device always crashes, so I can't be sure of the interval, but assuming 15ms, then given the 244B data length, multiple packets must be sent during a given interval.

With a iPhone X, I was still only able to hit a 182B data length, but an average transfer speed of ~500kbps was achieved. Again, obviously multiple packets were sent.

So, it seems that multiple packets are being sent per interval, but it also seems that, based on my code testing, making calls to sd_ble_gatts_hvx before receiving BLE_GATTS_EVT_HVN_TX_COMPLETE is not the mechanism which enables multiple packets per interval to be sent and actually doesn't seem to do anything since, until BLE_GATTS_EVT_HVN_TX_COMPLETE is received, sd_ble_gatts_hvx returns NRF_ERROR_RESOURCES.

Apologies that I kind of backed in to this as an answer, but based off of documentation/threads elsewhere, I was led to believe that the multiple calls to sd_ble_gatts_hvx before receiving BLE_GATTS_EVT_HVN_TX_COMPLETE was necessary to maximize throughput. I just want to be sure that I have a (somewhat) reasonable understanding about how the examples work before I start working on my own code.

Please let me know if you disagree or find any issues with what I've stated above.

-Chris

RE: Multiple packets per connection interval - s132/IOS

Hung Bui — Wed, 24 Jan 2018 13:27:22 GMT

Hi Chris,

Yes, that is the correct way of doing this. I don't know why you only get one packet.

Please let us know the result of the test with your phones. What printed out on UART ? What is the connection interval.

My test here with the unmodified example above, with an S6 showing 60kbps, 5 packets per interval , 15ms interval. Please use NRFConnect to test. On S8 it's 1200kbps.

Please try capture a sniffer trace.

You can also test between 2 nRF DK one as central one as peripheral to see the maximum through put it can achieve.

RE: Multiple packets per connection interval - s132/IOS

Chris — Tue, 23 Jan 2018 18:33:52 GMT

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?

RE: Multiple packets per connection interval - s132/IOS

Hung Bui — Tue, 23 Jan 2018 16:17:03 GMT

Hi Chris,

Please try with this example and let us know what throughput you have. Note that you may tune it to have 15ms interval. And also to get 247 bytes MTU, you shouldn't request MTU update, let the phone do it.

ble_UART_TP_examples.zip

RE: Multiple packets per connection interval - s132/IOS

Chris — Mon, 22 Jan 2018 18:41:26 GMT

Hung- The questions above still apply, but I was able to achieve a 15ms connection interval using the max and min interval set to 15 - I thought I had previously tried this, but apparently not. So, while I still cannot achieve more than a packet per interval for whatever reason, this shortened interval time effectively doubled my throughput - great news. Please let me know what I might be doing wrong in terms of sending packets to be queued, clearly I must be doing something incorrectly given how quickly I receive the RESOURCES error.

I did also try an iPhone 10, curiously enough, the negotiated MTU size was still 185 bytes.

-Chris

RE: Multiple packets per connection interval - s132/IOS

Chris — Mon, 22 Jan 2018 14:59:53 GMT

I dropped the packet size down to 20B, now I am seeing 9-10 packets per interval being sent. This is with an interval set to 30ms or 60ms. Good news - does not seem to be a limitation on the iOS side. BUT, I also now realize that I am seeing a NRF_ERROR_RESOURCES error upon consecutive calls to "ble_nus_string_send" (really sd_ble_gatts_hvx) - even with a packet size of only 20B. It seems like I can only call "ble_nus_string_send" once I've received " BLE_GATTS_EVT_HVN_TX_COMPLETE" - but my understanding was that I could repeatedly call "ble_nus_string_send" until the buffer was full. Based on my current testing, the "buffer" fills after 20B - doesn't seem right. Should I be doing something differently to queue up packets?

-Chris

RE: Multiple packets per connection interval - s132/IOS

Hung Bui — Mon, 22 Jan 2018 13:29:34 GMT

I don't think there is anything else. Note that you can always look at the MD (More Data) bit in a BLE packet (Link layer) to see if the slave saying that it still have more data to send but the master didn't send more packet or it's the opposite that the slave didn't have more data to send (MD = 0).

I would suggest to test also with different central, Android, or another NRF52 acts as central for example.

RE: Multiple packets per connection interval - s132/IOS

Chris — Fri, 19 Jan 2018 16:44:42 GMT

Hung - Yes, this is already done in nrf_sdh_ble.c:

#if (NRF_SDH_BLE_GATT_MAX_MTU_SIZE != 23)
memset(&ble_cfg, 0x00, sizeof(ble_cfg));
ble_cfg.conn_cfg.conn_cfg_tag                 = conn_cfg_tag;
ble_cfg.conn_cfg.params.gatt_conn_cfg.att_mtu = NRF_SDH_BLE_GATT_MAX_MTU_SIZE;

In the sdk:

#ifndef NRF_SDH_BLE_GATT_MAX_MTU_SIZE
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247
#endif

So it seems like the buffer and softdevice are configured correctly, right? Anything else that must be configured to enable multiple packets per interval? I know I still need to test a smaller packet size, I should get to this in the afternoon.

-Chris

RE: Multiple packets per connection interval - s132/IOS

Hung Bui — Fri, 19 Jan 2018 15:50:38 GMT

Yes, but you also need to tell the softdevice to prepare big enough buffer for large packet (and x7 of them) when you enable the softdevice.

You can find the code I pointed above in nrf_sdh_ble_default_cfg_set() in nrf_sdh_ble.c . I assume the function is used in your code and NRF_SDH_BLE_GATT_MAX_MTU_SIZE in sdk_config.h isn't modified to smth else but 247 ?

RE: Multiple packets per connection interval - s132/IOS

Chris — Fri, 19 Jan 2018 14:23:42 GMT

Yes, with hvn_tx_queue_size = 7, and with the necessary updates to ram_start implemented, I can only call ble_nus_string_send once before receipt of a NRF_ERROR_RESOURCE return (in other words, upon the second call of ble_nus_string_send, with a 182 byte packet, I receive the NRF_ERROR_RESOURCE error).

I am making this call in gatt_init:

err_code = nrf_ble_gatt_att_mtu_periph_set(&m_gatt, NRF_SDH_BLE_GATT_MAX_MTU_SIZE);

Is that not sufficient to configure mtu size? Certainly this is what enabled 182 byte data transfers.

Thanks for your help!

-Chris

RE: Multiple packets per connection interval - s132/IOS

Hung Bui — Fri, 19 Jan 2018 14:15:08 GMT

Hi Chris,

You are telling that even with hvn_tx_queue_size = 7 you can only queue 1 packet ?

Could you try testing with very small packet says 1 byte payload and see if you seeing the same issue ?

Also when you configure the softdevice, you should declare max MTU :

ble_cfg.conn_cfg.params.gatt_conn_cfg.att_mtu = NRF_SDH_BLE_GATT_MAX_MTU_SIZE;

RE: Multiple packets per connection interval - s132/IOS

Chris — Fri, 19 Jan 2018 14:00:18 GMT

Hung- I am doing the following with regards to queuing up packets (quoted from my above post) -

"I've also increased hvn_tx_queue_size to 7 and event_length to 320 (per other posts) in an attempt to increase the packets per interval (and adjusted ram start as needed). I am calling ble_nus_string_send (effectively sd_ble_gatts_hvx) until the response is no longer NRF_SUCCESS - at this point, I wait until I receive BLE_GATTS_EVT_HVN_TX_COMPLETE before calling ble_nus_string_send again."

Based on this implementation, I can't exceed more than one call to ble_nus_string_send before I receive a NRF_ERROR_RESOURCES response. Is there some other way I should be queueing up packets? Or is there something else I should be doing to increase the buffer size?

RE: Multiple packets per connection interval - s132/IOS

Hung Bui — Fri, 19 Jan 2018 11:52:39 GMT

Have you make sure you queued the notification packets until the buffer is full (on the nRF52 side) ? I don't see any other way to increase the number of packets per interval except for queuing as quick as possible. As far as I understand, iOS will give a connection a limited event length in each connection event. I have seen at least 3 packets per connection interval (30ms) with 251 bytes each packet.

RE: Multiple packets per connection interval - s132/IOS

Chris — Fri, 19 Jan 2018 00:53:34 GMT

Hung- I should add to the above that, when operating with a 60ms interval, I still was not sending more than 1 or 2 packets per interval. Is there anything else I should be doing to increase the number of packets sent per interval?

-Chris

RE: Multiple packets per connection interval - s132/IOS

Chris — Thu, 18 Jan 2018 13:59:27 GMT

Hung-

Thanks, it will take me a bit to work through this but I'll try to get back to you later today/tomorrow with my successes or failures - I appreciate the feedback! For reference, I am not requesting the MTU update, I am initializing with NRF_SDH_BLE_GATT_MAX_MTU_SIZE and the negotiation occurs to get to a data length of 182 (I believe this is a limitation of an SE running iOS 11.2).

Yesterday I did try requesting a connection parameter update with the same parameters used during initial negotiation (15ms min, 75 ms max) - initial negotiation resulted in a 30ms connection interval, but the update request resulted in a 60ms interval!?! Its like iOS was punishing me for making the request:) I'll review your code vs. mine to see if there are any differences.

I'll also see if I can borrow someone's iPhone8 to confirm your results.

-Chris

RE: Multiple packets per connection interval - s132/IOS

Hung Bui — Thu, 18 Jan 2018 11:57:30 GMT

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

RE: Multiple packets per connection interval - s132/IOS

Chris — Wed, 17 Jan 2018 21:22:24 GMT

I've also increased hvn_tx_queue_size to 7 and event_length to 320 (per other posts) in an attempt to increase the packets per interval (and adjusted ram start as needed). I am now calling ble_nus_string_send (effectively sd_ble_gatts_hvx) until the response is no longer NRF_SUCCESS - at this point, I wait until I receive BLE_GATTS_EVT_HVN_TX_COMPLETE before calling ble_nus_string_send again. Based on a simple counter, upon the second call ble_nus_string_send, I receive a NRF_ERROR_RESOURCES error. What am I missing?