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

"

Hi Nordic support,

We had an "intermittent" connection failure with a BLE radio in one of our products under development, which exhibited itself with an <unknown> device name in the pop-up menu after clicking on the Connect button for the device - it was always found with the expected device name (ORC_CHRG) in the nRF Connect app Discovered Devices scan list.

The BLE radio worked perfectly fine for well over a month, but failed for ~ 24 hours a few days ago (on 7/29).  Then, late in the afternoon of 7/30, it started working properly again.  We're not sure if the problem is due to an intermittent hardware issue in our design, some sort of intermittent bug in our firmware execution, a bug/nuance in your nRF Connect app, or some negative interaction with the Windows 10 OS. 

We're using the latest version of nRF Connect (3.4.1) on a Windows 10 laptop pc (Windows 10 Enterprise, 64 bit, Version1709, OS Build 16299.1992).  We're using a Nordic dongle (nRF52840-dongle) via a USB connection on the pc side of the BLE communication link.

For a short fraction of a second (I think even less that 0.1 seconds) I can see that the pop-up menu will display the name <unknown> for the BLE device being Connected, before it quickly changes to the proper name which was listed in the Discovered Devices list.  I'm not sure if this is related to the malfunction that we observed a few days ago, or not.

Can you provide any guidance for what might have caused our BLE radio's intermittent behavior?  We're not sure if it is a "serious" issue that we should investigate further, or if it was caused by some strange sort of short-term interaction between the BLE device(s), the nRF Connect app, and the Windows laptop pc.

Thanks very much for your support on this inquiry!

Best regards,

Steve Boor
Abbott Neuromodulation
Plano, TX

Parents
  • Hi Steven,

    I have not heard of this behavior in nRF Connect or any other firmware solution like this before. 

    I could not find anything on devzone on any similar things that are discussed regarding sudden change of device name too. Is this happening while in connected state or in advertising state? Could you see if there is a sudden disconnect/connect happening when this happens (restart ->disconnect, advertise, connect)

    It would be good to get some air sniffer log to get more understanding on what is happening under the hood, it is very difficult to narrow it down based on the info provided.

  • Thanks for the reply Susheel.

    Unfortunately, the DUT malfunctioned in the manner I described only for a relatively short time duration - a little over a day.  The erroneous <unknown> device name occurred while the DUT was trying to connect.  Its name showed up correctly and as expected in the Scan List while it was advertising.

    Since the device "recovered", it has been operating flawlessly.  I was just hoping, with the very brief (~ 0.1 secs) display of the <unknown> device name during the initially successful device communication connection (which happens even now), that that might somehow have some relevance to understanding the malfunction.

    If the malfunction happens again, I'll see if our RF engineers can jump into helping to analyze the situation more extensively, e.g. with the logging from an RF sniffer as you suggested.

    Thanks! 

  • Steve Boor said:
    If the malfunction happens again, I'll see if our RF engineers can jump into helping to analyze the situation more extensively, e.g. with the logging from an RF sniffer as you suggested.

     That would be a very useful log in attempting to narrow down the problem. Also make sure that you have logs for any APP_ERROR_CHECK failures (that is if any functon call returned error and is caught in APP_ERROR_CHECK).

Reply
  • Steve Boor said:
    If the malfunction happens again, I'll see if our RF engineers can jump into helping to analyze the situation more extensively, e.g. with the logging from an RF sniffer as you suggested.

     That would be a very useful log in attempting to narrow down the problem. Also make sure that you have logs for any APP_ERROR_CHECK failures (that is if any functon call returned error and is caught in APP_ERROR_CHECK).

Children
No Data
Related