5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

OwainIncus — Tue, 17 Jan 2023 13:39:01 GMT

Hi Hung,

I can now confirm this was the issue. In this case with Security L2 and the PHY negotiation the Polar H10 did not work. Turning off our central starting the PHY negotiation worked.

Turning off L2 and leaving PHY neotiation on worked also.

This does look as if it is an isssue of the Polar H10; which I believe is there latest version. SW 5.0.0, FW 3.1.1 as reported in device information service.

Many thanks for all your support. Without your help and knowledge we would not have been able to work our way around this Polar device bug.

Kind Regards,
Owain

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

Hung Bui — Tue, 17 Jan 2023 13:27:23 GMT

Hi again Owain,

Thanks for the update. Now we can narrow the issue down.
I would suggest to set

CONFIG_BT_AUTO_PHY_UPDATE=n

CONFIG_BT_USER_PHY_UPDATE=y

Then you can control when you want to request 2Mbps (if you plan to use it) in your application by calling bt_conn_le_phy_update() to switch PHY.
I would suggest to call the function after the link is encrypted.

This way we can avoid the corner case where the PHY request is not responded before the encryption request.

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

OwainIncus — Tue, 17 Jan 2023 12:55:27 GMT

You may have cracked it...

CONFIG_BT_AUTO_PHY_UPDATE=n

Here trace for simple project. I am now going to try in our standard company prodject.

devzone.nordicsemi.com/.../SimplePolarL2NoPhyNeg.pcap.pcapng

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

Hung Bui — Tue, 17 Jan 2023 12:22:24 GMT

Hi Owain,

I would need to see how you implemented it in your code.

But you can try setting

CONFIG_BT_CTLR_PHY_2M=n in the controller (on the nRF53 you need to add it to the hci_rpmsg).

I would assume you don't call bt_conn_le_phy_update() in your application ?

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

OwainIncus — Tue, 17 Jan 2023 10:31:20 GMT

Hi Hung,

the SimplePolarNotL2Secure.pcap.pcapng added above was the standard 5340 dk without the request to switch to L2 security. The Phy negotiation takes place and gets negotiated to 2M.

Where can I disable the PHY negotation to get a trace with L2 requested and restricted to 1M phy?

Regards,
Owain

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

Hung Bui — Tue, 17 Jan 2023 08:32:58 GMT

Hi Owain,

Could you let us know the result if 2Mbps was not requested ?
There could be a chance that it still support 2Mbps but the PHY request came at the wrong time and it trigger a corner case causing the problem.

And please provide us the trace when you use central uart to connect to the HR. I would assume PHY request was not sent (?).

As far as I know the Polar H10 may actually use Nordic's Softdevice on it and we did have an issue earlier with these old Softdevices that they doesn't support PHY request change.

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

OwainIncus — Mon, 16 Jan 2023 16:37:18 GMT

devzone.nordicsemi.com/.../simplePolarNotL2Secure.pcap.pcapngI Can try that, but this Polar H10 heartstrap works if I do not request the security change to L2.

This Polar Hear Strap the H10 is one of the most widely used heart monitors in the world. This and the Garmin are the devices used by 99% of athletes using a monitor.

As I think I have said I have tinkered with the peripheral uart example to change uuid etc; and I have tried with a standard 5340 dk (non-secure).

I get the same behaviour.

Here a trace without the switch to L2; and we do see the update for the PHY update in this trace. And they do agree to use 2M phy.

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

Hung Bui — Mon, 16 Jan 2023 11:47:57 GMT

Hi again Owain,

After checking with the team, I think we found something suspicious here. In both of your sniffer trace the slave didn't respond to the LL_PHY_REQ from the central.
This could be the reason the central couldn't send the LL_ENC_REQ. The central can't send the encryption request before the previous request has been responded.

Could you please try modify the central so that it doesn't request 2Mbps PHY change to see if it would let the pairing complete ?

You may want to call bt_conn_get_remote_info() to get the information to know about the peer's BLE stack. If it's very old it may doesn't support PHY request change.

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

Hung Bui — Fri, 13 Jan 2023 16:39:02 GMT

