Dear Sirs,
I have a sensor working as a peripheral and using the Nordic NUS service. I have a poblem discovering the two MSBits of the sensor's address when it connects to a nRF52840-DK working as a central device. To help to test this issue, I am running the ble_app_uart_c application example in the nRF52840-DK board.
Debugging the ble_app_uart_c application, I have put a breakpoint in the execution of the BLE_GAP_EVT_CONNECTED event into the ble_evt_handler() function (just after the execution of the ble_db_discovery_start() function). When the sensor device connects, I understand that all the information of this device is on the local p_ble_evt->p_gap_evt structure, according to the next code:
static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
ret_code_t err_code;
ble_gap_evt_t const * p_gap_evt = &p_ble_evt->evt.gap_evt;
switch (p_ble_evt->header.evt_id)
{
case BLE_GAP_EVT_CONNECTED:
err_code = ble_nus_c_handles_assign(&m_ble_nus_c, p_ble_evt->evt.gap_evt.conn_handle, NULL);
APP_ERROR_CHECK(err_code);
err_code = bsp_indication_set(BSP_INDICATE_CONNECTED);
APP_ERROR_CHECK(err_code);
// start discovery of services. The NUS Client waits for a discovery result
err_code = ble_db_discovery_start(&m_db_disc, p_ble_evt->evt.gap_evt.conn_handle);
APP_ERROR_CHECK(err_code);
break;
case BLE_GAP_EVT_DISCONNECTED:
NRF_LOG_INFO("Disconnected. conn_handle: 0x%x, reason: 0x%x",
p_gap_evt->conn_handle,
p_gap_evt->params.disconnected.reason);
break;
case BLE_GAP_EVT_TIMEOUT:
if (p_gap_evt->params.timeout.src == BLE_GAP_TIMEOUT_SRC_CONN)
{
NRF_LOG_INFO("Connection Request timed out.");
}
break;
case BLE_GAP_EVT_SEC_PARAMS_REQUEST:
// Pairing not supported.
err_code = sd_ble_gap_sec_params_reply(p_ble_evt->evt.gap_evt.conn_handle, BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP, NULL, NULL);
APP_ERROR_CHECK(err_code);
break;
case BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST:
// Accepting parameters requested by peer.
err_code = sd_ble_gap_conn_param_update(p_gap_evt->conn_handle,
&p_gap_evt->params.conn_param_update_request.conn_params);
APP_ERROR_CHECK(err_code);
break;
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;
case BLE_GATTC_EVT_TIMEOUT:
// Disconnect on GATT Client timeout event.
NRF_LOG_DEBUG("GATT Client Timeout.");
err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gattc_evt.conn_handle,
BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
APP_ERROR_CHECK(err_code);
break;
case BLE_GATTS_EVT_TIMEOUT:
// Disconnect on GATT Server timeout event.
NRF_LOG_DEBUG("GATT Server Timeout.");
err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gatts_evt.conn_handle,
BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
APP_ERROR_CHECK(err_code);
break;
default:
break;
}
}
The data captured in this breakpoint is on the next file attached in text format
3051.ble_app_uart_c_pca10056_s140_BLE_GAP_EVT_CONNECTED_Variables.txt
I can see that the p_ble_evt->evt.gap_evt.params.connected.peer_addr.addr_type has the value 0x01. According to the information in Nordic'c infocenter (https://infocenter.nordicsemi.com/index.jsp) this value correspond to a BLE_GAP_ADDR_TYPE_RANDOM_STATIC type. Anyway, the sensor always sends the same address information.
The p_ble_evt->evt.gap_evt.params.connected.peer_addr.addr array has the values (LSB first) 14:99:89:4D:FB:E3. And this values are also cloned into the local ble_gap_evt_t const * p_gap_evt variable.
However, the real address of this sensor peripheral it's supposed to be 14:99:89:4D:FB:23, so there is a misalignment in the two MSBits. I read two '11' (so 0xE3 values) in spite of the right '00' that I should recover (0x23). Please, and considering the different fields in the structures of the variables captured in the text file, may you help me in understanding HOW may I get this right 0x23 MSB value?
I also find this issue in other units of this type of sensor. However, and depending on the address unit, the address recovered matches with the right one. For example, for one device with the MSB value of 0xFB I can see this 0xFB into the p_ble_evt->evt.gap_evt.params.connected.peer_addr.addr.
If this may helps as another clue, the sensor manufacturer has an iPhone app that recovers the right address (used for filtering purposes), with the rigth 0x23 MSB, by reading the "Manufacturer Data" field. What I understand of this data is that the sensor management of its address is a customized one and that it has to be a solution to manage by using the Softdevice.
Thank you very much in advance.
Best Regards,
Joel
