nRF51 high current at connected state.

RE: nRF51 high current at connected state.

Stefan Birnir Sverrisson — Tue, 08 Sep 2015 07:49:47 GMT

Thank you for your feedback. I am glad that you found the issue

RE: nRF51 high current at connected state.

Valer_I — Mon, 07 Sep 2015 14:47:27 GMT

Dear Stefan Birnir Sverrisson, Many thanks for your explanation and links but I solved this problem befre read your answer )). I have seen all these threads you've mentioned and many others to investigate the problem. I do not use nRF51 sdk due to tight memory budget and use only sd_... functions to communicate with softdevice. My code is next:

err = sd_ble_gap_connect(&current_addr, &c_scan_param, &c_connection_param);

c_scan_param - here put our desired connection params (as far as I understand here they written to the PPCP characteristic). The central able to read them and use, but on all devices I've try - skip. After connection the connection interval depend on device and is in range 20-100ms. Next I follow bonding routines and it is better to do them on high speed. Than when bonded:

}else if (evt_id == BLE_GAP_EVT_AUTH_STATUS){
...
   if (ble_evt->evt.gap_evt.params.auth_status.bonded == 1){
...		
 uint32_t res=sd_ble_gap_conn_param_update(gs_central.conn_handle,NULL);
...

"If NULL is provided on a peripheral role, the parameters in the PPCP characteristic of the GAP service will be used instead." Next I'm waiting for BLE_GAP_EVT_CONN_PARAM_UPDATE event from central to find out what parameters were chosen. Here I have not experienced any changes of parameters. But establish software timer. After 20s (could be adjusted of cource) I've send

uint32_t res=sd_ble_gap_conn_param_update(gs_central.conn_handle,&alt_c_connection_param);

to central with slightly different connection intervals (yet not tested what if use the same as at connection). And it responds with connection interval in range that I asked. Now power consumption decreased in one order of magnitude. I have tested this on Windows 8, Android 4.4.2, 5.1, Mac and it seem to work.

RE: nRF51 high current at connected state.

Dave_couling — Fri, 04 Sep 2015 17:45:25 GMT

Your peripheral is using the Central default Connection Parameters. This explains the difference you are seeing. For iOS its ~30ms for Android ~50ms depending on the device.

RE: nRF51 high current at connected state.

Stefan Birnir Sverrisson — Fri, 04 Sep 2015 10:58:20 GMT

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.

RE: nRF51 high current at connected state.

Valer_I — Fri, 04 Sep 2015 09:02:37 GMT

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

RE: nRF51 high current at connected state.

Valer_I — Fri, 04 Sep 2015 07:43:42 GMT

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

RE: nRF51 high current at connected state.

Valer_I — Thu, 03 Sep 2015 08:13:10 GMT

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

RE: nRF51 high current at connected state.

Dave_couling — Wed, 02 Sep 2015 20:43:49 GMT

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.