High power when connected and Sleeping

[mraposo1]

When Going into Sleep, I see peaks of 12mA every 30ms (see image)
I'm assuming I can adjust that changing the connection interval settings.
I have my Connection intervals set as:

#define CONN_INTERVAL_DEFAULT (uint16_t)(MSEC_TO_UNITS(500, UNIT_1_25_MS))
#define CONN_INTERVAL_MIN (uint16_t)(MSEC_TO_UNITS(500, UNIT_1_25_MS))
#define CONN_INTERVAL_MAX (uint16_t)(MSEC_TO_UNITS(600, UNIT_1_25_MS)) 

And I think I looked at all issues in the Devzone about it without any luck.

Could you help me please?

[Einar Thorsrud]

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.

[mraposo1]

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?

[mraposo1]

[mraposo1]

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);
  }

}

[Einar Thorsrud]

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