Delayed/latched re-triggered wake-up

[jcaron]

Hi all,

I'm trying to find the most effective way (in terms of power consumption) to do the following:

• - I have an input signal that goes high for a couple of seconds when an event is detected
  - initially, the ESP32 should have a state set to "inactive"
  - when the input signal goes high:
  • - if inactive: the ESP32 should be woken up, set the state to active, send a message, set a timer (say, 5 minutes), then go back to sleep
    - if already active, the timer should be reset (cancelled and re-armed at 5 minutes)
  - when the timer expires, the ESP32 should be woken up, set the state to inactive, send a message, then go back to sleep.

In addition, there should be another longer timer (say, 1 hour) to wake up the ESP32, send a message, then go back to sleep, but that one is less important, so we can ignore it for now.

The goal is to have one message sent out when "activity" starts, and another one when there has been no activity for a given time (5 minutes here). Average power consumption should be as low as possible. The input signal will usually have long periods (hours) of either staying low all the time, or going up/low many many times. I don't want to send a message any time the input signal goes high, and would like to avoid waking up to ESP32 every time.

Input signal:

Code: Select all

________-__-_____-_-_-_-____-____________________
        |                   |----timer----|
        Active message                    Inactive message

My initial though was to use the ULP to achieve this, but there does not seem to be a way to set the ULP to sleep and only wake up when a signal goes high, is there? That would mean keeping the ULP active, which even though it's only about 100-150 µA, is still 10-15 times what could be achieved in deep sleep.

Another option would be use the ESP32 wake stubs to do the minimal work required when the signal goes high (check a flag, reset timer) and go back to sleep immediately, but I have no idea how long that takes nor how much power it would draw. From what I understand, the wake stub happens very early and skips a lot of the initialisation, so it should be relatively quick and draw limited current, but I have no idea how quick and how much.

So, here are the questions:
- Is there a way to stop the ULP and wake it up (but not the ESP32 cores) on interrupt?
- How much time and power would a minimal wake stub take?
- Is there another alternative?

Thanks!

[ESP_igrr]

Depending on duty cycle of your ULP program, ULP might be an option. Based on your description, duty cycle can be made very low — it would be sufficient to let ULP wake up every, say, 100ms and keep working for a few 100us. This would result in average current consumption little over the deep sleep current consumption. Perhaps you can check system/ulp example in IDF, which does pulse counting, and see if it can be used as a base?

[jcaron]

Thanks for your response.

I thought about that, but I admit I'm a bit confused about the figures for ULP consumption.

The data sheet says:

• - Deep Sleep / The ULP co-processor is powered on -> 150 µA
  - Deep Sleep / ULP sensor-monitored pattern -> 100 µA @ 1% duty
  - Deep Sleep / RTC timer + RTC memory -> 10 µA

Which led me to think I should count about 100 µA if I used the ULP to check the signal level on a regular basis.

But https://github.com/espressif/esp-iot-so ... etup_en.md says:

• - Deep-sleep -> 6 μA
  - Delay Nop -> 1.4 mA
  - GPIO Toggle -> 1.4 mA
  - SAR_ADC Sampling -> 2.3 mA

If I understand things correctly, if the ULP is doing anything, it's actually using closer to 1.4 mA than 150 µA? Then 1% duty should only use 1.4 mA / 100 = 14 µA, not 100?

The next-to-last graph in https://github.com/espressif/esp-iot-so ... tion_en.md shows spikes to about 1 to 1.5 mA every 100-something ms (not 10 times per minute as the text above says). The spike looks really short (and seem to be less than 1% of the interval), but the average is still nearly 80 µA, probably mostly due to the "tail" of each spike.

I understand that most instructions take about 6 cycles. I suppose the whole logic I need should not need more than 20 instructions (probably less), so about 120 cycles, plus 20 cycles for wake up and go back to sleep = 140 cycles. That means the ULP would be running for 140 / 8 MHz = 17.5 µs, is that correct? Or should I somehow count that "tail" which seems to increase the average quite a bit?

Will probably have to try and measure by myself, but want to see what I should expect...

Thanks!

[ESP_igrr]

When ULP is running constantly, current consumption will be closer to 1.4mA. It takes about 4 cycles for the ULP to wake up and go to sleep, the rest is determined by the program being run. For simple programs which only check GPIOs you can expect around 15uA current consumption. Above mentioned ulp pulse counting example has it around 16uA: https://github.com/espressif/esp-idf/tr ... system/ulp, waking up every 20ms. Regarding the "tails" on the graphs in iot-solutions repository, i think this is a measurement artifact. In reality current consumption increases and decreases quite sharply.

[jcaron]

Great, thanks! 16 µA seems like a pretty decent value, and since I can probably use a larger sampling interval I should be able to get even lower.

Time to get to work and try this out!