Two of the main features introduced in Bluetooth SDK 2.0.0 were dual-topology and multi-master support which are part of the Bluetooth 4.1 spec:
Dual-Topology: Maintaining simultaneous connections as a master and a slave
Multi-Master: Having more than one simultaneous master connection
In this article we will show how to initiate and maintain both master and slave connections and what are the recommendations for simplifying the application flow and how to handle the corner cases.
The attached example has the following high-level flow-chart.
The basic principle to support multi-master/multi-slave/dual-topology operation is that the device must be advertising and scanning simultaneously.
After boot the device starts advertising with the device name "MSMMDT" (so that it can be discovered by master devices) and it also starts scanning (so it can discover slave devices)
In the scan response event it will be looking for devices advertising the Health Thermometer Service (UUID: 0x1809) and it will try to connect to them.
To block master devices from connecting while the slave connection is on-going the advertisements are stopped. This is not mandatory but it simplifies the workflow by making connections as "atomic" operations. A 10s timeout timer is also initiated in case the connection doesn't go through successfully (e.g. slave device goes out of range) and for simplification purposes it is not included in the above flow-chart.
If the connection is not successful then we simply resume scanning and advertising. If the connection is successful then we need to see if we have reached the maximum number of supported connections (which is 8 for this example but can be easily decreased by changing the MAX_CONNECTIONS define). If we have reached the maximum number of connections then we don't resume scanning (no new slave connections can be established) but we can resume advertising as NON-CONNECTABLE.
As master connections are created we also need to see if we have reached the maximum number of support connections. If we haven't reached it then we can simply resume advertising because that is automatically stopped when a master connects (scanning is not affected by master connections so that will continue uninterrupted). If we have reached it then we must stop scanning and advertise as NON-CONNECTABLE.
If a disconnection occurs we check if the remaining number of connections is maximum - 1, in which case we can resume scanning and advertising to allow a new connection to form.
The code example prints out debug information over the WSTK VCOM @ 115200 baud (without flow-control). As you start connecting to slave and master devices you should see a debug log as depicted below.
For this example 2 iPhones and 6 BLED112 were used. The iPhones were using a generic BLE app and the BLED112 devices were controlled by the BLE GUI and programmed with the standard usbcdc example to which we added the HTM service to the GATT (attached to this article).
The two possibilities for the last supported connection are both shown:
- When the last connection is with a Slave device scanning had already been stopped before connecting so it resumes advertising as NON-CONNECTABLE
- When the last connection is with a Master device then scanning needs to be explicitly stopped and advertising resumes as NON-CONNECTABLE
To finalize, also the disconnection behavior is shown. When a disconnection occurs after we've had all the devices connected then scanning and advertising is resumed, otherwise no actions need to be taken.