Connection disconnects with connection interval above about 200mS

We just recently started testing with slave latency above 0 to save power. Our connection interval is 60. If we have a slave latency above 3, then the connection terminates every few seconds. Also, if we keep slave latency at 0, and set connection interval to 180 or higher, then it has same issue.

This seems to work correctly on the DK, but not our PCB. So we are suspecting a clock issue. But this is not a particularly long connection interval, so it would mean the clock is pretty far off. Anyone have ideas how to confirm this?

Parents
  • Hi,

    If this happens under good RF conditions (not much noise / interference), then I agree that LF clock accuracy is the first thing that should be considered. Which clock source do yo use, internal RC or external 32.768 kHz crystal? How have you configured the clock in your firmware (clock accuracy etc)? Also, if you use a xtal, which exact xtal are you using (with which CL value), and which what is the value of your load caps?

  • We also believe this is related to the circuit. Now checking all components, such as crystals. I don't think its software related. You said LF, low frequency? I thought this would be related to the HF crystal.

  • It could theoretically also be related to the high frequency clock. If that is inaccurate, then radio frequencies would be off etc. Before measuring it makes sense to check the crystal circuitry there as well. And you can set up a carrier using the radio test example and measure the frequency deviation to check if it is good.

    A much more common issue when talking about clock accuracy and disconnects is the low frequency (LF) clock. This is because in Bluetooth, the peers sleep between connection events, and wakes up to communicate at specific times. This is based on the LF clock, and if the LF clock is too inaccurate / there is too much drift between the peers, they will try to communicate at different times. This is also why the sleep clock accuracy is exchanged between the peers so that they can account for the inaccuracy (and this is also why I asked for your firmware clock configuration, to check that the configured clock accuracy matches the actual accuracy).

  • Thanks for your advice. We were focused on the wrong clock. Will let you know what we find. I need to ask the firmware guy about the clock configuration, I have no idea.

Reply Children
No Data
Related