Which SDK example shall I use?

[Daliwan]

Hi, I am a newbie in nRF51 application. I am busy with a project which required the peripheral to communicate with the central once per second. Just to make sure that the peripheral is not lost. The project requires to save as much power as possible. Which SDK example shall I use? I read the files in proximity, but it mentions that it uses advertisement. Since Ad mode use 3 channels, I think it is better to use communication mode. What's more, can you give me any suggestion that in what documents I can find to control the Tx power, the time between each connection? Thanks.

[endnode]

Hi Daliwan,

You can restrict advertising to single channel if this is your concern. Note that if you use non-connectable/scannable advertisement then SoftDevice (BLE stack) completely skips receiving phase which has significant power consumption spike so by using adv. only solution will be probably the most power efficient. Indeed you are losing reliability (the other side must have 100% scanning duty cycle if possible and because Nordic Soft Devices currently cannot restrict scanning to single adv. channel (= they are rotating channels 37/38/39 with fixed "scanning interval") you might anyway decide to advertise on all 3 channels (or you need to fine-tune other parameters on both sides - if possible - to achieve desired data rate/periodicity).

However if information transfer is critical then you should go with some connection-based solution with long connection interval (you can go way beyond 1s). It will consume slightly more energy but you will be sure that packets get re-transmitted if Central device misses it.

If power consumption is the biggest problem for you and you are ready for custom HW design you can go with some "extreme" architecture where nRF5x chip is powered off (or in SYSTEM OFF deep sleep mode) and is woken up once per second by some low-power external RTC chip (there are components which run in 1-50nA range which is much less then nRF5x in SYSTEM ON sleep mode).

Depending on the approach you can choose either beacon example (advertising only) or some Peripheral/Central examples such as Nordic BLE UART Service (NUS) or general BLE template (depends if you want to support things like BLE Security Manager with pairing/bonding mechanisms).

Cheers Jan

[endnode]

(2/2)... you can on Central side do other processing (e.g. scan for other broadcasters or handle some connection link). Also with advertising only you have no reliability on data transferred. With connection link approach you are sure that data will either pass over the link or it will timeout (which will notify both sides that something is wrong, timeout can be configured by connection parameters to certain extend). It should also be more power savvy on Central side then continuous scanning. However if you have some limitation on Central side (e.g. that you can maintain only one link at the time) it can prevent you from doing other things. Final decision largely depends on what devices you have on both sides, what capabilities (in terms of BLE stack) they have and what other use cases they need to support.