nrf52810 beacon disconnection issue

RE: nrf52810 beacon disconnection issue

Kenneth — Tue, 10 Apr 2018 14:31:05 GMT

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.

RE: nrf52810 beacon disconnection issue

pktron — Tue, 10 Apr 2018 04:10:40 GMT

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

RE: nrf52810 beacon disconnection issue

Kenneth — Mon, 09 Apr 2018 15:39:00 GMT

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

RE: nrf52810 beacon disconnection issue

pktron — Fri, 06 Apr 2018 09:07:30 GMT

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

RE: nrf52810 beacon disconnection issue

Kenneth — Thu, 05 Apr 2018 11:15:40 GMT

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()?