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

Issues with Proximity Example

I tried to get the ble_app_proximity example to work today, with either the nRF51-DK, nRF51-Dongle or nRF52-DK, along with the Nordic Connect app on Android.

I encounter the following issues:

With nRF5 SDK v11, the code size became too large for the free version of UV5, whether I compile for nRF51-DK or nRF52-DK. Is there a way to reduce the code size by reducing some array size, may be?

With nRF51 SDK v10, I encounter these issues:

  1. When I tried to flash onto nRF51-DK with S110, I soon encounter connection drops everytime I write to the Immediate Alert. The connection drop typically occurs about 2-5s after the write.

With a modified project for nrF51-Dongle (defines BOARD_PCA10031 instead of BOARD_PCA10028), I don't have this issue with the nRF51-Dongle at all.

  1. When I tired to read or write characteristics or descriptor, it rarely works. Most of the time nothing happen when I hit Read or Write at all. This happens with both nRF51-DK and nRF51-Dongle.

Could anyone please help me resolve these issues?


Edit 1: Add Master Control Panel (PC) log of a connection drop case: nordic_prox_loss_log.txt


Edit 2: Add nRF Sniffer capture of failure to read/write following by a connection drop case: nordic_prox_loss_log.pcapng


Edit 3: Reproduced the issue with a nRF52 DK and nRF Connect PC app as central/master, nRF51 DK as slave/peripheral running Nordic Proximity (and nRF51 Dongle as Sniffer):


Edit 4:

More information on what I did with SDK v10. This is basically what I have done and seen:

  • On PCA10028: used unmoddified ble_app_proximity example - Encountered read/write issue. Encountered connection drop issue.
  • On PCA10031: used ble_app_proximity example, change compiling preprocessor BOARD_PCA10028 to BOARD_PCA10031 to load appropriate board configuration. Otherwire the example is unmodified. Rarely encountered connection drop issue

Here is a picture of where the preprocessor I modified is located: image description

As for what I mentioned in the comments about testing on a different prototype board, I have to admit I only tried a couple of times and could not remember exactly what I see.

On other news, I realized that I was not very methodical and thorough in my experiment to help you narrowing down the issue. So I tried a few more thorough experiments and recorded them down here. Hopefully it helps you reproduce the issue/see what might be going on

Note: When I wrote these records, I didn't notice that there are various DEBUG log in the actual log file of nRF Connect. So what I mentioned here is just the notable INFO logs. Full detailed log are also attached for reference.

PCA10031 aka nRF51 Dongle

  • Setting up:

    1. Full erased chip with nRFGo Studio and program SoftDevice S110 v8.0.0
    2. Ran the project in ble_app_proximity/pca10028/s110/arm5_no_packs
    3. Changed preprocessor BOARD_PCA10028 to BOARD_PCA10031
    4. Compiled and programmed the example
  • Experiment and observations on Android:

    1. Cleared bonding/paring data of the PCA10031 board
    2. Scanned and connected via nRF Connect. The app displayed status "Connected - Not Bonded"
    3. Attempted to read Tx Power Characteristics. The app logged the operation failed with "Errod 137(0x89): GATT AUTH FAIL". But it also logged "Device bonded" and display accordingly.
    4. From now, read/write could be performed normally.
    5. After ~3 minutes, the app logged "Error 59 (0x3b): UNKNOWN (59)" and "Disconnected"
    6. Because I missed the following advertising period, I had to unplug and plug the dongle back in to reconnect to it. But from this point on, I could never read/write characteristics any more. Pressing read/write does not result in any log at all.
    7. Tried "Refresh services", the app logged "Cache refreshed", "Services discovered"
    8. Tried pressing read Tx Power a few time. The first press resulted in "Error 132 (0x84): GATT BUSY". All following pressed resulted in "Error 133 (0x85): GATT ERROR"
    9. After a little while,the connection is dropped. The app log "Error 59 (0x3b) UNKNOWN (59)" and "Disconnected".
  • Experiment and observations with nRF Connect on PC with nRF52-DK as adapter

    1. Started with the same PCA10031 as above, no reprogramming
    2. Connected to the board successfully.
    3. Attempts to read results in "Read operation failed: BLE_GATT_STATUS_ATTERR_INSUF_AUTHENTICATION (0x0105)"
    4. Tried to pair with the board
    5. After "Security updated, mode:1, level 2", read operations are all successful. I unwittingly didn't try write...
    6. Disconnected from the board
    7. All subsequent connect attemps failed with the following logs: "Disconnected from device [address], reason: BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED", "Device disconnected", "Failed to get services (Unknown value)"
    8. Unplug the board and plug it back in.
    9. All subsequent connect attemps failed with the following logs: "Failed to encrypt", "Encrypt procedure failed: [object Object]", "Failed to get services (Unknown value)", "Error occured when starting service discovery. Errorcode: Unknown value (0x3002)" and "Disconnected from device [address], reason: BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED"

