• State Verified Answer
  • Replies 8 replies
  • Subscribers 73 subscribers
  • Views 4743 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 109023
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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.

Parents
  • 0

    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.

Reply
  • 0

    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.

Children
No Data
Related
Terms of service