High power when connected and Sleeping

RE: High power when connected and Sleeping

Einar Thorsrud — Thu, 14 Jun 2018 08:02:47 GMT

You are right, the conn_handle should not be 0 when you have a connected event. Can you upload the rest of your code to provide more context? Which SDK version are you using?

RE: High power when connected and Sleeping

mraposo1 — Wed, 13 Jun 2018 15:54:17 GMT

Here is what I tried inside on_ble_gap_evt_connected:

ble_gap_conn_params_t ConnParams;

ConnParams.min_conn_interval = 0xF0;
ConnParams.max_conn_interval = 0xF0;
ConnParams.conn_sup_timeout = 0x200;

if (p_gap_evt->conn_handle != 0)
{
err_code = sd_ble_gap_conn_param_update(p_gap_evt->conn_handle, &ConnParams);
APP_ERROR_CHECK(err_code);
}

But p_gap_evt->conn_handle is always 0.
How is that even possible?

RE: High power when connected and Sleeping

Einar Thorsrud — Wed, 13 Jun 2018 07:06:13 GMT

Hi,

OK, so we see that the connection interval chosen by the central is 0x18 * 1.25 ms = 30 ms, which matches the current spikes. You only call sd_ble_gap_ppcp_set() in the code snippet. Most likely the central ignores / never reads this, so you should also request a connection parameter update if you find the connection parameters unacceptable. You can do this with sd_ble_gap_conn_param_update() directly, or using the connection parameters module which is used in for example the Heart Rate Application example.

RE: High power when connected and Sleeping

mraposo1 — Tue, 12 Jun 2018 17:21:30 GMT

This is zoomed in

And this is zoomed out

3mA average while connected,

Here are the Connection params:

RE: High power when connected and Sleeping

Einar Thorsrud — Tue, 12 Jun 2018 07:31:53 GMT

Hi,

Can you please look at my previous post and answer the few questions there? It will hopefully bring us closer to understanding what is going on.

RE: High power when connected and Sleeping

mraposo1 — Mon, 11 Jun 2018 15:42:48 GMT

Any updates on this one?

RE: High power when connected and Sleeping

Einar Thorsrud — Wed, 06 Jun 2018 06:25:33 GMT

It is not advertising then, as you should have a advertising interval of 2000 * 0.625 ms = 1.25 s, so it is probably in a connection as you wrote. We can see more clearly if you "zoom in" on one of the spikes in time (so that the x axis is only a few microseconds).

Assuming this is connection events, then the connection interval is 30 seconds regardless of what you configure. That is possible, as connection parameters can only be requested by the peripheral. It is always the central that decides. The peripheral can disconnect if the connection parameters are unacceptable, but I do not see that in your code.

You can verify what is actually being used by using a sniffer to see the connection request and connection parameter updates, or by logging this in the nRF side when you get the BLE_GAP_EVT_CONNECTED event (p_ble_evt->evt.gap_evt.connected.conn_params).

Which chip and SDK version are you using?

(I also want to mention that you can get a better software for the power profiler, as the nRF Connect for Desktop now has a Power Profiler plugin.)

RE: High power when connected and Sleeping

mraposo1 — Tue, 05 Jun 2018 21:02:58 GMT

Here is my code:

NRF_BLE_GATT_DEF(m_gatt); // GATT module instance.

ble_gap_adv_params_t const adv_params =
{
.type = BLE_GAP_ADV_TYPE_ADV_IND,
.p_peer_addr = NULL,
.fp = BLE_GAP_ADV_FP_ANY,
.interval = ADV_INTERVAL,
.timeout = 30,
};

static MTU_params_t CocoonService_MTU_Params =
{
.att_mtu = NRF_SDH_BLE_GATT_MAX_MTU_SIZE,
.conn_interval = CONN_INTERVAL_DEFAULT,
.data_len_ext_enabled = true,
.conn_evt_len_ext_enabled = true,
.phys.tx_phys = BLE_GAP_PHY_2MBPS | BLE_GAP_PHY_1MBPS,
.phys.rx_phys = BLE_GAP_PHY_2MBPS | BLE_GAP_PHY_1MBPS,
};

