This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Connection stability with S130

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.

Parents
  • 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...

Reply
  • 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...

Children
No Data
Related