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
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
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
..
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
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
..
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
..
If you see the same with RC LFCLK (with 500ppm tolerance configured) then it's not related to clock or timing. Based on what I have seen so far the sniffing snippet you have shared and the disconnect reason you have shared does not match, and the only explanation to that is missing connection request packet and that the disconnect reason was for different connection.
Kenneth