Timeslot API - low power optimization

RE: Timeslot API - low power optimization

adriand — Thu, 14 May 2015 06:23:20 GMT

@hungbui: ok. Thanks!

RE: Timeslot API - low power optimization

Hung Bui — Wed, 13 May 2015 12:16:02 GMT

@adriand: I am not aware of similar issue. I suggest you to create a new case for the issue and accept the answer for this case. You can try to debug by checking if the radio is on when scaning is enabled when issue occurs by measuring the current consumption.

In your question for this issue, you may need to add more information on how you configure the radio, the scanning window, the timeslot interval and the advertising interval.

RE: Timeslot API - low power optimization

adriand — Wed, 13 May 2015 07:29:34 GMT

@hungbui: ok, thanks! I also overlooked that. However I have one more question - sometimes scanning stops. Advertising is working, disabling / enabling scanning is being performed however scanner doesn't "see" any packets and no errors are produced (asserts are ok). Event radio events (8, 4) are showing. I don't know to debug it. I know this is not so specific description of the problem, but maybe you came across that kind of issue?

RE: Timeslot API - low power optimization

Hung Bui — Tue, 12 May 2015 12:41:57 GMT

@Adriand: I'm sorry that I didn't noticed it before. The reason you got high power consumption was due to issue #39 described in the nRF51822 PAN (Product Anomaly product) document where GPIO_TASK would consume higher power than it should.

This issue's fixed on chip version 3. The chip on your PCA10004 is most likely chip version 2.

RE: Timeslot API - low power optimization

adriand — Fri, 08 May 2015 10:53:50 GMT

Ok, I suppose I found the problem, but I doubt if I solved it correctly. In the file ll_scan.c in function ll_scan_start() I commented out every line that has GPIOTE->CONFIG:

  /* Toggle pin when radio reaches END (RX or TX) */
  // NRF_GPIOTE->CONFIG[DBG_RADIO_END] = ..

  /* Toggle pin when radio reaches READY (RX or TX) */
  // NRF_GPIOTE->CONFIG[DBG_RADIO_READY]= ..

   /* Toggle pin when timer triggers radio START (TX) */
   // NRF_GPIOTE->CONFIG[DBG_RADIO_TIMER] = ..

maybe it's strange but it works (only several minutes test): advertising works, disabling / enabling scanner works, connecting works. And current consumption is ok.

RE: Timeslot API - low power optimization

adriand — Fri, 08 May 2015 09:51:51 GMT

Thanks. Ok, I tried your last hint, but it seems that HFCLK is enabled after scanner is enabled and disabled after scanning stops. So it's rather not HFCLK. I also checked debug (I disconnect jlink and manage power reset), uart for logging is also disabled. I tried multiactivity beacon with hrs and it seems to be ok - power consumption is about 0.01mA after scanning stops. I will try to compare source codes. The first diffrence I can see is that GPIOTE is being used (ll_scan_start()) in the observer example and there's not in multiactivity+hrs.

RE: Timeslot API - low power optimization

Hung Bui — Thu, 07 May 2015 14:05:04 GMT

@adriand: I would suggest you to use the register directly to control the HFCLK instead of using sd_* api because the application has full control of radio, HFCLK when in its timeslot. What you can do is to start the HFCLK crystal using this code:

if (!(NRF_CLOCK->HFCLKSTAT & CLOCK_HFCLKSTAT_SRC_Msk))

{

  NRF_CLOCK->TASKS_HFCLKSTART = 1;

  NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;

  while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);

}

Then stop the HFCLK after you finish scanning using :

NRF_CLOCK->TASKS_HFCLKSTOP = 1;

Another thing can cause high current consumption is the debug mode. You need to make sure you power off and on the device at least once after you program the chip, otherwise it will remain in debug mode.

RE: Timeslot API - low power optimization

adriand — Thu, 07 May 2015 12:05:51 GMT

@hungbui thank you for your input. I didn't think about it before. However, it looks like HFCLK is always disable. I put following code into while in the main:

while(1){ 
	btle_err_code = sd_clock_hfclk_is_running(&hf);	
	ASSERT (btle_err_code == NRF_SUCCESS);			
	if(hf==0)
		__LOG("DISABLED");
	else
		__LOG("ENABLED");

	sd_app_evt_wait();

	if(sw_interrupt()){
           		//handling adv and resp packets
     }
}

and hf is always 0. Is there any other way to check HFCLK (when SD is being used)? However, regardless of checking if HFCLK is working, I tried to invoke sd_clock_hfclk_release() after scanning disable, but it didn't change anything.

Maybe I should mention that I changed BLE stack initialization than it is made in timeslot example. I'm using: SOFTDEVICE_HANDLER_INIT(20ppm, false); defined BLE_STACK_SUPPORT_REQD

RE: Timeslot API - low power optimization

Hung Bui — Tue, 05 May 2015 12:22:58 GMT

@adriand : Have you tried to disable the HFCLK crystal after you disable scaning ?

It seemed that when you request the timeslot with earliest possible type, the HFCLK crystal was kept running and hadn't been turned off after you finish.