The `delay(1)` triggers the "Automatic Modem Sleep" mode, which keeps the WiFi connection alive. It should draw about 15-16 mA, which is pretty close to the 18-24 mA measured in the TFA.
The WiFi radio consumes a lot of power. During initialization, I believe it can consume 500 mA or more. In normal usage, WiFi apparently has a continuous drain of ~70 mA. If WiFi is not needed, the ESP8266 can be placed into "Forced Deep Sleep" mode, with an idle current of 0.02 mA. Using a ~2000 mAh battery (e.g. 3xAA NiMh, or 1x18650 Li-Ion), that means over 11 years on battery, if no other work is performed. The lowest current that I have measured personally is 0.04 mA on various ESP-01 modules. But that still means about 5.5 years on a single charge.
If the WiFi is needed only intermittently, the ESP8266 can be placed into "Forced Deep Sleep" mode, with the internal RTC configured to wake it up after a certain time, e.g. 15-30 minutes. It can then connect to WiFi, transmit the data payload, then go back to Deep Sleep again. Unfortunately, the ESP-01 module does not support this (without hardware hacking), because it does not expose the GPIO16/D0 pin necessary to trigger the RESET.
Other ESP8266 dev boards (e.g. D1 Mini, NodeMCU) do support waking up from Deep Sleep. But these dev boards often contain a voltage regulator which consumes a quiescent current. On my D1 Mini boards, I get about 0.22 mA in Forced Deep Sleep mode. In theory, that's enough for 1 year of life on a single charge of a 2000 mAh battery. But waking it up every 15 minutes, for 5-6 seconds of WiFi time, reduces the battery life to about 4-5 months. At this point, the active power usage during the 5-6 seconds of WiFi is already 2X the power consumption of the 15 minutes of Deep Sleep, so I have not attempted to reduce the idle consumption any further.
You can actually get the wifi state as low as 2 seconds in very ideal conditions.
Average less than 4 seconds.
If rssi is extremely low then it will def take longer.
Yea the voltage regulator is very important and the ones on the nodemcu have very high quiecient current. Also on the top end you have to look for regulators that can handle the ~500mA peak current too.
People do say that WiFi reconnect can be done in 2 seconds, but I have never been able to achieve that myself on my network, no matter the signal strength. I tried static IP, static subnet, and various configs before going to sleep (to retain WiFi signal strength? I can't remember). I always get 5-6 seconds.
I think I remember measuring the NodeMCU with a higher Deep Sleep current than the D1 Mini, but I don't remember what that value was.
The other thing I forgot to mention that consumes current is the USB-Serial converter on boards like the D1 Mini and NodeMCU, but not present on the ESP-01. I don't know which consumes more, the voltage regulator or the USB-Serial converter.
It also could be if you're still using 8266 vs esp32 or if you're on Arduino vs esp-idf. Arduino esp32 is a wrapper on top of the idf so not sure what added things could be slowing the program? Static ip might be even faster! Also, I have it initialized station mode.
I do recall the d1 mini having a really low quiescent current.
Yea the converters can also take up power I separate that and place it on a jig.
Anyone trying to do wireless with low power should be using other protocols. Zigbee, Bluetooth, Z-Wave, ANT... anything but WiFi. I mean, WiFi just wasn't designed for low-power like these other protocols.
Hell, you might do better with LoRa (long-range, ~3-miles) signals than WiFi.
> Other ESP8266 dev boards (e.g. D1 Mini, NodeMCU) do support waking up from Deep Sleep. But these dev boards often contain a voltage regulator which consumes a quiescent current. On my D1 Mini boards, I get about 0.22 mA in Forced Deep Sleep mode. In theory, that's enough for 1 year of life on a single charge of a 2000 mAh battery. But waking it up every 15 minutes, for 5-6 seconds of WiFi time, reduces the battery life to about 4-5 months. At this point, the active power usage during the 5-6 seconds of WiFi is already 2X the power consumption of the 15 minutes of Deep Sleep, so I have not attempted to reduce the idle consumption any further.
Have you tried going even slower? You can cut your current usage in half by going every 30-minutes, and then in a quarter by connecting every 60-minutes (etc. etc.) until your current consumption is as low as you want.
There are practical limits (is one connection per day sufficient?), but 15 minutes still has some leeway depending on the application.
If you need low-power but still wireless and more updates than that... having a faster-to-initialize and lower power usage to boot (10mA for those 30ms, rather than for 100mA for 2000mS), you'll grossly cut down your power consumptions.
You are not wrong about WiFi. But sometimes worse is better. :-)
With WiFi, I don't need any other technology stack, no hubs, no bridges. I can use my existing network infrastructure. The data packets from the ESP8266 devices get delivered directly to the MQTT broker over TCP/IP over WiFi. It's cheap (~$3 for a D1 Mini), dead simple, and good enough.
Every 15 minutes seems about right for temperature/humidity sensors. Increasing it beyond 15-30 minutes becomes a diminishing return, because at that point, the Deep Sleep power usage becomes greater than active WiFi usage.
Yeah, obviously getting the project done is highest priority. So if it works, and you're at .5 mA average, its good enough.
Still though, WiFi's specs are pretty awful. It bothers me to see such huge numbers whenever people talk about WiFi. And since we're in tiny microcontroller land, its not like any of us are actually tranferring GBs or MBs of data. We're all just passing a few kB, so much slower protocols (ex: Zigbee) are very reasonable.
Things start to get silly below the 500uA levels anyway. You start worrying about aluminum capacitors with 22uA leakage current and such... and realizing you need to upgrade to Tantalum capacitors with specified 2uA or 1uA leakage.
The Arduino IDE is very limiting. It hides a lot of these important implementation details in an attempt to keep things simple and easy to switch between Arduino-like devices (which is fine for users who aren't doing complex stuff or want all the features out of their particular chip or care much about optimization). I would instead recommend to use Espressif's SDK directly (https://docs.espressif.com/projects/esp8266-rtos-sdk/en/late...) so they have access to all the API the SDK offers.
If I remember correctly, ESP chips are not really power efficient comparing with other alternatives. And if you want to save power without sacrificing performance, you should do things like sleep and wait for interrupt.
not sure about wifi, but for BLE I think people generally use nRF controllers, there are modules with builtin antenna that you can use directly and are not too expensive.
A current-controlled power supply will often tell you the current-usage. Obviously, it depends on your power supply, but even a $50 one these days has this feature.
If you're off of battery power or USB power instead, you'll need to build a current-sense circuit. Analog wise, its very simple: a small 0.01 ohm resistor (called a "current sense resistor") is placed in series, and you measure the voltage drop across it. 0.0001 V across a 0.01 ohm resistor -> V / R -> 0.0001 / 0.01 == .01 Amps == 10 mA being drawn.
Now the question is "how do I measure 0.0001V accurately" ?? And that's a trivial op-amp problem. So trivial, that people sell cheap chips that already do this for you, called current-sensing amplifiers. They just multiply the voltage by 200 accurately. (so 0.0001V into the amplifier comes out as 0.02V), and 0.02V can be measured by pretty much anything.
Voltage-multipliers though are a trivially easy OpAmp circuit, and I'd recommend that beginners actually try to build their own current-sense amplifiers from scratch. Its good to learn how to use OpAmps, and learn all the issues (ex: Rail to Rail, positive / negative voltages, etc. etc.). I'd recommend you do a 9V project with the LM358.
An integrator should be in the circuit "somewhere", but there's a lot of creativity available where I left off.
Staying in the analog world alone, you can output the voltage into a 555 Timer, and then have it flash an LED every time the capacitor filled up (and the discharge would also dump the capacitor). For example.
Or you could just wire it up to a microcontroller and busy-loop ADC-convert the input. So you can perform the "integral / summation" in microcontroller / in C-code rather than circuit magic.
The important tidbit is that we've turned 10mA current into a value we can "touch" and use. Hell, maybe the easiest solution is to just hook up a wire somewhere and shove an oscilloscope there to finish things off, depending on how lazy you wanna get.
-------
I know one professional chip did Opamp Integral -> Comparator (if integral is full, dump the charge to ground. If +V, do register++. If integral was full of negative voltage, do register--).
Then, whenever the register overflowed, it'd generate an interrupt edge on its output (for both overflow or underflow). Alas, I forgot which chip did this. But this way, you could build all your stuff out of 100kOhm resistors, 10nF capacitors, tiny digital logic circuits with micro-amps of power usage that wakes up your microcontroller out of sleep for just a "Current_Reading++" statement on overflow and you go back to sleep. (or current_reading-- on underflow)
But that's all advanced stuff that probably doesn't matter for a student making their first practical OpAmp circuit :-)
That is the way. Once you get into actual measurement there is plenty of hard problems, like your device might only wake up for 10ms, take few hundred mAs of current and go to sleep.
You can place a small resistor in series with the supply, and measure the voltage drop over it. From this and using Ohm's law you can calculate the current. Then the power is trivial.
There are special resistors for this purpose that are very low in resistance.
The data acquisition is kinda a bitch if you want to measure accurately over long time, small IoT device can take microamps when idle and tens of even hundred+ mA when transmitting and that's 4-5 orders of magnitude of dynamic range and that's kinda hard to deal with accuracy
https://www.joulescope.com/ handles most of that edgecases but it's a pricy piece of kit if you just want to do some measurements and are not using it to make actual product.
I wonder if you could rely on a capacitor charging over time, that you discharge every time you poll? That way you delegate the real-time "counting" to the capacitor and can read it at approximate times (as long as it's frequent enough to avoid fully charging the capacitor since it can't count beyond that)?
Pretty much. Just need to be very stable source and a lot of generic engineering around to not incur error.
Hell, that's actually very easy way to make ADC, just start counting, charge cap to pre-determined value then trigger counter stop. There are few improvements to that technique (like dual slope ADC, where you use reference voltage to discharge the cap to get the ratio between reference and input signal) but in general it can be very accurate way to measure.
I am not sure what your search for "simplest circuit" is as there are many defintions I would need to know first, e.g AC vs DC, power level, etc. to narrow it down.
Like others mentioned it is a about measuring voltage*current.
I dunno if you want to use a simple circuit; but, you can use a voltmeter in series ampmeter mode. However, I just use one of these: https://www.amazon.com/gp/product/B00FPU6G4E which has the advantage of being able to tune the voltage and current to be either constant current or voltage.
We charge a capacitor up and time its discharge to a certain level while running the circuit.
Then we repeat it using resistors instead, until we match the discharge rate exactly.
Then measure the resistor and do I=V/R, using the midpoint V. That accounts for all the surges and eliminates most error sources, giving you a nice and extremely realistic average current draw.
measure the current, e.g. an ampmeter in series; voltage in parellel. W=V.I
Most of the time you care about the current only. Now if you actually want power over time, that is energy. in that case you would need some logging, and sampling
The sampling is the problem here. If you sample at say 1s and the chip is using say 100mA for 50ms to send some data, you might completely miss it, you might overcount that pulse
well yeah, of course, if you care about transients, you may switch to an oscilloscope.
Alternatively have a multiplemeter that records min/max, and/or has a rs-232 interface.
However with enough sampling, even 1Hz frequency should be sufficient.
Oscilloscopes also have a dead-time. If you want to judge the power usage accurately you pretty much have to go to dedicated stuff like https://www.joulescope.com/ althought you might get close enough with using some tricks. Or the ye olde analogue way of integrating the current usage via
Like, if you know your device is on 50ms and off 10 seconds you can just record both states power usage and calculate based on ratio, most scopes memory is probably enough for 50ms with enough resolution and idle power usage will most likely be the same over the period.
> Alternatively have a multiplemeter that records min/max, and/or has a rs-232 interface.
Min/max ain't going to do you much, some WIFI-enabled devices can spike to like 500mA for few us so even if it captures it the max doesn't tell you much.
>Unfortunately Arduino "experts" have this bad habit of spending a lot of time to do things wrong, then proudly and authoritatively dictating their esoteric hacks and myths to impressionable newbies.
Counterpoint: I think it's cool and fun that there's still a tech community which thrives on goofy hacks which aren't "correct". If you're programming an ESP8266 with the Arduino SDK, you're probably not working on mission critical stuff anyway, and this kind of thing represents a hacky spirit which I think is otherwise largely missing in this era of computing.
I agree completely, but I recently discovered that this stuff has a tendency to leak beyond where it belongs.
Arduini are fine for prototyping, learning, and hacking, but I would avoid the software ecosystem for commercial products. Unfortunately, those raised on these boards do not see the peril of its hackery, and they will incorporate it into products. That’s where things start to go off the rails.
I am currently working on a bringing up a board that replaces one that included an entire 40-pin DIP board. That Arduini-based solution is difficult to maintain and fragile.
These are fine for hobbyists and experimenters, but please use a better tool chain if you need to do real work.
I find it useful for the ESP to import the Arduino libraries as a component in the espressif toolchain. Saves a lot of time when I can just use the Arduino code for the stuff i'm too lazy for (ie handling ethernet) without compromising functionality.
ESP8266 and ESP32 both have deep sleep. CAn't remember the ESP8266's details but the ESP32 even has an auxiliary processor that can run during deep sleep and do trivial ALU/memory work to collect data or wake up the device. My friend made a temp sensor that runs on battery with an ESP32 and it runs > 1 year without a new battery.
Yes, and sleep(), delay(), yield() in Arduino Core for ESP* are task switch to and from Wi-Fi handling code, not busy-loop delays. Espressif seems to have put a lot of scaffolding for you behind the Upload button.
What if OP is just a hobbyist who only knows Arduino and doesn't want to learn a whole new SDK just to toy around with microcontrollers in their spare time? I respect posts like this. They are fun and cool.
If you must use ESP8266 for some reason, then completely agreed. ESP8266 is obsolete now though, there are far more capable ESP32 variants, some of them specifically designed and marketed to replace the 8266 and to make transition as easily as possible. Not to mention the benefits of a now quite mature ESP-IDF SDK.
Arduino is a great onramp to embedded, but it really needs an offramp.
I for one still have plenty of esp8266 based nodemcu/wemos around the house, they still do just fine for most hobbyist purposes and the RTOS SDK is just as pleasant to use as ESP-IDF. Most of the API is the same and they have example code for almost everything.
I also have several smart plugs from different vendors, smart bulbs, one thermostat, a camera, all still using esp8266 and doing just fine.
That's a very ignorant statement; they are still in production and entirely enough for many use cases, just like original arduinos are.
They are also like $2 a pop for whole breakout board and less if you make actual device.
I do agree if you just want to tinker the tiny extra for ESP32 is probably worth just for tinkerer but there is still a plenty of devices (in IOT space mostly) that are just "ESP8266 + some peripherals" and thus nice and hackable
"Original" Arduino on the ATMega8 is fully obsolete and should be moved off of. Fortunately, it wasn't that popular.
"Arduino Uno" (which popularized the Maker movement in 2010) with ATMega328 is also obsolete. You should use ATMega328pb at a minimum (but even then, the 328pb is nearly a decade old now...), or really the AVR DD chips that are cheaper, faster, simpler, more powerful. Ex: AVR64DD32
To explain how absurd it is... the AVR64DD32 uses 4.7mA at 24MHz fully active.
In contrast, the old ATmega328 uses 12mA at 20MHz (its limit), and 3.5mA while idle (aka: 1st level of sleep).
So an idle (1st sleep) ATmega328 uses basically the same power at a fully active AVR64DD32. Indeed, AVR64DD32 only uses 500uA (microAmps) at 4MHz fully active, so it can "busy loop" with less power than a sleeping ATmega328.
AVR64DD32 costs $1.67 at lot size 1 from Digikey. ATmega328 costs $2.73 for lot size 1 from Digikey.
ATmega328 comes with 32kB of Flash and 2kB of RAM. AVR64DD32 comes with 64kB of Flash and 8kB of RAM. It completely dominates the older chip in every possible regards.
------
Original Arduino Uno is still a great learning tool. But there have been over 10+ years of improvements to these chips. Anyone actually dipping down into AVR programming should prefer the newest chips.
IMO, Arduino Uno should be seen as a learning tool. Fortunately, all of the stuff (ex: Assembly language, sleep modes, etc. etc.) still apply to the AVR64DD32. The peripherals have changed though... USART rather than UART. DAC included, OpAmps in AVR64DB32, etc. etc. Integrated dual-power supply on AVR DD chips (PortC can be on a 2nd voltage level, so its basically an integrated level-shifter). Full 24MHz speed at 1.8V (ATMega328 has this annoying "derating" curve, where 1.8V can only handle 4MHz).
But no one should be using ATmega328 in new "serious" designs. Its just "still" useful because all of those old tutorials from 10 years ago still work today. So it has the most tutorials written for it, and should remain "steady" as a learning platform.
But anyone taking the next step (learning the actual chip, learning how to solder, learning how to breadboard), needs to switch to the newest chips. The newest stuff is just cheaper, faster, and easier in practice. And still _mostly_ compatible with the old ATMega328 (same assembly language. A superset of the features. Similar concepts in layout / design, etc. etc)
I wasn't being clear enough, I meant "over just picking some ARM part".
Is there any actual benefit over just going for some Cortex M0 aside from "run old stuff on it" ?
I started my adventure with AVRs and avr-gcc, played a bit with arduino but nowadays there doesn't seem to be a good reason to pick them, M0s and M3s are cheap and plentiful and usually better specced for the price
The old ATMega328 is obsolete. That's my point. There's a ton of chips that are better than ATMega328.
But if we're talking about _MODERN_ chips, like AVR64DD32, the modern successor to ATMega328, with AVR assembly language, GCC support and all that jazz...
EDIT: AVR64DD32 is basically a "modern ATMega" btw. Its not an ARM, its an AVR processor. Is this the point of confusion?
* Running directly off of 5V USB power without any voltage regulators is a neat trick. No ARM Cortex M0+ part I'm aware of goes above 3.6V (they're designed for Li-ion cells). Dropping down to 1.8V is also a neat trick, the AVRs have a very wide practical range of voltages.
* Dual power supply. PortC of AVR64DD32 runs off a 2nd power supply. So the AVR64DD32 can run off of 5V USB power, and with an external LDO regulator can have PortC running 3.3V. (Aka: integrated level shifter). You know, for all of that annoying 3V crap that you need to integrate with 5V other crap.
* The big-brother, AVR64DB32 (the DD turns into DB. Confusing, yes, I know), has 3x OpAmps. Meaning you don't even need a power supply anymore. You can power PortC / secondary I/O lines from the integrated OpAmps on the AVR-DB.
If you upgrade to the bigger AVR DB in the series to $2.00 to $3.50... you get 3x rail-to-rail OpAmps with integrated resistor ladders and suddenly you're in a very flexible mixed-signal world.
I think STM32G4 chips have integrated OpAmps. But these are $7+ chips and a ARM Cortex-M4 (much more expensive / complex / bigger than the M0).
> M0s and M3s are cheap and plentiful and usually better specced for the price
Which one? AVR64DD32 is 64kB of Flash and 8kB of SRAM for $1.60.
Cheapest STM32L0 I can find is $1.82 and only has 2kB of SRAM. And it doesn't go to 5V, doesn't have integrated level shifters, op-amps, or any of the other neat tricks... (And STM32L0 is a _very_ competitive Cortex-M0+ line in my experience).
Like, we all want to just code our way out of problems. But sometimes, you have a 3V thing that you need to connect to a 5V thing. And AVR DD is the perfect tool for that.
------
EDIT: Ah right. And ATMega328 can still sink 20mA to fully turn on an LED without any MOSFETs / external amplifiers. I think PIC is the only other major line of chips that has this feature. AVR-line is legendary for its current source / current sink strength.
I guess I'm showing my "hobbyist" bias, because I was looking at Digikey-pricing quantity 1, not bulk prices, with my discussion earlier. So that's still in the general price range (XMC1 is similar to STM32L0). Not that the price point matters too much, but just trying to keep things apples-to-apples here.
But the 1.8 to 5.5V support and 50mA is _definitely_ impressive. Its not very common in my experience to see such a wide voltage range on an ARM chip (though it is somewhat common in PIC / AVR / 8051 8-bit uCs).
I'd still say that AVR DB has the advantage though, because 3x OpAmps can do so so much. The marketing page for that XMC1 shows off a SMPS DC-DC voltage converter for example with the XMC1 50ns comparator. Certainly nifty but...
I'll one up that with a true-and-proper DAC and a rail-to-rail OpAmp controlled by the AVR DB series. (The cheaper AVR DD also has a DAC, but is missing the OpAmp). There's just things you can do with a 5MHz OpAmp / analog control that you can't do as well with digital logic. I'm willing to bet that the current control / response time off of the 5MHz OpAmp from the AVR DB will beat the pants off of any digital logic the XMC1 tries to do.
And while 50mA is huge, the most I've seen in this class of chips... the AVR DB OpAmp is specified for ~30mA current source / sink. So while its smaller than the 50mA pins of the XMC1, its still rather strong.
------
> The upshot there would be high commonality with XMC4 (Cortex-M4F), and general commonality with other Arm platforms.
Yeah, that's definitely the biggest advantage to ARM in general. It scales really high.
8-bit MCUs scale lower though... down to 32B, bytes (not kB) of RAM... and other such designs. This ~$1 to $3 price point is really a battle between "the biggest 8-bits" (PIC/AVR/8051) and "the smallest 32-bits aka ARM" (with TI being weird with a 16-bit MSP430 sitting comfortable)
If you're thinking of "scaling down" to sub $1 (or more importantly: lower power designs), 8-bit wins. If you're thinking of "scaling up" to $10 (or higher-power, more CPU-intensive designs), 32-bit wins.
--------
EDIT: Honestly, the coolest thing about this XMC1 seems to be the LED controls at the XMC1202 chip, closer to the $3 price point. The XMC1100 are a bit feeble / low end and weaker than the 8-bits I'm familiar with at its ~$2ish price point.
9-channels of LED with 12-bit exponential voltage controls means you can probably offer a full 32-bit color off of those RGB LEDs. And with 50mA per pin, you can probably just drive those LEDs without any resistors.
EDIT: Ah, looks like 50mA pins are the "high current" pins. Only 6 high current pins on the XMC1100. The other I/O pins are 10mA. So resistors are still needed, but that's still a lot of nifty control for those LEDs.
That reminds me of https://jaycarlson.net/microcontrollers/ "$1 microcontrollers" with all of the weird and wonderful variations. Probably not actually $1 after the chipaeddon tho.
Yeah, its those stories hitting the top of Hacker News that got me looking at modern uCs again, and thinking of a hobby-project to do with 2022-era tools.
That page is still a bit out-of-date now. 2022-era uCs have taken a sizable step forward compared to 2018-era... though inflation / chipaeddon has made everything more expensive.
But peripherals, power-usage, Flash/SRAM, etc. etc. are all getting better across the board. Its just one of those 'tredmills', you can never really be an expert on the market, cause the market of chips keeps changing so quickly.
Oh, chipaggedon... I was few weeks off trying the assembly service (think it was on seeed studio?) of small dev board, and then I realized near nothing I had on it was still in stock. Even managed to run Rust on the previous breadboard iteration of the project.
Year and half later I got all the parts finally delivered...
> But peripherals, power-usage, Flash/SRAM, etc. etc. are all getting better across the board. Its just one of those 'tredmills', you can never really be an expert on the market, cause the market of chips keeps changing so quickly.
Sure but you can stay on same chip family for 10+ years and just grab new part when you need features. Especially on hobbyist level there isn't that much reason to chase the latest and greated
I work with artists who build great teetering cathedrals on top of Arduino(and Processing), and it's really difficult to incrementally move to a more serious solution once things have reached a certain level
Specifically the things it does that bake in bad habits are:
- Encouraging globals
- Everything in one namespace
- Arduino is not C++
- not needing pre-definitions(mostly) and spamming all .pdes into the same file leads to tangled code that's really hard to pull apart into modules, even if it's separated in tabs in the Arduino editor
- delay: not composable!
- for esp specifically:
Thinking in terms of a single loop function Vs multiple rtos threads
- the ide is terrible, and encourages a copy-paste workflow because that's how best to work within it
Use Platform IO (I use it inside Visual Studio Code). It's C++. You don't have to use globals. .pde is processing, it's not required to use that (I write python scripts that talk over serial instead). ESP32 in Arduino supports multiple threads (cores).
> Arduino is a great onramp to embedded, but it really needs an offramp.
Does it?
PIC-BASIC was the great onramp like 20 years ago. It never got an offramp. Arduino just did it better / simpler, and all the hobbyists switched to that.
Nodemcu's lua is a reasonable option too. In terms of offramps, platform.io can get you moving towards the doors anyway. I haven't used it with esp8266, but on ESP32, you can switch between arduino and esp-idf; of course, if you use arduino components in your build, you still need them; you can use arduino as a component in esp-idf. It's a little fiddly, but I could see replacing components bit by bit until you run out of Arduino.
The `delay(1)` triggers the "Automatic Modem Sleep" mode, which keeps the WiFi connection alive. It should draw about 15-16 mA, which is pretty close to the 18-24 mA measured in the TFA.
The WiFi radio consumes a lot of power. During initialization, I believe it can consume 500 mA or more. In normal usage, WiFi apparently has a continuous drain of ~70 mA. If WiFi is not needed, the ESP8266 can be placed into "Forced Deep Sleep" mode, with an idle current of 0.02 mA. Using a ~2000 mAh battery (e.g. 3xAA NiMh, or 1x18650 Li-Ion), that means over 11 years on battery, if no other work is performed. The lowest current that I have measured personally is 0.04 mA on various ESP-01 modules. But that still means about 5.5 years on a single charge.
If the WiFi is needed only intermittently, the ESP8266 can be placed into "Forced Deep Sleep" mode, with the internal RTC configured to wake it up after a certain time, e.g. 15-30 minutes. It can then connect to WiFi, transmit the data payload, then go back to Deep Sleep again. Unfortunately, the ESP-01 module does not support this (without hardware hacking), because it does not expose the GPIO16/D0 pin necessary to trigger the RESET.
Other ESP8266 dev boards (e.g. D1 Mini, NodeMCU) do support waking up from Deep Sleep. But these dev boards often contain a voltage regulator which consumes a quiescent current. On my D1 Mini boards, I get about 0.22 mA in Forced Deep Sleep mode. In theory, that's enough for 1 year of life on a single charge of a 2000 mAh battery. But waking it up every 15 minutes, for 5-6 seconds of WiFi time, reduces the battery life to about 4-5 months. At this point, the active power usage during the 5-6 seconds of WiFi is already 2X the power consumption of the 15 minutes of Deep Sleep, so I have not attempted to reduce the idle consumption any further.