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]

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.

[Sanjay Shreedharan]

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?

[endnode]

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)

[endnode]

(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.

[endnode]

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.