Sporadic disconnects with reason 8 but good RSSI

[Phobios]

Hi,

I'm having some problems with sporadic disconnects with reason 8 (timeout) although the RSSI values are in a good range.
The disconnects are very rare, I would say maybe every 1-2 hours; if there is more interference, then maybe more.

As peripheral and central I'm using a NRF52840; my RTOS is Zephyr and my NCS Version is 2.5.1

Details:

• I'm using coded PHY S8
• RSSI values are all about -70dbm
• Connection parameter:
  • Interval: 400ms
  • Latency: 4 (means every 2 seconds the sensor must awake and send
  • Timeout 8 seconds
• External LF crystal, 20ppm

I've already tried to play around with the PPM settings and tried CONFIG_CLOCK_CONTROL_NRF_K32SRC_150PPM, but there was no improvement. Also the crystal is rated with 20ppm, so I think that should not be the problem.

I've chooses the connection parameter like this, because I really do not have to send much data and want to keep the battery consumption on a minimum.

What could be the problem and how could I improve the connection? What can I try?

Thanks a lot,
Phobios

[Torsten Robitzki]

Are you able to use a sniffer, to at least see at which side, the connection is going to be lost? Could you replace the central with something else, to rule out this part of the communication?

[Phobios]

I'm currently trying to set up the sniffer and will provide some logs as soon as I have entered the sniffer world (never used it before). I think replacing the central is not a good idea, because it changes the environment; i'm using an external antenna. What I can do is to program the central example and connect to the sensor and log the disconnects there.

[Torsten Robitzki]

Could you then replace the peripheral? Divide and Conquer! ;-) If you are able to rule out half of the system, searching becomes easier.

[Vidar Berg]

I'd also suggest building the central and peripheral project with the CONFIG_RESET_ON_FATAL_ERROR set to 'n', if you haven't already done so. This will help catch any crashes. A reset triggered by the fault handler could explain the connection timeout. By the way, was the connection timeout reported by the central or the peripheral?

[Phobios]

It was reported by the central. I think I can rule out the reset, because I'm sending a status package with the uptime every minute; and the uptime never resets. But I sure will try it with the parameter.
Also if I change the environment e.g. put the sensor closer to the central, there are no more disconnects.

[Torsten Robitzki]

Well, in the end, it could boil down to some unavoidable disconnects due to the environment.