@casainho , regarding your comment from previous PR:
Maybe the issue is about code on interrupts... can you try to not use the delays inside the interrupts and test again? see that you could set / clear flags / machine state on interrupts and then processing on the main loop, as main loop will also always be executed when interrupts fire.
it seems it is not that, I removed all delays inside button interrupts in the previous PR.
Flagged actions are handled in the main loop.
However, the good new is, I think I may have found the problem!
It turn out that the app_button library has a define BUTTON_DETECTION_DELAY that was set to 25ms.
When you click fast, the button press lasts less than 25ms, and the click is missed!
So, I reduced this to 10ms, and the button is much more responsive.
What is the tradeoff with time?
Looking on the nordic forums, I found this:
Hi, I looked through the app_button library in SDK 17 and the extra current consumption is because of how the button library is designed. Whenever the button is pressed there is a timer running which is polling the status of the button, until it is released again. The polling frequency is decided by the BUTTON_DETECTION_DELAY define. So by using a higher delay, the current consumption will go down. from (https://devzone.nordicsemi.com/f/nordic-q-a/64090/increase-current-consumption-with-app_button/264322#264322)
So current consumption can go up when the button is pressed due to the timer. This also may explain the high current I saw when the buttons were pressed from the previous pwm measurements!
Anyway, this current increase is ONLY during the time (a few ms) when the button is pressed, so the impact is minimal.
Here is what I measure with the button held down:
1 ms delay button pressed avg current: 72ua standby current, 2ma! button pressed = 2ma!
5ms delay button pressed avg current: 72ua standby current, 602 ua button pressed = 530 ua
10ms delay button pressed avg current: 72ua standby current, 440 ua button pressed = 368 ua
25ms delay button pressed avg current: 72ua standby current, 345 ua button pressed = 273 ua
so I changed the button detection time to 10 ms. Seems a good compromise.
The buttons are more reponsive now, and the power impact is minimal.
@casainho , regarding your comment from previous PR:
it seems it is not that, I removed all delays inside button interrupts in the previous PR. Flagged actions are handled in the main loop.
However, the good new is, I think I may have found the problem! It turn out that the app_button library has a define BUTTON_DETECTION_DELAY that was set to 25ms. When you click fast, the button press lasts less than 25ms, and the click is missed! So, I reduced this to 10ms, and the button is much more responsive. What is the tradeoff with time? Looking on the nordic forums, I found this:
So current consumption can go up when the button is pressed due to the timer. This also may explain the high current I saw when the buttons were pressed from the previous pwm measurements!
Anyway, this current increase is ONLY during the time (a few ms) when the button is pressed, so the impact is minimal.
Here is what I measure with the button held down:
1 ms delay button pressed avg current: 72ua standby current, 2ma! button pressed = 2ma! 5ms delay button pressed avg current: 72ua standby current, 602 ua button pressed = 530 ua 10ms delay button pressed avg current: 72ua standby current, 440 ua button pressed = 368 ua 25ms delay button pressed avg current: 72ua standby current, 345 ua button pressed = 273 ua
so I changed the button detection time to 10 ms. Seems a good compromise.
The buttons are more reponsive now, and the power impact is minimal.