BLE communication between multiple actors and a single sensor

[whati001]

Hi all,

this is my first project with nordic and ble, hence, I feel a little bit lost and overwhelmed with all the new function and callbacks used in the ble samples.

Therefore, I would like to ask, how I could design my use case best and which samples could help me writing the code.

The idea is really simple, the environment consist of a single "sensor" and multiple "actors". Because I am still sure if it's better to use a single central with multiple peripherals or vise-versa, I will use the terms "sensor" and "actor". So the sensor will use the ADC to identify either high or low voltage ('1' or '0' is enough) and should propagate this information to the actors. Depending on the value of the sensor, the actor will change it's state. Hence, a single byte value exchanging between the sensor and actors would be sufficient, because I could represent 255 different states with it.

After hunting down several BLE and zephyr documentations, I am still not sure if I should use multiple peripherals and a single central instance and write to the GATT. Or use a peripheral which advertises multiple and therefore allow multiple centrals to connect. Which one makes more sense in regard to ble?

Further, are there some good samples available in zephyr or nrf-sdk (connect) can I have a look at? I went through some of them already, but they are somehow difficult to grass. However, {central,peripheral}_uart was quite nice because this signaled that we can push data from a central to a peripheral.

Thanks in advise

[Einar Thorsrud]

Hi,

What you are describing here is a start topology. The typical start topology in BLE is with one central (master) which connects to several peripherals (slaves). Generally having a single central and many peripherals is much easier than the other way around, as then it is a single central that is responsible for scheduling all the links etc. It is possible to have a single peripheral that is connected to many centrals, but in that case there is no coordination between the links. So, if a start topology is what you want, I suggest that the sensor is the central and that the actors are peripherals.

 Another topology which could be considered if you want to add multiple sensors or similar in the future is mesh. In that case the network can grow naturally. For a few devices and a simple setup mesh may be more complicated. But as the network grows a mesh network soon becomes the most manageable, and it can also cover larger physical distances as all nodes does not need line of sight to the "hub" in the start network.

Regarding samples the NUS examples are often a good place to start, as they demonstrate a simple way to transfer data. Note however that if you consider the solution I suggested, where the sensor is the central, It would still make the most sense if it also was the NUS server, and the peripherals should be the NUS client. This is the other way around compared to how this is done in the samples in the SDK.

[whati001]

Hi Einar,

thank you very much for your answer. I will double check the NUS client and give up an update.

After some time, I finally got a simple central <-> peripheral up and working. A very nice resource was the Webinar, which showed how to setup a peripheral properly and describes all the "complicated" macros.

Further, my looking at the nus example, I was able to write a simple central which transmits the pressed button to the peripheral, which sets the led respectively. My code is very ugly, but I have created an tag for everybody who faces the same starting problems BasicCentral->PeripheralTransfer.