Selecting the right SDK Solution for the project. Mesh, Point-to-Multipoint, Server, Observer, Peripheral... Advice needed

[Jev]

Hi,

I am a bit confused after looking through all the SDK solutions available for NRF52 and need a piece of advice...

I am have started on the project that consists of several BLE devices (BLE peripherals I guess) powered from the battery (Switches, Temperature Sensors and etc.) and single gateway/server that collects all the data and is powered from the mains. Basically, Point-to-Multipoint solution is needed. I can't use Mesh network due to the fact that BLE sensors need to be power efficient and will be in deep sleep the rest of the time. What the best example to start with for this kind of project? BLE Central for a server & BLE Peripheral for a sensor? Any recommendations are welcome.

Similar to smart home solutions based on Z-wave, Zigbee, Thread.

Thank you in advance,

Jev

[Edvin]

Hello Jev,

Let us discuss possible approaches.

 

I can't use Mesh network due to the fact that BLE sensors need to be power efficient and will be in deep sleep the rest of the time.

 What do you mean by deep sleep? I assume you are running these on batteries. How many peripheral nodes do you have, how often do you intend to transmit data, and how much data do you transmit each time?

Since you rule out Bluetooth Mesh, I think we can rule out Zigbee (Z-wave) and Thread as well. They have more or less the exact same current consumption. The reason for this is that these types of networks need to keep the radio in RX mode whenever they are not transmitting. So basically, you need to run the radio 100% of the time (RX power consumption is the same as the TX consumption).

So that leaves us with BLE. Now it really boils down to how many devices (peripherals) that should transmit to your gateway (central), and how much and how often they are sending data. Are all the nodes within radio range of the gateway?

Best regards,

Edvin

[Jev]

Hi Edvin,

Sorry, I was a bit unclear. Let me explain in details then.

The idea is to have up to 10 nodes (sensors & call-points) and one base station (gateway) per network. Yes, all nodes will be powered from a battery, that is why the low power consumption is the key. Nodes will be in a sleep mode/low power mode (no scanning or transmission) most of the time. Nodes will be transmitting a minimal amount of data, e.g. couple of bytes once every 10-30mins from the sensor or once the call-point was triggered. All nodes will be located within 10metres from the gateway, that is why distance is not an issue as well as no real need in the mesh network for distance increase. The base station will be powered from the PSU, so the power consumption won't be an issue, it will be scanning for messages on the nodes most of the time.

I might be missing something, but I assume BLE would be the right option for this. Isn't it? If yes, what would be the best SDK example to start with? For nodes as well as for base station? Peripheral for the nodes and Central for a base station?

Thanks,
Jev

[Edvin]

Jev said:

I might be missing something, but I assume BLE would be the right option for this. Isn't it?

 It definitely sounds like it is in this case.

 

Jev said:

Peripheral for the nodes and Central for a base station?

 Indeed.

So you have 10 nodes. It is actually possible to just be connected to all the nodes all the time, if that is an option. The central supports up to 20 concurrent connections. If you increase the connection interval, perhaps that is power sufficient enough for your case. You can look into different connection parameters. You can use the Online Power Profiler to estimate the current consumption. 

There are still a few different approaches. 

1: Nodes are beacons, advertising their data, the Gateway is a scanner looking for their advertisements. In this case, there is no way for the beacons to know when/if the gateway has picked up the advertisements, and the gateway can never send any messages back to the beacons, in case that is needed.

2: Nodes advertise whenever they have data to send. The gateway connects to the node, the node transmits data, and the gateway can send some messages as well, if needed. When they are done, they disconnect, and the node goes back to sleep.

3: The devices are connected at all times using a high connection interval. This may not draw as much power as you think, and maintaining a link is more power-efficient than establishing one, so depending on how often you intend to do that, this may actually be better.

Either way, an example that you can use for basic testing that can send custom data is the ble_app_uart (peripheral) example and ble_app_uart_c (central) example. Check out the test description here:

peripheral: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/ble_sdk_app_nus_eval.html?cp=7_1_4_2_2_25_2#project_uart_nus_eval_test

central: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/ble_sdk_app_nus_c.html?cp=7_1_4_2_0_7_2#ble_nus_c_test

[Jev]

Thanks, for such a detailed reply! That answers all my questions.

I have quickly checked the Online Power Profiler and it looks quite acceptable to keep the signal all the time. So it would be even possible to power the node from a coin battery and it should last a year or two. I haven't realized that it can be so power efficient.

In terms of options. I think Option 2 and Option 3 would be the best to consider in my case, as Option 1 doesn't allow the base station to send data to the node, that might be needed from time to time.

Will go and do research into details of both options.

Thanks for your help!

Regards,
Jev