Associated nRF Connect logs:

PCA10028 aka nRF51 DK

  • Setting up:

    1. Full erased chip with nRFGo Studio and program SoftDevice S110 v8.0.0
    2. Ran the project in ble_app_proximity/pca10028/s110/arm5_no_packs moddified in previous experiment
    3. Changed preprocessor BOARD_PCA10031 back to BOARD_PCA10028, so the project is essentially unmoddified
    4. Compiled and programmed the example
  • Experiment and observations on Android:

    1. Cleared bonding/paring data of the PCA10028 board
    2. Scanned and connected via nRF Connect. The app displayed status "Connected - Not Bonded"
    3. Attempted to read/write to characteristics. The app logged the operation failed with "Errod 137(0x89): GATT AUTH FAIL". But it also logged "Device bonded" and display accordingly.
    4. From now, read/write could be performed normally.
    5. After ~3 minutes, the app logged "Error 59 (0x3b): UNKNOWN (59)" and "Disconnected"
    6. Connected back to the DK. Attempted to read Tx Power Characteristic. After ~20 seconds, the connection is dropped. The app logged "Error 133 (0x85): GATT ERROR", "Disconnected" and "Error 8(0x8): GATT CONN TIMEOUT"
    7. Connected back to the DK. Run "Refresh services" and tried reading Tx Power Characteristic. The app then logged "Error 132 (0x84): GATT BUSY" for the first attempt, and logged "Error 133 (x085): GATT ERROR" for all subsequent attemps.
    8. After a little while, the connection is dropped. The app logged "Error 8 (0x8): GATT CONN TIMEOUT" and "Disconnected".
  • Experiment and observations with nRF Connect on PC with nRF52-DK as adapter

    1. Started with the same PCA10028 as above, no reprogramming
    2. Attemps to connect immediately resulted in "Disconnected from device [address], reason: BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED", "Device disconnected" and *"Failed to get services (Unknown value)"
    3. After a little bit, attempt to connect again, and it was successful... I guessed that previously I attempted to connect during its Whitelist advertising period.
    4. Connection is soon lost with log "Disconnected from device [address], reason: BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED"...
    5. Connected back to the board again, and quickly tried to read Tx Power Characteristic. The first read resulted in "Read operation failed: BLE_GATT_STATUS_ATTERR_INSUF_AUTHENTICATION (0x0105)", second read resulted in "Disconnected from device [address], reason: BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED"
    6. Connected back to the board again, and quickly tried to pair. However, just seconds after "Security updated, mode:1, level:2", the connection is dropped again...
    7. Tried step 6 again, was too slow to try reading Tx Power Characteristic before connection is lost again.
    8. Subsequent attempt to connect resulted in "Device disconnected", "Failed to get services (Unknown value)"
  • Experiment with Android: AndroidNrfConnect_DkProx.txt

  • Experiment with PC: PcNrfConnect_DkProx.txt

I ran out of time now so I was only able to test on our prototype board for shortly with my phone. I set it up the same way I set up the PCA10031 experiment, with a custom board support file for the board pinout. From my tests on Android, I saw result very similar to the PCA10031 experiment. If you need a similar log/record, please let me know and I will try it should I find the time.


Edit 5: Further testing with enable bonding with Proximity Example and HRM example, as suggest by @hungbui in the comment:

With Proximity Example

Using Master Control Panel:

  • Because I could not see the "Pair" option anywhere, I tried hitting "Bond" and/or "Encrypt" instead
  • With either nRF51 DK or nRF51 Dongle as central and the other as the Proximity peripheral, I keep getting Link Loss ~5-8s after connection

Using nRF Connect:

  • Also with either nRF51 DK or nRF51 Dongle as central and the other as the Proximity peripheral, I keep getting Link Loss ~5-8s after connection
  • Using nRF52 DK as central and nRF51 Dongle as Proximity peripheral, hitting "Pair" with "Perform Bonding" selected, I could read the characteristics without issue.
  • Using nRF52 DK as central and nRF51 DK as Proximity peripheral, I still get Link Loss soon after the connection is established...

With HRM Example

Using nRF Connect

  • Using nRF52 DK as central and nRF51 DK as HRS peripheral, I was able to get HRM notifications for a few seconds. Then I got a connection drop. After that, whenever I reconnect to the device, I keep getting "Cannot handle HVX event" error pop-up. Because it pops up every 1s, the set up become unusable. I had to press Esc to disable nRF52 as central. But even after I reselect the nRF52 DK to use, connect to the HRS peripheral results in repeating "Cannot handle HVX event" again... So I close and open up nRF Connect again, this time that bizarre error did not happen anymore. I tried getting notification with the HRM characteristic. I got disconnected after a few notifications. I retried, but this time trying to get notifications with the Battery Level characteristics. I didn't get disconnected after 2~3 minutes. But as soon as I enable HRM characteristic notifications, I got disconnected after a few notifications again I retried Battery Level notification again, and again no disconnection in >3 minutes. But as soon as I enable HRM notification, I got disconnected after a few HRM notifications again Here I made a notice that the disconnections happen a little while after connection parameter update
  • Using nRF52 DK as central and nRF51 Dongle as HRS peripheral, I was able to obtain notification from both Battery Level and HRM characteristics fine for >2 minutes without disconnection

