Issues with Proximity Example

[Hieu]

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.

2. 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):

• nRF Sniffer capture: nordic_prox_sniffer_trace.pcapng
• nRF Connect log: nordic_prox_connect_log.txt

---

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:

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:

• Experiment with Android: AndroidNrfConnect_DongleProx.txt
• Experiment with PC: PcNrfConnect_DongleProx.txt

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.

[Hung Bui]

Chao Hieu,

Which central device did you use ?

Could you try to record a sniffer trace on what happens ?

Could you check what was the disconnect reason when the BLE_GAP_EVT_DISCONNECTED event occurs ?

I would suggest to get started with the nRF Connect or nRF Master Control Panel app on PC.

Regarding the issue with the size of the example on SDK v11, in SDK v11 we introduced the peer manager and the fds, fstorage to replace device manager and pstorage. The code size increased quite a lot. My suggestion is to port the example to use device manager and pstorage instead. You can follow what we have with other example such as ble_app_hrs on how to use the pstorage.

[Hieu]

Chao anh Hung,

The central I was using is an Android device. I don't think I have encountered troubles with this device as far as it concerns BLE.

I tried to install nRF Sniffer and Wireshark to record a trace but I encountered another issue with that. When I launch Wireshark from nRF Sniffer, I encountered an error saying Couldn't load module C:\Program Files\Wireshark\plugins\2.0.5\nordic_ble.dll:'C:\Program Files\Wireshark\plugins\2.0.5\nordic_ble.dll': %1 is not a valid Win32 application. This probably is why Wireshark also pops up a warning saying The NPF driver isn't running. You may have trouble capturing or listing interfaces. I tried replacing nordic_ble.dll with the .dll files in the sniffer package, both x64 and x86 versions. However neither file works.

[Hieu]

I tried using the PC version of Master Control Panel, and ran into the same connection drop problem, however after a much shorter time. Once I saw that it drops the connection 1~3s after connection formed, and another 1~3s after the service discovery completed. I will have the Master Control Panel log attached to the main post for your reference.

[Hung Bui]

@Hieu: Please install Wireshark v1.10 instead of v2.x . Wireshark v1.10 is the only version we support.

From the log I can see it was the BTLE_CONNECTION_TIMEOUT that caused the disconnection, there is something wrong with the slave or it could be too much interference caused the timeout.

Have you tried with other examples in the SDK ?

[Hieu]

@Hung: I have obtained a sniffer trace with the nRF Sniffer.

I have tried with the ble_app_uart example and may be a couple more. 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.

I could not judge if the interference is severe, but we now have 5~10 prototypes/BLE devices powered within the 2-meter radius around me at all time, together with two WiFi routers. However, the prototypes and the kits/dongle have no issue with mentioned example and firmware.

I also tried the proximity example on one of our prototype and it also resulted in similar connection issues.

[Hung Bui]

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.