Hrs Peripheral Example

[MPH]

Hi, can you assist please....

I am using the Hrs example in SDK 17.0.2 as the basis for an application.

Using an unmodified code by loading the supplied hex file ble_app_hrs_pca10040_s132.hex loaded into an nRF52 DK board I notice a few things...

If I use the nRF Toolbox App everything appears to work fine and I see Advertising, Connection and the peripheral sending data to the App via a Sniffer/nRF Dongle. This does not appear to use LESC.

However if I follow the in the example notes https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v12.0.0%2Fhardware_driver_twi.html&cp=4_0_0_2_18

and use nRF Desktop I am not able to observe the same behaviour. I can connect via nRF Desktop & I see Advertising via the Sniffer ok. I follow the notes to initiate pairing and that looks good but if I press "Play" to try and get data from the peripheral nothing happens, meaning I don't see a regular transmission from the Slave/peripheral and eventually there is a disconnection by the Slave.

Whilst following the sequence in the notes I get this report from nRFdesktop. 

After connection but before the Disconnection I get this Sniffer trace which shows the pairing appears completed ok but thereafter I don't see anything coming back from the peripheral/slave.

In nRF Desktop I get a green text indicating Pairing ok?

This is the "Play/Stop" button in nRF Desktop I am using...

So I think I am following the test notes ok but maybe I'm doing something wrong or there is some more detail?

If I retry a connection but without pairing again I get...

So the link appears to use encryption ok but the result is the same meaning there is no Peripheral/slave regular transmission of (heart rate or other) data and after some timeout...

If I clear the bonding info by resetting on the nRF52 DK and go through the same procedure but without pairing I get the same result, meaning no regular transmission of heart rate etc from the Peripheral/slave.

This is the Sniffer trace in the above case.....

I have followed the pairing settings shown in the example notes which show to enable LESC,MITM & Bonding. I did do that but also not enabling MITM and I don't see any behaviour change, I consider the Peripheral ignores the MITM setting. The same goes for the I?O capabilities. I'm not sure MITM is valid using the nRF52 DK so perhaps this setting is not valid for the notes.

My application will want to use LESC and so I need to understand what is going on with these observations.

Your help would be appreciated.

Have a great weekend.

Martin

[MPH]

Hi, I developed the peripheral application further with another nRF52 DK programmed with the Hrs central example. That pair of boards works as expected and so now it is nice to know the reason why the observations in the thread above are being made. 

Regards Martin

[Amanda Hsieh]

Hi Martin, 

Are you able to provide the log from the terminal tool? 

Would you see the same issue if you do "Erase all" before "Erase & write" on that board? I cannot reproduce that issue on my side and hard to say what causes that without the log. 

-Amanda H.

[Amanda Hsieh]

Hi Martin, 

The disconnection reason 34 (0x22) is BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT  which is the same as the log indicates on the nRF Connect BLE app after the connection parameters update. 

What do you modify the example?

What OS is the nRF Connect BLE App running on? 

The LENGTH_REQ is not handled correctly and will result in a LMP_RESPONSE_TIMEOUT. You could try to modify the NRF_SDH_BLE_GATT_MAX_MTU_SIZE as 23 in the sdk_config.h.

-Amanda H.

[MPH]

Hi Amanda 

I did not modify anything, hex file loaded into a nRF52 DK as mentioned. Then just following the notes for the Hrs example.

Win 10 for the OS.

Regards Martin

[Amanda Hsieh]

Hi Martin, 

Are you able to upload the sniffer log? Thanks. 

-Amanda H.

[MPH]

There are a couple above Amanda

[Amanda Hsieh]

No, I need the sniffer file instead of the images for the last disconnection of LMP_RESPONSE_TIMEOUT if you want to know the root cause. The original disconnect reason is BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION, and the third Sniffer trace image shows the master side disconnected connection. That is different from what I saw after your last update. 

-Amanda H.

[MPH]

I don't have the log saved Amanda.

If I get a spare moment I'll send one but can't commit to a timeframe. 

Regards Martin

[MPH]

Hi Amanda

I had time to revist this today and have better news.

After reprogramming the 2 nrF52DKs, swapping some cables and connections to a USB hub everyting apperas to function as expected! I cannot pin point what was wrong, however one of the DKs needed to have the Jlink OB loaded again, more recently it was being used with the first PPK.

If it happens again and I get more clues etc I'll let you know.

Have a great weekend.

Martin

[Amanda Hsieh]

Hi Martin, 

Thanks for the update. 

Have a nice weekend.

-Amanda H.