nrf51822 throughput iPhone6 BLE 4.0 iOS 10.3

RE: nrf51822 throughput iPhone6 BLE 4.0 iOS 10.3

Sanjay Shreedharan — Sun, 15 Oct 2017 11:54:34 GMT

The issue is solved! The was timer was ticking faster than the data was getting sent!

RE: nrf51822 throughput iPhone6 BLE 4.0 iOS 10.3

Sanjay Shreedharan — Mon, 02 Oct 2017 09:39:54 GMT

Sure. For now, I'll be working on fixing this problem. Once I have some updates, I'll post it here.

RE: nrf51822 throughput iPhone6 BLE 4.0 iOS 10.3

endnode — Sun, 01 Oct 2017 20:21:54 GMT

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:)

RE: nrf51822 throughput iPhone6 BLE 4.0 iOS 10.3

Sanjay Shreedharan — Sun, 01 Oct 2017 14:33:26 GMT

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.

RE: nrf51822 throughput iPhone6 BLE 4.0 iOS 10.3

endnode — Sun, 01 Oct 2017 10:27:36 GMT

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

RE: nrf51822 throughput iPhone6 BLE 4.0 iOS 10.3

Sanjay Shreedharan — Sat, 30 Sep 2017 21:32:12 GMT

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.

RE: nrf51822 throughput iPhone6 BLE 4.0 iOS 10.3

endnode — Sat, 30 Sep 2017 21:23:08 GMT

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.

RE: nrf51822 throughput iPhone6 BLE 4.0 iOS 10.3

endnode — Sat, 30 Sep 2017 21:18:46 GMT

Oh yes, you are really on S110 v5.x Soft Device? I really cannot look up quickly what is maximum throughput on that stack with 30ms connection interval but it can be limited to 2 PDUs each transporting maximum 20B on GATT layer.

RE: nrf51822 throughput iPhone6 BLE 4.0 iOS 10.3

endnode — Sat, 30 Sep 2017 21:17:10 GMT

(2/2) ... with frequency matching connection interval (30ms in your example so 3 samples in one packet). Anyway all this is theoretical discussion, the only truth is in the air (= radio). Get some radio analyzer (e.g. some BLE sniffer like Nordic sniffer FW on nRF51 or 52 DK board), record data exchange and simply write down what is actual connection interval, how many PDUs get transported in each interval, what is (G)ATT laye data size in these PDUs and so what is effective throughput. Only then compare it with logging in phone app and you should get the same number. If not then most probably some bug or design mistake is in the mobile app. On the other side if you won't like how the packets look like (content, frequency etc.) on radio then you have bug or design mistake in your nRF5x app.

Looks simple.

RE: nrf51822 throughput iPhone6 BLE 4.0 iOS 10.3

endnode — Sat, 30 Sep 2017 21:12:56 GMT

You seems to be missing the main point how BLE works: data get transported only once per connection interval. Meaning that if you prepare multiple packets they might be transmitted all at once but not more then typically 6 (and even that requires decent BLE stack on phone side). So if your interval is 30ms but you will try to stack one-byte GATT packets each 10ms then typically 3 packets will be waiting for radio transmission when next connection interval will occur. Now under normal circumstances this should be fine for iPhone, all 3 packets should go through and if you collect enough packets for some statistics you should see ~100 packets per second. However it seems not the case in your set-up and to be honest most of the people would be doing it in opposite way: collecting sensor data with whatever frequency (100Hz in your example) and transmitting several samples per packet... (1/2)

RE: nrf51822 throughput iPhone6 BLE 4.0 iOS 10.3

Sanjay Shreedharan — Sat, 30 Sep 2017 21:04:35 GMT

I completely agree with you on the first point, that the value with be very close to 100Bps and not 100Bps as there will be losses/ retransmission.

The sensors are based out of I2C communication. The loop in the main function, keeps communicating and updating the values to a global variable. And once the timer goes off, the callback function just takes the global variable values and sends it to the function ble_nus_send_string(). In this scenario, does a queue really matter? As, I just read the value from a global variable and send it.

Also, the above data which I stated, connection interval = 30ms and number of packets per connection interval = 3. Are they correct? Though apple developer docs says it to be 30ms, in other forums I read that it can brought down to 20ms and the number of packets can be increased to 6. So, just wanted a confirmation.

Finally, because I'm using a very old version of SDK, is there a chance that the number of packets per connection interval is restricted to 2, and that's why I get a lower throughput?

RE: nrf51822 throughput iPhone6 BLE 4.0 iOS 10.3

endnode — Sat, 30 Sep 2017 15:05:55 GMT

Footnote: 100Bps doesn't mean that 1B is sent every 1/100 second. It is saying that average throughput is 100 bytes per second meaning that if you measure amount of data transferred over longer interval, lets say 10 seconds or rather 100 then you will see value very close to 100Bps (there might be some packet loss/retransmission events). I actually believe that problem is in your app: you simply don't utilize the throughput correctly with your 0.01s timer. Do you have proper queue on timer/sensor side which logs data for future use by UART service and then on NUS side independent state machine which takes data ready and prepare next Tx packet (which will go out in 30ms)? Connection interval is the main "timer" in your system not some artificial 0.01s.