I am working on a logger project using an ESP-07, which needs to be battery operated for long times in an inaccessible place. The plan was to use the ESP-07 built-in deepsleep function in order to run a measure cycle every few hours up to every 24 hours.
But it turns out that the built-in deepsleep timer is grossly inaccurate so it cannot be used. And it cannot be set to sleep for 24 hours to boot.
So I am looking for an external interrupt timer that can be programmed from the ESP-07 using a 1-wire interface and is accurate to a few seconds per day (and running off 3.3V of course).
Is there such a part available somewhere?
If there is an Arduino library for the device it would also help a lot of course...
Indeed, an RTC alarm will do this. Most run fine on 3.3V and have their own 3V battery backup which can last for years. With calibration you should get it down to the seconds a year.
How "grossly inaccurate" is the deep sleep timer? The built-in RTC should be quite good. And if not settable for 24 hrs - just have it check the time and if it's not time to do the measurement just set the alarm and go to sleep again. That's done within at most a few ms so no significant power lost.
I have not looked into using an ESP8286. I use several ES32's which have 3 cores. The two main cores and the core called RTC, that has its own RAM and programming. The RTC core, I'll call it RTC core to avoid confusion with a Real Time Clock, uses Assembler and communicates well with the GPIO pins. There are quite a number of RTC core assembler programs available, on the I-net, where the ESP32 is ran in a deep sleep mode and the RTC core checks on the GPIO pins.
Using the RTC core, the assembler is loaded into regular flash, something to take into consideration, and then the RTC core program is loaded from flash into the RTC core program space. The RTC core can be used when not in deep sleep mode for GPIO monitoring.
wvmarle:
How "grossly inaccurate" is the deep sleep timer? The built-in RTC should be quite good
My timing for deepsleep at 1-2-3-4-5 minutes show that it is about 10% slow...
Web discussions show 3-5% error. So it is pretty bad.
And if not settable for 24 hrs - just have it check the time and if it's not time to do the measurement just set the alarm and go to sleep again. That's done within at most a few ms so no significant power lost.
Well, that means firing up the WiFi and connecting to an NTP time source and then if the time is not up what?
In deepsleep the RTC is not available AFAICT, and switching to a less deep sleep will make current drain on the battery too big.
Another deepsleep may well pass over the target time by a great deal? While the chip draws very small current while sleeping it uses about 100 mA with WiFi operational so I would rather wake up, take a reading and go to deepsleep.....
MarkT:
So don't power up WiFi before you are ready to communicate...
But without WiFi I cannot connect to an NTP server and establish the current time....
Note that I don't have any RTC on the board, just the ESP-07 and support components.
Two sensors are planned to be wired in to two GPIO ports and that is all there is...
I do have a system like this running in my attic with 4 sensors, but it is connected to mains power. It runs continuously and does measurements on times determined by reading millis(), which is a very accurate clock for the purpose of measuring every hour. Works within 1-2 seconds after weeks of operation.
The new system is intended for a location where there is no mains available so batteries must be used and the deepsleep function too in order to reduce battery drain.
What is your power budget?
Your requirements are quite strict - single pin for both communication AND wake up?
Also how precise the timing must be? I don't know how precise the internal oscillator is but maybe it may be calibrated? Or maybe once per 24 hours is more important than precise time of day? If you wake up too early one day you may sleep longer the next day to compensate?
I was thinking of using 3 AA alkaline batteries. By googling I found that the capacity of these are between 2000 and 2500 mAh.
If the device is powered on for 10s every measurement it means in a year it runs a total of 1024365/3600 = 24 h at full drain. If current is 100 mA (=2400 mAh) the batteries have no reserve for the deep sleep drain...
So by reducing the target operating time to 270 days on batteries the consumption becomes 1024270/3600*100 = 1800 mAh. And given the capacity of 2500 mAh the deepsleep drain then can use 700 mAh during the full 270 days giving a max current drain of:
Imax = 700/270/24 = 108 uA <= So this is the target for the deep-sleep consumption.
Your requirements are quite strict - single pin for both communication AND wake up?
Also how precise the timing must be? I don't know how precise the internal oscillator is but maybe it may be calibrated? Or maybe once per 24 hours is more important than precise time of day? If you wake up too early one day you may sleep longer the next day to compensate?
I don't know what you mean by the communications here. The ESP-07 will communicate when it runs through the WiFi and Internet. It also uses one GPIO pin to communicate to each sensor. THere are more than this available on the device.
As I tried to explain the internal crystal oscillator is quite precise, but it is switched off during deep-sleep and instead some other oscillator is used to count down the time until wake-up. This oscillator has very low accuracy.
The way deep sleep works on an ESP-07 is that GPIO16 is wired to the Reset pin of the device. Then when the device is set into deepsleep and it times out a reset pulse is generated on GPIO16 that fully resets the ESP-07.
This means the there is no data available between the sessions, everything is erased, so the system must establish its time reference from outside sources if it needs an accurate time. I.e. a call to a time server is required via WiFi.
I don't need this but I do need the device to measure at 1 hour intervals and since it is unattended I want this to be fairly accurate since it will be "dead reckoning" from start to start.
Smajdalf:
OP wants 1-wire interface. Including the wake up line if I understand it correctly. Not impossible but not trivial either AFAIK.
Well that was just a suggestion to avoid having an SPI with 3 wires. Each wire will need one GPIO and there are not so many of them.
Anyway I might have to accept a way to handle this where I make do with a not so accurate sampling time...
I thought that there was an IC which could be programmed easily (via a 1-wire interface) and was accurate enough for this but it seems like I am out of luck. I thought about one of these very small 5-pin packages that consume next to no current and basically contain a programmable down counter and an oscillator...
I don't know how costly is connecting to the NTP server. Consider the internal RTC is accurate to +/-4%. After last measurement you go to sleep for 23 hours. After wake up you have error about +/-1 hour. You connect to NTP and discover, it was only 22 hours (=worst case). It means you need to wait additional 120 minutes. You go to sleep for 115 minutes (with +/- 5 minutes error), wake up and connect to NTP to get real time. Worst case is 10 minutes left. If you go to sleep for 10 minutes you will wake up in 24 hours +/- 24 seconds from last measurement. It is not a bad result considering it is worst case. All it needs is two checks of the NTP server. Surely it takes some power but you don't need any extra hardware.
EDIT: I think there is some memory in the RTC part of the ESP that is not erased during wake up from sleep which may be used for saving data to connect to WiFi much faster.
EDIT II: Do you want wake up every hour or every 24 hours? What takes 10s to measure? It is loooong time. If you are doing measuring only you can keep WiFi turned off and consumption should be much less - about 15mA?
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.
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.
UPDATE:
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:
86 mA at startup for a couple of seconds (connecting WiFi and doing one measurement cycle)
75 mA after the initial activity has ended
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!
Note:
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.
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.