Automatically re-connect to the previous bonded device in certain range

[Hao Tsui]

Hi there,

Currently, I am working on a project which uses iphone(or other IOS device) as a central, and nrf51822 as peripheral. Basically, the concept is that peripheral device stays in a fixed position, and according to the connection to central(iphone) device, peripheral device will activate/deactivate some functions. For example, when iPhone (central) closer, it(peripheral) turn on LED light, when iPhone(central) leave, it(peripheral) switch LED off.

I've tried to implement this service in Ble_peripheral -> ble_app_proximity (when in case BLE_LLS_EVT_LINK_LOSS_ALERT, switching on/off the LED).

I have few questions regarding to this project and hope someone can help me:

1. I put segger_rtt_writestring() in on_lls_evt(ble_lls_t * p_lls, ble_lls_evt_t * p_evt), and in case: BLE_LLS_EVT_LINK_LOSS_ALERT; and also in on_bas_evt(ble_bas_t * p_bas, ble_bas_evt_t *p_evt), in case: BLE_GAP_EVT_CONNECTED and BLE_GAP_EVT_DISCONNECTED

static void on_lls_evt(ble_lls_t * p_lls, ble_lls_evt_t * p_evt) { switch (p_evt->evt_type) { case BLE_LLS_EVT_LINK_LOSS_ALERT: alert_signal(p_evt->params.alert_level); // write a call function!

        SEGGER_RTT_WriteString(0," LINK LOSS ALERT!!!\r\n");
        //call_func();


        break;

    default:
        // No implementation needed.
        break;
}

} and

static void on_ble_evt(ble_evt_t * p_ble_evt) { uint32_t err_code = NRF_SUCCESS;

switch (p_ble_evt->header.evt_id)
{
    case BLE_GAP_EVT_CONNECTED:
        err_code = bsp_indication_set(BSP_INDICATE_CONNECTED);
        APP_ERROR_CHECK(err_code);

        m_advertising_mode = BLE_NO_ADV;
        m_conn_handle      = p_ble_evt->evt.gap_evt.conn_handle;
        // call the function
        SEGGER_RTT_WriteString(0," GAP_connected!!!\r\n");  // *****************
        break;

    case BLE_GAP_EVT_DISCONNECTED:
        err_code = bsp_indication_set(BSP_INDICATE_IDLE);
        APP_ERROR_CHECK(err_code);

        m_conn_handle = BLE_CONN_HANDLE_INVALID;
        SEGGER_RTT_WriteString(0," GAP_disconnected!!!\r\n");  // *****************
        advertising_start();
        break;
----
}

I noticed that: (In JlinkRTTClient) Once I connect to the service, it will output: LINK LOSS ALERT!!! GAP_connected!!! If I disconnect by myself, it will output only: GAP_disconnected!!

If the central and peripheral are disconnected due to the "far distance", it will output: LINK LOSS ALERT!!! GAP_disconnected!!!

I am wondering the reason behind this, is that case BLE_LLS_EVT_LINK_LOSS_ALERT mainly used for distinguish the disconnected between "manually" and "cause by distance"?

• second question

My second question is that in order to achieve the task(automatically re-connect), has anyone any suggestion? Following is my idea: In the beginning, I manually connect the devices (my iPhone and the peripheral), and after iPhone outside the reachable distance, the "case BLE_LLS_EVT_LINK_LOSS_ALERT" will call a function to turn off the LED. And after I comeback (closer at certain range), they will automatically re-connect and switch on the LED again!

Also, in terms of energy consumption, will this idea waste power due to the peripheral tries to detect is the iPhone within a certain range all the time?

I am a beginner, if anyone has the any solution or suggestion please kindly inform me :)

Best,

[FormerMember]

1)

"LINK LOSS ALERT!!!" will be printed if the reason for the disconnect is a timeout, i.e. the central is out of range and the peripheral doesn't receive any packet within the connection supervision timeout. When the disconnect reason is "timeout", the event BLE_LLS_EVT_LINK_LOSS_ALERT will be triggered, see on_disconnect(..) in ble_lls.c.

"GAP_disconnected" will be printed no matter what the disconnect reason is.

When the central disconnects the link, the reason is be something else than "timeout", and thus, only "GAP_disconnected" will be printed.

2)

For a fast reconnect, provided that the peripheral is within the range of the central, you can use directed advertising with high duty cycle. Directed advertising with high duty cycle does only last for 1.28 s. So if the peripheral initially is out of range of the central, it may be better to use normal advertising with a short advertising interval.

In addition, you have to set up the central device to automatically scan and re-connect upon a disconnection. I would think the Nordic iOS app nRF Toolbox --> proximity do that?

[Hao Tsui]

Hey, Kristin. It works fine now on NRF TOOLBOX, it will print out the "LINK LOSS ALERT" when iOS far away. and when iOS closer it automatically re-connect! It is cool!

However, when I used LightBlue to test again it did not automatically reconnect. Could you help me to figure out why there is different result testing on LightBlue and nRF toolbox?