• State Verified Answer
  • Replies 12 replies
  • Subscribers 62 subscribers
  • Views 4033 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 125598
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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?

Parents
  • 0

    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

Reply
  • 0

    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

Children
Related