ul-gh/ESP32Touch

Support for deep sleep

Closed this issue · 3 comments

Hi,

Thank you for your work - is there some guidelines to add deep-sleep / wake from deepsleep - seems the Arduini way and your lib is mixing up...

/Kasper

ul-gh commented

Hi Kasper,

the focus of the ESP32Touch library is to have reliable readouts of the button state.
To achieve this, the inputs are sampled continuously and we hook into the IIR filter from ESP-IDF API.

This is done at line 73 and 74 of esp32_touch.cpp.

This is likely not suitable for battery operated devices, this is a continuously running software filter.

The ESP32 touch sensor API does support hardware interrupts which then can do wake-up from deep speep, but in that case, we do not have any filtering. And without the filtering, at least with the Arduiono API (touchRead function) I did not have any good results, I observed random false triggering of the touch inputs.

==> I did not check if the current version of the ESP32 SDK still has this bug in the touchRead() function.
==> I also did not check how reliable the hardware wake-up from deep sleep is when using the ESP-IDF API.

Please have a look at the ESP-IDF documentation regarding the software filtering and touch hardware interrupt related API.
I would very much like to hear if you have good results using this, then I could look more into this.

If that does not help (if the touch sensor is just too noisy from the hardware side), what might have to be done then is to only wake up periodically every 100...200 milliseconds, acquire a small number of samples, do some averaging (or better, throw away the extreme outliers first like a simplified median filter) and then after evaluation go back to sleep.

Best wishes,
Ulrich

Hi,

Thanks for the answer.

What I had in mind, was using your SW filter when application was running, then unload, set irq and go to deepsleep - at beginning initialize yours filter code again.... but seems I have to unload your code or re-initialize the Arduino function again... I will try look into that, what's going wrong...

I made it work that way - the issues was the "gain settings" in the signal is changed in your lib compared to the arduino, så the treshold value had to be different....