What are latency and supervision timeout limits?

[Primož Kralj]

Hey guys,

I'm building a remote control (similar to TV remote) and I'm using nRF51. I am trying to figure out optimal connection parameters so the battery would last as long as possible while the remote would be reasonably responsive (200-250ms latency is fine). The peripheral (remote) has a service with characteristic which holds button state which is notified to central when button press occurs. I've read nRF51 Low power modes and power profiles documentation but still need some input.

Since user could not press any button for a very long time (few hours) I am not sure what should be my connection parameters. I am thinking of setting the supervision timeout to a very large value (maybe 1 hour) and set the latency to a very large value too (maybe 10000). Connection interval is going to be [200ms,250ms] so the remote wouldn't need to respond for ~45min if no button was pressed. 1.) Does this sound logical or is my thinking wrong?

I've also noticed that if I set latency to be more than supervision timeout then the peripheral never even connects to central. This happened with latency 20, supervision timeout 4000ms and conn interval ~250ms. 2.) Why is this? Should (latency * conn_interval) < supervision timeout?

[Ulrich Myhre]

Hi,

There are some rules for supervision timeout values in combination with latency and connection interval, and these are outlined in ble_gap.h (and the module documentation for GAP). You will find that BLE_GAP_CP_CONN_SUP_TIMEOUT_MAX is set to 32 seconds, and that will be the absolute maximum you can set.

For your scenario, there are multiple options:

1. You could be connected all the time, setting supervision timeout to 32s and use slave latency (and optionally local connection latency which can be up to half the supervision timeout). This makes the device wake up every 16s to send an empty packet during inactivity, but instantly wake up when there is data to send. Thus response time on button press is very quick.

2. Disconnect after some time of inactivity and go to sleep. Whenever the remote control is moved, you could use e.g. an accelerometer to detect this and wake up the chip and the connect. If you use high duty cycle directed advertisements, the latency of the new connection is bound by the scanner. Advertising intervals will then be 3.75ms for up to 1.28s. It should then be ready to immediately process button presses with very little delay. Directed advertisement is very resource intensive, so make sure that these are not triggered too often.

3. A combination of the two, where a connection is kept after a button press and then discarded after inactivity. You can then choose to connect when a button is pressed, again using directed advertisements to minimize connection setup time. This should consume less power than by using an accelerometer, but will add some delay to the first press after inactivity.

So to summarize: What you ask for in the original post is not really feasible. It is not possible to keep a connection for more than about half a minute without activity before it is teared down. The spec simply does not allow for more than this, and it is grounded in the fact that the devices will start to drift away from each other due to inaccurate clocks. Having very little communication also leads to rapid connection losses, because you can only miss 2 packets due to noise before things start failing.

Instead you should focus on keeping your device in system off most of the time, and improve the connection setup time. This might require tweaking with the receiver so that it is able to quickly detect any advertisements that come along. If you are bound on resources on the receiver too, you will have to gather some data on normal usage to figure out the optimal strategy.