Connection Parameter Selection for Central Device with 10 Peripheral Simultaneous Connections

[Mark J]

Hi,

I am developing both Central and Peripheral devices with nRF52840. For consistency, both are using SDK 15.3.0 and S140 V7.

I am able to connect to peripherals and negotiate MTU ATT size of 247 and I am able to negotiate 2 Mbps phy. Logging on both peripheral and central devices confirm this is working.

My challenge is getting notification data from my peripherals to my central. If I set up (for example) 2 peripherals to notify my central device every 500 mSec with approx 160 bytes of data, all data comes into the BLE event handler (BLE_GATTC_EVT_HVX) within my central device just fine. If I double the data speed on peripherals (ie. 160 bytes every 250 mSec from each of the 2 devices), I only get BLE_GATTC_EVT_HVX events notifying me of incoming data from the first peripheral only.

I believe that I am not getting correct connection service intervals setup after peripheral connection.

For a scenario where a central is talking to 10 peripherals and getting notification data from each every 250 mSec, what would good connection interval, slave latency values be? I cannot seem to find a good reference for setup of connection intervals for multiple simultaneous peripheral connections to a central device - where each peripheral is notifying the central independently.

Note that my connection event length is 6 x 1.25 mSec or 7.5 mSec. This should be plenty long enough to get an MTU of 247 bytes transferred.

I have been using default min and max connection intervals of 7.5 and 30 mSec respectively and a slave latency of 0 (for both central and peripheral devices).

Suggestions for my scenario would be much appreciated.

Thanks in advance,

Mark J

[Edvin]

Hello Mark,

Glad to hear that you are on the right track!

I just wanted to let you know that I am leaving for vacation in the beginning of next week, so if you discover any new issues after the workday tomorrow (Norwegian time), I suggest that you create a new ticket. You can always link to this one for background information.

Best regards,

Edvin

[Mark J]

Hi Edvin,

I hope that you enjoyed you time off this summer.

Not sure if it is appropriate to close this off with a verified answer or continue it.

I have gotten my previous use case (10 peripherals each notifying every 250 mSec with 160 bytes of data). For the record, my config is:

Peripheral and Central:

Min and Max connection interval of 150 mSec.

Slave Latency of 0

Connection supervisory timeout of 8000 mSec.

sdk_conffig.h - NRF_SDH_BLE_GAP_DATA_LENGTH 251

sdk_conffig.h - NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247

sdk_conffig.h - NRF_SDH_BLE_GAP_EVENT_LENGTH 6

I have another use case. I need to get more data delivered to my central device every 250 mSec from fewer (4) peripheral devices. Specifically - 2400 bytes from each of the 4 peripherals every 250 mSec. If more efficient to get more data less often, I can also live with 9600 bytes every 1 sec from each of the 4 peripherals.

To get high throughput from a single peripheral in the past, I have had to dramatically increase NRF_SDH_BLE_GAP_EVENT_LENGTH. I have followed Sigurd's advice as shown here: nRF52840 Speed Improvement Post. This confuses me. If I am able to use the 2 Mbit/s phy and MTU of 247, I would expect much shorter event lengths are required. At 2 Mbit/s, I should be able to send 2400 bytes in approx 12 mSec (1/2000000 * 10 bits/byte * 2400 bytes). I recognize that it will take longer than 12 mSec given that many packets within a connection interval are required and there will be time between these packets, however it should be not much more than 12 mSec. The post linked above includes a suggestion to increase the NRF_SDH_BLE_GAP_EVENT_LENGTH to 400 1.25 mSec units or 500 mSec. This seems huge. 

Firstly - does my new paradigm require a new devzone submission or post? If yes, this reply can serve as an answer and I can create a new post. If no, can you please advise:

Are my data throughput expectations reasonable?

What kind of GATT and GAP params are suggested given that my peripherals will only advertise every 500 mSec and that no scanning will occur on the central when servicing these 4 peripheral connections to handle their notifications.

Thanks for your help as always.

Mark J

[Edvin]

Hello Mark,

Thank you! I did

Let's keep going here for now, as it is still related to the title. 

So the device receiving data is the central, and the throughput from each peripheral is.

T1 = 2400 bytes * 8bits/byte * 4/s = 76 800bps

and for all 4 devices:

T4 = 4*T1 = 307 200bps, or 300kbps.

So this seems plausible with 2MBPS. However, I don't know what range you are looking at between the central and the peripherals. Using 2MBPS you will start dropping packets quickly if the range increases. The BLE stack will handle retransmissions, but this means a lower throughput.

According to the link you refer to: The maximum throughput that you can get from a link is when you have a fairly long connection interval, and a long connection event. This is the case for one link. If you have 4, like in your case, you obviously have a limitation in how much time you can spend on each link. I suggest you try to set the connection event = 1/4 of the connection interval (150/4ms). Try that. I don't think it would hurt to increase the connection interval even more. Perhaps 400ms, and then use 100ms connection event length.

You can play around with the parameters using the ble_app_att_mtu_throughput example from the SDK. 

Have you tested any parameters?

BR,
Edvin

[Mark J]

Hi Edvin,

To answer your first question... Range will typically be within 2 to 20 meters. Sometimes this will be outdoors with only the ground supporting reflection of wireless between central and peripherals (ie. when they do not have a direct line of sight). That (I think) will be our most challenging setup.

Our calculations for payload transition times line up (76800 bps per peripheral). If all packets get through on a 2Mbps phy, and ignoring the minimal expected time between packets, that should require 76800/2000000 or 38.4 mSec per sec to handle data from each of the 4 peripherals. The only reason for loosing data from any of the 4 peripherals would be many retransmissions. Is there a way to limit retransmissions to 3 or 4? It is preferable to loose a packet here or there and still keep data moving from all 4 peripherals.

The above calculation also begs the question ... why setup NRF_SDH_BLE_GAP_EVENT_LENGTH to huge number like 500 mSec when a connection supporting 2 Mbps should support event data delivery in much less time than 500 mSec?

I will try try your suggestions for connection interval and event times and reply in this thread.

Thanks,

Mark J

[Edvin]

Mark J said:

The only reason for loosing data from any of the 4 peripherals would be many retransmissions. Is there a way to limit retransmissions to 3 or 4?

 Unfortunately, no. That is a limitation in the BLE spec. All packets will be retransmitted until they either are Acked, or the link will die trying. This means that the only way a packet is aborted is if you have a disconnect. 

 

Mark J said:

Our calculations for payload transition times line up (76800 bps per peripheral). If all packets get through on a 2Mbps phy, and ignoring the minimal expected time between packets, that should require 76800/2000000 or 38.4 mSec per sec to handle data from each of the 4 peripherals.

 I don't know how you did these calculations, and they may be correct, but remember that there are headers on the packets, ramp up on the radio, and some more HW things (which I don't know the details of). See here:

https://devzone.nordicsemi.com/nordic/power/w/opp/2/online-power-profiler-for-ble

So basically, the payload throughput you can expect is listed here:

https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/ble_data_throughput/ble_data_throughput.html

Near the bottom there you see the maximum theoretical throughput with 2MBPS, which is 1376.5Mbps (NB: bits, not bytes).

When you divide this on 4 links, it means that you need 4 times the headers, and radio ramp up, and so on, so realistically it is 1376/4, and then take away a bit more. This is why I suggested setting the event length = conn_interval/4, because this gives a more realistic throughput for each link. It means it can only spend 1/4th of the time on that connection.

As mentioned, the throughput on 2MBPS is more sensitive to distance and radio signal strength than 1MBPS, so you simply have to test this in the environment where the product will be used.