Other Parts Discussed in Thread: BLE-STACK
I am fairly new to BLE and embedded device development and I am testing out an application design of using the LP-CC2652RB (as well as the CC26X2R1 Launchpad) to act as a central device, scanning and connecting to peripherals: Eddystone beacons which mainly utilize a third party chipset (NRF52810).
The application processes involve the central device scanning the peripherals within the ranges of the central device and then connecting to each peripherals one by one to collect some data and issue some custom commands from the central to the peripherals. Therefore a connection is necessary for the 2 ways communication. At any given point of time, there could be up to a dozen or even more than a hundred non-stationary peripherals beacons within the range of central device. And the application requires the central device to be able to exchange data with each peripheral devices before the peripheral leaves the communication range of the central device.
Therefore I do need to implement a very robust scanning and connecting mechanism to peripheral devices from the central device. I am using CC13x2_26x2 SDK 4.30.0.54. and I am building my test application by modifying the simple_central example project. The beacon I use have a 2.5 second advertising interval and I am using standard 1M phy to scan and connect to them from the central device.
I have done my reading on the forum, the BLE stack user guide, and the SimplyLink Academy, but I don't seem to be able to find the exact answer I am looking for.
The questions I have are similar to the discussion in this thread:
e2e.ti.com/.../3142669
I would like to understand what is the BLE stack behavior in the following scenarios.
In the reference thread I referred above, Vetle mentioned that "you can resolve information from multiple peer devices during one scan. This means that after one scan, you are ready to initiate connections to all your peer devices (one by one)". Assuming I have 3 beacons peripheral in range, and the central device acquire all their address on one scan, what is the best practice to connect and exchange data to each of the 3 beacons?
Right now, I am following the simple_central example to connect to the one beacon at a time by issuing the one GapInit_connect () command with 2750 ms as the timeout parameter, then set the flag variable memberInProg (connection in progress) to true and then wait until the connection is either establish or cancelled(timeout), then the flag variable will be set to false; afterwards, the application proceeds with connecting the second beacon. In terms of the time taken to connect to all 3 of the beacons in range, the worst case theoretical time will be 7.5 seconds to be able to establish connection to all the 3 beacons, one after another. And in real case, the timing is somewhat similar to the worst case scenario, since the application do have to wait the full 2750 ms for the timeout to happen in the case where the connection fails to establish.
Is 2750ms an optimal value for the timeout parameter? Given that the beacon is advertising at 2.5 seconds interval, and in the worst case scenario the central device connection request will meet the peripheral's next advertising packet, it seems that 2750 ms should be sufficient to provide all the time necessary for the connection to be established. At least this is what my understand of how the "timeout" logic works. Or am I wasting too much time here to wait for a possible success connection?
During the time which the the central device wait for the peripheral to establish a connection, can the BLE stack do anything else? To be clear, I am explicitly referring to the time between the issuing of the Gapinit_connect command and receiving the Connection_establish_event or Connection_cancelled_event. I read in the forum that " TI BLE-Stack has an internal scheduler that prioritizes between different BLE tasks (connection event, scanning for advertisements)". (can anyone point me to resource that I can understand how the internal scheduler work? which type of operations got priorities over the others.) Therefore, without in-depth knowledge, I am not sure if it will be "safe" to issue other BLE commands, for example: scanning for advertising packet, or GATT commands for exchanging data with already connected beacon during this waiting time? The reference thread suggested that "The connection initiation is directed to a specific peer device (address), and the central will stay in this mode waiting for an advertisement from the specific address until the peer device replies", it is not clearly to me that when the central staying in this "waiting mode", can it do anything else or if I ask it to do something else, will it affect the chance of successfully establish connection to the target peripheral.
The reason I am asking this is because in my current application design: after the central established connection with first peripheral, it will then proceed to call the Gapinit_connect to the 2nd peripheral, however while waiting for the 2nd peripheral to establish the connection, the application will continue to send GATT read and GATT write command to the first connected peripheral. Does this has an adverse effect on connection establishment of the 2nd peripheral beacon? aside from GATT read and write, is it possible to also do scanning while the central is in this "waiting mode"?
In this current design, I am facing an issue where I am observing quite a high rate of timeout in cancelled connection establishment (getting the connection cancelled event). In my testing scenario, I have 3 peripheral beacons (the type mentioned above) located 5cm apart from the LP-CC2652RB launchpad. The test scenario involves connecting to each of the beacons one by one, then exchange data, finally disconnect, and start all over again. Running the application for an hour, the statistics are around 600 successful connections and 550 occasions of connection cancelled timeout; the ratio is almost 1:1. I am quite surprised by this number and wonder if I am doing anything wrong with my design.
I also have a question on the Gapinit_connect command return status where it says bleNotReady and bleAlreadyInRequestMode, what exactly are their differences in terms of meaning? Does bleAlreadyInRequestMode means that a connection initiation is already in progress and cannot start a second Gapinit_connect() process? And what situation will the stack report a bleNotReady status instead.
If I am to re-design my application current process flow, will it be possible to do the following?
What happening if I issue GapInit_connect() command to all 3 beacons consecutively after a scan? Will the BLE stack internal scheduler automatically queue up the 3 commands, and then report success/fail of connection as the BLE stack processes the connection requests one by one? Or will it report bleAlreadyInRequestMode on the Gapinit_connect() command targeting the second peripheral, while the central waiting for the connection to establish on the first peripheral?
Thank you.
