Tech Note 057 - ESP32 Ultra Low Power Test Results
HTML-код
- Опубликовано: 2 авг 2024
- Thinking of running an ESP32 as a battery powered data logger? then you might need to think again unless you like changing batteries all the time. The best I can achieve is ~200-days on a 3000mAh battery and that is not considered to be a good result!
I conclude that conventional RF links are far superior until the RF power can be reduced on the ESP32, which might help somewhat to improve battery life.
The BME280 is a non-regulator type, so no 5-3.3v voltage regulator, it has to run at 3.3v only. If you use a 5v variant, it will consume typically 5mA in non-measuring mode.
Code Example: github.com/G6EJD/ESP32-Deelp-... 
Наука
You should change upload strategy, and store measured data every hour and use ULP coprocessor to measure temp/hum 6 times per hour (every 10min) without turning the main chip on. That will give you almost 6 times better results.
Do you have any github or other link of using the ULP instead of main chip on this purpose? That would be great. Thanks in advance
Thank you! This was very useful for a project I am working on.
My advice is make sure you have good power supply filtering/storage capacitors, but not too big, otherwise you will get unreliable operation. You should aim to have at least a 0.1uF as close to the ESP32 power pins as possible and a larger reservoir capacitor of about 10uF or more elsewhere, that way the capacitors can handle short or long peaks in power demands that your supply cannot deliver and the ESP32 takes a lot out of the power supply when it starts and during certain (mainly radio/Wi-Fi) operations.
@@G6EJD you could use a small solar cell to charge the pack to extend the life since lifp04 are fairly safe and the charge controler is like 1.80 usd you looking at maby 4$ for a 4v solar cell that will do 160mah and a charge controler like the www.batteryspace.com/PCB-for-1-cell-3.2V-LiFePO4-Battery-Pack-at-2A-limited.aspx?gclid=Cj0KCQiAjfvwBRCkARIsAIqSWlPhWrc5AimLG1wf7Lpeg7cXzb7wwld9DnLZQ2FUsdBCuBP18G2sO1QaAlCPEALw_wcB
For this kind of tasks more suitable to use smaller controllers. Like atmega328 or even smaller. In pair with Rf24 or lora modules. It will be very power-effective devices with low consumption and will work over 1-2 years from 2 AA. Create your own base station on lora or rf24 that will receive data from loggers via rf and transmit data to internet if it needed.
I'm having exactly the same radio temperature 2xAA battery powered device (atmega328+nRF24l01), that i created in april 2019 - it sending data (temperature, hum, and battery voltage) every minute. Today (it is about 9 month of work ago) the voltage droped from 2.96v to 2.88v (batteries that i used was not fully charged).
you need to use the ESP-NOW protocol for data transmission. This will reduce transmission time from 3 sec to ~220msec. Build a gateway that transfers ESP-NOW packets to WLAN and your battery will last forever ...
Have you tried that approach? The ESP32 was/is marketed as an IOT device, so using a non-standard intermediary is counter to the concept and introduces additional overheads in equipment and design.
@@G6EJD I run a bunch of sensors in my house using this approach. The Gateway consists of 2 ESP32 ... on is permanent in ESP-NOW mode .. the other on WLAN - communication is via serial interface. (The ESP's can't do both modes at the same time) I know there are project around using just 1 switching betwenn WLAN and ESP-NOW .. but I wanted to have a more 'clear' solution. Just search Inet for ESP-NOW (f.e Andreas Spiess videos). I'm also using this method for 'pushbutton' style application, just powering on the ESP32 during button press. A normal button press gives me always enough time to complete everything. Actual project is to replace all the window sensors of my alarm system using this approach. Check code will run in the ULP .. transmission every 10 minute or so via ESP-NOW or when the status changes. This will allow me to detect dead sensors and always give an updated view of forgotten open windows. Maybe I'll add those cheep chineese radar sensors that are incredible sensible to turn them on on demand - or permanant for some mains powered sensors at special locations ... At least that's the plan ...;-)
AFAIK it also has BLE what about using that instead of WiFi? Isn't that better suited to low power wireless applications?
Otherwise, as you say elsewhere you could stick to 433MHz FSK modules because I guess the low power processor mode is still good right?
+stewartrv Yes BLE would help reduce the power consumption by the RF section, but it's a matter of convenience and infrastructure and BLE is not widely used (yet) to enable its use. For example a wifi router that enables network connectivity could include a BLE transceiver to enable Bluetooth as a transport method, but I have not seen any take up of it, probably due to cost or simply a lack of demand. Also for BLE to be used another (perhaps) ESP32 would be required to receive and route data to the network onward in my example to Thingspeak. Yes the processors are viable low power variants, but in normal mode the current consumption is still relatively high at ~45mA and there are much lower power devices around than that. The ability to reduce ESP32 RF power output would help, but I haven't found a means of doing that yet and I know the device supports it. The ESP8266 appeared to have a more efficient RF section and I don't know why Espressif did not use it in the ESP32 assuming the CPU's are using less power!
Hi David, since the main power is consumed when on, I am wondering how this power on power consumption would be influenced if you would use bluetooth LE only or even a external RF module to transmit the data. I realise this is an old post, just wondering.
Luc Segers, there’s no doubt that using a low power RF transmitter would dramatically reduce power consumption but at the expense of link reliability and quality. BLE would work like the low power RF alternative but at the expense of having to use a special to type receiver. Unfortunately it is the ESP32 receiver that consumes the majority of the power whilst the RF section is on. Various techniques have been tried to reduce time to upload, but probably one of the most efficient way now is to reduce the CPU clock speed to 80MHz that drops cpu power consumption by 50%
Solution: after a few weeks of testing and reading the solution was bad silicon from Espressif. All early ESP32 have Rev0 silicon that prevents reliable wake up from deep sleep. I’ve ordered and tested newer ESP32 modules with 100% success. My last test had the ESP wake every hour over three days with no issue. There are sketches you can run that show the silicon revision and you can also show it by compiling in verbose mode in the IDE. Rev 0 silicon cannot be fixed in software. My Rev0 silicon ESP modules will be used in projects that do not need sleep mode.
Yes, I recall it was because (you can tell from the Chip boot message when it failed) that it was due to Wi-Fi being started instantaneously, but worth remembering the silicon revision resolved it. I think I'll label my Rev.0 chips so I know and to prevent many hours of fruitless diagnostic work! Thanks.
So, are the ULP coprocessor performances mediocre ?
+Bouras Abdennour well the problem is not the processors as the dominant power consumption in mobile/portable/remote operation on batteries is the WiFI transmitter, it is nearly double that of the ESP8266 and takes a relatively large power surge at startup this places demands on supply filtering and layout and design. In sleep mode the consumption is an impressive 6uA with the WiFi off the power consumption is about 40mA all of which indicates it's not that good for wireless low power use IMO and Microchip offer better solutions in their an1810 or derivatives.
First of all, thank you for the nice presentation of the video. I have a question. In the module I have taken, there is no stabilizer on the board. Are you using the board with or without a stabilizer? According to the technical manual, the voltage of the bare esp 32 is from 3-3.6V. I don't even have the 2 resistors between the buttons. What value do they have?
The battery is a 3.2v LiFePO4 rechargeable so no regulator required, check the ESP32 data sheet it requires 2 pull up resistors to start properly one is to set the state the other a reset.
@@G6EJD The battery voltage ranges from 4.2 - 2.8 Volt. Can't burn the esp32 that has an operating voltage of 3-3.6V? My board has a backrest for voltage stabilizer. Just not stuck. It doesn't even exist.
@@master3763 Please not in this example I'm using a LiFePO4 battery with a voltage of 3.2v - NOT a LiPo with a voltage of 4.2v. If your using a voltage regulator then your wasting power to drop 4.2 down to 3.3v
@@G6EJD Thank you very much ! I didn't notice that the battery is at 3.2V.
Could you write data to flash every 10 mins instead of transmitting, then transmit only once per X hours (eg once per day, or per 8 hours)
Yes of course, but then the data is no-longer near real time.
Wi-fi takes a lot of time while connecting to AP. So it "eat" a lot of power. LORA or RF24 or CC1101 more effective in this case.
very analytical
Great video! As a test I’m blinking an led a few times every 15 minutes. The deep sleep/timer wake up code is the same as yours but after three hours or so it stops. The battery voltage is fine so I’m wondering if there is a bug in the ESP code. Have you run yours over a few days?
There are no bugs and I have the same circuit above running since 08-Aug-17 sending data to Thingspeak. g6ejd.dynu.com/index.php/wx-logger-data/
The main let's call it issue, with the ESP32 is the relatively large start-up current of early Rev.0 silicon devices, which has been reduced a bit with Rev.1 devices now the norm.
The current demand can be ~450mA for a short time and then 150mA and various current spikes in-between. For your test, I would increase the amount of storage in the capacitor and add a parallel 0.1uF - why. Large capacitors tend to be very inductive so limit current discharge when there is a rate of change, that's where the smaller 0.1uF low inductive capacitor helps out, you generally always see this arrangement in a circuit two capacitors in parallel one large one small. Regarding the size of the larger capacitor, to prevent power supply dip - even from a battery short cable runs can result in a supply dip at the device, you can calculate the value with the approximation. Q=CV or I^2t = CV and where I=450mA and t = 10mS and v=3.3 gives a value for C=61uF. In my setup I used 10uF and noted it was a compromise. IN the ESP8266 functions there was a WIFI_NOCAL option that after sleep did not go through the initial RF calibration routine which the ESP32 does on wake-up and accounts for these high current demands and usually resultant lost of reliability. You could try turning off the Wi-Fi before sleep, or better to try increased storage to eliminate power supply issues.
You can see some of these artefacts during programming, if the power supply is not sufficient to drive the device, lets say a USB to serial dongle, the chip will keep saying flash programming error or give various error messages, when nothing seems wrong with the programming activity. In fact it reports programmed correctly, but then won't start, this is the high current demand pulling the supply low. But if fed with a separate 3.v power source then it all works.
So my summary is I think your problem is insufficient power supply filtering.
Other things you can try are making the delay variables long using L or LL to increase their size, I don't know what your code looks like, so that's a guess. That said for a 15-min duration a 32-bit integer has more than enough range to store that delay value.
Does your code run OK on the bench on a development board? As that will have reasonable power supply filtering. IF not then it is a code issue. How are you saving LED state between wake-ups?
G6EJD thank you for the detailed reply. I’ll tack on two capacitors as close to the ESP32 as possible and run tests again. My blink led code is here: pastebin.com/dMCQdFGm
Looked at your code and interestingly, I stopped testing for wake-up reasons when I discovered it made my code unreliable. The other issue might be timer overrun (32-bit) and there is an improved test you can do to prevent that, so at overrun there are no unexpected results. I tend to make the timer variable a LL type to be sure (128-bit).
No voltage divider for mesuring VBat?
Thanks.
Marc.
Marc, it depends on the board but solved by placing say a 100K resistor in series with the ADC connection maybe pin39 to Vbat and then another 100K to Gnd from pin 39 that will divide the input voltage by 2 allowing 0-6.6v to be measured.
@@G6EJD with 4.2v battery 220k and 220k voltage divider is OK??
, perfect
Can it run with only 1 battery ??
Thanks.
Yes, I only used two to get the capacity up to ~2600mAHr The Lifepo4 18650 chemistry batteries tend to be about 1000mAhr, mine were 1200mA, I have seen 3000mAHr and 2000mAHr, but I believe they are fake capacities as the big branded batteries make nothing like that. I think 1600mAhr is the very maximum you can get. The voltage is nominally 3.2v but they start fully charged at 3.5v and drop to about 2.8v discharged, but have a very flat (3.2v) discharge curve if you can call it that, with a sudden knew voltage at 3.1 that goes to flat/2.8v very quickly, so not much warning. Nonetheless a highly usable battery for 3.3v logic like the ESP8266 or ESP32, one of the easiest ways of getting extended battery life is to use a development board and feed it 3.3v directly onto its 3.3volt pin by-passing all of the UART and regulator that waste power in the final running system. I asked Wemos if they would make a board with a link to isolate the UART, LED, Regulator and whatnot but so-far all they've said is their thinking about it.
Where did you get the cells from?
Amazon, but not easy to find. Google 18650 LifePO4 will find stockists, but be careful many are fake like the Li-ion 18650 versions.
Good Evening!
The voltage of a fully charged battery is 3.65V.
1) If the battery voltage drops to 3V when discharged, the analog measurements will not be affected? As far as I know analog needs a constant operating voltage for correct measurements.
2) What is the operating voltage of the analog of the naked ESP32? The linear voltage according to graphics from datasheet is observed from 0.21V to 2.53V. Right?
Depends what sort of battery. A li-ion battery is 4.2v fully charged and 3.6v depleted. The ESP32 or ESP8266 supply voltage is a nominal 3.3v but can work down to 2.8v, maybe a little lower but not recommended. A typical LDO regulator requires 0.1v to operate so the absolute minimum supply voltage is 3.3+0.1v = 3.4v or 2.8+0.1 = 2.9v
@@G6EJD So is there an internal voltage regulator that can take from 2.8 to 3.6V and make it 3.3V without affecting the measurements? Also I tried to just give digitalWrite (Pin, HIGH)? when the supply voltage of the bare esp32 is 3v and in the pin I got + 3V with the multimeter instead of 3.3V. Which means that the output depends on the operating voltage of the ESP32. So I thought of analog ...
The bare ESP32 does not have an on-board regulator and the ADC reading will be affected at the higher end by lower supply voltage, but it uses a common mode input so that supply rail variations are ignored with the range 0 to Vdd so the ADC should work normally even if supply voltages drop. If Vdd drops it is the maximum voltage reading of the ADC that is reduced.
The data sheet says a GPIO voltage will be Vdd - 0.3v
@@G6EJD If I understood correctly the analog reference voltage will be affected if the supply voltage is low 3V .. But the indications I will get will be normal and will correspond to the analog input voltage as in the case of 3.3V.
Can I set the reference voltage of analog only? Is there an AREFF pin in esp32 (external reference voltage)?
Hi! I've read on the BME280 that the current consumption during humidity, temperature and pressure monitoring is 3.6 uA. I can't understand why your slides consider 720uA. Could you help me understanding this please? (the datasheet I used www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme280-ds002.pdf)
Have you tried measuring the supply current? It’s a combination of the bme280 and its supply regulator, for the on board regulator to shut down it needs the bme280 in sleep mode so there is no load and then both shut down, the difference is quite large in relative terms. I’m sure if the bme280 was connected without any supporting circuitry then the 3.6uA would be achieved, but for most applications the 3rd party boards are a practical usage.
@@G6EJD Hi and thank you very much for answering. I'm very new to electronics and I still need to get a lot of things. Your answer was really helpful. That said, when I need to project a circuit I always have to calculate power consumptions myself instead of using provided datasheet if I'm not using only the chip ? Or is there any sheet/website where I can read what is the avarage power consumption for the whole board (like the ESP32 board and the BME280 board you are using in this video) instead of the single chip?
@@G6EJD For example, in your other video (ruclips.net/video/b2aWZYlmL30/видео.html i love your videos btw!) the description says
"WiFi ON 70.3mA
WiFi OFF 15.2mA
Sleep 0.24mA"
Are these values measured by you, or did you get them from any sheet?
@@xTheColinox unfortunately not as the number of variables is huge, on any typical development board there is say the ESP32, then a multitude of regulators, uarts, battery chargers, flash memory, I have not seen any common devices other than the ESP32, in fact what separates good from bad performance boards is the power regulators especially when in sleep mode, plus some designers leave the UART connected when on battery power when they should have powered it from only the usb power, some designers understand the low power requirements some not, some don’t care as well! Some of this knowledge only comes with experience of having designed systems too.
@@xTheColinox measured by me, even between the same devices the spread of results can be quite high maybe a standard deviation of 3 or more, so you can read a data sheet and you will see the consumption range across the device from manufacturing process but can’t predict what it will be, maybe from the same batch you might have a much lower standard deviation, therefore only by measuring individual boards can you be sure, it is not a deterministic or quantitative process. Plus measuring low level currents needs skills and clear understanding of the measuring instruments capabilities, a low cost dvm will not be able to measure currents less than 1mA with any degree of accuracy and usually prevent correct operation. Lots more for you to learn I think!
Are the reading from the BME280 accurate?
Some sensors, and I can't remember if the BME280 is one of them, needs a few seconds to settle before an accurate reading can be taken.
I wasn't sure, so just checked the data sheet, it takes 2mS to start from standby then it can output data at a rate of typically 60Hz so 16.6mS, it can be adjusted to deliver readings at up to 160Hz, also the reading rate will be synchronous to the SPI bus but that is running at 4MHz so not a significant factor. I've found the bme280 to track my Davis weather station to 0.1hpa so on that basis I'd consider it accurate, but it's all relative.
All sounds fine then, Great!
+Craig Fryer new stock of Wemos D1 Mini v2.3 available in 15-days according to Wemos.
Thanks for the update.
That 115.5 mA for 48 hours. means the current that is consumed for one hour is 2.4mA. means to make a minimum system esp32 without leds, regulators, only consumes 2.4mA current when active (wifi on). Is it really like that?
Your calculations are wrong, and the results are in mAhr not mA
@@G6EJD my question is how much power consumption when standby (WiFi on) for minimum system esp32? my case will turn on the minimum system with a 5Ah battery
@@G6EJD I really hope for your reply, because I will make a motorcycle alarm project. power supply from the 5Ah motorcycle battery, but I'm worried that my motorcycle battery will drop quickly.
@@ta7615 the ESP32 consumes 140mAhr when running, so 5000mAh/140mA=250/7=35hrs
It will if you run WiFi continuously.
I did something similar with same results. My findings is that the esp chips can take up to 3 or even sometimes 6 seconds to join the wifi ap which is a huge battery waste. Compared to gfsk modules that wake up and tx the data in 50msec
+thefatmoop Yes, there are far superior devices like that one on the market, but why is the ESP range being apparently marketed as a low power IOT device when it’s just not capable. Thanks for letting us know as it validates findings. Also, yes the ESP32 is remarkably slow at getting an IP address and joining a network and has poor RF range as reported on many forums, but the ESP8266 is quite the opposite and very fast with good RF range.
The 802.11/whatever other 'wifi' protocols just aren't designed for low power. 3g cellular has the same issue where you can't just wake up and tx right away then go back to sleep. You can tx raw frames with the esp chips which would likely be fast as there's no association with an ap, but then you need a device listening in promiscuous mode to rx the data. At that point you're implementing a 'proprietary' protocol and might as well go with fsk/gfsk/lora.
But for 'low power' definition: getting a year on a battery with a wifi device is pretty extreme.
Well it was a test/trial for a product that is marketed as a low power IOT device, and in relative terms it may be low power, but the ESP8266 was much lower and other devices produced by Microchip are far superior and using 802.11/IP protocols, so it can be done, it's just that the ESP32 is not a good implementation when compared with other brands. I was really hoping for better performance than the ESP8266 at the very least. Also, I have noticed very poor Wi-Fi performance and rang as noted in many forums and especially compared to the ESP8266 that gives me reliable and fast connections. As per my conclusions my trial aim was not achievable but sometimes it is good to stretch the target to see what's possible. Also latterly I have tried reducing RF power output, but it has negligible affect on the power drawn because of RF stage designs, I see this a lot with class-A/B RF designs. Espressif could have usefully used the ESP8266 RF stages, the ESP32 is particularly power hungry.
Hello G6EJD, it was nice video. Can you tell me how you calculated the ESP32 active power consumption( average) over 48 hours?
If you have documentation of mathematical calculation of power consumption please share with me.
Thank you.
+Vishnu Dhanavath The average mAh calculation was quite simple. I used my digital storage scope to monitor and store the readings (when > 0) of the voltage across a series 1-ohm shunt resistor and set to mV (mA because mV /1 from v=I x r ) then simply added up all the samples taken every 0.5 seconds and divided by 48-hrs. See my other video on how to calculate mAh. In simple terms if you measure circuit current consumption say it was 100mA and lasted for 60-secs then mAh = 100*60/3600=1.6mAh. The reason for 48-hrs was this was the storage limit of my digital scope.
BTW if you want the recording file send me your email its a CSV format
You could try to log the data for a period of time and run some simple compression before sending all the recordings for that period...
You can always set upper and lower limits which if exceeded would send immediate etc... else send every hour or two... could give a serious increase in battery life...
Michael O'Toole Yes a change in upload strategy could increase battery life, but the Thingspeak API I’m using has no provision for the time of the reading uploaded, so bulk readings all get the same time stamp, so I’ve given up on the ESP32 and gone back to the ESP8266 which can easily achieve the design aims as its RF stage uses significantly less power and the sleep current of ~60uA whilst x10 more than the ESP32 is still insignificant and therefore gives the best solution. Until the test was conducted I did not know the durability of the ESP32 but now I do and for me in these applications it’s no good, so it’s my opinion that it is for others to decide if it provides an acceptable solution for them.
So it would mostly depend on load.
once an hr event increases life almost 6 times.
Yes
why not a 1000uF capacitor? only 10uF ??
It was to big for the case I was fitting the ESP32 in to plus sensor and battery, also nearly every development board use a 10uF smoothing capacitor so I thought I would use the same, well except I'm not using a voltage regulator. The correct value for the peak current demand is closer to 10,000uF! (I.t=C.V where I and V are delta values)
Yes Sir, but 1000uF works good. This device has some huge current drop, almost half amperes in milliseconds periods. The little 1000uF by 6.3V is working good to me. Do you know Andreas Spiess channel? Many nice videos about this subject. Thanks.
Yes I know Andreas Spiess and yes 10000uF will work well if space is not a problem. If you use a LDO regulator you can use much smaller values. Like Andreas I have been measuring the ESP32 current profile during Wi-Fi switch on and yes it has a relatively high current demand, that's where the value of 10,000uF came from and the equation Q = CV
This is really interesting - when I was playing with the ESP32 on the same breakout board you show, I couldn't get ANY wifi-using code to work because of brownout until I put a lot more than 10uF of capacitance on the power rail... this was directly from my bench power supply. Do you think 10uF was enough because your power wasn't regulated? I should try it direct from an 18650 (though all the 18650s I have are 3.7V nominal, coming in at up to 4.2V... maybe some alkaline cells would work better.
Really only the Lifepo4 3.2v cells are safely within the ESP32 voltage range 2x1.5v cells are too low for reliable operation and 3x1.2 nicad are too high unless discharged a little. All long cables to the ESP32 introduce resistance and voltage drop so some form of energy storage is necessary to keep the ESP32 running during the high current transient demands. I’ll work out the optimal value and post the answer.
Comparing apples and oranges, the ESP32 has capabilities that you won't get in an analog rf solution. In low power mode WiFi is out, setup time is too large, use the ESP Now which is peer to peer and doesn't require setup time. Two the ULP processor can take the readings and store them so you can reduce transmission time. If you are using the ESP32, why aren't you doing any processing with it? Perhaps it isn't being used for what it is best suited for? I never would have expected a processor like that to last years on batteries. That it lasts months is great and it is running for 3 seconds so it is busy being idle, you should be able to reduce the up time by an order of magnitude by optimizing the rf time.
Christopher Guy, The reason for the test was to demonstrate that the ESP32 whilst marketed as a Ultra-Low Power IOT device, is in fact quite power hungry. It’s RF stage consumes twice that of the ESP8266 and whilst the ULP could be used to collect results, that was not the design intention which was to make a real-time IOT sensor not to simply store values then upload them later to get around poor efficiency of the design. There are CPU’s + WiFi that out perform the ESP32 and these do meet the design criteria, but until someone did the tests with the ESP32 we’d never know if the ESP32 was capable of being an practical low power IoT device - it’s not! BTW no one has come up with a solution to the design criteria and if you check out Instructables you will see that I tried a number of techniques to reduce connection times using fixed IP, no DNS, etc and it made little difference. The ESP32 RF stage is too inefficient because the Receiver is taking too much power (Espressif conclusion not mine). I still look forward to someone solving this solution with an ESP32 - comparing apples with oranges ,I don’t think so. I now have a board with an ESP32 plus LORA and it achieves my design aims which was my conclusion as a solution.
My point was that by using WiFi instead of ESP-Now you were waisting power performing the WiFi setup every time it woke up.
While LoRa may be a winner in long distance, ESP-Now communicates at 2.4G and it is point to point like LoRa but without the time (and power) consuming WiFi setup. This gives the communication speed of WiFi without a large power drain everytime. As with LaRa, you'll need another ESP32 at the other end.
I understand but the design intention was for the IOT device to take a sensor reading and upload the result to Thingspeak and using ESP Now would need an intermediary I receive the data and then upload it. If the ESP32 RF stages and receiver took less power it would help I can get the total upload time down to ~2-secs but low efficiency results in high power demands. I don’t see how ESP Now could change the RF stages to reduce power the RF section is the same power hungry class-D stage no matter what modulation/protocol is used. As I say no one has solved the low power ESP32 IOT solution yet afaik and lots have tried. There are now plenty of cpu+WiFi solutions around that use a fraction of the ESP32 power and so more suitable for IOT designs notice how the ESP8266 is still dominant in many or most IOT devices!
@@G6EJD Which Lora/ESP32 board you found that runs on low power? I'm looking for one and most development boards seem to be a bit power hungy unless you desolder a lot of stuff that's not needed.
hoggif, like you I have not found any boards that can achieve low power because they all omit the control lines to the LoRa modules that enable the LoRa module to be placed into sleep mode, that said most LoRa modules don’t take a lot of power. You can get just a LoRa transceiver on a board then hook that up to an ESP32 which enables you to add a gpio line that places the LoRa into power down, that’s what I would do.
Are you using low power wifi in tests?
I have tried reducing RF power output, but it has negligible affect on the power drawn because of RF stage design, I see this a lot with class-A/B RF amplifier designs. Espressif could have usefully used the ESP8266 RF stages, the ESP32 is particularly power hungry. For example with my 100W HF transmitter it consumes about the same power on 100Watts as it does on 20-Watts because it is the early stages that consume the bulk of the power. yes, RF power is reduced, but not efficiency. The ESP8266 performance far better in this regard.
Thanks, Yeah I was just reading the RF cal boot up modes, it seems to already be fairly optimized, and light sleep already disables radio between beacons also.
I also tried starting the ESP32 in no_cal mode like the ESP8266, it's the really high peak in current ~350mA when the radio starts that really hits the PSU and causes problems, fixed in Rev.1 silicon, but it's such a short pulse it has little energy over hours and makes no difference from my measurements.
Battery power over many months is not really the forte of an ESP32 !
Do you know if the 8285 is designed for low power usage? I noticed it is much smaller and with built in flash, but have not checked specs yet or tested one.
It requires ~80mA verses ~160-240mA so about 1/2 to 1/3 of what the ESP32 requires. Flash size is 1Mb which for most applications should be adequate, I’d put it into the same category as an ESP8266 which may use less, I consistently measure 8266 current consumption at 74mA. There are that many 8285 development boards around, some are dedication boards too so not fully versatile.
How about you actually read the BME with the ULP and power on to transmit only if data actually changed. Can't really compare the 433/866 MHz to WiFi/BT ;) or compare ESP32 to ESP8266 and expecting it to use less power... There are ways to lower power consumption by lowering the RF power, lowering the CPU clock and even disabling one of the CPUs. And surely you can use ESP8266 since it's slower and has only WiFi, which is what this project requires (not a dual core beast)
The genesis of this topic and trial was that the ESP32 is marketed as a ultra low power IOT device and so a perfectly reasonable trial to conduct and sending data back to a cloud-like service is for me a given, if it's to be a useable IOT device.
Yes the ULP processor could be used to read the BME, but neither of the processors in sleep or operating mode are the dominant power consumers and that includes the ESP8266 too.
I do show that the ESP32 uses less power than the ESP8266 but to reiterate that is not the issue, both ESP devices and their transmitters use a lot of power in relative terms.
Lowering the CPU clock has no effect on RF power consumption and neither would disabling one of the CPU's because they are not dominant in the power budget.
I have lowered the RF power and the difference between full and lowest power settings is minimal, but this does not surprise me, because the devices appear to use (no data sheet information, so an educated and experienced guess) a class-B RF stage that is inefficient. As an example my 100W transceiver consumes broadly the same power whether it is set to 100Watts or 20Watts, but the efficiency changes dramatically and this is not unusual for any RF power stage / transmitter and the ESP8266 / ESP32 RF sections are no different in that regard.
On the Instructables forum I and others have conducted numerous tests aimed at reducing power by for example, keeping alive the IP connection, changing protocols (TCP v UDP), not using DNS Services and other techniques, but none made any appreciable difference to power consumption.
For efficiency there are far superior Wi-Fi devices on the market like the Microchip 1810 series, showing that a high efficiency Wi-Fi connection can be achieved, but ironically not advertised//marketed as a ultra-low power IOT device!If you can find a way of reducing power consumption then there are a lot of people around who would be very interested to know how to do it.
It is (in my opinion) only ever going to be a viable IOT device if it can be used for low power work and be powered with a battery for a reasonable amount of time, say 6-months to 1-year, but it can't.
There is a lot of variation in how many seconds to log on my BT router so this varies the average current when the current is at the highest. The only way to improve is to use the RTC memory of the ESP that is preserved by reset as long as power is maintained. Then send say once a hour. This means that data would take longer to send but would save seconds overall. The down side is the data stamp from thingsspeak would be the upload time not the measured time. Reduce the WiFi power of the ESP if close to the router? A larger capacitor 1000uF? might help to stop the battery droop when the reset occurs as that will give an earlier battery brown-out. Watch out some capacitors have a bad leakage current that is proportional to capacitance value. I have some LifePO4 1800mA 18650 but don't believe the capacity, I don't know for ESP32 but the 8266 really need 3V to boot correctly so don't get all the battery as specified down to 2.8V for the capacity calculation. Thanks for another interesting video/
My Sky-Q router is very quick, despite it's poor RF range and the ESP32 can easily make a connection and upload the data in 3-secs. Using the RTC RAM is a good idea, I can't recall if the THINGSPEAK API can support data recording time with data readings, and time could be stored locally in a minimal form. I estimate the ESP32 would take ~1-sec to wake up, take a BME280 reading and then enter sleep mode, perhaps faster than that, so that would be 6-secs/hour of recording time, which is less than the 18-secs (6x3) now, so that's a saving, then one long burst every hour, let's say 6-secs, so that saves energy. Yes both the ESP8266 and EPS32 take a huge current demand at Wi-Fi switch-on, about 310mA for 2mSecs for the ESP32, though much less for the 8266. So for the ESP32 and from Q=C.V then I.t=CV. and C=(0.310*0.002)/(3.3-2.9)=6200uF to handle a 310mA 2mS transient demand and a voltage deviation of 3.3 down to 2.9Volts., so probably use a 10,000uF capacitor for the typical range of demands. Yes leakage current is an issue, but a good quality capacitor is the only answer I think. Likewise on the batteries, mine are 1500mAh, but more likely 1200mAh in-practice and to keep them within their nominal operating region. Problem is, that exacerbates the battery life and expect a time-on-battery duration of more like 150-days, which for the size of battery is another poor performance result for a device that's hailed as 'low power' which it is, but only on in sleep mode!I think on-balance the ESP8266 provides the better low power solution, I'll try to run the same test with an ESP8266. Well I already know the result, the ESP8266 will beat the ESP32 hands-down because it's Wi-Fi current demand is nearly half that of the ESP32 and that's the dominant power consuming factor.When there is easier access to RF power reduction, this will help with peak current demands.
Thanks for the great video!
From your code it doesn't look like you are using a fixed IP address. Apparently the (re)connection time is reduced significantly by using a fixed IP address. I haven't actually tested this yet.
Craig Fryer Good idea and I haven't tried that either, yes it should be faster as it won't need to go through all of the DHCP protocols. As the time-on is the dominant power consumer, every second reduced is a bonus, so I'll give it a trial, I'm currently waiting for an ESP8266 module to arrive (no uart) so I can do the same test with that device and where I'm expecting a better result, if it is as fast to connect as the ESP32 that is.
Yes, I have one sitting there waiting for me to work on it for a very similar project.
I don't know why the WEMOS type boards don't have a physical switch, jumper or solder bridge to disable the UART. Maybe it isn't that simple.
I read the latest version of the WEMOS D1 mini has a much lower power consumption from the UART when running on the battery module, but it still isn't really low enough.
Craig Fryer I asked WEMOS if they could use any UART other than the 2102 or go back to the original 340 as it was the lowest power consumer for a development board on the market, they told me they would redesign and reissue it. I don't know why they have not made an ESP32 version. Yes a simple switch or jumper would enable the UART and LED to be powered down for low power development work. I use a cheap USB UART to achieve the same though. I learnt the hard way that a USB-UART cannot power a esp8266 and definitely not an ESP32 with the WiFi on, the devices apparently work but crash consistently with flash read errors, also power rail decoupling of 100uF plus a low inductance ceramic 0.1uF are essential for reliable bare bones operations. The ESP32 really needs a dustbin C of about 470uF or more to reduce power demand spikes unless a really low impedance supply is used, two 18650 batteries do-not provide a sufficiently low impedance to drive an ESP32 without a large C in circuit.
Consumption at 3.3 V is not measured in mAh. It is measured in mA. But many thanks for your great work!
Horus777 All my units are correct, I measure current consumption in mA and I then convert to mAhr to compare with a battery capacity specified in mAhr, what’s wrong then?
Hi that was interesting to find that 433Mhz is better than ESP32 so cheaper and better I have two door monitors on 433Mhz that only come on when the door is opened and the batteries are now 3 years old with a range of 150 meters so I think I will stick to 433Mhz
Bob Wareham, yes nothing can beat those 433mhz links, so are so power efficient.
@@G6EJD Thanks David love your channel it is so full of information you are a very clever engineer
If you really want to go low power you will need NRF24L01+ or something similar (obviously you will also need the gateway which will receive this data and make it available on the internet), here is a sample project github.com/aformusatii/RFTransmitterSecondGenerationSensor. I made a sensor like that and is working now for a year the battery voltage is still 3V!! :) I think it will run forever on a CR2025... btw nowadays it is simpler just to buy a Xiaomi Temperature/Humidity sensor and the gateway, I believe in the end it will be even cheaper..
+Andrew Parker Yes, that’s what my conclusion was in the video!