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.



Example Description


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)



Connecting to Slaves


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. 



Connecting to Masters


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.



Testing the Example


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.



  • Knowledge Base Articles
  • Bluetooth Low Energy
  • Bluetooth Classic
  • 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.


  • Hi,


    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. 

  • He @tmonte,


    For our case, would I need to change anything in my BGscript or should this "just work" when using the new SDK?

  • Hi @spiritonline


    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).