Softdevice S140 temporarily stops advertising BLE

[karnram]

We are using softdevice S140 6.1.1 with nrf52840 for a BLE peripheral. We see that mobile devices are not able to discover this peripheral intermittently for some time during the day ranging few minutes to hours. In an exception case, it required a physical power reset to recover from this issue. We use FAST BLE advertising with interval of 150ms and timeout of 0 (infinite). We additionally handle GAP connection and disconnection events to change the advertisement to Non-connectable when someone connects and back to connectable when the user disconnects. We don't see any failures in firmware logs which can indicate an issue with BLE configuration. These issues were reported for production peripheral devices and we have not been able to able to reproduce them locally. I need help with following queries:

1. Can a softdevice stop advertising for any reason if the duration is set to infinite? We don't see any logs for BLE_GAP_EVT_ADV_SET_TERMINATED which can possibly indicate such a thing.
2. Can we land in a situation where peripheral is not able to prioritize processing of GAP events like connected, disconnected, terminated etc. and we are not able to make softdevice resume advertisement after these events?
3. Can there be an issue with peripheral radio which can cause it to stop advertisement for some reason? We are thinking of logging radio notifications to concretly capture any such issues, is it advisable to enable radio notifications for production devices, are there any best practices to leverage this feature? 

[karnram]

>> Too large frequency offset in the BLE central (phone)

This is interesting, what tests can we perform for the phones to rule this out?

>> Is it possible for you to obtain one of the failing devices and test it in your lab or alternatively send it to us? 

Yes, I will plan to do this for one of our failing device.

Thanks for the document link to perform RF tests.

[Einar Thorsrud]

Hi Ram,

karnram said:

This is interesting, what tests can we perform for the phones to rule this out?

Yes, you can test this on the phones as well in much the same way. You can use for instance nRF Connect for Android to set up an advertiser and measure the frequency deviation / offset of the advertisement packets. It is not as straight forward as measuring a pure carrier but certainly possible. A potential problem here is that there could be some variation between the performance of the same phone model.

karnram said:

Yes, I will plan to do this for one of our failing device.

That sounds good. Would it be possible to send one of the failing devices to us for analysis as well?

Update: Another question. Did you measure frequency deviation on assumed good devices? Or can you do it? You typically want the carrier in the middle of the band when measuring at room temperature, and if that is the case, you should have good margin for temperature variations within the specification for crystal and nRF. 

[karnram]

>> Yes, you can test this on the phones as well in much the same way. 

Shouldn't we be testing how well a phone is able to receive advertisements i.e. their receiver senitivity?

>>  Would it be possible to send one of the failing devices to us for analysis as well?

Sure, I will update you once we have hardware boards for these production devices available with us after the field service visits.

>> Did you measure frequency deviation on assumed good devices? Or can you do it?

Sure, we were planning to do that as well.

[Einar Thorsrud]

Hi Ram,

karnram said:

Shouldn't we be testing how well a phone is able to receive advertisements i.e. their receiver senitivity?

I am not sure. Is there a reason to suspect that receiver sensitivity is a problem here? If so, then moving the phone and nRF device a bit closer together should work - is that the case? If the issue is a frequency deviation/offset between the peers (which we do not know, but it remains a strong hypothesis), then we we need to measure that on the Tx signal from the phone. But it would have the same frequency offset for Tx and Rx, so whatever you find when measuring in Tx is equally valid for when the phone is in Rx.

I look forward to hearing results of your findings on what we have discussed.

Einar

[karnram]

Hi Einar,

I found out that vendor already does the frequency accuracy test for our devices as part of their factory exit process. Please find attached the test report of one of the production device where we saw high incidence of discovery issues:

device-1.pdf

Does this make sense?

Thanks

Ram