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

Bluetooth disconnects after being connected for 18 hours

Hello,

I am working with nrf5281 and its bluetooth connection, the connection is established well and the chip and the nrf connect application stay connected, however the connection is lost after about 18 hours or so, what I want to achieve is to keep the connection for several days or weeks.

I have not been able to debug for the same reason that the disconnection occurs too long after the connection is established.

I leave here the parameters that I am using for the connection, I would like to know if to achieve the connection for several days can be accomplished only by changing some of these parameters.

#define APP_ADV_INTERVAL                625                                     

#define BATTERY_LEVEL_MEAS_INTERVAL     APP_TIMER_TICKS(5000)                 


#define APP_ADV_DURATION                8000                                  
#define APP_BLE_OBSERVER_PRIO           3                                       
#define APP_BLE_CONN_CFG_TAG            1                                       

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(100, UNIT_1_25_MS)        
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(200, UNIT_1_25_MS)        
#define SLAVE_LATENCY                   0                                      
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(6000, UNIT_10_MS)         

#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(5000)                 
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(30000)                  
#define MAX_CONN_PARAMS_UPDATE_COUNT    5                                       

#define SEC_PARAM_BOND                  1                                       
#define SEC_PARAM_MITM                  0                                       
#define SEC_PARAM_LESC                  0                                       
#define SEC_PARAM_KEYPRESS              0                                       
#define SEC_PARAM_IO_CAPABILITIES       BLE_GAP_IO_CAPS_NONE                    
#define SEC_PARAM_OOB                   0                                       
#define SEC_PARAM_MIN_KEY_SIZE          7                                       
#define SEC_PARAM_MAX_KEY_SIZE          16   

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
    bool erase_bonds;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_DISCONNECTED:
            buttons_leds_init(&erase_bonds);
            sleep_mode_enter();
            break;

        case BLE_GAP_EVT_CONNECTED:
            bsp_indication_set(BSP_INDICATE_CONNECTED);
            m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
            nrf_ble_qwr_conn_handle_assign(&m_qwr, m_conn_handle);
            break;
            
        default:
            break;
    }
}

Parents Reply
  • Hello José,

    Thank you for your patience with this. The summer holidays have begun here in Norway, and DevZone is therefore operating with reduced staff for the time being. Sorry for any inconvenience this might cause.

    joshu2991 said:
    I have seen the error in the nrf connect log

    The Error 22 (0x16): GATT CONN TERMINATE LOCAL HOST means that the central (phone) has terminated the connection.
    It seems to me that the message prior to the error contains an acl_disconnect action.
    Could you provide me the entire log, in text - not a screenshot - from when this happens?
    It could also be beneficial to see a sniffer trace of the communication happening right before this disconnect occurs.

    joshu2991 said:
    Honestly I have not been able to find the parameters that allow a connection for at least a week, and in all the posts I have found none of them explain this. Could you help me to know what values I should use? Thank You!

    The connection parameters will either be accepted, or rejected. In the case that they are rejected, the connection will be terminated from the side that rejected the parameters. Since the central is the one that actually decides which parameters is used, a disconnect for this reason is likeliest to be initiated from the peripheral side of the link. In your log, it seems that it is the central that initiated the disconnect, and therefore I do not think that the connection parameters are what is causing this. I think we should look more into what is happening in the log and/or sniffer trace prior to the disconnect, to understand what is happening here.

    Looking forward to resolving this issue together!

    Best regards,
    Karl

Children
No Data
Related