Hi Owain,
Thanks for the update.

I would assume there is some configuration with your board that chose HCI H4 ?
By default if you compile with nRF5340 hci_rpmsg will be selected for the netcore.

Could you try compile for nRF5340dk_nrf5340_cpuapp ?
Also if you have a nRF52 board please try to do a cross check. We need to see if the issue only happens on the nRF53 or also on the nRF52. Then we can narrow down it to the dual core setting that cause the issue.

I also assume that you only try to pair with one device ? By default CONFIG_BT_MAX_PAIRED = 1 so you can't pair with 2 devices or more.

I looked at the trace again and have to correct myself that it was not "The nRF5 didn't send the pairing confirm and then the slave disconnected. " but the pairing confirms were sent and pairing randoms received but the confirm value from the POLAR was not match and it explain why the central terminate the pairing process.

I will check internally to have the confirmation, but it's strange that the POLAR works with other central but not the DUT. I assume it works fine with a phone ?

Please also try testing the nRF5340 to pair with a nRF5 running peripheral_hr to see if the pairing would work or not. From what you described, it worked with the Garmin ?

I did a quick test with your firmware and it paired fine with a nRF52 running peripheral_hr.

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

OwainIncus — Fri, 13 Jan 2023 14:16:28 GMT

Hi Hung,

I have taken the uart example as you suggest; I have had to make some small changes to ensure HCI RPMSG is used rather than HCI H4.

This the outpu from the test on the console; looks that same as my own project; fails on the security change.

