HCI Connection Timeout too often.

[Marius Heil]

Hello,

in my Scatternet, I often receive HCI Connection Timeouts. Depending on the settings this happens once or twice over half a day between 10 Nodes or it could happen multiple times. The Scatternet does not have circles but is built as a tree. The RSSI between nodes was not worse than -80. I do send some packets between devices from time to time.

Here's my Setup:

All Devices are connected to one, two or three other devices. Slave and Central at the same time:

• 10 nRF51 Dongles with S130 v2.0.0-8 alpha
• Connection interval 10ms
• Supervision timeout: 6000 ms

Meanwhile, they scan with the following settings:

• Scan Interval: 20ms
• Scan Window: 4ms

And they advertise:

• Advertising Interval 100 ms

I initialize the Softdevice with NRF_CLOCK_LF_XTAL_ACCURACY_500_PPM, which is the most forgiving value that I could possibly pick. I tried with other values but the connection seemed to be less stable.

Now here are my questions:

Is there anything I could be doing wrong in my program code? I do not block interrupts or anything so I would guess that there's nothing that I could be doing wrong which would cause HCI Connection Timeouts. Because I thought that Connections are fully handled by the SoftDevice.

With the given parameters I would not expect connection losses to happen this often. Can you confirm this with internal measurements that this is really to be expected?

Marius

[David Edwin]

I think this issue is happening as the connections get synchronized at some point and start trashing each other's packets, resulting in a link loss. You should be able to re-connect and proceed.

You can also check if this happens with connection intervals that are not perfect multiples of each other for the neighbor nodes, so they do not trash each other so often.

[Marius Heil]

OK, that explains quite a bit if the Link Layer Connection update is not used. Using different intervals seems to e counter-intuitive at first, but I guess that should work. Thanks for the tip, will try that. But I think this is going to cost more energy, right? Because now the CPU needs to be woken up multiple times and before it would have had the possibility to sleep for a long time and then activate for all connection events.