https://devzone.nordicsemi.com/f/nordic-q-a/11263/distinguish-new-connection-from-previousHello, I am developing a wearable device that utilises nRF51822. Right now, I am having a problem because when the wearable device is connected to a new phone, it needs to be able to know that and reset memory. How should I go about distinguishingen-USTelligent Community 13Tue, 12 Jan 2016 11:21:45 GMThttps://devzone.nordicsemi.com/thread/42349?ContentTypeID=1Tue, 12 Jan 2016 11:21:45 GMT137ad170-7792-4731-bb38-c0d22fbe4515:d4270797-9862-4b48-a1e5-1c35be13be8dPetter Myhre<p>Two other solutions come to mind:</p> <p>The first solution is only valid if memory isn&#39;t accessed before you bond. If you are bonded to the central, you will receive the BLE_GAP_EVT_SEC_INFO_REQUEST event when the central wants to encrypt the link, see <a href="http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v2.0.0/group___b_l_e___g_a_p___p_e_r_i_p_h___e_n_c___m_s_c.html?cp=1_3_0_1_0_2_0_1_0_10">this</a>. If you are not bonded you will receive the BLE_GAP_EVT_SEC_PARAMS_REQUEST event when the central wants to bond, see <a href="http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v2.0.0/group___b_l_e___g_a_p___p_e_r_i_p_h___b_o_n_d_i_n_g___j_w___m_s_c.html?cp=1_3_0_1_0_2_0_1_0_6">this</a>. You can use this event to trigger a memory reset.</p> <p>The second solution is to try to resolve the device address with the IRK(s) of the currently bonded central(s). Have a look at Ulrich&#39;s answer <a href="https://devzone.nordicsemi.com/question/38730/resolve-ble_gap_addr_type_random_private_resolvable-address-without-using-whitelist-advertising/">here</a>. If you are able to resolve, don&#39;t reset memory, if you are not, reset memory.</p><div style="clear:both;"></div>