The latter redirects to a page that shows Git commits, but it's a hidden page in a Dutch site about online casinos. It does look a bit shady. In the GitHub org of jeelabs, there are only two authors and neither seem to be based in the Netherlands.
Here's an archived website that documents the jeelib library.
An apparently very common CloudFront misconfiguration that has spawned a thousand articles and StackExchange Q&As on how to fix it. Randomly chosen one:
This functionality is commonly built in to the microcontroller itself. MSP430s, STM32s ATMegas, and many others have real time clock and gpio wakeup functionality, which effectively lets you power off almost the entire die until either a time period passes or a gpio changes state. Commonly you can do similar for more complex peripherals as well, eg power off the core until you receive a UART message, but typically this is not a full power down like RTC sleep as it requires some peripheral clocks to stay running.
Indeed it is present across the board but performance wise, the most extreme example I've seen of low current, deep sleep, is the EFM32 family from Silicon Labs.
That's the kind of performance that makes you question the accuracy of your test equipment.
Yes, they're called low-power (or nano-power) system timers. Some also incorporate watchdog timer functionality. These chips turn on power to the main CPU based on some given interval. TI has a few that consume ~30nA (@2.5V), like the TPL5100.
This is when the MCU itself you're using doesn't have this functionality of if it's still consuming too much power. MCUs like the ATMega368(PU) consume ~100nA in their deepest sleep states, so it can be a rather drastic reduction in some cases.
On one of the projects I worked on, I brought a PIC16 down to ~20nA - where our fancy meter only went down to 10nA precision. It was completely unnecessary, but I'm still quite proud of it.
For more standard cases, the 43uA from the article is roughly the same order of magnitude you'll get from pretty much any micro in sleep mode, after doing your first pass low power optimisation. The stuff I normally work with gets about 10. The thing is just, most of the time, that's low enough already - for this project 2500mAh/43uA = 6 years of sleeping. The bigger factor is the current it consumes while awake - and that's where the Arduino's a bit of a letdown, the stuff I normally use is only in the order of 100uA while awake.
The ATmega328 (i.e. arduino without the garbage) is that microprocessor.
It can sleep and only use ~66 microamps at 5V with the watchdog timer enabled. That's 330 microwatts. A 1000 mA lithium cell (3.6 watt-hours) could then run it for ~10909 hours, or 454 days (~1 1/3 years).
Almost every microprocessor made these days has some sort of low-power sleep. The ATmega series aren't even particularly good at being low-power.
Of course, you then realize the "arduino" is really just a badly designed development board for an atmega, and they went and used cheap voltage regulators that have an idle current consumption of > 1 mA, and give up on the whole project.
Arduino a poorly designed board is up there with the iPod being lame. Arduino was designed to be accessible and lower entry barriers and it became unrivaled for these purposes. If you want to have long lasting battery powered project you just power directly with 3.3v.
TI's MSP430 is well suited for low-power applications (sleep current less than one µA) and has a number of other interesting features. Chances are the run-time is then limited by the self-discharge rate of the battery.
I keep hoping that somebody way smarter than me will eventually make a modern version of the TRS-80 Model 100. The original would run for days on 4 AA batteries. You would think that with modern chips and displays, you could get months of runtime on a set of 4 AA batteries.
The ideal system for me would be almost identical to the original machine. Simple OS (not Linux), basic applications, no web browser or WiFi.
I wonder how well this works in practice with a more complicated project. For example, if you have something that's usually sleeping but still needs access to wifi in order to send data and can also be woken up by another sensor in which case the loop isn't as simple. Throw in some threads running in parallel and it becomes much harder to manage. There are sleep modes that you can use for this but it's not as simple as this.
running RF for wifi or BT or something may boost the budget a bit. Fixed point sampling capture would mean clock coordination which drifts. Sending a wake call to come out of low power states is what the old "Morse code" audible pulses of interference on radio in the GSM days were doing: making the higher cost digital signalling stack wake up.
I think zigbee does stuff in this space. 6lowpan too.
Put a wifi or bt shield on, battery will drop faster.
If the led can blink a code, you could remote read it off a phone or something. Newton's did IR networking. The conference translation headsets use it too: the radiators for the signal get appreciably hot.
Readit News
What is the casino thing ? It looks like an abandoned project that got web squatted / Brandjacked.
Source code: https://github.com/jeelabs/jeelib
Website: https://jeelabs.org/202x/sw/jeelib/
The latter redirects to a page that shows Git commits, but it's a hidden page in a Dutch site about online casinos. It does look a bit shady. In the GitHub org of jeelabs, there are only two authors and neither seem to be based in the Netherlands.
Here's an archived website that documents the jeelib library.
https://archive.ph/nmF5Q
Relevant line:
> a Sleepy class for ultra low-power sleeping of ATmega and ATtiny µC’s
From a quick skimming of the codebase, I couldn't find this class. If I were the author, I would have forked the Sleepy class for my own use.
Edit: Here's the definition of the Sleepy class.
https://github.com/jeelabs/jeelib/blob/6df2d8da785aca77790e9...
It uses avr-libc's sleep functions.
> <avr/sleep.h>: Power Management and Sleep Modes
https://www.nongnu.org/avr-libc/user-manual/group__avr__slee...
He did a series of posts as he made it ever more power efficient, but that was about 10 years ago.
* https://minac.github.io/2015-05-20-s3-cloudfront-access-deni...
https://web.archive.org/web/20210615000000*/https://makecade...
Otherwise great post, though I'd love to have seen the images!
Else, the schematic is here (the first pic is just a shot of the atmega chip): https://ibb.co/8gVbm1XR
That's the kind of performance that makes you question the accuracy of your test equipment.
This is when the MCU itself you're using doesn't have this functionality of if it's still consuming too much power. MCUs like the ATMega368(PU) consume ~100nA in their deepest sleep states, so it can be a rather drastic reduction in some cases.
For more standard cases, the 43uA from the article is roughly the same order of magnitude you'll get from pretty much any micro in sleep mode, after doing your first pass low power optimisation. The stuff I normally work with gets about 10. The thing is just, most of the time, that's low enough already - for this project 2500mAh/43uA = 6 years of sleeping. The bigger factor is the current it consumes while awake - and that's where the Arduino's a bit of a letdown, the stuff I normally use is only in the order of 100uA while awake.
It can sleep and only use ~66 microamps at 5V with the watchdog timer enabled. That's 330 microwatts. A 1000 mA lithium cell (3.6 watt-hours) could then run it for ~10909 hours, or 454 days (~1 1/3 years).
Almost every microprocessor made these days has some sort of low-power sleep. The ATmega series aren't even particularly good at being low-power.
Of course, you then realize the "arduino" is really just a badly designed development board for an atmega, and they went and used cheap voltage regulators that have an idle current consumption of > 1 mA, and give up on the whole project.
The ideal system for me would be almost identical to the original machine. Simple OS (not Linux), basic applications, no web browser or WiFi.
i.e. https://ww1.microchip.com/downloads/en/devicedoc/39941d.pdf
I think zigbee does stuff in this space. 6lowpan too.
Put a wifi or bt shield on, battery will drop faster.
If the led can blink a code, you could remote read it off a phone or something. Newton's did IR networking. The conference translation headsets use it too: the radiators for the signal get appreciably hot.
No, that's the phone itself transmitting in its TDMA timeslots. https://en.wikipedia.org/wiki/Time-division_multiple_access#...
Would you agree it's part of the re-initialisation sequence, even if not directly caused by the transmission infra talking to the phone?
kinda, but in this instance the radio in receive mode is quite expensive, something like 1-20ma. To get years long battery power you need micro amps.
Dead Comment