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

nRF52833 - BLE - How to handle BLE_GAP_EVT_PHY_UPDATE_REQUEST?

Hi Nordic team, 

I am having issues to connect to my Nordic device. The connection times out. By doing some research on the dev zone, it seems a known issue that could be related to update of physical layer for Bluetooth 5.0. 

My device is nRF52833. I am using s140 and sdk17.0.2. 

Here are my questions:

  1. Is the physical layer update needed? 
  2. If yes, why? Is there a way to know what soft device and/or what devices need this update?
  3. If yes, how to handle the PHY update request?  

Many thanks 

Parents
  • Hello,

    1. No, not necessarily, but the application must respond to PHY update requests if sent by the connected peer device. Otherwise the connection will time out like you mentioned.

    This message sequence chart illustrates some different scenarios: Peripheral PHY Update and only scenario #1 if don't care about issuing phy update requests.  And here is how we handle PHY update requests in our SDK examples by default:

    /**@brief Function for handling BLE events.
     *
     * @param[in]   p_ble_evt   Bluetooth stack event.
     * @param[in]   p_context   Unused.
     */
    static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
    {
        ret_code_t err_code;
    
        switch (p_ble_evt->header.evt_id)
        {
        ...
        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;

Reply
  • Hello,

    1. No, not necessarily, but the application must respond to PHY update requests if sent by the connected peer device. Otherwise the connection will time out like you mentioned.

    This message sequence chart illustrates some different scenarios: Peripheral PHY Update and only scenario #1 if don't care about issuing phy update requests.  And here is how we handle PHY update requests in our SDK examples by default:

    /**@brief Function for handling BLE events.
     *
     * @param[in]   p_ble_evt   Bluetooth stack event.
     * @param[in]   p_context   Unused.
     */
    static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
    {
        ret_code_t err_code;
    
        switch (p_ble_evt->header.evt_id)
        {
        ...
        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;

Children
No Data
Related