ESP32-S2-Wroom - new lows in power saving.
Two weeks ago I was shopping on mouser to find some GPS modules (might blog about this project later). Beside finding out that any of the possible units I wanted are all sold out, I ran across the ESP32-S2-Wroom for €1,68.
This is a fairly new single core ESP32 Xtensa LX7 core and a RiscV ULP (ultra low power) core. Given I have been working a lot with a custom RiscV implementation and writing a lot of low level code for it I decided to buy one. Seems like this could be good for low power modules that cannot go into deepSleep. You can offload your monitoring to the ULP and wakeup the main core when needed. So I ended up buying 10.
After bodgy setup going (yes I did fix that short on the uart before using):
I got it to run fine (not yet the ULP). It was high usage when running and ~20uA when in deepSleep. Not bad.
While reading the
datasheet (yes, I read
through these datasheets) I noticed it had power management features and could do DFS (Dynamic Frequency Scaling) that
switches the CPU and the APB bus. Using this light-sleep mode allows the WiFi still be connected, neat. I wonder if it
does DFVS given the significant difference ( usage ~
C(voltage*voltage)*frequency+Estatic$, so voltage scaling will
give you the most gain)
Now I hoped this would bring the consumption down to 10-20mAh average as it has to wake up constantly for the WiFi. I planned to see if I could tune my access points to improve this later, but to my surprise I got way better results.
In my test program, I use esp-idf directly. I connect to my WPA2-PSK home network and mqtt server. I send every minute a message, I also subscribe to a topic that periodically wake me up. To me this seems to be a reasonable use case. I made it get disconnected and reconnected a few times during the experiment.
After fighting a bit with randomly triggered watchdog timers, I got it to run stable and my power supply read 0mA on it display and sometimes blipped up. Neat. Now this is not a good way to measure consumption (but good for a first indication), but how to measure it over a longer run. The spikes are very high and very short. While I could measure it with my multimeters, its difficult to get an average. My old Philips scope can easily measure this and average this, but not over the long time I am interested in (and did not feel like having a pc to log the info over GPIB ). So I decided to try out a ltc4150 coulomb counter I had lying around.
My final setup contained a stm32f108 to read the coulomb counter, a ltc4150 small test board and the esp32. After running for 3 hours in this setup, I got an average ~1.7mA usage. This is extremely low in my opinion. After forcing it to reconnect to my other AP that is several thick walls further away, the usage wen slightly up to ~2.65mA (3 hour average). Still very good. I did not properly calibrate the coulomb counter, but I did some testing and it seems within 1%
I must say I am impressed with the esp-idf flow, it takes some getting used too (I kept typing
make (muscle memory)
and breaking the current project) but it is very solid. I find it working better then the default arduino setup. The
WiFi properly reconnects, so does MQTT. The debug output I am getting is very helpful, so is the backtrace.
The only thing I cannot find is a simple adaptor board for this chip. So I quickly designed one and ordered 10 pieces
from jlpcb (with shipping and import duty almost as expensive as the esp32). I made it as minimalistic as possible, no
usb, no voltage regulator only two push buttons and minimal required pull up resistor and a voltage divider to measure the
input voltage as I plan to run them off lifepo4 battery.
Does anybody know if this chip can measure it own VCC like the esp8266 or the esp32?
rom_phy_get_vdd33 seems to exist
in esp32 and esp32s3 but not esp32s2.
A board like this is probably more suitable for most users: https://github.com/eggsampler/ESP32-S2-Breakout.
Now two things are left, find an actual use for this and try out the RiscV. Suggestions are welcome.comments powered by Disqus