RE: What are latency and supervision timeout limits?

Ulrich Myhre — Thu, 03 Dec 2015 15:17:00 GMT

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:

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