nrf51822 throughput iPhone6 BLE 4.0 iOS 10.3

[Sanjay Shreedharan]

Hello,

I'm using a nRF51822 to send data to the iPhone using the NUS service. I'm using the oldest SDK4.x and v5.x S110 soft device. I know that the least connection interval for iOS 10 is 30ms and the number of packets per connection interval is 3.

Considering the maximum payload of 20bytes per packet, the throughput is calculated as follows:

Throughtput = (1/30ms) * 3 * 20Bytes = 2000 Bps

Considering, I'm sending only 1 byte, instead of the maximum payload of 20bytes:

Throughtput = (1/30ms) * 3 * 1Byte = 100Bps

100 Bps means 1 Byte of data being sent 1/100 of every second.

Currently, I have a timer, which goes off every 0.01, which is 1/100 of every second. When the timer goes off, the sensor values are sent to the iPhone. When I log the data on the iPhone over a period of 5 mins, what I receive is only 66.667Bps and not 100Bps.

I have been trying to track down this issue but I'm not successful till now. Can anyone help me out with this?

[endnode]

Looking quickly to S110 V5.2.1 release note it seems that S110 supports 6 ATT MTUs per one connection interval since V4.0.0. It might be lower when approaching minimal connection interval 7.5ms but it should be 6 without problems at 30ms. So it looks more like some design flaw o bug in one of your apps... sniffer will tell you quickly.

[Sanjay Shreedharan]

How do I prepare multiple packets? As far as I know, calling the ble_nus_send_string() as many times as wanted, keeps adding multiple packets. And once the data is sent, the buffer is flushed.

I have a Nordic nRF51 DK. I'll use it as a BLE sniffer and see what results I get.

Thank you very much for the swift response.

[endnode]

Yes, that's how it works: calling ble_nus_string_send leads to SoftDevice call sd_ble_gatts_hvx which prepares one GATT MTU with Notification method and payload as per data you put into the call. Now each Soft Device can have slightly different number of Tx buffers but luckily for you that's always more then 4 so you probably never need to deal with BLE_ERROR_NO_TX_BUFFERS error code (where your app is responsible to wait for BLE_EVT_TX_COMPLETE and try to invoke another ble_nus_string_send which will try to invoke sd_ble_gatts_hvx internally - btw. there is sd_ble_tx_buffer_count_get function call available to see how many Tx buffers are available).

So again: Nordic BLE UART Service aka NUS example is protocol which sends unstructured data without flow control, meaning that you application is responsible for both (interpreting the data and buffering/fragmentation/defragmentation on both sides).

And few more observations:

• I have only nRF51 SDKs since V4.4.2 but from all the newer releases it is evident that ble_nus_string_send was introduced in SDK V8.0.0. So I highly doubt you really use nRF51 SDK V4.x for your project if you call this function.
• NUS module is provided in source code so you can go into it (e.g. nRF51_SDK_8.0.0_5fc2c3a.zip\components\ble\ble_services\ble_nus\ble_nus.c) and see what is really happening when you call some function like send string.
• I believe that having UART debug which will log all the calls of ble_nus_string_send (with the returned error code!!!) and BLE_EVT_TX_COMPLETE events (coming from SD to your event handler) will already show you what is actual throughput of your application and what to expect on mobile side (I would even start with sending simple generated sequence of bytes 0x00, 0x01, 0x02... and you need to get the same sequence on the other side, that will show you if and which packets are missing and from UART log you should find out quickly why). Sure BLE sniffer might be solution as well...

Good luck

[Sanjay Shreedharan]

My SDK is a mix of v4.4.2 and SDK8.1.0. I borrow the libraries/ headers which are not available in SDK4.4.2, so that it makes my task easier. NUS services were borrowed from v8.1.0.

Ya. Logging the calls of ble_nus_string_send and the BLE_EVT_TX_COMPLETE, will give me more info. Sending 0x00, 0x01, 0x02 seems to be a good idea, as I can exactly figure out which packet goes missing.

[endnode]

OK (I would very much recommend to upgrade to S130 V2 and nRF5 SDK V12.3.0 to avoid any old bugs and limitations, it gives you optimal performance and better support from Nordic... but understand if there are some in-the-field constrains why you must stay with this obscure set-up:)