How can the peripheral/slave sleep as much as possible?

Question

I'm developing a BLE application where I want my slave/peripheral to sleep as much as possible to save power. I'm not sure how to set the connection parameters.

Petter Myhre · Accepted Answer

The meaning of the different connection parameters are described in this question. They are specified in Vol. 6, Part B, Section 4.5.1 in the Bluetooth Core specification v4.2. The maximum connection interval (connInterval) is 4 s. The maximum supervision timeout (connSupervisionTimeout) is 32 s. The slave latency (connSlaveLatency) shall be less than 500, and it shall not exceed ((connSupervisionTimeout / (connInterval*2)) -1). This gives: connSlaveLatency ≤ ((connSupervisionTimeout / (connInterval*2)) -1) connSupervisionTimeout ≥ (connInterval * 2 * (connSlaveLatency + 1)) If you use the maximum connSupervisionTimeout of 32 s, and divide by 2 on both sides, you can see that (connInterval * (connSlaveLatency + 1)) must be less or equal to 16. This means that the slave must respond at least every 16 seconds. This means that the master can lose one packet from the slave without hitting the connection supervision timeout. (In spec 4.0 and 4.1 the requirement was actually ((connSupervisionTimeout / (connInterval)) -1), so the slave only needed to respond every 32 s, but this has changed.) Anyways, if you want to push this to the limits, and don't have any real time or high throughput requirements, you can set the connection supervision timeout to 32, the connection interval to 4 and use a slave latency of 3. If you require reduced latency, you can for example set the supervision timeout to 32, the connection interval to 1, and the slave latency to 15. In both cases the power consumption in the slave will be the same, but in the second case the power consumption in the master will be higher (assuming that you only respond every 16th second). However, it is not recommended to use the limits, we recommend parameters where the master can lose more than 2 packets, maybe 3 or 4. This is because if you lose the connection you need to scan, advertise and re-establish the connection, which consumes power. Another thing to keep in mind is the sleep clock accuracy. If the slave only responds every 16 seconds, the clock will drift for 16 seconds (on both sides), which means that the RX window of the slave must be bigger to account for this drift. Sleep clock accuracy is described in Vol. 6, Part B, Section 4.2.2 in the Bluetooth Core specification v4.2. So if you have +-250 ppm on both the master and the slave, you will have total of +-500 ppm sleep clock accuracy. This means that if the slave only responds every 16 s you need to have a window widening on either side of the anchor point of 8 ms, i.e. the slave needs to have its radio in receive mode for 16 ms extra. I estimated the average current for 0 RX Payload, 0 TX Payload, 4 s connection interval and a slave latency of 3. With 250 ppm on both master and slave I got 11.85 uA, and with 20 ppm on both master and slave I got 4.93 uA, just to give this some context. Additionally, Apple has a guideline for what connection parameters to use with their products, please see Section 3.6 in this document. Interval Max * (Slave Latency + 1) ≤ 2 seconds Interval Min ≥ 20 ms Interval Min + 20 ms ≤ Interval Max Slave Latency ≤ 4 connSupervisionTimeout ≤ 6 seconds Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout The maximum connSupervisionTimeout is 6 seconds. and if you use that the last equation, and divide by 3 on both sides you see that (Interval Max * (Slave Latency + 1)) must be less than 2. This means that the master can lose three packets from the slave without hitting the connection supervision timeout. Anyways, if you want to push this to the limits, and don't have any real time requirements, you can set the supervision timeout to 6, the connection interval to just below 2 and use a slave latency of 0. If you require reduced latency, you can for example set the supervision timeout to 6, the connection interval to just below 1, and the slave latency to 1. In both cases the power consumption in the slave will be the same, but in the second case the power consumption in the master will be higher. On our SoftDevices the connection interval parameters are given in 1.25 ms units, and the supervision timeout parameter is given in 10 ms units. typedef struct { uint16_t min_conn_interval; /**< Minimum Connection Interval in 1.25 ms units, see @ref BLE_GAP_CP_LIMITS.*/ uint16_t max_conn_interval; /**< Maximum Connection Interval in 1.25 ms units, see @ref BLE_GAP_CP_LIMITS.*/ uint16_t slave_latency; /**< Slave Latency in number of connection events, see @ref BLE_GAP_CP_LIMITS.*/ uint16_t conn_sup_timeout; /**< Connection Supervision Timeout in 10 ms units, see @ref BLE_GAP_CP_LIMITS.*/ } ble_gap_conn_params_t; So this gives: conn_sup_timeout * 10 > (max_conn_interval* 1.25 * 2 * (slave_latency+1)) which equals conn_sup_timeout * 4 > (max_conn_interval* (slave_latency+1))

How can the peripheral/slave sleep as much as possible?

Top Replies