nrf51-ble-app-lbs throughput test

[Marcus Rundgren]

Hi,

I am using the Evaluation Kit, and I have tried to send some data between the Developoment Dongle (PCA10000) to the Evaluation Kit board (PCA10001). As the Development Dongle supports only one packet per connection interval, the theoretical maximum throughput is:

( 1 packet x 20 B ) / 0.0075 = 2667 B/s

And when I try to send data from the dongle to the evaluation kit board I manage to reach this throughput (thanks to Ole Morten) when using the nrf uart example you provided.(previous question)

But when I try the nrf51-ble-app-lbs throughput test I can't reach the same level of throughput (about 1 kB/s). I thought that it should be the same?

The code setup:

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

I have tried to find something that could slow the throughput down, but do not find anything...

[Ole Morten]

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.

[Marcus Rundgren]

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.

[Ole Morten]

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.