"High Duty Directed advertising" appears repeatedly and then Disconnected and Connected.

I am developing a keyboard using "ble_app_hids_keyboard" of SDK17.1.0 version.
When I look at the log during testing, "High Duty Directed advertising" appears repeatedly and then Disconnected and Connected.

What is this function and why does it appear like this?
And is there a detailed document about this?

High Duty Directed advertising.
Disconnected
Connected
High Duty Directed advertising.
Disconnected
Connected
High Duty Directed advertising.
Disconnected
Connected
High Duty Directed advertising.
Disconnected
Connected
High Duty Directed advertising.
Disconnected
Connected
High Duty Directed advertising.
Disconnected
Connected
High Duty Directed advertising.
Disconnected
Connected  

Parents
  • Hello,

    This is just an advertising method used directly after the disconnection so that if the disconnection was caused by packet loss, they would have a higher probability to reconnect faster. 

    So I guess the real question here is why do you get these continuous disconnections. You can start by adding:

            case BLE_GAP_EVT_DISCONNECTED:
                NRF_LOG_INFO("Disconnected - reason %02x", p_ble_evt->evt.gap_evt.params.disconnected.reason);

    Then you can look up this reason in ble_hci.h.

    My guess is that there is an issue with bonding. One of your devices, either the keyboard that you are developing, or the central device (Computer? Phone?) has an old set of bonding data stored, while the other device does not. Try erasing the bonding information on both devices, and try again. On the nRF, it can be done by erasing the chip, and re-programming the application (nrfjprog -e), or by holding button 1 (0 indexed) while powering on the device. 

    On the central side it depends on what device it is. On a computer you will typically remove the device from the computer's bluetooth settings, and the same goes for a phone, really. 

    Best regards,

    Edvin

Reply
  • Hello,

    This is just an advertising method used directly after the disconnection so that if the disconnection was caused by packet loss, they would have a higher probability to reconnect faster. 

    So I guess the real question here is why do you get these continuous disconnections. You can start by adding:

            case BLE_GAP_EVT_DISCONNECTED:
                NRF_LOG_INFO("Disconnected - reason %02x", p_ble_evt->evt.gap_evt.params.disconnected.reason);

    Then you can look up this reason in ble_hci.h.

    My guess is that there is an issue with bonding. One of your devices, either the keyboard that you are developing, or the central device (Computer? Phone?) has an old set of bonding data stored, while the other device does not. Try erasing the bonding information on both devices, and try again. On the nRF, it can be done by erasing the chip, and re-programming the application (nrfjprog -e), or by holding button 1 (0 indexed) while powering on the device. 

    On the central side it depends on what device it is. On a computer you will typically remove the device from the computer's bluetooth settings, and the same goes for a phone, really. 

    Best regards,

    Edvin

Children
Related