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

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

Children
No Data
Related