Peripheral Not Responding to LL_FEATURE_REQ

[Dave_couling]

What issues could cause a Peripheral to not respond to the LL_FEATURE_REQ?   Devices are in close proximity so its not an RF issue.

Regards,

DC

[Kenneth]

Hello,

Can you share the sniffer trace?

Also, can you read out the disconnect reason? It should be passed with the BLE_GAP_EVT_DISCONNECT event in p_ble_evt->evt.gap_evt.params.disconnected.reason, I expect reason to be one of the Bluetooth status codes as listed in ble_hci.h.

It may also be as simple as the connection request packet was not received by the peripheral device (I expect this may happen in <3-5% of the connection attempts in a normal office environment due to interference), the peripheral will continue to advertise as nothing happened in such case.

Best regards,
Kenneth

[Dave_couling]

..

[Kenneth]

I don't think the 0x13 disconnect reason belong to the above log, I think that 0x13 may be from the previous connection.

A disconnect reason 0x13 (BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION) means that the peer have terminated the connection, this is not shown here.

From the above log I would however suspect 0x3E (BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED), since the connection is not successfully established. However it may also be that the CONNECT_IND packet was not received by the peripheral, in which case there will be no disconnect reason, simply because the CONNECT_IND packet was not received.

I don't think there is much that can be done here, the only parameter that I would think could have a influence here would be the NRF_SDH_CLOCK_LF_ACCURACY, you may try to set NRF_SDH_CLOCK_LF_ACCURACY 1 in sdk_config to check if that make any difference.

Kenneth

[Dave_couling]

..

[Kenneth]

Have you tried repeating the same using internal RC as LFCLK?

The central device should by BLE spec send the first packet between (transmitWindofOffset+1.25ms) and (transmitWindofOffset+1.25+transmitWindowSize). Can you see from the timing if that occurs?

Kenneth

[Dave_couling]

..