BLE Protocol for one peripheral connected to multiple centrals

Question

Hi, we have a project that we're currently working on, and we're looking for some information on BLE behaviour that would be very helpful. We are currently using SDK 15.3 and softdevice s132 v6.1.1. 
 We are looking to implement a setup where we would have our nRF52832 in a peripheral role connected to multiple mobile devices (iOS and Android) with central roles. The main goal of the wireless communication is to have the nRF chip send one notification (containing a single 8-bit value) to each connected device once per connection interval. We would also like to be able to send as many notifies as possible to each connected device (ideally ~20/sec each), i.e. have as small a connection interval as possible. Before trying to work out the timing / BLE scheduling, there are a few questions that I'm unsure about: 
 
 Since it is the peripheral doing all of the communication (via notifications), will the softdevice be able to set up the most efficient scheduling to get the notifies out as quickly as possible? 
 With the peripheral be able to dictate the connection intervals, or will that be determined by the individual centrals? 
 I read in the s132 documentation that a notify takes 2.5ms to transmit. Is that correct? If so, does that mean that if the connection interval is 10 ms for 4 connected devices, the peripheral would be able to send out one notify to each device? 
 In order to minimize the connection interval (to send as many notifies as possible), is it possible to adjust the connection interval depending on many devices are connected to the peripheral (i.e. adjust the value each time a new device is connected)? Or is it better to have a set value to be able to accommodate the max number of connected devices? 
 In a situation where there are connected devices receiving notifies from the peripheral and then a new central initiates a new connection, will the notifies stop being sent until that new connection is established? 
 Along the same line, if we would like the centrals to be able to send messages (writes) to the peripheral, will that interfere with the notifies that the peripheral is trying to send? i.e. Will the writes collide with the notifies and take priority? 
 
 I apologize for all of the questions, but any answers to them would be much appreciated! Thanks!

ovrebekk · Accepted Answer

Hi Adam 
 1. It is the central that is the link layer master, and decides the timing of each connection. The peripheral can request different connection parameters by issuing an connection parameter update request, but the the central will always have the final say. 
 The notification latency is primarily decided by the connection interval, which can be anywhere in the 7.5ms to 4s range, and the peripheral should request a range of values suitable to the use case (lower values give lower latency but also higher average current consumption). 
 An nRF52 based central will normally allow the shortest connection interval (7.5ms), but as Darren mentioned this is usually not the case for mobile phones. 
 2. As mentioned above the central decides the connection parameters, but the peripheral can request a change. In our examples you can have the peripheral disconnect if it can't get the right connection parameters, but this can be changed so that it accepts what it gets instead. 
 3. Do you have a link to this comment? It doesn't take a full 2.5ms to send a single notification, but 2.5ms is the minimum time needed to serve a single connection event. This means that if your connection interval divided by the number of connections is smaller than 2.5ms you won't be able to serve every connection for each interval, which will increase the latency. 
 4. I think it's better to request the same connection interval regardless of the number of connected devices, as there is quite a bit of overhead involved when changing this. The SoftDevice has a system for handling scheduling conflicts when a device is connected to multiple different centrals. 
 5. No, you can keep sending notifications while establishing a link to a new central, but if the timing of the new connection conflicts with the timing of one of the current connections you might see delays. 
 6. No. Every connection event starts with a packet from the central to the peripheral, followed by a response packet from the peripheral to the central. The peripheral will never send anything without receiving the packet from the central first. 
 Queued writes on the central side will be included in the first packet, while queued notifications in the peripheral would be included in the second packet. 
 Best regards Torbjørn

BLE Protocol for one peripheral connected to multiple centrals

Top Replies