This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE disconnect every 30sec depending of the PC since Windows update

Our BLE HID mouse devices has work well during several months and since some windows update, on some PC, the BLE is disconencted every 30 sec.

We received a BLE_GAP_EVT_DISCONNECTED from the host.

Then we re advertize and reconnect in loop.

Only at the first pairing, we have no disconnection:

We are using SDK 15.2.

No issue with Nrf Connect on an Android Smartphone 

Regards,

  Sebastien

Parents Reply Children
  • Hi,

    Reason 34 = 0x22 = BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT

    Seems to be related to an  procedure has timed-out. I have seen in the past that some peer may not handle the case where MTU exchange/DLE update is initiated on BLE_GAP_EVT_CONNECTED event. Using a delay of for instance 100ms can workaround in such case, e.g. in on_connected_evt() in nrf_ble_gatt.c add a delay like this:

            nrf_delay_ms(100); // Add a delay
            err_code = sd_ble_gattc_exchange_mtu_request(conn_handle, p_link->att_mtu_desired);

    Though, it can also be something completely different, e.g. that the peer is initiating a BLE procedure that is not handled by the mouse (e.g. an event is not replied to). E.g.  case BLE_GAP_EVT_PHY_UPDATE_REQUEST event is not handled, and adding this may help:

            case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
            {
                NRF_LOG_DEBUG("PHY update request.");
                ble_gap_phys_t const phys =
                {
                    .rx_phys = BLE_GAP_PHY_AUTO,
                    .tx_phys = BLE_GAP_PHY_AUTO,
                };
                err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
                APP_ERROR_CHECK(err_code);
            } break;

    But to be 100% sure we need an on-air sniffer log.

    Btw, what softdevice and version are you using here?

    Best regards,
    Kenneth

  • Hi,

    I will try what you proposed.

    We are using s140_nrf52_6.1.0_softdevice.

    Regards,

    Sebastien

  • the first 100ms delay seems to fix the issue.

    Thanks a lot.

    100 ms is a lot, do you think this delay could be reduce ?

  • Shorter than 100ms can likely be used since it is a mouse, which typically use a connection interval of 7.5ms, you only need to make sure a few connection interval have elapsed. So try with 50ms.

    Best regards,
    Keneth

Related