nrf52810 beacon disconnection issue

[pktron]

Hi All,

We are working on nRF52810 chip for on of our beacon project and we are using external antenna on board but

We are  dealing with the Reason 8 disconnections.

 We are not sure why this is happening. We have changed the Crystal and it is more stable, but we still get the disconnection.

What could help to debug it? We had got the antenna tested at a facility and they said it was working well.

Please have a look at the logs and check whether you can make out anything.

 You can search for the disconnections in the data from the two instances below.

We observed disconnection because of error 8, the rssi in each case are:

03/04/2018 12:35:21:770  debug [BleManager]onConnectionStateChange: Last rssi value- -84 -84 -84 -84 -84 -84 -84 -84 -84 -84

 

12:40:22:671  debug [BleManager]onConnectionStateChange: Last rssi value-

-61 -61 -61 -61 -61 -61 -61 -61 -61 -61

on both the cases its disconnecting.

thanks in advance

Pktron

[Kenneth]

Hi, from disconnect reasons (ble_hci.h) I can find that 8 means BLE_HCI_CONNECTION_TIMEOUT.  So this may indicate that there is an issue with the tolerance of the 32kHz clock. What parameters have you provided for clock_lf_cfg in sd_softdevice_enable()?

[pktron]

Hi,

Parameters of clock_lf_cfg are as follows:

    nrf_clock_lf_cfg_t clock_lf_cfg =

    {

        .source        = NRF_CLOCK_LF_SRC_XTAL,

        .rc_ctiv       = 0,

        .rc_temp_ctiv  = 0,

        .accuracy      = NRF_CLOCK_LF_XTAL_ACCURACY_75_PPM,

    };

The disconnects are erratic.

It seems they happen when around metal objects and due to Wifi Pollution.

 

Connection parameters were connection interval of 250ms , 300ms, slave latency 5, with 6 seconds supervision timeout.

 

We tried with the following values and it is working better.

300ms 330ms, slave latency 2, and 6 seconds supervision timeout.

 

I guess the problem is that the central selects and sends packet over a channel. The peripheral must respond on the same channel. If for some reason the channel becomes in use during the time or the first message gets corrupted, then peripheral is not able to respond. So in first case the keep alive had to succeed 1 in 3 times. While now it has to succeed 1 in 6 times. This increases the reliability a lot, at the expense of power consumption.

Thanks in advance

Pktron

[Kenneth]

Any change if you use NRF_CLOCK_LF_XTAL_ACCURACY_250_PPM? What central device are you using here?

[pktron]

No , no changes.

because of Disconnects at high RSSI values. This means that although the signal strength is good there is too much interference.

A suggested solution to determine bad RSSI is to detect packet loss and then take whatever action that is needed.

 We have implemented an adaptive scheme where we increase/decrease the power when RSSI goes low.

But this does not help if RF interference is high.

Is there a way to detect the RF interference?

If we can know that then we can change connection parameters to send the packets more frequently. Allowing the network more chance to recover the connection.

 Is it possible to get an estimate on SNR values, or number of available channels?

If there are less no. of available channels then also we can increase the frequency.

please confirm

[Kenneth]

Hi, we don't have any statics or numerical value of SNR etc. So I guess my recommendation is to increase output Power or reduce connection interval to avoid (or reduce) the issue you experience in the first place.