better BLE data rate between two NRF52840

[jawadk]

Hi,

I am developing a project where I have NRF52840 as a device and another NRF52840 as a BLE USB dongle connected to PC.

I have to improve the BLE data rate between the dongle and the device.

Using for the Device usbd_ble_uart example and added to it the NUS service from the ble_app_uart example

Using for the Dongle the ble_app_multilink_central example because one dongle should be allowed to connect to more than one device, added to the example the ub perepheral from the usbd_ble_uart and the central NUS from the ble_app_uart_c example.

The PC an the Device communicate throw the Dongle, and experience a big delay ( in milliseconds) between sending the command from the PC until the reply from the Device received back.

at the BLE_GAP_EVT_CONNECTED event I check the min_conn_interval and the max_conn_interval like this : 

        case BLE_GAP_EVT_CONNECTED:
	  BLE_Connected = true;

            m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
            err_code = nrf_ble_qwr_conn_handle_assign(&m_qwr, m_conn_handle);
            APP_ERROR_CHECK(err_code);

	    min = p_ble_evt->evt.gap_evt.params.connected.conn_params.min_conn_interval;
	    max = p_ble_evt->evt.gap_evt.params.connected.conn_params.max_conn_interval;

both the minimum connection interval and the maximum connection interval are 24 .

I set the minimum and the maximum connection interval from the Device to 7.5 ms, after the connection the device got a BLE_GAP_EVT_CONN_PARAM_UPDATE event where the minimum and the maximum connection intervals is set to 6 ms.

1. Am I doing it right ? this will improve the BLE data rate yes ? if No what is the optimal connection interval for a better data rate!?

2. Is there anything else can be done to improve the BLE data rate ?

3. Is setting  the connection intervals to 6 ms as I mentioned above is gonna work for both of the connected devices to the dongle? how it will affect the data rate when two device is connected ?

[Karl Ylvisaker]

Hello,

1. Am I doing it right ? this will improve the BLE data rate yes ? if No what is the optimal connection interval for a better data rate!?

Yes, a shorter connection interval will give more frequent connection events in which data is transferred - which increases throughput. Without knowing more about how much data you will be transferring and how fast it is generated, it is impossible for me to tell you what the optimal connection interval is.

2. Is there anything else can be done to improve the BLE data rate ?

You should also make sure that you are using the 2 Mbps PHY to transfer your data. This lets you transfer more data in less time.
Depending on what / how much data you are transferring in each connection event, you may also benefit from increasing the MTU size ( sending more data per transmission ).

3. Is setting  the connection intervals to 6 ms as I mentioned above is gonna work for both of the connected devices to the dongle? how it will affect the data rate when two device is connected ?

Please be advised that the shortest possible connection interval is 6 in units of 1.25 ms, which translates to 7.5 ms.
You may set the minimum connection interval to 6, but this then means 7.5 ms.
On the question if this is going to work, that depends on what your peripheral devices are configured to support. You central will be the one to determine the connection interval, but your peripherals may only support a certain range to choose from.
If you configure your centrals connection interval _MIN and _MAX to 7.5 ms, you force the central to choose 7.5 ms connection interval. If the connected peripheral devices then support 7.5 ms, the connection will use 7.5 ms. If they do not support 7.5 ms, the connection will be terminated.
7.5 ms should be fine when working with 2 devices, but if you connect more devices with 7.5 ms connection interval, your central might face problems keeping up with all the peripherals.

Best regards,
Karl

[jawadk]

Hi Karl,

Thanks for your reply.

the command data size sent from the dongle to the device and the reply data size sent from the device to the dongle is not bigger than 25 bytes. (think that the default PHY is fine no?)

I know that during the connection interval the BLE can send 6 packets yes ? that means that I can send command and get a reply 6 times ? or 3 times ?

the MTU is already the biggest MTU ( 247), and I am using the default 1Mbps PHY, using the biggest phy isn't really help in this senario right?

Karl Ylvisaker said:

On the question if this is going to work, that depends on what your peripheral devices are configured to support.

I am allowing only two devices to connect to the central(dongle), as I mentioned before the data packets is not big, but the issue here that the central never stops sending the commands to the devices, 
I measured the time takes to the dongle to send command until it receives the reply from the device, this time ranges is 10-13 ms, and one packet every 4-5 packets took 60 ms.

I need to get the lowest send command and get a reply duration.

Best Regards

JK

[Karl Ylvisaker]

Hello JK,

jawadk said:

So the lowest connection interval will let me get the biggest BLE data rate yes ?

This is correct, lowest connection intervals increase throughput.

jawadk said:

This cant work with this application, can't wait for data until it fill the biggest MTU, it's a real time .application.

The data does not need to fill the biggest MTU size before it is sent. The MTU size just designates how big a packet maximally may be.
A packet is sent every from and to the master each connection event ( if you are not using slave latency ). If there is no data ready when the connection event occurs, an empty packet is sent to maintain the connection. If too much data is ready, then some of it is postponed to the next connection event.

jawadk said:

the communication is a Master - slave communication, where the dongle sends a command to the device and waits for the reply and only when a reply received the dongle sends the next command. The device accept the command and send back a reply.

Understood, thank you for clarifying.

jawadk said:

When you say 2 connection intervals you mean that the minimum latency between sending the command and getting the reply is 2*7.5ms = 15ms ?

Yes, I should have said " 2 times the connection interval", sorry for the inaccuracy. Indeed I would expect it to at worst take 2 * 7.5 ms in order to send a command, and receive a reply ( since your command needs to be processed, as I understand it ). This is the worst case scenarios - if you command is queued for sending right before an upcoming connection event, it will take 7.5 ms to send and receive a reply. 
Please know that every packet is acknowledged in an BLE link, so if the central only needs to know that the command packet has been received ( not actively accepted by the peripheral application ), then you may know this 'immediately' ( without waiting for the next connection event ).