*** Booting Zephyr OS build v3.2.99-ncs1 ***
[00:00:00.259,552] \033[0m<inf> fs_nvs: 2 Sectors of 4096 bytes\033[0m
[00:00:00.259,552] \033[0m<inf> fs_nvs: alloc wra: 0, ec0\033[0m
[00:00:00.259,552] \033[0m<inf> fs_nvs: data wra: 0, 154\033[0m
[00:00:00.284,606] \033[0m<inf> bt_hci_core: No ID address. App must call settings_load()\033[0m
[00:00:00.284,637] \033[0m<inf> central_hr: Bluetooth initialized\033[0m
[00:00:00.286,254] \033[1;31m<err> settings: set-value failure. key: bt/name error(-2)\033[0m
[00:00:00.287,139] \033[0m<inf> central_hr: Scan module initialized\033[0m
Starting Bluetooth Central HR example
[00:00:00.289,978] \033[0m<inf> central_hr: Scanning successfully started\033[0m
[00:00:01.612,976] \033[0m<inf> central_hr: Filters matched. Address: E0:EF:E7:CA:6A:68 (random) connectable: 1\033[0m
[00:00:02.115,417] \033[0m<inf> central_hr: Connected: E0:EF:E7:CA:6A:68 (random)\033[0m
[00:00:02.167,572] \033[0m<inf> central_hr: MTU exchange done\033[0m
[00:00:17.817,810] \033[1;33m<wrn> central_hr: Pairing failed conn: E0:EF:E7:CA:6A:68 (random), rea[00:01:05.502,258] \033[1;33m<wrn> central_hr: Pairing failed conn: E0:EF:E7:CA:6A:68 (random), reason 9\033[0m
[00:01:05.502,410] \033[1;33m<wrn> central_hr: Security failed: E0:EF:E7:CA:6A:68 (random) level 1 err 9\033[0m
[00:01:05.502,441] \033[1;31m<err> bt_gatt_dm: Discover failed, error: -128.\033[0m
[00:01:05.502,441] \033[1;31m<err> central_hr: could not start the discovery procedure, error code: -128\033[0m
[00:01:05.503,570] \033[0m<inf> central_hr: Disconnected: E0:EF:E7:CA:6A:68 (random) (reason 8)\033[0m

This was built using ncs 2.2.0.

devzone.nordicsemi.com/.../6305.central_5F00_uart.zip

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

Hung Bui — Fri, 13 Jan 2023 09:10:22 GMT

Hi Owain,
Sorry my mistake. My idea is to use central_uart because it has similar behavior as your application to require L2 when connected. But I forgot that it won't connect to the polar HR because it's different UUID.

What you can do is to change the scan_init() to filter the HRS UUID instead of the NUS UUID. The goal is to make it connect and pair to the Polar HR. You can remove any code related to NUS client.

I just want to have a very simple application that connect and pair and do nothing else. The prj.conf should be kept the same as in the sample. If it works we can try to compare it with your application to see what cause the issue.

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

OwainIncus — Fri, 13 Jan 2023 09:01:12 GMT

Hi Hung,

central uart or central heart rate example?

Our device is both a central and a peripheral. One can connect from a mobile to manage our device; but it can connect to peripherals.

Looking at the central heartrate example it works quite differntly to the uart example; it also does not change the security level. Note the Garmin strap works fine changing level to 2.

Regards,
Owain

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

OwainIncus — Fri, 13 Jan 2023 08:51:51 GMT

Hi Hung,

I attached the config yesterday. Yeah all works fine with the Gamin strap; bonded ok.

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

Hung Bui — Fri, 13 Jan 2023 08:42:26 GMT

Hi Owain,

Have you tried to test using the central_uart example to connect to the Polar ?

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

OwainIncus — Thu, 12 Jan 2023 14:59:26 GMT

Here more debug but with CONFIG_BT_DEBUG_SMP=y

033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.016,998] \033[0m<inf> app: connected: Central: connected to F0:C9:75:7D:CB:FF (random)
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.017,059] \033[0m<inf> app: connected: security is currently 1
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.017,150] \033[0m<dbg> bt_smp: smp_send_pairing_req: \033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.018,615] \033[0m<dbg> bt_smp: smp_init: prnd 2ec0d9a9193c2b1b54b14f14734e4279\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.018,768] \033[0m<inf> app: connected: security set to BT_SECURITY_L2
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.020,782] \033[0m<inf> app: systemProcessThread: System got EVENT_BLE_PERIPHERAL_CONNECTED\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.517,974] \033[0m<dbg> bt_smp: bt_smp_recv: Received SMP code 0x02 len 6\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.518,035] \033[0m<dbg> bt_smp: smp_pairing_rsp: \033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.518,127] \033[0m<dbg> bt_smp: legacy_pairing_rsp: \033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.518,280] \033[0m<dbg> bt_smp: smp_c1: k 00000000000000000000000000000000\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.518,371] \033[0m<dbg> bt_smp: smp_c1: r 2ec0d9a9193c2b1b54b14f14734e4279\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.518,554] \033[0m<dbg> bt_smp: smp_c1: ia 40:68:15:E7:B9:37 (random)\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.518,737] \033[0m<dbg> bt_smp: smp_c1: ra F0:C9:75:7D:CB:FF (random)\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.518,829] \033[0m<dbg> bt_smp: smp_c1: preq 0100000d100707\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.518,890] \033[0m<dbg> bt_smp: smp_c1: pres 02030001100303\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.518,981] \033[0m<dbg> bt_smp: smp_c1: p1 01010100000d10070702030001100303\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:12.519,256] \033[0m<dbg> bt_smp: smp_c1: p2 ffcb7d75c9f037b9e715684000000000\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.018,035] \033[0m<dbg> bt_smp: bt_smp_recv: Received SMP code 0x03 len 16\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.018,127] \033[0m<dbg> bt_smp: smp_pairing_confirm: \033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.518,066] \033[0m<dbg> bt_smp: bt_smp_recv: Received SMP code 0x04 len 16\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.518,127] \033[0m<dbg> bt_smp: smp_pairing_random: \033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.518,188] \033[0m<dbg> bt_smp: legacy_pairing_random: \033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.518,280] \033[0m<dbg> bt_smp: smp_c1: k 00000000000000000000000000000000\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.518,371] \033[0m<dbg> bt_smp: smp_c1: r d316e0f3d51aaefd4c0a38df9f5ec1cb\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.518,554] \033[0m<dbg> bt_smp: smp_c1: ia 40:68:15:E7:B9:37 (random)\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.518,737] \033[0m<dbg> bt_smp: smp_c1: ra F0:C9:75:7D:CB:FF (random)\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.518,829] \033[0m<dbg> bt_smp: smp_c1: preq 0100000d100707\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.518,890] \033[0m<dbg> bt_smp: smp_c1: pres 02030001100303\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.519,012] \033[0m<dbg> bt_smp: smp_c1: p1 01010100000d10070702030001100303\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.519,287] \033[0m<dbg> bt_smp: smp_c1: p2 ffcb7d75c9f037b9e715684000000000\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.519,531] \033[0m<dbg> bt_smp: legacy_pairing_random: pcnf 2e7254e2fc169911f174a35f9f321152\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:13.519,622] \033[0m<dbg> bt_smp: legacy_pairing_random: cfm 2e7254e2fc169911f174a35f9f321152\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:28.018,096] \033[0m<dbg> bt_smp: bt_smp_disconnected: chan 0x20009bec cid 0x0006\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:28.018,188] \033[0m<dbg> bt_smp: smp_pairing_complete: status 0x8\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:28.024,200] \033[0m<dbg> bt_smp: bt_smp_encrypt_change: chan 0x20009bec conn 0x20009790 handle 0 encrypt 0x00 hci status 0x1f\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:28.024,261] \033[0m<dbg> bt_smp: smp_pairing_complete: status 0x8\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:28.024,444] \033[0m<inf> app: authPairingFailed: Pairing failed: F0:C9:75:7D:CB:FF (random) reason: 9
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:28.024,719] \033[0m<inf> app: securityChanged: Security failed: F0:C9:75:7D:CB:FF (random) level 1 err 9
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:28.024,780] \033[1;31m<err> bt_gatt_dm: bt_gatt_dm_start: Discover failed, error: -128.\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:28.024,841] \033[0m<inf> app: gatt_discover: Could not start the discovery procedure, error code: -128
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:28.030,883] \033[0m<inf> app: disconnected: Peripheral disconnected (reason 0x08)
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:01:28.031,372] \033[0m<inf> app: systemProcessThread: System got EVENT_BLE_PERIPHERAL_DISCONNECTED\033[0m
\

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

OwainIncus — Thu, 12 Jan 2023 13:57:38 GMT

Config for the App does not have CONFIG_BT_SMP_SC_ONLY set; and has CONFIG_BT_TINYCRYPT_ECC set.
I will attach the .config. Can you anything wrong in the BLE trace or does all look good?

The 37228 issue sounds pretty much like what I am getting....

devzone.nordicsemi.com/.../0042.config.txt

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

Hung Bui — Thu, 12 Jan 2023 13:31:02 GMT

Hi Owain,

Have you tried to test using the central_uart example to connect to the Polar ?

Do you use CONFIG_BT_SMP_SC_ONLY in your project configuration ?
This will force the pairing to only Secure Connection. It doesn't seem the Polar band support Secure Connection.

There is some discussion here with the same error BT_SECURITY_ERR_UNSPECIFIED and related to nRF53 and legacy pairing:

https://github.com/zephyrproject-rtos/zephyr/issues/37228

Could you try CONFIG_BT_TINYCRYPT_ECC=y to see if it work. Note that you may need to rebuild and reflash hci_rmsg

I would suggest to double check using nRF52 which doesn't seems to have this error.

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

OwainIncus — Thu, 12 Jan 2023 10:37:35 GMT

I just took another trace to be sure. Yes that is the trace.
Here the debug log ones sees for such a sequence.....

033[1;32mnovaPro>\033[mbt central heart connect 0
\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:24.080,566] \033[0m<inf> app: Updated MTU: TX: 23 RX: 23 bytes
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:24.080,932] \033[0m<inf> app: Central connected to F0:C9:75:7D:CB:FF (random)
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:24.080,993] \033[0m<inf> app: security is currently 1
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:24.082,550] \033[0m<inf> app: security set to BT_SECURITY_L2
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:24.086,486] \033[0m<inf> app: System got EVENT_BLE_PERIPHERAL_CONNECTED\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:40.088,104] \033[0m<inf> app: Pairing failed: F0:C9:75:7D:CB:FF (random) reason: 9
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:40.088,348] \033[0m<inf> app: Security failed: F0:C9:75:7D:CB:FF (random) level 1 err 9
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:40.088,409] \033[1;31m<err> bt_gatt_dm: Discover failed, error: -128.\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:40.088,470] \033[0m<inf> app: Could not start the discovery procedure, error code: -128
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:40.094,299] \033[0m<inf> app: Peripheral disconnected (reason 0x08)
\033[0m
\033[1;32mnovaPro>\033[m\033[8D\033[J\033[1;32mnovaPro>\033[m\033[8D\033[J[00:03:40.105,041] \033[0m<inf> app: System got EVENT_BLE_PERIPHERAL_DISCONNECTED\033[0m
\0

What we see here is in the connected() callback; where I check the security level before sayng I wish to set the L2.

Then 16 seconds later we see the securityChanged() callback with the level 1 error 9; followed by we drop into try and do the gatt_disover().

Looking into the bluetooth trace (I am not that familiar with these low level BLE protocols); packet 2568 at time 23.20s the slave sends the master a "SMP receved pairing random"; after which we just see empty PDU's tll approx 41s when the connection is dropped and the heartstrap starts advertising again.

So what is Noridic BT stack doing in those 16 seconds where the connencton is up; but t has not reported the success or failure; till the end of the 16 seconds where the error is reported?

I will try and get a better trace.

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

Hung Bui — Wed, 11 Jan 2023 15:32:35 GMT

Hi Owain,

Yes I can see the new trace now.
The new trace shows the exact same situation compared to the last one you sent back in May last year. The nRF5 didn't send the pairing confirm and then the slave disconnected.
I don't know why the central worked that way.

As I suggested earlier, have you tried to use the central_hr example we have in the SDK to see if it work ?

Your central code, does it work with other HR strap ? Did it do bonding with other strap ?

I would need to see how you configure the central , to see if there is any issue with security configuration.

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

OwainIncus — Wed, 11 Jan 2023 13:21:59 GMT

Hi Hung,

is this one OK?

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

OwainIncus — Wed, 11 Jan 2023 10:49:33 GMT

devzone.nordicsemi.com/.../novaToPolar.pcap.pcapng

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

Hung Bui — Wed, 11 Jan 2023 09:52:45 GMT

Hi Owain,

Could you please re-upload the sniffer trace ?

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

OwainIncus — Tue, 10 Jan 2023 18:06:45 GMT

My code is pretty much the Nordic example.

In the connected callback; if I just do the gatt_discover(); all is is good; my Polar H10 works fine; but if I set the security to L2; I get an error flagged in the security_changed callback for level 0 and error 9.

The same code works fine for a Garmin heartstrap setting security to L2.

We have just been using Garmin straps since I last posted the issue; but now I would like to tackle and get the Polar working.

See attached a wireshark BLE trace of the attempted connection from my 5340 to the Polar; setting security to L2.

Can you see anything in this trace to indicate why the connection would be dropped and the heartstrap starts advertising again?

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

OwainIncus — Tue, 10 Jan 2023 18:05:02 GMT

RE: 5340, Zephyr failure to connect to Polar Heart rate strap; ble wireshark trace

Hung Bui — Mon, 23 May 2022 12:39:15 GMT

Hei Owain,

You are right, the error is from the bt_security_err and it's BT_SECURITY_ERR_UNSPECIFIED not BT_SMP_ERR_REPEATED_ATTEMPTS.

I'm not so sure why the central didn't send LL_ENC_REQ (0x03) after receiving pairing Random from the peripheral. It's most likely the confirm value didn't match with the random value generated.
You can have a look at this message sequence chart from Bluetooth Spec v5.2 here:

My suggestion is to try testing the Polar strap with one of our central HR sample to see if it works. Please try to capture a sniffer trace with that.
Also, I don't know if removing the battery on the strap would make it clear the bond information or not. But if you can use other device to make a new bond/update bond then it should work with the nRF53.

I don't think the order where you do feature/phy request would affect the pairing process. However, you can control when the central starts the pairing process by choosing when to call bt_conn_set_security()