NRF52 central immediately disconnected,reason:0x3e

[daoms]

I'm using 52832 as a Central(SDK_17.0.2/S132_7.0.2), and sometimes get a connect-disconnect failure with reason 0x3e.It happens randomly and frequently.

I search the forum here, find a lot a guys have the same problem with this 0x3e problem.

Obviously, it is because the peripheral doesn't respond to the CONNCT_REQ in the timming, or the Central dosen't catch that respond from the peripheral.

Some people say that it has something to do with connection_param here  and here ,while some people disagree with that here.

Some people say it is because of interference...

Most of the time the phone is always working, so it is most probably the nordic problem.

Can Nordic make a official post or blog to discuss with this 0x3e issue?

Thanks,

[haakonsh]

It can be the nRF device that is missing the receive window, but in that case you have an issue with one or both of the LF and HF clocks. Why don't you measure the clocks and see if they are within spec? 

[daoms]

Could you please help more? Because this is the ble stack thing, I can really do nothing more in my application.

1.Where and how to check the code about LF and HF clock?

2.How to measure them? Use a oscilloscope？

3.What is the spec?

[haakonsh]

daoms said:

1.Where and how to check the code about LF and HF clock?

2.How to measure them? Use a oscilloscope？

You can use a TIMER + GPIOTE to toggle a pin with the HFXO as the clock source. Then you can use either an oscilloscope or digital analyzer to measure the Interval of the toggling pin. 

The same goes for the RTC + GPIOTE with the LFRC or LFXO as the clock source. 

daoms said:

3.What is the spec?

The BLE spec requires +/-50PPM on the HFXO. 

The LF clock can be up to +/-500PPM, but you need to set the clock accuracy that the SoftDevice will use. If you've set the LF clock accuracy to 20PPM when it is in reality ~100PPM then you will get missed radio event. By default our examples use 20PPM and the LFXO as the clock source. 

[daoms]

1.Is it OK to use the radio_test example or DTM example to measure the tx carrier frequency to see whether HFXO or LFXO ppm is good?

2.How about change the LF clock accuracy to 100PPM or even bigger if I'm not sure the performance of the HFXO and LFXO?

3.Or if I don't care about the current consumption, can I use LF_SRC_SYNTH to get a better accuracy?

Thanks

[haakonsh]

daoms said:

1.Is it OK to use the radio_test example or DTM example to measure the tx carrier frequency to see whether HFXO or LFXO ppm is good?

TX carrier frequency is a great measurement for the HFXO if you have access to a spectrum analyzer :) 

The LFXO can be measured with the RTC example in the nRF5_SDK. This example will toggle p.0.17 (LED2) every 3 seconds exactly. If you measure the period between two toggles then you should be able to calculate the PPM of the clock source. 

daoms said:

2.How about change the LF clock accuracy to 100PPM or even bigger if I'm not sure the performance of the HFXO and LFXO?

That is a good option for debugging. But I recommend that you verify that your clock sources are operating as expected before you go into production. 

daoms said:

3.Or if I don't care about the current consumption, can I use LF_SRC_SYNTH to get a better accuracy?

You can do that, given that your HFXO is good, but your sleep current will be ~400µA instead of ~2-3µA.