We are currently developing a project using the nRF52832 as the microcontroller, Segger Embedded Studio version 5.42a as the IDE, and the nRF5 SDK 17.0.2. We began by creating a concurrent central and peripheral switching example project. Subsequently, we integrated the NUS (Nordic UART Service) client and peripheral functionalities into the nRF Relay example project.
Our setup involves three device types:
- Response Device: This device operates as both a central and a peripheral. In its central role, it scans for advertising packets from BLE beacon sensors. In its peripheral role, it awaits BLE connections from a central device. We have four response devices.
- Submaster Gateway Device: This device facilitates data transfer between the connected response devices and the supermaster device. It acts as both a central and a peripheral. In its central role, it establishes connections with the peripheral role of the response devices. In its peripheral role, it waits for connections from the supermaster gateway.
- Supermaster Gateway Device: This device is the final destination for data relayed through the submaster gateway. We have one supermaster device.
The code for these three devices is based on the nus_c and nus integrated nrf_relay example project
Initially, when we power on the four response devices, followed by the submaster device, all four response devices successfully connect to the submaster device. Then, when we power on the three additional response devices and the supermaster device, these three response devices and the submaster device successfully connect to the supermaster device. Data transmission and reception between any of the response devices and the supermaster device function correctly in this scenario.
However, if we power on the devices in a random order, connection issues arise. Devices frequently connect and then disconnect, exhibiting unstable behavior. This leads us to suspect potential timeout issues.
The following BLE macro definitions are used across all devices (response, submaster, and supermaster):
#define PERIPHERAL_ADVERTISING_LED BSP_BOARD_LED_2 #define PERIPHERAL_CONNECTED_LED BSP_BOARD_LED_3 #define CENTRAL_SCANNING_LED BSP_BOARD_LED_0 #define CENTRAL_CONNECTED_LED BSP_BOARD_LED_1 #define DEVICE_NAME "nRF Relay" /**< Name of device used for advertising. */ #define MANUFACTURER_NAME "NordicSemiconductor" /**< Manufacturer. Passed to Device Information Service. */ #define APP_ADV_INTERVAL 300 /**< The advertising interval (in units of 0.625 ms). This value corresponds to 187.5 ms. */ #define APP_ADV_DURATION 18000 /**< The advertising duration (180 seconds) in units of 10 milliseconds. */ #define APP_BLE_CONN_CFG_TAG 1 /**< Tag that identifies the SoftDevice BLE configuration. */ #define FIRST_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(5000) /**< Time from initiating event (connect or start of notification) to the first time sd_ble_gap_conn_param_update is called (5 seconds). */ #define NEXT_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(30000) /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */ #define MAX_CONN_PARAMS_UPDATE_COUNT 3 /**< Number of attempts before giving up the connection parameter negotiation. */ #define SEC_PARAM_BOND 1 /**< Perform bonding. */ #define SEC_PARAM_MITM 0 /**< Man In The Middle protection not required. */ #define SEC_PARAM_LESC 0 /**< LE Secure Connections not enabled. */ #define SEC_PARAM_KEYPRESS 0 /**< Keypress notifications not enabled. */ #define SEC_PARAM_IO_CAPABILITIES BLE_GAP_IO_CAPS_NONE /**< No I/O capabilities. */ #define SEC_PARAM_OOB 0 /**< Out Of Band data not available. */ #define SEC_PARAM_MIN_KEY_SIZE 7 /**< Minimum encryption key size in octets. */ #define SEC_PARAM_MAX_KEY_SIZE 16 /**< Maximum encryption key size in octets. */ #define HART_RATE_SERVICE_UUID_IDX 0 /**< Hart Rate service UUID index in array. */ #define RSCS_SERVICE_UUID_IDX 1 /**< RSCS service UUID index in array. */ #define NUS_SERVICE_UUID_TYPE BLE_UUID_TYPE_VENDOR_BEGIN /**< UUID type for the Nordic UART Service (vendor specific). */ #define APP_BLE_OBSERVER_PRIO 3 #define DB_DISCOVERY_INSTANCE_CNT 2 /**< Number of DB Discovery instances. */ #define BUZZ_PIN 20 #define POWER_STS 19 #define BATTERY_ON 22 #define POWER_ON 0 #define POWER_OFF 1 #define CLEAR 0 #define SET 1 static ble_hrs_t m_hrs; /**< Heart Rate Service instance. */ static ble_rscs_t m_rscs; /**< Running Speed and Cadence Service instance. */ static ble_hrs_c_t m_hrs_c; /**< Heart Rate Service client instance. */ static ble_rscs_c_t m_rscs_c; BLE_NUS_C_ARRAY_DEF(m_ble_nus_c_arr, NRF_SDH_BLE_CENTRAL_LINK_COUNT); BLE_NUS_DEF(m_nus, NRF_SDH_BLE_TOTAL_LINK_COUNT); NRF_BLE_GQ_DEF(m_ble_gatt_queue, NRF_SDH_BLE_CENTRAL_LINK_COUNT, NRF_BLE_GQ_QUEUE_SIZE); NRF_BLE_GATT_DEF(m_gatt); NRF_BLE_QWRS_DEF(m_qwr, NRF_SDH_BLE_TOTAL_LINK_COUNT); BLE_ADVERTISING_DEF(m_advertising); BLE_DB_DISCOVERY_ARRAY_DEF(m_db_discovery, 6); NRF_BLE_SCAN_DEF(m_scan); static uint16_t m_conn_handle = BLE_CONN_HANDLE_INVALID; static uint16_t m_conn_handle_hrs_c = BLE_CONN_HANDLE_INVALID; static uint16_t m_conn_handle_rscs_c = BLE_CONN_HANDLE_INVALID; static uint16_t m_conn_handle_nus_c_arr[NRF_SDH_BLE_CENTRAL_LINK_COUNT];
Does having the same advertising and connection parameter delays on all three devices affect the issue? Or, is it possible that a connection problem occurs when one device tries to connect via BLE but another device is not ready?
