Many-to-one sensor collector topology, which BLE sample is better to modify?

Question

Hi, 
 1) I want to collect sensor data using BLE like the following topology, the sensor devices are battery-powered, which sample in the NCS is suitable to modify? 
 
 2) Does NUS central/peripheral can do many-to-one topology in this usage? or need to use BLE mesh?

Edvin · Answer

Hello, 
 I think the peripheral/central_uart samples is a good starting point for this. I wrote an answer to a similar question just a couple of weeks ago. It was in a private ticket, but I'll paste it here: 
 ------------- 
 I am not aware of any official samples that will connect to multiple peripherals, but it is indeed possible. To get started, I would use the peripheral and central sample that are closest to what you want to use. E.g. the peripheral_uart and central_uart are good starting points. 
 While it is not official, a colleague of mine has a multi-nus sample, which is basically a central that can connect to multiple peripherals. You can have a look at it for inspiration: 
 https://github.com/NordicMatt/multi-NUS/tree/master 
 You can see that it has some functions for sending messages to one particular peripheral, or multiple. But in theory, all you need to do is to do some changes in prj.conf of the central_uart sample: 
 CONFIG_BT_MAX_CONN=20
CONFIG_BT_MAX_PAIRED=20
CONFIG_BT_CONN_CTX=y 
 This will allow it to connect to up to 20 devices. Then your app needs to keep track of how many connections it has, and resume scanning if the maximum is not reached. You don't need CONFIG_BT_MAX_PAIRED if you are not going to use pairing (encryption). 
 Another thing that you need to do is to look at the way that the central_uart sample keeps track of the connection pointer, bt_conn *default_conn. In the connected() callback, which triggers when the device enters a connection. This particular example sets the default_conn pointer in it's scan_connecting() callback, but you can do it in the connected() callback. And in your case, you need to have an array of bt_conn pointers. As many as the maximum number of simultaneous connections. Then set them using bt_conn_ref() when you enter a new connection, and unset them using bt_conn_unref() when you disconnect. 
 It may also be a good idea to have this conn pointer as an input in the function that you use to send data, like the bt_nus_client_send(). This sample in particular doesn't do that, because it assumes only one connection, and this is set in the nus_client parameter, but you can see how it uses the conn pointer inside bt_nus_client_send(): 
 err = bt_gatt_write(nus_c->conn, &nus_c->rx_write_params); 
 So that you send the message to the intended peripheral. You can see how it is done in the multi-nus example (link to github above). 
 ------------- 
 
 So there is a description on how to make the central have multiple concurrent connections. When sending data the other way, you can look at the conn* pointer in the callback to see what device the data is coming from. 
 
 Also, in general, Bluetooth Mesh is probably not the solution you are looking for. It will work, but the power consumption is a lot higher than in a BLE application. So since you mentioned that they will be battery powered, I recommend using normal BLE. 
 
 Best regards, 
 Edvin

Many-to-one sensor collector topology, which BLE sample is better to modify?

Top Replies