Go Down

Topic: Suggestion for an external interrupt timer generator? (Read 482 times) previous topic - next topic


That 100 mA is peak currents when transmitting. Not constant current, not even when transmitting. Constant current is more like 10-20 mA.

That internal RTC can't it be calibrated? Or is that error all over the board? The processor's 80 MHz oscillator is supposedly pretty precise, about as good as a basic crystal.

WiFi credentials are normally stored in the ESP's on-board flash memory for faster reconnects. That's still there even after weeks of disconnection from power.
Quality of answers is related to the quality of questions. Good questions will get good answers. Useless answers are a sign of a poor question.


About current drain:
I have hooked up my DVM in series with the 7V feed to the prototype breadboard. It is feeding a DC/DC-converter block that creates the 3.3V output with a high efficiency. Under no load the converter pulls 1.6 mA.
Now, when I start up the prototype it pulls 68 mA for a few seconds (2-3 s), then idles down at 43 mA. WiFi is on and at the start it also measures sends the first measurement data set out.
Now, since efficiency is about 90% and the conversion voltage factor is 3.3/7=0.47 it means that the currents on the 3.3V output should be 144 mA and 91 mA respectively.
I plan on replacing the switched converter with a low dropout and low quiescent current linear regulator feeding from the 3xAA battery (nominal 4.5V) in the battery powered version.

About timing:
The sketch as it sits now runs a measurement upon startup then moves on into loop() where the next measurement will trigger later depending on the reading interval stored in config data in EEPROM. Typically that is once every hour.
In a deep sleep scenario there will be no loop running because at the end of setup() the deepsleep() is called. So the initial reading(s) is all that is going to be done before deep sleep. The time until that happens depends on the speed at which the ESP-07 will connect to the WiFi network on startup, and this varies a lot I have seen. Additional to this is the time to switch on power to the sensors and wait for them to stabilize, here I have a randomly selected 2 s delay. So the total time until the deep sleep will happen might be a bit less than 10s, possibly even shorter than 5s. But I took 10 s as a pessimistic example.

Deep sleep precision and oscillator
The 80 MHz oscillator is switched off in deep sleep! So it is not available. It is what I use when running without deepsleep and it is amazingly accurate. That is why I was so surprised to see the big error in sleep time from the nominal setting!
Probably it is some really not very accurate RC oscillator used for the deepsleep timing...

WiFi settings
I store the complete design configuration in a 256 byte struct stored in EEPROM, which is read on startup in setup(). The reading of that takes milliseconds only and the WiFi settings are configured in setup() based on the config settings struct values. This works just fine.


I just bought a number of MCP1702-3302E 3.3V LDO and low bias current linear regulators and replaced the switched regulator I used before with one of these. I also removed the 5V regulator I used before for feeding the sensors. Instead I connected that feed via the switching transistor directly to the input power line. I set the input voltage to 4.7V thus simulating a 3xAA battery pack.
The resulting current drain is:
1) 86 mA at startup for a couple of seconds (connecting WiFi and doing one measurement cycle)
2) 75 mA after the initial activity has ended
3) 0.53 mA when set to deep sleep

My problem is the deepsleep drain, because it will cause about 4600 mAh over a year just for the deep sleep idling current. The webpages about low current operation for the ESP8266 all talk about an order of magnitude less current in deepsleep. Somewhere in the region of 50-80 uA.
With this drain there will not be energy enough for the measure cycles...

In fact the AI-Thinker documentation about the ESP-07 module states that the deep-sleep power usage is typ 20uA...
But that is not what I see, I have tried to eliminate all current leaks of the proto board but cannot get below 530 uA!

This is the current drain AFTER I have physically removed the power LED from the ESP-07 module. This was lighted up even when the module was in deep sleep.


Feel free to post code & complete circuit diagram and we can have a look.
Quality of answers is related to the quality of questions. Good questions will get good answers. Useless answers are a sign of a poor question.


I know little about the ESP8266. They claim 20uA current consumption while in deep sleep. While doing power needed estimates you can use 1uA continuously ~ 10mAh per year. It means the ESP needs about 200mAh per year while sleeping if properly configured for minimal consumption.
You did not say what your sensors are but most of sensors need only small amount of current (a few mA). Also the ESP may be in deep sleep while waiting for the sensors to "stabilize" - possibly huge power savings. Anyway I think your power consumption estimates are very overestimated - provided you do it the right way.

If I were to do this project I would use a standalone ATMega328p (MCU for Arduino Uno) - or possibly ATMega88pa for cheaper chip (the -p suffix is quite important). Using internal RC oscillator as main clock and a Timer2 in asynchronous mode with external 32kHz crystal you can get quite accurate timing with current consumption <1uA in power-save mode. The ATMega may also do all the sensor reading work - likely with less power demand than the ESP. It would only wake up the ESP when power connection is needed, provide the measured data to be send and possibly get NTP time to correct crystal drift. In this scenario ESP may be powered off (<0.5 uA). Since ATMega tolerate wide voltage range you may probably power off the regulator saving its quiescent current. I guess this way the total average power consumption may be something like 10 or 20 uA, meaning the battery life several years.


Feel free to post code & complete circuit diagram and we can have a look.
Code to start a 10 s deep sleep for testing:

Code: [Select]
                case '5':   //Initiate a deep-sleep cycle of 10 s
                    uint64_t sleeptime;
                    sleeptime = 1e7;
                    if ((cmd[1]) > 0)
                        sleeptime = (uint64_t)(cmd[1] - '0') * 6e7;
                        if (sleeptime == 0) sleeptime = 1e7;
                        SerialDebug.print("Starting deepsleep() with T=");
                        SerialDebug.println((unsigned long int)sleeptime);


1) There are no connections to the SerialIO, Flash and TxDebug connectors.
2) The voltage +5Va is really a switched version of the battery supply at +4.5V
3) The voltage limiting zener diodes D2..D5 are not connected on the prototype.
4) Q1 switches on the sensor supply only during actual measurements


UPDATE:  :smiley-red: :P
I have now traced down the connections of my breadboard and found two pullup resistors for the DHT sensors that were not connected to +5Va (which is really the battery voltage input through the switch transistor Q1).
Instead these were connected close to the ESP-07 as pull-ups to the 3.3V supply!!!

When I rerouted these to be connected to the switched sensor supply the current drain in deep-sleep dropped to 19 uA!
To protect the ESP during sensor power off the sensor signal line is set to active low output state so no over-voltage could damage the ESP. But then the pull-ups must be connected to the switched sensor supply of course!

So the ESP-07 datasheet seems to be all right except for the module's power LED which has to be removed from the module since it is directly connected to 3.3V and ground.

Now since the breadboard is verifying the expected power drain I can go back to figuring out how to run this with some timing accuracy when deployed. In order to "calibrate" the deep-sleep interval I would need to store a few values across a deep sleep:
1) The deep-sleep argument value itself (which needs to be calibrated)
2) The NTP time at which the last sleep was started
3) The requested sleep duration
This could be stored in EEPROM.

Then it should be possible to time sync with NTP on startup and then calculate backwards (using millis()) at what NTP time the device last started up and therefore how long it slept using the time of last sleep command.
Given this the system could be self calibrating by modifying a scaling factor value used when setting up for the next deep sleep.

Go Up