This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Softdevice S140 temporarily stops advertising BLE

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? 
  • Hi Ram,

    I am sorry for the late reply.

    Regarding the test results in LierdaTestReport.xlsx I assume the offset is given in kHz. If so it looks like the offset here is no more than 9.3 ppm, which is well within the 40 ppm required for BLE. However, it does not necessarily mean that it is OK over the whole temperature range. Is this data also for a device that you saw a high frequency of the issue?

    Have you got one of the failing device into your lab now? If so it would be good if you can test the frequency accuracy over temperature range. That way we will know more.

    Regarding testing mobile phones I do not believe there is any way to output a pure carrier on those (I assume there is a hidden test mode in all phones, but not publicly documented or accessible). So the approach to use here is to set up a advertiser in for instance nRF Connect, and use a spectrum analyzer that can demodulate the signal and provide information about it. Then you will be able to get the carrier frequency deviation from the analyzer. The exact method depends on the analyzer you have, but you can refer to this documentation from R&S to see an example.

    Einar

  • Hi Einar,

    Thanks for your reply. We are yet to receive the failing device in our lab for testing. The field visit is already scheduled, will update you once we have received and tested them.

    We tried your recommendation for testing cat phone and following is the test report:

    Could you please review it?

    Thanks

    Ram

  • Hi Ram,

    Yes, this is the best way to measure frequency accuracy of a arbitrary phone. The measurements here looks good and do not indicate any issue as far as I can see.

    I look forward to getting numbers from the failing nRF devices when you get them.

  • Hi Einar,

    If there are no issues with frequency accuracy of this specific phone, what can be other ways to rule out phone specific issues? We continue to see high incidence rate of issues on Cat S48C, S41, E6910, BV5900 etc. 

  • Hi Ram,

    It is not easy to say. Based on the observations so far frequency accuracy issues seems most likely, though there is no way to be sure before having measurements to either back it up. It is not unlikely that some phone models have larger variation than others, and that could explain why you see more issues with some phones than others, even if the nRF board may be the main problem. There could be other interoperability issues, though I am not able to find any specific indication of what that should be based on the current information. A key to know more would be to reproduce the issue in the lab, so that you could make a sniffer trace and see what actually happens on air (at least if the frequency accuracy issue hypothesis prove to be a dead end).

    Einar

Related