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.
I spent some time* working on the firmware side of developing custom electronics based on various AVR chips, ATmega328 among them. Arduinos are not good for much more than babby's first microcontroller project. They're not even that great for prototyping. Besides the aforementioned hardware design issues, the "arduino" language(really just C++) and core library had several problems both in terms of code quality and abstracting over things that shouldn't be abstracted over when working with such a limited chip(8bit, 2k SRAM...), like significant memory allocations and interactions with SREG.
My EE partner in crime ended up designing a prototyping board himself, with various creature comforts included that we needed shields for with Arduino, and I ended up writing just C with avr-libc instead of using any of the arduino library/tooling, developing a set of core modules to use the things we added to our boards, in a more flexible manner than the Arduino library. It took some time, but it saved us a lot of time and friction in our future prototyping efforts.
All that being said, there's nothing wrong with Arduino as a platform for learning and personal tinkering. I do think they could've done a better job bridging the gap between that and prototyping though.
* Ten years ago, so my memory of specifics is very fuzzy and only reflects the state of things back then.
> Arduinos are not good for much more than babby's first microcontroller project.
Baby’s first microcontroller project is exactly what they excel at and, by doing so, they made hobbyist microcontroller development vastly more accessible.
The Arduino value comes from the ease-of-starting and they made that a lot easier than the then-extant state of the art.
>So ... exactly for what the device is being sold as? Weird complaint: "I purchased an apple, and all I got was an apple that's only good as an apple."
Like I said:
>>All that being said, there's nothing wrong with Arduino as a platform for learning and personal tinkering.
I was just adding my 2 cents on Arduinos based on personal experience. That is all.
>Then you would know that ATmegas are in a lot of successful commercial products from the past.
Yes. What led you to believe I was suggesting otherwise? I made no criticism of the ATmega328, any other ATmega chip, or the AVR ISA for that matter. I could make some if I wanted to, but it doesn't seem relevant. The topic was Arduino boards, which typically contain an AVR chip, but is in fact not a chip but a dev board.
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.
There is an obvious mistake in the include.
And the library doesn't seems well documented and rather shady actually.What is the casino thing ? It looks like an abandoned project that got web squatted / Brandjacked.
> JeeLib is an Arduino IDE library for JeeNodes (made by JeeLabs)
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...
The root page that you want is https://jeelabs.org/w/ .
Jeelabs was a guy that made a whole ecosystem of compact lowpowered arduino boards with radios attached.
He did a series of posts as he made it ever more power efficient, but that was about 10 years ago.
Are images loading for anyone else? Seem broken for me.
An apparently very common CloudFront misconfiguration that has spawned a thousand articles and StackExchange Q&As on how to fix it. Randomly chosen one:
* https://minac.github.io/2015-05-20-s3-cloudfront-access-deni...
archive.org has saved the images:
https://web.archive.org/web/20210615000000*/https://makecade...
Not loading for me either.
Otherwise great post, though I'd love to have seen the images!
Try https://web.archive.org/web/20210928210220/https://makecadem...
Else, the schematic is here (the first pic is just a shot of the atmega chip): https://ibb.co/8gVbm1XR
Maybe there are specialized microcontrollers that just efficiently sleep and wake up other microcontrollers?
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.
I spent some time* working on the firmware side of developing custom electronics based on various AVR chips, ATmega328 among them. Arduinos are not good for much more than babby's first microcontroller project. They're not even that great for prototyping. Besides the aforementioned hardware design issues, the "arduino" language(really just C++) and core library had several problems both in terms of code quality and abstracting over things that shouldn't be abstracted over when working with such a limited chip(8bit, 2k SRAM...), like significant memory allocations and interactions with SREG.
My EE partner in crime ended up designing a prototyping board himself, with various creature comforts included that we needed shields for with Arduino, and I ended up writing just C with avr-libc instead of using any of the arduino library/tooling, developing a set of core modules to use the things we added to our boards, in a more flexible manner than the Arduino library. It took some time, but it saved us a lot of time and friction in our future prototyping efforts.
All that being said, there's nothing wrong with Arduino as a platform for learning and personal tinkering. I do think they could've done a better job bridging the gap between that and prototyping though.
* Ten years ago, so my memory of specifics is very fuzzy and only reflects the state of things back then.
> Arduinos are not good for much more than babby's first microcontroller project.
Baby’s first microcontroller project is exactly what they excel at and, by doing so, they made hobbyist microcontroller development vastly more accessible.
The Arduino value comes from the ease-of-starting and they made that a lot easier than the then-extant state of the art.
>Arduinos are not good for much more than babby's first microcontroller project
So ... exactly for what the device is being sold as? Weird complaint: "I purchased an apple, and all I got was an apple that's only good as an apple."
>I spent some time working on the firmware side of developing custom electronics based on various AVR chips, ATmega328 among them*
Then you would know that ATmegas are in a lot of successful commercial products from the past.
>So ... exactly for what the device is being sold as? Weird complaint: "I purchased an apple, and all I got was an apple that's only good as an apple."
Like I said:
>>All that being said, there's nothing wrong with Arduino as a platform for learning and personal tinkering.
I was just adding my 2 cents on Arduinos based on personal experience. That is all.
>Then you would know that ATmegas are in a lot of successful commercial products from the past.
Yes. What led you to believe I was suggesting otherwise? I made no criticism of the ATmega328, any other ATmega chip, or the AVR ISA for that matter. I could make some if I wanted to, but it doesn't seem relevant. The topic was Arduino boards, which typically contain an AVR chip, but is in fact not a chip but a dev board.
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.
they are called "nanowatt"
i.e. https://ww1.microchip.com/downloads/en/devicedoc/39941d.pdf
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.
There is no free lunch, but you can sleep for minutes, you can use BLE for comms, e-ink for infrequent display updates etc.
Wifi is about 20-60ma, so its unlikley.
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.
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
No, that's the phone itself transmitting in its TDMA timeslots. https://en.wikipedia.org/wiki/Time-division_multiple_access#...
So I got the directionality wrong, but it did seem to presage a call event: you heard the distinctive tones before the ring.
Would you agree it's part of the re-initialisation sequence, even if not directly caused by the transmission infra talking to the phone?
> 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
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]