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):
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?