nrf51-ble-app-lbs throughput test

RE: nrf51-ble-app-lbs throughput test

Ole Morten — Wed, 12 Mar 2014 13:40:50 GMT

As is commented elsewhere, the minimum connection interval supported will be dependent on device. As far as I know, the S4 won't accept this, and hence, will deny any such request. After the defined number of attempts, you should therefore see an error from ble_conn_params, saying that the connection parameters were not accepted.

I haven't tested this with the S4 myself, but I suggest you get a sniffer trace and post a separate question if you have further questions. Remember that it may not even be using a 20 ms interval, but you can check this either with a sniffer, or by checking the conn_params in the connected event, in ble_gap_evt_connected_t.

I'd also be happy if you could accept my reply as an answer, to clear up the question, since I think it covers the initial question.

RE: nrf51-ble-app-lbs throughput test

Marcus Rundgren — Wed, 12 Mar 2014 12:26:26 GMT

Thanks for your answer!

When I try to decrease the connection interval in the Master Control Panel, I reach the theoretical throughput (2.67 kB/s) :D

But I also tried to define MAX_CONN_INTERVAL to 7,5 ms without any success. It seems like it does not matter and the throughput is still like for connection interval = 20 ms.

So when I try your application nRF Master Control for Android, I do not manage to get connection interval = 7.5 ms. The phone I use is Samsung Galaxy S4. And I had also expected that it should use several packets per connection interval. But I only reach 1,6 kB/s.

RE: nrf51-ble-app-lbs throughput test

Ole Morten — Tue, 11 Mar 2014 13:35:42 GMT

Have you checked what the connection interval for the link actually is? You can easily see this in the log pane (or log file, File -> Log file) of MCP. If you use the parameters you list here in the code on the Peripheral side, and connect with the Master Control Panel's default settings, which is a connection interval of 20 ms, the connection interval will stay at 20 ms. The reason is that this is well within the range wanted by the Peripheral (from 7.5 to 40 ms), and it will see no reason to send an update request.

Using a connection interval of 20 ms, with 1 packet per interval, you should expect to see exactly 1000 bytes/second, which seems to be close to what you get. If you want to actually get 7.5 ms connection interval, you need to change the settings, so that an update request is actually sent (i.e. make sure that the initial interval of MCP is outside the wanted range), or make sure that MCP connects with 7.5 ms to start with. The latter can be changed from MCP's options, found in the File menu, Options and then on the Connection parameters tab, while the former can be achieved by changing the peripheral code to for example this:


#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(7.5, UNIT_1_25_MS) 
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(7.5, UNIT_1_25_MS)

(This may not be recommended for production code though, since it doesn't give the Central a lot of wiggle room.)

I haven't explicitly measured the throughput with MCP and the throughput-test, but as far as I can see, the behavior on-air (as seen using our sniffer) is as expected, both with 7.5 ms and 20 ms connection interval, so I believe the throughput should be close to the theoretical 2.67 kB/s.