Strategy for long time connectivity over BLE

[Emil]

Let's say I Have an nrf51822 on a small button cell battery having a sensor that is triggered on certain conditions.

What is the most efficient and power saving way to give a notification over BLE to the central (the central is a computer with a bluetooth USB dongle which is always on).

1. What is the most low power / efficient protocol to use? UART, pure GATT or ipv6?
2. How do I stay connected during sleep (I plan to wake on IRQ)?
3. Is there any example that clearly shows how to properly wake up and quickly on an GPIO signal?
4. Should the central poll for the NRF or should it be the other way around? I suppose I should first "pair" it so the central knows about it's name or MAC or whatever. Basically, I want to have as quick response as possible, and both to be connected as much as possible. Can the BLE connection be sleeping too but be ready?

Thanks :)

[pastisprologue]

Hi Emil,

Bluetooth Low Energy saves energy by minimizing the on-time of the radio. Power consumption is further diminished by putting the nRF to sleep when the radio is off. However, the nRF must be awake during Radio:on periods.

There are basically two ways to do what you want: 1) Advertise your sensor data, or, 2) Connect with central and push sensor data through notifications.

Advertising

As a peripheral, your device can advertise as often as every 20ms, or as infrequently as every 10.24s. You can transmit 31 bytes of data in an advertising packet, with the ability to send an additional 31 bytes if your central device actively requests a "scanning response".

Advertising is a function of a broadcasting role, so every observer-central that is scanning can hear what an advertiser has to say. (You can direct advertisements at specific centrals, but you essentially lose your ability to put own data in the 31 bytes I mentioned previously). Advertising is not a form of "reliable" communication. If a central's scanning interval and window do not align with an advertiser's advertising interval, the central may never receive any information from the peripheral.

Advertising also only operates on 3 physical channels, so with large numbers of peripherals, traffic/noise can become an issue. Most advertisers advertise on all three channels each advertising interval (this differs from connection, where data is put on only one channel per connection interval).

Advertising is nice for your application because it allows you to shut off the radio for long periods of time and sleep. Only when you get an interrupt from your sensor do you need to start advertising. Set a timeout so that after a period of advertising, you stop advertising and sleep indefinitely until your next interrupt. And if your advertising interval is large enough, you can even put your peripheral to sleep between advertisements.

Connection

Connection events can occur as often as 7.5ms or as infrequently as 4s. However, connection intervals are determined by the central, so as a peripheral, you will be bound by the central's connection parameters. You can, as a peripheral, set "preferred" connection parameters, but the central may or may not adjust the connection accordingly.

So on the surface, because connection events must occur in general more frequently than advertising events, a connection state appears to be less efficient. Connection states do have some tricks up their sleeve, however, such as Slave Latency (allowing a slave/peripheral to skip connection events if no data is available) and Supervision Timeout (maximum time between successful connection events).

As a peripheral in a connection, you can be either a GATT client or a GATT server. For your application, it makes most sense for your peripheral to be a GATT server. The central will then act as the client. The client can either periodically from the server (theoretically up to 120 bytes per connection event) or the server can push up to 20 bytes at a time to the client through notifications and indications.

There are some significant advantages to connections, especially if reliability is desired. A peripheral can connect and communicate with only 1 central, while a central can form multiple connections with different peripherals. Each connection can be encrypted and signed, if necessary, to protect the information passed between each central and peripheral. And each connection will hop from channel to channel on the 37 channels used for connections, minimizing collisions.

Power Save

Most examples given in Nordic's SDK use a function called power_manage(), which demonstrates putting a device to sleep when it has nothing to do and allows it to wake up with a button press.

I hope this gave you an idea for how to start your project.

Regards, past

[pastisprologue]

Hi Emil,

Yes, the nRF needs to report in in order for the connection to not be terminated. I would investigate the previously mentioned parameters "Supervision Timeout" and "Slave Latency" if you're interested in learning about "not reporting in" but also not dropping the connection. With Slave Latency, a slave (peripheral) can choose to skip a number of connection events (up to 499 according to the spec, as long as the time between connection events doesn't exceed 16.0 seconds). And Supervision Timeout is a parameter set by the central (although a peripheral can specify a preferred value) that dictates the maximum amount of time between two successful connection events, with the maximum amount of time being 32.0 seconds. I'm not hugely familiar with these, as in my experience, I went the advertising route, but that's what I'd investigate if I were to go the connection route.

-past