jawadk said:

what is the latency of the same connection event !? 0 ms ?

Close, but not quite. Any type of transfer will take some time, and again, it depends on the PHY. Please take a look at the Online Power Profiler I linked earlier, to see how long time it takes to send / receive a message in a connection. The length of a connection event depends on many things, including PHY and TX / RX payload size, but I would expect it to be in the 100's of us range.

jawadk said:

I mean as I mention above that the communication is master-slave, the master sends commands ad waits for the reply, the slave gets the command and send a reply.

I did measure the latency time after the dongle sends the command until it got the reply back from the device, his latency range from 10 ms to 13 ms, and once every 4-5 commands the latency is something in range 50 ms - 60 ms.

Again, this depends on whether or not your application needs to accept the central's command, or if it is enough for the central to know that the command was received.
For example, what is the possible replies that the peripheral can reply to a command? Is it possible for the peripheral to reply with anything other than accepting the command?

The latencies in the 10 - 13 ms range sounds fine - since it depends on when the command is queued for sending from the central.
I would think that the latencies in the 50 - 60 ms range is caused by the application running on the peripheral side - i.e the command is received just as quickly, but not processed.

Are you familiar with the nRF Sniffer tool? It would be helpful to see the 50 - 60 ms instances captured in a sniffer trace.

Best regards,
Karl

[jawadk]

Hi Karl,

thank you a lot for your fine explanation.

Karl Ylvisaker said:

what is the possible replies that the peripheral can reply to a command?

there is replies that require a peripheral work, as you explained, ad now it make sense.

But that raises for me another question:

In one second we have 1/0.0075 = 133.33 connection events, if the connection interval is 7.5 ms.

and the biggest MTU is 244 bytes, then the biggest data rate can be 133.33 * 244 = 32533 Bps= 31.7 KB ps = 254.16 Kbps.

So how can BLE 5 reach 800 Kbps with 1Mbps PHY!?

Best Reagrds

JK

[Karl Ylvisaker]

Hello JK,

jawadk said:

thank you a lot for your fine explanation.

No problem at all, I am happy to help!

jawadk said:

there is replies that require a peripheral work, as you explained, ad now it make sense.

I am happy to hear that we are on the same page now, and that I have understood you correctly - thank you for clarifying!

jawadk said:

But that raises for me another question:

In one second we have 1/0.0075 = 133.33 connection events, if the connection interval is 7.5 ms.

and the biggest MTU is 244 bytes, then the biggest data rate can be 133.33 * 244 = 32533 Bps= 31.7 KB ps = 254.16 Kbps.

So how can BLE 5 reach 800 Kbps with 1Mbps PHY!?

You can change the connection event length, to transfer multiple packets per connection event.
I recommend that you read through this blog post by my colleague for further detail.
Please also have a look at the example project and the reply by my colleague Edvin in this ticket.

Please do not hesitate to ask if anything should be unclear!

Best regards,
Karl

[jawadk]

Hi,

Thank you again and again for the help.

Lets say the I am using the maximum connection event length (500ms), maximum MTU (247), maximum data length (251) and connection_interval (min and max) 100ms. as your colleague suggested.

If I am trying to send a message in between two connection events, it will be sent immediately as a part of the current connection event? or it will be sent as a part of the next connection event ? in other words the latency will be affected or not !? 

Best Regards

JK

[Karl Ylvisaker]

Hello JK,

jawadk said:

Lets say the I am using the maximum connection event length (500ms), maximum MTU (247), maximum data length (251) and connection_interval (min and max) 100ms. as your colleague suggested.

If I am trying to send a message in between two connection events, it will be sent immediately as a part of the current connection event? or it will be sent as a part of the next connection event ? in other words the latency will be affected or not !? 

Not quite. The SoftDevice will control the CPU for the entire duration of the connection event - so your application may not queue new data for transfer while the event is ongoing.
However, an event may end early if there is no more data queued for sending, in which case your application will be given back the CPU.
So, I guess the answer to your question regarding latency is: it depends on how much data you have queued in between each connection event.
Bear in mind that the connection event length will scale to be < connection_interval. By setting 500 ms event length, you are basically asking to set to to the maximum value possible, for your given connection interval.

The aforementioned is also the reason why you should use easyDMA and PPI for most of your peripherals - so that they may continue working / sampling / receiving / transferring while the SoftDevice controls the CPU.

Best regards,
Karl

[jawadk]

Hi Karl,

Lets say that the connection interval is 10 ms.

In case that the application queued a 25 bytes to send (one packet), and the softdevice send them in the first connection event, after the sending is finished, you said that in this case the first event ends, so what the application queue for sending for now on till the second connection event will be sent during the second connection event yes ?

the first connection event ends and not returns in this case, is that what you meant ? so in this case my  latency will still be <= 10 ms, is that right ?

Best Regards

JK

[Karl Ylvisaker]

Hello again JK, 

jawadk said:

In case that the application queued a 25 bytes to send (one packet), and the softdevice send them in the first connection event, after the sending is finished, you said that in this case the first event ends, so what the application queue for sending for now on till the second connection event will be sent during the second connection event yes ?

This is correct, once a connection event has ended you must wait until the next connection event occurs to transfer any data.

jawadk said:

the first connection event ends and not returns in this case, is that what you meant ? so in this case my  latency will still be <= 10 ms, is that right ?

I am not sure what you mean when you say "and not returns in this case", but if you mean to ask if your worst case latency for the data transfer is <= 10 ms with a connection interval of 10 ms, then: Yes, in this case, your latency will indeed be <= 10 ms.

Best regards,
Karl