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.

[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.

[Vidar Berg]

Thank you for the clarification. I assume the uptime counter is only reset after a reboot, not upon disconnection. This suggests that the connection timeout isn't due to an unexpected reset, at least. The fact that this issue doesn't occur when the devices are placed closer together indicates that it's likely not related to exessive clock drift either.

The s8 encoding is more susceptible to interference from other devices operating on the same frequency bands, as the packets require a longer airtime.

[Phobios]

Ok, thanks for the hint with the clock drift, that makes sense.

To the encoding: I thought S8 increases the range and robustness because it is coded and adds error correction? That's the reason I'm choosing this, because I want to cover a long distance. If I have to switch back to 1M PHY then the range is limited.

Can I play with the connection parameter or are there any other options I can try?

[Vidar Berg]

s8 will generally extend the range, but it may perform worse in noisy environments.

You can try to disable slave latency to see if it helps improve the robustness of your link. 

Phobios said:

If I have to switch back to 1M PHY then the range is limited.

Is the RADIO configured to transmit with 0 dBm (default), or have you increased it to +8 dBm? 

[Phobios]

I've already increased to 8dBm - but as you said (and the RSSI value shows) - I think in that special environment, the problem is more the interference than the range limits.

I've also thought about using Nordic range extension IC, but only on the central device (since the sensor is battery powered, I don't want to loose more capacity). According to the datasheet is increases the receiving sensitivity as well, not only transmitting power.

Do you think changing to 1M PHY will help me with the interference, and the range extension IC (but only on the Central) will help me getting longer range? 

[Vidar Berg]

Just to make sure, are both the peripheral and central transmitting at +8 dBm? This is necessary to really increase the link budget. Also, I'm curious if you have done comparisons between coded and 1M in your environment? There is a significant power cost associated with using the CODED PHY since the radio needs to stay on 4 times longer to transmit/receive the same amount of data.

Phobios said:

Do you think changing to 1M PHY will help me with the interference, and the range extension IC (but only on the Central) will help me getting longer range? 

I think you need to use the FEM on both sides to improve the link budget. If you have a choice between increasing the power output or using CODED PHY, you should typically see the biggest improvement by increasing the power. Note that ETSI does not permit more than 10 dBm for BLE.

[Phobios]

Sry for the late reply, I had finally some time to test some more. I'm using CONFIG_BT_CTLR_TX_PWR_PLUS_8=y on both sides, Peripheral and Central.
For the power cost; since my connection interval is so long (2s with latency) there is really not much difference between 1M and S8, from what I've measured.

I've done tests with 1M, I see a little improvement but the disconnects are not gone.

I also tried different connection parameters with success. After setting

• Interval: 200ms
• Latency: 9 (means every 2 seconds the sensor must awake and send)
• Timeout 20 seconds

The disconnects are gone. 

So for me it looks like, sometimes it misses all connection intervals up to the 8 seconds and the timeout kicks in. If I increase the timeout, then the devices have more chances to get one interval right.

Is there any downside to such a big timeout? I'm sending only sporadic messages, so I don't have much data throughput. 

[Vidar Berg]

Thank you for the update and the interesting findings. Initially I expected an 8 second timeout to be sufficient. But with your long connection interval, you only had to miss 4 events.

Whether using a large timeout has any drawbacks depends on the application.  A delay of 20 seconds to detect a lost connection is often not ideal if is for a user facing application.