Connection failure

[toddyu]

The nRF52832 devices have been produced in hundreds of units. Currently, it has been found that individual central devices are problematic – connecting to peripherals often takes a very long time, whereas switching to another central device usually results in quick connections. There is a noticeable difference when testing with these two central devices. What could be the possible reasons for this?As shown in the sniffer log, the faulty central device sends multiple CONNECT_IND packets before finally establishing a connection, whereas other central devices often succeed on the very first CONNECT_IND attempt.

[Kenneth]

Hello,

Do you know if the peripheral in question get any connection event for these packets, or does it simply advertise as normal during this period since the connection request packet was not received? Is it possible the peripheral here have whitelist enabled (thereby preventing other/new central devices to connect)?

Finally, have you performed any radio test or direct test mode on the board to ensure the design is operating within specifications?

Also, which SDK and SDK version are you using here?

Kenneth

[toddyu]

1.our program does not use a whitelist.

2.The peripheral can be connected by mobile phones or other central devices easily.

3.We replaced the 2 crystals on the problematic central devices, and the issue appears to be resolved.

4.We don't perform any radio test or direct test mode on the board. Do you have any documentation?We suspect it might be an issue with the crystal oscillator, but it seems we don't have the proper testing equipment on hand.I change NRF_SDH_CLOCK_LF_ACCURACY to 500PPM and it doesn't work.

In addition, our central device is also a peripheral device.When a phone connects to it, the same issue occurs - it often requires multiple connection attempts before successfully establishing a link.

softdevice:s132_nrf52_7.2.0

SDK:nRF5_SDK_17.0.2

[Kenneth]

Hello,

I suspect the problem is the high frequency crystal, especially since using 500ppm for the low frequency clock still fail.

You can setup the radio test example:
https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.0.2/page/nrf_radio_test_example.html 

Then use the start_channel and start_tx_carrier commands.

You should then for instance see a unmdulated carrier exactly on the frequency of 2400MHz + channel, e.g. 2402MHz if channel = 2.

You then need access to a spectrum analyzer, set it up to sweep around 2.402MHz and check how much off the center frequency the carrier is. If it's within specification it should be maximum +-96kHz off center frequency.

Kenneth