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 (by default "Empty Example" if using soc-empty as basis), so that it can be discovered by master devices. 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. During device connecting, new scan responses are blocked to handle one connection operation at a time (atomic) and to limit number of connections going over maximum in any case.
NOTE: To block master devices from connecting while the slave connection is on-going, the advertisements should be stopped. This is not mandatory but it simplifies the workflow by making connections as "atomic" operations and also helps limiting the number of connections going to maximum while an another is connecting.
A 10s timeout timer is also initiated in case the connection doesn't go through successfully (e.g. slave device goes out of range). It will stop the connection operation and restarts scanning.
If the connection is successful then we need to see if we have reached the maximum number of connections which is 3 by default for this example. It can be easily changed by changing the application MAX_CONNECTIONS define in app.c. (Note that there is also a stack total MAX_CONNECTIONS in main.c that should be greater than or equal than the application MAX_CONNECTIONS but not more than supported 8)
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. Also advertising is stopped.
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.
It is possible to use an another WSTK with the standard soc-thermometer app as slaves. And phones using for example Blue Gecko app to make a connection as a master using Bluetooth Browser.
Is there any support needed from the smartphone in regards to the 4.1 spec?
Most phones are 4.2 compliant.
That's good news!
Are there any figures on from what OS versions (Android & iOS) 4.2 is supported?
We would be able to build a major feature arround this but we'd have to know how well it would be supported by the customer smartphone.
There probably are but it's not something we keep track off, you need to find the answer elsewhere. What is the feature that you want to build around exactly?
We'd want to monitor multiple BGM111's by multiple phones.
We ware previously planning to do this by creating a link between the phones an repeat the data but this seems much better.
Ah, I see. you want to connect multi phones (as masters) to the same BGM111s (as slave) being that there will be several phones connected to each of the modules.
From the phone perspective this is just talking to several slaves which was already supported in 4.0 so no changes there, it will work with all 4.0 compatible phones (virtually all of them). But you need to have the latest SDK on the BGM111 to support the multiple master connections which was added on SDK2.0. Please be aware the maximum number of simultaneous connections (regardless if the role is slave or master) is limited to 8.
This saves us a ton of time!
Thanks for updating.
For our case, would I need to change anything in my BGscript or should this "just work" when using the new SDK?
It should just work when you go for the new SDK, assuming that your code is already looking for devices to connect to and advertising itself as connectable so that masters can connect (and re-advertising when a master connection occurs).