Connection stability with S130

[Marius Heil]

Hello,

has anyone done some good testing on the connection quality between multiple nRF51 chipsets running on the S130 SoftDevice? (Using all four connections, 3 as Central, 1 as Peripheral) Given an environment with very low interferance and a timeout of 6 seconds with a connection interval of 100ms, can the SoftDevice stay in connection for multiple months? I am currently experiencing connection losses at a rather high frequency (about 2-3 per day) and I am wondering wether this is a bug that I introduced somewhere in my code. At times, I receive the BLE_GATTC_EVT_TIMEOUT event which basically forces me to close the connection. But I am wondering why this happens, because both sides process the BLE events quickly.

I guess that Nordic has done quite a bit of testing on connection stability, would you share these results?

Thanks, Marius

Edit: I am initializing the SoftDevice with NRF_CLOCK_LFCLKSRC_XTAL_20_PPM, maybe that is part of the issue, I am currently investigating this.

[vich]

Hi Marius,

We do stress test the multiple concurrent connections. Please provide details of your firmware (SD versions, GAP and GATT procedures exercised, etc.), to better understand your observations.

I would like to bring your attention towards the fact that peripheral links drift in time and overlap over multiple Central links in time on a chip, but as you have 100ms and 6s timeout, each link should sync within few retransmissions; hence disconnections should not be observed.

continued...

[vich]

But, some known factors that could affect my earlier statement are, if you are forming scatternet using multiple S130 firmware leading to connection loops, then synchronization could end up in a deadlock if Centrals and Peripherals in your loop be Central and Peripheral respective at all times (i.e. at tN chip1 is central and chip2 too is central).

Another factor, if you do have two independent BLE connections of same connection intervals between chip1-chip2, chip3-chip4 and they coincidentally use the same hop sequence, then overtime they will drift into each other so to cause CRC error on air, leading to connection loss.

continued...

[vich]

It is strange you receive BLE_GATTC_EVT_TIMEOUT, when using supervision timeouts of 6s, and if you do correctly implement GATTC responses on your peer. Please be aware that in S130 v1, APIs do return NRF_ERROR_BUSY, APIs need retry (future releases SD API will better mitigate this).

If you need greater support, one of our support engineers will be glad to assist you.

Cheers, Vinayak

[Marius Heil]

Hello, thank you. I am currently going over all SoftDevice calls and I am checking my error handling. When I am done, I will have to see if the behaviour remains the same.

I am using S130 v1.0 production, I am using some GAT procedures to build connections, but afterwards, I am using only GATT writes to communicate and connection losses should not occur. I am indeed using scatternets, but I do not have loops. Drift should therefore be carried through the tree.

My current test was only using 8 devices, so I do not think that they chose the same hopping scheme, which is picked randomly as I think?

I will have a look for the NRF_ERROR_BUSY as you propose, but I'll have to understand some of these errors a little better before I handle them, so I will open another Question.

Thank you