Unreliable Central Connection on BLE Relay

[Collin]

I am working on a project where an nRF52 is a multi-role BLE device. It is an advertising Peripheral, to which smartphones can connect, and a Central which scans for and connects to up to 3 accessories. Let's call the multi-role device the Hub, and its peripherals Accessories.

The Hub's peripheral side has an advertising interval of 200ms. Preferred conn params are conn interval of 30-170ms, with slave latency of 3 and supervision timeout of 2200ms. The Hub's Central side has a scan interval of 100ms, a scan window of 50ms, and has two sets of connection parameters for different Accessory types. One set (for 2/3 of the accessories) is 30-60ms conn interval with 30 slave latency, and 5590ms supervision timeout, and the other being 30-630ms conn interval, slave latency 6, and 13,240ms supervision timeout.

Smartphones (multiple Android and iOS handsets and tablets) can connect just fine to the Hub when the Hub has no Accessories connected. The Hub receives commands from the smartphone via a service very much like NUS, and those react within a few hundred milliseconds. This is fine, because the commands are issued by users and trigger motors to move.

The problem arises when one or more Accessories are connected to the Hub. Once Accessories are connected, the Hub's advertising packets are sporadic (not every 200ms like they should be), connecting through our app takes longer than usual, and command latency goes up sporadically as well, sometimes up to 2 seconds! Also, on some Samsung Android tablets and a Note 9, the Hub has lost connection while in use, with no apparent reason. I have not been able to get an iPhone to lose connection, and iPhones have less command latency than Android devices in general, but it is still a noticeable difference when there are Accessories connected to the Hub.

I am looking for general advice about multiple connections. Is there some way to measure radio utilization that I am missing, and it's getting overloaded? Do I need to prioritize something?

Updates: As I read softDevice documentation, I found that the default GAP config event_length is 3.75ms, and the minimum is 2.5ms. In my softdevice_init function I set ble_cfg.conn_cfg.params.gap_conn_cfg.event_length to 320 decimal, so that would be 400ms!  I am going to try with a value of 3, which is the default and would give 3.75ms event length.

[Susheel Nuguru]

Hi Collin,

Please choose the event length wisely based on the size of the maximum packet size you send and how many packets per connection interval you want to have.

If throughput is not the most important thing for you, then like you said, you can have the event_length configured to be small.

Also note that the scanner part of the Hub is using the radio 50% of the time. That is only the rest 50% of the time is left for connections and the peripheral role on the hub. I do not think that you are missing anything related to prioritizing as this is taken care by the softdevice itself on which event to prioritize and the applications have no control on that. I think you need to draw a time chart and layout your events in it to see if three peripheral roles + scanner role with those connection perameters are having too many conflicts in terms of the timeline competing for the radio..

[Collin]

Ok, thanks for the guidance. I have tested with the app, Hub, and 2/3 peripherals, and there is a noticeable performance improvement.

Now I am wondering, what is the relation between MTU, event length, and packet size? I imagine that if I have Event Length small, it will have to fragment larger packets, but am not sure.

We are looking for low power, low data rate, but low latency commands between Hub and Accessories. Accessories are battery powered but Hub is not, so Hub to phone link doesn't need to be low power.

I read endnode's comment in one question, I can't find it right now, but I think she said to lower both the scan interval and scan window in order to make scheduling easier. After reading the SD specification on Scheduling, I see how this could happen, because the long scanning windows will take lots of time. I would like to detect most advertising packets, as one of the Accessories only advertises every 5 seconds to save power. Can you suggest parameters that might make sense, ie should I stick with 50% duty cycle, but a smaller time window and interval, or change the scanner duty cycle? I understand that the scan window duty cycle can only get so high before it and the connections run out of time to be scheduled.

[Susheel Nuguru]

Collin said:

I read endnode's comment in one question, I can't find it right now, but I think she said to lower both the scan interval and scan window in order to make scheduling easier

I am not so sure if reducing both scan interval and scan window will help. The trick is to keep the scan window as minimal as possible (at the same time not too low that it missed the adv packets all the time). It is your architect who needs to balance these values correctly.

Collin said:

would like to detect most advertising packets, as one of the Accessories only advertises every 5 seconds to save power.

I think in that case the trick here is to keep the scan interval and scan window NOT a perfect divisor of 5 seconds, to avoid the risk of scan window missing the advertising interval always at the same time keep the scan window large enough to capture the adv packet.

Collin said:

Can you suggest parameters that might make sense, ie should I stick with 50% duty cycle, but a smaller time window and interval, or change the scanner duty cycle?

 I would suggest you to attach the problem by freeing up space.

On your peripheral role , try to keep maximum possible intervals. So your peripheral having adv interval of 200ms and a connection interval close to 80-170ms. 

for the scanner, maybe you can keep 190 ms scan interval and 95 ms of scan window (since advertisers normally has 0-10ms random adv delay) we can make sure that the scan window have higher probability on overlapping with adv packets.

Also keep the connection interval for the connections with the accessories as large as possible if the data throughput is not the highest priority. I cannot suggest any numbers here as I do not know what your system is trying to do. Your system architect will be able to answer this for you.