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

[Daliwan]

Dear Jan, Thank you very much for your help. In my case, the power efficiency is the first thing to consider. It seems that Adv in one channel is the most suitable way to me. But I don't know how to realize it. Can you give me some example for that? I also wonder if I can bond it to a central once and later just use communication mode, without advertising. It will not send any big information, but only show its ID to say it is nearby is enough. Is it possible? Which is better, the Adv method and communication method if both of them use only one channel? Thank you very much!

[endnode]

Have you see Nordic Soft Device API? There is channel_mask parameter supplied inside p_adv_params structure to sd_ble_gap_adv_start function.

To the rest of your question: you cannot avoid advertising phase because without advertising there is no BLE connection. Once the connection is established the advertising is typically turned OFF and only link events are carried ON. Both methods have advantages and disadvantages, mainly in fact that for broadcasting only you need (preferably) scan all the time on Observer (Central) side (eats lot of power if you care...) but on the other hand (1/x)

[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.

[Daliwan]

Thank you very much. Now my plan is to use the UART example, but don't sent any data, just keep the peripheral connected the central. The peripheral will send its information, only its UUID or so every interval. If they disconnect with each other, then an alarm occurs. I think maybe this is the simplest and most power efficient solution for my simple case.