nRF51 high current at connected state.

[Valer_I]

Hello all, Before asking question I thotoughly read the previous discussions but it didn't help in my case. I use nRF51822 rev.2 + SD130 device with NUS service for BLE data exchange. I have decreased current to 14uA in idle during advertisement. However when I connected to peer central the current consumption increased to about 460-500uA and remains in this range until I disconnect device. I tried to increase connection intervals but no noticable result was received. I switched off all peripherals to exclude influence of possible bug in code or hardware. Now I think about HFCLK and 1.2V LDO but didn't found what peripherals use it. Please help with advice or direct to possible wayout.

Connection params: Connection interval: 500-1900ms Slave latency: 4 Supervision timeout: 20000ms

I tried to increase min connection interval but it didn't led to current fall.

[Dave_couling]

What are your Connection Parameters set to? Its likely you are advertising at a longer interval then your Connection Parameters. 0.460uA sounds like a phones default connection parameters.

[Valer_I]

Edited my question. My aim to achieve results as stated in devzone.nordicsemi.com/.../ ( i.e. 20-50uA)

[Valer_I]

I have measured current in time deflection within osciloscope on 10ohm resistor. There are glitches and spikes, but timings are clearly seen. It seems that cpu does not sleep. The period is near 20ms. The current is 400-500uA. I didn't found this value in code. Could it be tuned? What could cause such behaviour? Advertisement: onedrive.live.com/redir Connected: onedrive.live.com/redir

[Valer_I]

...Connected to another android device, the current consumption decreased to 170uA...Osciloscope shows that connection interval changed to 50ms, previously it was near 20ms.

So the question now is: how could peer central set 20 or 50ms conn interval if at advertisement I allowed 500-1900ms?

[Stefan Birnir Sverrisson]

Hi

Perhaps I will start with clarifying a few things to prevent any potential confusion

There are different rules that apply when BLE device is advertising and when a BLE device is in connection.

• First the peripheral advertises with a certain advertising interval which only the peripheral decides what is.
• The central will scan for those packets and eventually connect to the peripheral by sending a connection request with connection parameters which the central device decides what is. They are totally independent of the advertising parameters which the peripheral decides what is.
• When the peripheral and central are in a connection, the peripheral can choose to send a request to the central device to update the connection parameters, see more on this thread how that works.
• The central may respond with a connection parameter update, and the peripheral application will be notified and will have to decide if it accepts what the central proposes. See this thread and this thread how to detect if there really is an incoming connection parameter update from the central and what actually the proposed connection parameters are.

Note that Android phones are not identical in their capabilities of their supported connection intervals and how many packets per interval they are able to send/receive, see this thread.

Also note that S130 is not tested and not made to work with nRF51 second revision, so I suspect that at least part of the reason for high current consumption is that you have second revision nRF51. You should upgrade to nRF51 third revision when using S130 softdevice. See the nRF51 compatibility matrix v2.4, table 4. You could also choose to upgrade to nRF52 and softdevice S132 for even better performance.