NUS Quiescent Power

RE: NUS Quiescent Power

benmack — Mon, 28 Jun 2021 12:21:58 GMT

That's great, many thanks Vidar

RE: NUS Quiescent Power

Vidar Berg — Mon, 28 Jun 2021 11:37:01 GMT

Yes, the central and peripheral will agree upon a fixed connection interval at which they can wake up and exchange data with each other (Note: peripherals can only request a preferred connection interval range, see Connection Parameters Negotiation). This is one of the main power saving features of the LE protocol because you only need to keep the radio active during the connection events (Bluetooth Low Energy power profiles).

[quote userid="93764" url="~/f/nordic-q-a/76754/nus-quiescent-power/317423#317423"]The central/client initiates each connection event, after the interval time from previous event. NUS_C sends any data it has to peripheral, using nus_rx_handle - see ble_nus_c_string_send().[/quote]

Correct, when you call ble_nus_c_string_send, the packet will become enqueued in the Softdevice's internal transfer queue and sent on the next (or current if called in an ongoing connection event) connection event.

[quote userid="93764" url="~/f/nordic-q-a/76754/nus-quiescent-power/317423#317423"]I found it would not accept a connection interval > 2000mS (this seems common, allows for a missed connection without hitting 4000mS connection timeout and dropping the connection).[/quote]

You may have to increase the supervision timeout. Excerpt from core spec. 5.2. , vol 6, Part B, section 4.5.2

Connection supervision timeout (connSupervisionTimeout) is a parameter that
defines the maximum time between two received Data Channel PDUs or
Connected Isochronous PDUs before the connection is considered lost. The
connSupervisionTimeout shall be a multiple of 10 ms in the range 100 ms to
32.0 s and it shall be larger than

(1 + connSlaveLatency) * connInterval * 2.

RE: NUS Quiescent Power

benmack — Mon, 28 Jun 2021 09:56:43 GMT

OK, my understanding so far, please correct me if I'm wrong. Maybe of use to others. NUS uses normal central/peripheral connections. The MIN/MAX_CONN_INTERVAL is configured in peripheral, which proposes it to central during negotiation. NUS_C appears to use the MIN_CONN_INTERVAL.

The central/client initiates each connection event, after the interval time from previous event. NUS_C sends any data it has to peripheral, using nus_rx_handle - see ble_nus_c_string_send().

Central also checks for a notification of NUS TX characteristic from the peer/peripheral (see on_hvx() using nus_tx_handle), and handles it (raises a BLE_NUS_C_EVT_NUS_TX_EVT event).

So basically every MIN_CONN_INTERVAL the client/central sends and receives any waiting data with the peer/peripheral. If there is no data waiting, it does an "empty" connection event, which keeps the connection alive.

I found it would not accept a connection interval > 2000mS (this seems common, allows for a missed connection without hitting 4000mS connection timeout and dropping the connection).

However even with just a 500mS interval my central quiescent dropped from 100uA to around 8uA - perfect

RE: NUS Quiescent Power

benmack — Mon, 28 Jun 2021 07:26:37 GMT

That's great, many thanks, works very nicely.

I still don't fully understand how the connection interval affects how each end of the NUS link decides when to send data. I don't suppose there is a tutorial on this, or any suggested reading?

RE: NUS Quiescent Power

Vidar Berg — Fri, 25 Jun 2021 15:50:32 GMT

Hello,

Have you tried to increase the BLE connection interval? The average consumption may come closer to around 5 uA if you for instance extend the connection interval to 3 seconds rather than the default interval which is between 25 ms to 75 ms.

Note that you can use our online power profiler to play around with different the configuration paramaters such as conenction interval, regulator setting, output power, etc.

https://devzone.nordicsemi.com/nordic/power/w/opp/2/online-power-profiler-for-ble