Which SDK example shall I use?

RE: Which SDK example shall I use?

endnode — Tue, 04 Jul 2017 09:05:03 GMT

And btw. that "send its UUID" doesn't make much sense in BLE GATT but I guess you will learn it... simply send "something" over your custom GATT Service&Characteristic (= these will have UUIDs, but that's different story)

RE: Which SDK example shall I use?

endnode — Tue, 04 Jul 2017 09:03:40 GMT

"Whisper" mode seems to be lowest Tx Power setting (-30 or -40dBm depending on nRF5x platform) so simply use particular SD function (or update registers directly if you don't use Nordic stack). Just be ready for really really low maximum distance achievable with reasonably reliable link (= low packet loss) especially indoors.

RE: Which SDK example shall I use?

Daliwan — Tue, 04 Jul 2017 08:04:58 GMT

By the way, how can I use whisper mode? Thank you.

RE: Which SDK example shall I use?

Daliwan — Tue, 04 Jul 2017 07:54:31 GMT

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.

RE: Which SDK example shall I use?

endnode — Mon, 03 Jul 2017 08:52:19 GMT

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

RE: Which SDK example shall I use?

endnode — Mon, 03 Jul 2017 08:47:28 GMT

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)

RE: Which SDK example shall I use?

Daliwan — Mon, 03 Jul 2017 03:09:53 GMT

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!

RE: Which SDK example shall I use?

endnode — Sun, 02 Jul 2017 11:31:04 GMT

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