Effect of connection interval on connection stability

[wrani]

Hi, 

1.I have a long-rage ( Coded PHy ) connection between a Master and a Peripheral. 
Master is 52840 , Peripheral is 52833 ( on battery ) 

We have notice that setting longer connection interval ( > 150 ) is making the connection unstable. 

lowering the connection interval to 70 makes the connection stable again. 

Slave Latency is set to 0 .   Why does the conn. interval causes disconnection  ? is this a Coded Phy thing ? 

2. For the same project, I am connecting up to 15 devices to my master ( Master acts as an aggregator ). 

The peripherals can be located up to 300 meters from the Master - This is up and running with Interval= 30.

With power consumption in mind, I am struggling to com up with the connection parameters so I can satisfy all 15 connections. 

No special data requirements, 100 Bytes every few minutes. 
(In case of OTA I can increase the conn. parameters, rare event ) 

3. Do I need to consider the Peripherals RSSI ( or distance from Master) and set different connection parameters ? ( requested by Peripheral ) 
- Or - one size fits all ? 

Thanks, 

Ran  

[Einar Thorsrud]

Hi Ran,

Why does the conn. interval causes disconnection  ? is this a Coded Phy thing ? 

The connection interval impacts the stability of the link because it affects the number of packets that can be lost before the connection times out. For example, if the connection interval is 30 and the supervision timeout is 300, then you must loose 10 packets in a row in order to get a supervision timeout. But if you increase the connection interval to 60, but keep the 300 supervision timeout, then you only need to loos 5 packets in a row in order to get a timeout.

With power consumption in mind, I am struggling to com up with the connection parameters so I can satisfy all 15 connections. 

I suggest you use a very long connection supervision timeout (at least if you don't have restrictions on latency). The maximum supervision timeout is 32 seconds. You could also combine that with using a short connection interval, but use slave latency. (With slave latency connection intervals can be skipped, but retransmissions will occur on every connection interval until success or supervision timeout.)

3. Do I need to consider the Peripherals RSSI ( or distance from Master) and set different connection parameters ? ( requested by Peripheral ) 
- Or - one size fits all ? 

I would try to find a common configuration for simplicity. If what I suggested above is acceptable and you have the same requirements for all the links, then I do not see why you could not use the same connection parameters on all links as well.

Einar

[wrani]

Thx. as for

if the connection interval is 30 .. you reduce the connection interval to 60 

Why going from 30 to 60 is reducing the connection interval ? number went up. what am I missing here ? 

Also - what is "short" for connection interval ? 30 sounds right ?

Thanks, 

Ran 

[Einar Thorsrud]

Hi Ran,

wrani said:

if the connection interval is 30 .. you reduce the connection interval to 60 

Why going from 30 to 60 is reducing the connection interval ? number went up. what am I missing here ? 

Ah, yes. I guess I was focused on the number of packets when i wrote "reduce". Updated the post to "increase" now.

wrani said:

Also - what is "short" for connection interval ? 30 sounds right ?

I mean that as a relative term, and it depends on a lot of factors.  As explained in my previous post, if you have a bad channel to begin with (such as with long distance between the peers) and expect a lot of packet loss for that reason, then increasing the connection interval while keeping the supervision timeout is expected to cause more timeouts, as explained in my previous post. So the mechanism is not that complicated in principle.

Exactly which tradeoff makes sense for you is difficult for me to say. What rate of packet loss do you expect? What is the connection supervision timeout (you have not stated)? Is a timeout a problem or not, etc?

Einar

[wrani]

Einar Thanks. 

My peripheral is a battery operated device that controls solenoid remotely. 

That matters to me most is :

a. Power Consumptions - Device is Idle 99% of the time

b. Reliability - I need as much a guarantee that message travel arrives safely from the Gateway ( NRF52850)

b. long range ( via coded phy and 8db TX ) 

I care "less" about  "responsivness" and "throughput"

So, after reading quite a bit, it seems that for most application, the following combination offers low power consumtion and high througput when needed : 

Short Connection Interval + High Slave Latency + Long  supervision timeout 

Combined with max MTU and DATA_LENGTH values.

Correct ?

Is there a safe slave latency value , one the does not causes time drifts between to NRF52's ?

Thanks

Ran 

[Einar Thorsrud]

Hi Ran,

wrani said:

So, after reading quite a bit, it seems that for most application, the following combination offers low power consumtion and high througput when needed : 

Short Connection Interval + High Slave Latency + Long  supervision timeout 

Combined with max MTU and DATA_LENGTH values.

Correct ?

Yes, that is correct, particularly for the peripheral device. For the central it needs to listen on every connection interval, so slave latency would not help as much in that case.

wrani said:

Is there a safe slave latency value , one the does not causes time drifts between to NRF52's ?

BLE uses window widening to accommodate more drift as the connection interval or slave latency increases (adding more margin). (This is only up to a certain point though, up to when  the window widening time is (CI/2) - TIFS - see BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 6, Part B section 4.2.4 for details). So anything up to this value which is set automatically, and also depends on clock accuracy, should be considered equally safe.

Einar