Using Master Control Panel

  • Using nRF51 Dongle as central and nRF51 DK as HRS peripheral, I could not figure out how to only receive notification for just one between Battery Level and HRM characteristics, so I had to enable both. Again, I got disconnected soon after a few notifications, shortly after connection parameters update.
  • Using nRF51 DK as central and nRF51 Dongle as HRS peripheral, I got a disconnection/link loss after ~2 minutes. I tested once more and got link loss after almost 1 minute. But these disconnection are long after connection parameters update, and seems to be due to a BTLE_CONNECTION_TIMEOUT event.

So there seem to be a problem with updating connection parameter on the nRF51 DK, asides from the issues with the Proximity Example. I guess that explains the different results I saw between the DK and Dongle when testing.

  • Hi Hieu,

    From your trace I couldn't find any write request/command. Could you try to capture again ? If still there is no write request from the master side, it could be an issue with the phone.

    Also could you capture the trace again with Master Control Panel or nRF Connect application on PC , instead of the Motorola phone ?

    You meant you have tested with the DK and dongle before and it worked fine and the issue just happened lately ?

    From your trace I can see the 2 device kept the connection for quite a long time without any packet drop. And at the end the slave just stop responding, the central keep transmitting until time out. After 20-30 seconds, the slave advertising again.

    This is pretty strange I haven't seen this with our example before.

  • Hi Hung, I tried what you suggested. Because I only have two nRF51 evaluation boards, I had to use the nRF52 DK together with the nRF Connect PC app instead of Master Control Panel, but I hope that it doesn't matter. What I saw was connection dropped again right after I attempt to read Tx Power. However, one thing differed. After that connection drop I cannot connect back to the Nordic Prox board. I have attached the sniffer trace and nRF Connect log for your reference.

  • <cont.> Regarding the testing with a different example, I tried again to be sure and tested with the Glucose example, with one more central, a Moto G (previous one is a Moto X). What I observed on the Android devices was that connection do drop, sometime after a long while (1~2m), sometime soon after the first read/write request. However, when run with PC version of nRF Connect, I have yet seen any connection drop yet. The Motorola devices are of the same generations running the same version of nRF Connect, so I will look more into this once I have more time.

  • Hi Hieu,

    It's fine to use nRF Connect.

    From the trace you attached what I can see is that:

    • The read request was sent and got Insufficient authentication error back. This is normal as the 2 devices are not paired, link is not encrypted. Then the link is continued for 2 seconds until the slave sent connection parameter update request and got accepted. The issue happens after the central update the new connection interaval which is 500ms.

    The slave failed to continue with the new connection interval. The central continue to send message until a timeout occurs. This usually happens when you don't have a good low frequency oscillator or you configured the wrong tolerance of the crystal/oscillator.

    I would like to have the following information:

    • Did you test with the stock example ? Without any modification ? Could you try to test with the precompiled hex file provided in each example ?

    • Did you test with other boards as well ? I was quite confused with information you provided, for example:

    *"With a modified project for nrF51-Dongle (defines BOARD_PCA10031 instead of BOARD_PCA10028), I don't have this issue with the nRF51-Dongle at all."

    "Furthermore I have used the Development Kits and the nRF Dongle to test our firmware a lot. They have never shown any issue with connection drop before."

    "However, the prototypes and the kits/dongle have no issue with mentioned example and firmware.*

    I don't understand this.

    Could you summarize on what works and what doesn't work ? What worked before and doesn't work now ?

    Could you maybe take a photo of your setup ?

    I attached the screenshot of the sniffer showing how the connection dropped in my answer.

  • Hi Hieu,

    Thanks for the update.

    I just tested here and found maybe a bug with the proximity example that it crashed if we do pairing but not bonding. I will do further investigation on this.

    In the mean time, please try to tick the check box "Perform Bonding" when you pair.

    Also please try to test using Master Control Panel on PC. You can test it by using the nRF51 dongle as the backend and the nRF51 DK/nRF52DK as the device under test. You would need to flash the nRF51 dongle with the firmware comes with Master Control panel.

    Also you can test with other example that doesn't require bonding, for example ble_app_hrs. This is to rule out the issue with bonding. And verify that the radio works fine.

    nRF Connect is fairly new application and I would say it's less reliable than the Master Control Panel application.

    the INSUF_AUTHENTICATION error is normal if you haven't bonded/paired with the device as the characteristic requires encryption.

Related