static ble_gap_conn_params_t MyService_conn_param =
{
.min_conn_interval = CONN_INTERVAL_MIN, // Minimum connection interval.
.max_conn_interval = CONN_INTERVAL_MAX, // Maximum connection interval.
.slave_latency = SLAVE_LATENCY, // Slave latency.
.conn_sup_timeout = CONN_SUP_TIMEOUT // Supervisory timeout.
};

static ble_advdata_t const adv_data =
{
.name_type = BLE_ADVDATA_FULL_NAME,
.flags = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE,
.include_appearance = false,
};

static ble_advertising_init_t init;

static ble_uuid_t m_adv_uuids[] = {{1523, BLE_UUID_TYPE_BLE}};
static ble_advertising_t m_advertising;
static Cocoon_ctx_t m_MyService_ctx;
static bool volatile m_mtu_exchanged;
static bool volatile m_data_length_updated;

static bool volatile = false;
static uint16_t BT_conn_handle = BLE_CONN_HANDLE_INVALID; /**< Handle of the current BLE connection .*/
static bool volatile BT_conn_interval_configured = false;

int main(void)
{
uint8_t PendingInt;
ret_code_t err_code;
ble_gap_conn_sec_mode_t sec_mode;

uint16_t service_handle;
ble_uuid_t ble_uuid;
ble_uuid128_t base_uuid = {SERVICE_UUID_BASE};

ble_stack_init();

CocoonUtils_LogInit();

BLE_GAP_CONN_SEC_MODE_SET_OPEN(&sec_mode);

err_code = sd_ble_gap_device_name_set(&sec_mode, (uint8_t const *)DEVICE_NAME, strlen(DEVICE_NAME));
APP_ERROR_CHECK(err_code);

err_code = sd_ble_gap_ppcp_set(&MyService_conn_param);
APP_ERROR_CHECK(err_code);

err_code = nrf_ble_gatt_init(&m_gatt, gatt_evt_handler);
APP_ERROR_CHECK(err_code);

err_code = ble_advdata_set(&adv_data, NULL);
APP_ERROR_CHECK(err_code);

memset(&init, 0, sizeof(init));

init.advdata.name_type = BLE_ADVDATA_FULL_NAME;
init.advdata.include_appearance = true;
init.advdata.flags = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;
init.advdata.uuids_complete.uuid_cnt = sizeof(m_adv_uuids) / sizeof(m_adv_uuids[0]);
init.advdata.uuids_complete.p_uuids = m_adv_uuids;

init.config.ble_adv_fast_enabled = true;
init.config.ble_adv_fast_interval = ADV_INTERVAL;
init.config.ble_adv_fast_timeout = ADV_TIMEOUT_IN_SECONDS;

init.evt_handler = on_adv_evt;

err_code = ble_advertising_init(&m_advertising, &init);
APP_ERROR_CHECK(err_code);

err_code = sd_ble_uuid_vs_add(&base_uuid, &(m_MyService_ctx.uuid_type));
APP_ERROR_CHECK(err_code);

ble_uuid.type = m_MyService_ctx.uuid_type;
ble_uuid.uuid = AMT_SERVICE_UUID;

// Add service.
err_code = sd_ble_gatts_service_add(BLE_GATTS_SRVC_TYPE_PRIMARY, &ble_uuid, &service_handle);
APP_ERROR_CHECK(err_code);

err_code = ble_advertising_start(&m_advertising, BLE_ADV_MODE_FAST;
APP_ERROR_CHECK(err_code);

while (1)
{
err_code = sd_app_evt_wait();
APP_ERROR_CHECK(err_code);
}

}

RE: High power when connected and Sleeping

mraposo1 — Tue, 05 Jun 2018 20:39:11 GMT

RE: High power when connected and Sleeping

mraposo1 — Tue, 05 Jun 2018 17:14:07 GMT

This is in connected state.
My APP_ADV_INTERVAL is 2000.
What level of resolution do you need to be able to have a better view of the power profile?

RE: High power when connected and Sleeping

Einar Thorsrud — Tue, 05 Jun 2018 11:11:25 GMT

Hi,

It is difficult to recognize the power profile as the time resolution is not good, but it looks like the device is advertising and not in a connected state. Can you verify that? If so, you have to adjust the advertising interval instead. You can increase the advertising interval by increasing the value of APP_ADV_INTERVAL in most BLE peripheral examples.