What is the most efficient method to share data with piconet slaves?

[youti]

Hi all,

In our application we have a piconet master (acting as GATT client) and several piconet slaves (acting as GATT servers). We have only limited time on the channel and therefore want this data sharing to be as time consuming as possible. We came up with some solutions, but are (very) unsure whether this is possible at all:

• On each connection update, replace the normally Empty PDU with another packet that wraps the relevant data. We basically want something like a Write Without Response that also ensures the connection remains alive;
• Broadcast all data on the GATT client at once to all GATT servers;

Our application uses the Nordic 15.0.0 SDK. Hence are our solutions possible at all? Is there another method that is approved by most BLE users?

I hope to hear from you!

Cheers

[Hung Bui]

Hi Remi, 

It's not really clear for me on what your requirements and your plans are. 

What do you mean by  "We have only limited time on the channel and therefore want this data sharing to be as time consuming as possible" ? 

Why do you want to use "Write Without Response" to ensure connection remains alive ? Do you plan to send any data in the write command ? 

Could you please elaborate more ? 

[youti]

Hi Hung,

It seems like part of the message was deleted when I made an edit. It should say 'data sharing should be as little time consuming as possible'. Besides, it is timestamp data we want to send from the GATT client to all GATT servers with the same GATT profile. Since all clients require the same timestamp (characteristic), we dislike the idea of sending separate write commands to different slaves, since it is time consuming and inefficient. 

In our setup we have up to 6 GATT servers with notifications enabled at 45ms intervals. The connection interval is set at 7.5ms. Each server requires 7.5ms to send its data as a notification to the client. Thus in case we have all 6 GATT servers up and running, there is no time left on the channel to write randomly to the clients to update their timestamp (this has been tested already). For this reason we came up with the two solutions:

• We want the GATT client to send a timestamp update as a replacement for the connection interval update (as you already interpreted correctly). This way, we hope the GATT server will respond with its notification data. The main problem with this method is we have to send this before the automatic connection interval update, and thus requires a timer. In addition, this method still requires distinct write commands to all clients;
• As for the broadcasting, broadcast the timestamp data every 45ms from client to all slaves;

I continued my investigation and the first option seems possible although I have only tested it with one GATT server currently. The second option is still unknown, but I would still like to know whether broadcasting from client to server is possible at all.

I hope this clarifies your questions. 

Remi

[Hung Bui]

Hi Remi, 

There is no concept of broadcasting data when in a connection in BLE. There is no multicast one-to-many packet except for advertising packets (which we don't cover here). 
Note that in 7.5ms you have at least one packet from the GATT client (I assume you mean the Central) and one packet from the GATT server (Peripheral). And if the peer wants to send more it can send more packets. Depends on the size of the packets, you can have up to 6 pairs of packets (or even more) in one 7.5ms connection event. I don't see a reason why the GATT client can't send a time stamp to the GATT server when the server sending a notification. 

There is no concept of "connection interval update" (I assume you don't talk about connection parameters update which is something else). There can be empty packet send from the Central to the Peripheral on each connection event. But that only happens when there is no data from the central to the peripheral. 

Time synchronization has always be a challenge in BLE, especially since it's a reliable protocol. A message can be retransmitted multiple times before it reaches the destination. And you can't send one packet to all your peripherals at once. 

I would suggest to have a look at this blog: https://devzone.nordicsemi.com/nordic/short-range-guides/b/bluetooth-low-energy/posts/wireless-timer-synchronization-among-nrf5-devices

The use of an external protocol concurently would be able to help you to have a very accurate time synchronization.  

[youti]

Hi Hung, 

Thanks, that's a clear answer. We have already tested with a concurrent protocol, but the product requirements prohibit this.

Thanks again for your time!

Remi 

[Hung Bui]

Hi Remi, 
Hope it's clear now. 
There is one correction I would need to make. One to many communication actually possible with latest Bluetooth version; v5.2 but it's pretty new and mainly applied for the new LE Audio. We don't have the implementation for that yet.