All things - Low Power

duff

Well-known member
I'm starting this thread in hopes people will find it and use it for all things related to low power for the Teensy 3.x/LC/++ and peripherals. This will help me and other find info in one place and can we stick this thread into the Quick Reference also?
 
Glad to see this...I tried to use your library a few months ago, maybe I succeeded but I wasn't sure about a few things and didn't have time to ask.

I think making this capability easily accessible will be very valuable (for me at least) since power usage is a critical issue with wearable and other appallingly small devices and Teensy 3.1 uses ~20 mA in its natural state. I'd like to learn how to put the K20 to sleep for x milliseconds, wake it up either periodically or on interrupt and when it's done its work go back to sleep.

I don't know if this kind of feedback is what you had in mind, but I look forward to seeing more info and a how-to on Low Power operations in one place.
 
Your wonderful library is already referenced in a Sticky thread in the "Project Gudance" section of the forum, called "Teensy Quick Reference, Code Examples, Tips & Tricks".

I have questions as well. I looked through the examples and it seems to relatively straight forward how to wake up the Teensy LC I am using in my project.
What I am trying to do is easy to describe. I am designing a little IR remote controlled lighting system. hte last three posts on that blog pertain to this project.
Currntly when turned off it uses 13-14 mA of current when turned off.
I'd like to put the Teesny into sleep/hibernate when turned off and would like to have the IR pin wake the Teesny up when it receiveds a signal from the remote. Ultimately I want to be able to run this light using rechareable batteries.

It seems I'd simply have to confirure the pin using config.pinMode(PIN, INPUT_PULLUP, RISING);

Question 1: If the Infrared Library already useses an Interrupt - not sure if it dues - on this pin would this conflict or can this be resolved using differnt Interrupt priorities. ?

Question 2: It is not apparent to me what code actually puts the Teesny into sleep mode other han the Snooze block in loop(). I don't see in the example code how I could the teensy into sleep mode using code that is only executed when I press the corresponding "off" button on the remote ?
 
Last edited:
Your wonderful library is already referenced in a Sticky thread in the "Project Gudance" section of the forum, called "Teensy Quick Reference, Code Examples, Tips & Tricks".
I want to also explore circuit design, commonly used chips and such related to low power also with this thread, that current sticky thread has a lot of good info but is really cumbersome to find the useful nuggets. I'm planning on consolidating it here. The first bunch of pages are speculations on how to put the teeny into a low power state which is already well established now.

I have questions as well. I looked through the examples and it seems to relatively straight forward how to wake up the Teensy LC I am using in my project.
What I am trying to do is easy to describe. I am designing a little IR remote controlled lighting system. hte last three posts on that blog pertain to this project.
Currntly when turned off it uses 13-14 mA of current when turned off.
I'd like to put the Teesny into sleep/hibernate when turned off and would like to have the IR pin wake the Teesny up when it receiveds a signal from the remote. Ultimately I want to be able to run this light using rechareable batteries.

It seems I'd simply have to confirure the pin using config.pinMode(PIN, INPUT_PULLUP, RISING);

Question 1: If the Infrared Library already useses an Interrupt - not sure if it dues - on this pin would this conflict or can this be resolved using differnt Interrupt priorities. ?

Question 2: It is not apparent to me what code actually puts the Teesny into sleep mode other han the Snooze block in loop(). I don't see in the example code how I could the teensy into sleep mode using code that is only executed when I press the corresponding "off" button on the remote ?
Q1: Yes, the Snooze library currently configures the pin and attaches a interrupt handler inside the library. You will most likely have to reconfigure that pin with the IR library after sleeping this is a known limitation, I'm looking at how to solve this issue with new version of Snooze with trying to save the current state of the pin (registers and irq handler) before sleeping and reconfiguring it after waking to not have these types of issues. It's actually kinda hard but I'm trying.

Q2: There are three functions currently, sleep, deepSleep and hibernate. The SnoozeBlock is to configure what will wake it up, pin, timer, rtc, tsi , etc. The deepSleep and hibernate put the processor into a real low power state but is limited in what can wake it, "sleep" on the other hand is very versatile and can use any interrupt to wake it. While saying that about the sleep function I tried to keep the wake ups similar for all three functions. My new version I'm hoping will open up so new avenues for configuring the teensy for better integration into peoples projects.

Glad to see this...I tried to use your library a few months ago, maybe I succeeded but I wasn't sure about a few things and didn't have time to ask.

I think making this capability easily accessible will be very valuable (for me at least) since power usage is a critical issue with wearable and other appallingly small devices and Teensy 3.1 uses ~20 mA in its natural state. I'd like to learn how to put the K20 to sleep for x milliseconds, wake it up either periodically or on interrupt and when it's done its work go back to sleep.

I don't know if this kind of feedback is what you had in mind, but I look forward to seeing more info and a how-to on Low Power operations in one place.
Yes, configure the SnoozeBlock for the "setTimer" wakeup. It uses the Low Power Timer (16bit) with the LPO clock so you have 1 ms resolution.
 
One thing I have noticed with this low power stuff is that people focus on just the teensy, I have a few projects that have modules that are much higher current consumption than the teensy and these need to be addressed also with switches and such to turn them off. I hope we can discuss this also so if anyone has something besides the teensy that is sucking up to much juice lets discuss it here since it can be very useful in many other projects!
 
The ESP8266 is an obvious choice for attention here with the wifi being quite a power hog. It is quite a versatile chip capable of performing many of the same tasks as the Teensy as a host to sensors, etc. but it only has 9 or so GPIOs. It can be programmed via an Arduino IDE...I am starting to se it as a standalone host for flight control and robotics. I wonder if your Snooze library could be adapted to work with this chip?
 
The ESP8266 is an obvious choice for attention here with the wifi being quite a power hog. It is quite a versatile chip capable of performing many of the same tasks as the Teensy as a host to sensors, etc. but it only has 9 or so GPIOs. It can be programmed via an Arduino IDE...I am starting to se it as a standalone host for flight control and robotics. I wonder if your Snooze library could be adapted to work with this chip?
Ummm maybe, I'm working on a new version that will add some hooks for before and after sleeping the teensy that could be used for this for the time being. These hooks would be new c++ classes that you write for user specific things like this that get called through inheritance through the Snooze library. If I get one of these I would consider adding it to Snooze's core structure but since its totally different chip the low power instructions are probably much different, is this at least an arm chip?
 
No, not an ARM chip, I believe it is made by Tensilica or some such. It is a 32-bit chip and has an SDK. But might be more trouble than it's worth?
 
I want to also explore circuit design, commonly used chips and such related to low power also with this thread, that current sticky thread has a lot of good info but is really cumbersome to find the useful nuggets. I'm planning on consolidating it here. The first bunch of pages are speculations on how to put the teeny into a low power state which is already well established now.


Q1: Yes, the Snooze library currently configures the pin and attaches a interrupt handler inside the library. You will most likely have to reconfigure that pin with the IR library after sleeping this is a known limitation, I'm looking at how to solve this issue with new version of Snooze with trying to save the current state of the pin (registers and irq handler) before sleeping and reconfiguring it after waking to not have these types of issues. It's actually kinda hard but I'm trying.

Q2: There are three functions currently, sleep, deepSleep and hibernate. The SnoozeBlock is to configure what will wake it up, pin, timer, rtc, tsi , etc. The deepSleep and hibernate put the processor into a real low power state but is limited in what can wake it, "sleep" on the other hand is very versatile and can use any interrupt to wake it. While saying that about the sleep function I tried to keep the wake ups similar for all three functions. My new version I'm hoping will open up so new avenues for configuring the teensy for better integration into peoples projects.

Thanks, I was aware of the three different methods ;-) That is well documented.
I have a checkIR() routine in my loop(). Once it receives the "off" signal this checkIR() routine calls a routine to fade out the LEDs and then do I call SnoozeBlock to put the Teensy to sleep , or doss SnoozeBlock() have to remain in loop(): and another command is used to enter sleep mode ?

I looked at IRLIB, the infrared library I am using and it does use a 50us timer driven interrupt code. Please forgive the following noobish question as I don't have much experience with interrupts.

I've got plenty of pins left on the Teensy LC. Instead of re-configuring the pin used in the Infrared library, could I not connect that same signal from the IR receiver to another pin and have a wakeup interrupt triggered from it so I would not have to reconfigure that other pin ?
 
I have a checkIR() routine in my loop(). Once it receives the "off" signal this checkIR() routine calls a routine to fade out the LEDs and then do I call SnoozeBlock to put the Teensy to sleep , or doss SnoozeBlock() have to remain in loop(): and another command is used to enter sleep mode ?
Is this the IRremote library from the teensy install? Can I run it without any hardware?

Define your SnoozeBlock globally and configure the wakeup code in your setup function, it will be preserved throughout the life time of the program i.e.
Code:
#include <Snooze.h>


SnoozeBlock config;[COLOR=#ff0000]// <--- defined globally here[/COLOR]


void setup() {
    config.pinMode(21, INPUT_PULLUP, RISING);//pin, mode, type [COLOR=#ff0000]<--- configure the wakeup type to use through out the program now[/COLOR]
}


void loop() {
    //IR code......
    Snooze.deepSleep(config);// [COLOR=#ff0000]<--- sleep[/COLOR]
}

I looked at IRLIB, the infrared library I am using and it does use a 50us timer driven interrupt code. Please forgive the following noobish question as I don't have much experience with interrupts.

I've got plenty of pins left on the Teensy LC. Instead of re-configuring the pin used in the Infrared library, could I not connect that same signal from the IR receiver to another pin and have a wakeup interrupt triggered from it so I would not have to reconfigure that other pin ?
So this pin is being toggled by the timer? You could use another pin but if you use the "sleep" function then it could start firing its pin interrupt before it powers down, deepSleep and hibernate should be fine though since the they use a different internal interrupt controller of the teensy and should not fire before it goes to sleep but I can't say for sure since this timer is running pretty fast. Is there a way to stop the timer before a call the any of the power down functions (Snooze) in this IR library?
 
It is the IRLIB library, which is a re-write of the IR library with better structure. I recently updated it to work with with the Teesny LC but did not have to dig into any interrupt code to do so.
Here is a link to the thread/post

I honestly have no idea what exactly happens to the pin. The following code to configure the interrupt starts in IRLib.cpp in line 1096:
Code:
void IRrecv::enableIRIn(void) {
  IRrecvBase::enableIRIn();
  // setup pulse clock timer interrupt
  cli();
  IR_RECV_CONFIG_TICKS();
  IR_RECV_ENABLE_INTR;
  IR_RECV_PWM_RESET;
  sei();
}

ISR code starts in 1122, also in IRLib.cpp.

Yes, I believe you can run this without any hardware.

The last paragraph you wrote is exactly what I am trying to get to the ground off: What is the sequence of events or better, what should it be. I don't want to consume too much of your time but it is an interesting and valuable learning experience for me!

Maybe I am being a bit dull, but I still don't understand what triggers the Teensy to go to sleep.
 
Ya that library is very hard to understand whats going on but it looks like you can disable the timer interrupt but I'm still not sure what that timer is for, input or output or both? Probably a good idea to disable that timer and pwm before hand if possible. I don't know though since its very hard to follow the examples for me.

The sequence of the current Snooze library for sleeping using a pin as wakeup for "deepSleep" would be, i.e. calling the function:
  1. configure pin for input/input pullup
  2. setup LLWU to use that pin that was configured for wakeup to use HIGH/LOW/ANY interrupt
  3. setup sleep type (sleep, deepSleep, hibernate) and call the "wfi" hint instruction.
  4. now it will be sleeping until the wake condition is reached on the pin.
As you can see there is some overhead before the actual instruction to put the processor to sleep, thats when trouble occurs when using code that fires interrupts like this. But have you tried it out, does it go to sleep? It might just work?
 
No, not an ARM chip, I believe it is made by Tensilica or some such. It is a 32-bit chip and has an SDK. But might be more trouble than it's worth?
Well if ever have a use for this chip i might see about adding support for this.
 
I'm starting this thread in hopes people will find it and use it for all things related to low power for the Teensy 3.x/LC/++ and peripherals. This will help me and other find info in one place and can we stick this thread into the Quick Reference also?
duff,
you may add a link to the SW in the first post, also a link to other threads that discuss usage of your low power software
 
Thanks for the help!
I will tinker around with this a little over the the next several days and see where I can get with it.
 
@duff - I've been working with the ESP8266 - mostly the onehorse modules bonded over the small half of the Teensy 3.2 - very cool. I'm doing all my work from Arduino 1.6.7 IDE and it is going well. Apparently it has the means to reset to disable the WiFi and other power modes with docs I haven't looked at yet. The official ESP8266 GitHub site esp8266/Arduino doesn't show ready reference info to setting modes and restarting but it is around if you ever see the need for an onboard WiFi radio and second CPU. Having a good programmatic way to keep this running and select radio and power mode would be a big win since it eats over 200 mA feeding the radio.
 
@duff - I've been working with the ESP8266 - mostly the onehorse modules bonded over the small half of the Teensy 3.2 - very cool. I'm doing all my work from Arduino 1.6.7 IDE and it is going well. Apparently it has the means to reset to disable the WiFi and other power modes with docs I haven't looked at yet. The official ESP8266 GitHub site esp8266/Arduino doesn't show ready reference info to setting modes and restarting but it is around if you ever see the need for an onboard WiFi radio and second CPU. Having a good programmatic way to keep this running and select radio and power mode would be a big win since it eats over 200 mA feeding the radio.
Someday I might look at this but now my time is limited for any code dev and I want to finish up the update to Snooze for the Teensy first then try to finish my Guitar Tuner.

If you do find some relevant material though please update here so people/me can use it for reference when trying to do some low pow stuff with the esp8266.
 
I found some ref notes from: github.com/esp8266/Arduino/blob/master/cores/esp8266/Esp.h with searchable func() names below.

Here is a board layout with pins ID'd: esp8266-wiki/wiki/Pin-definition

Does system_deep_sleep_set_option work?

DeepSleep goes very low current with Radio off:
Another post with example last year - it is evolving

This header info for "EspClass ESP" - where ESP seems to exist as given in the sketch. This 15 day old code add-on not yet distributed: EspClass::getResetReason()
Code:
void system_restore(void); 
void system_restart(void); 
bool system_deep_sleep_set_option(uint8 option); 
void system_deep_sleep(uint32 time_in_us); 

typedef enum { 
	NONE_SLEEP_T	= 0, 
	LIGHT_SLEEP_T, 
	MODEM_SLEEP_T 
} sleep_type_t; 
 
bool wifi_set_sleep_type(sleep_type_t type); 
sleep_type_t wifi_get_sleep_type(void); 

sint8 wifi_fpm_do_sleep(uint32 sleep_time_in_us); 
void wifi_fpm_set_sleep_type(sleep_type_t type); 
sleep_type_t wifi_fpm_get_sleep_type(void);
 
Last edited:
Thanks for your great library. I have started using it with a Teensy LC and was able to reach about 4.4 uA in hibernate for the Teensy LC itself. I'm using it for a LoRa node as mentioned here configured as described here (see how to build a Teensy TTN node). The node is working fine without sleep / hibernate. I tried adding some sleep / hibernate pauses in onEvent routine at the case EV_TXCOMPLETE

In itself this works OK, but jobs are delayed by the amount of time spent in deepsleep / hibernate. As the LMIC library uses the micros() function to determine if a job needs to be scheduled,I guess during a (deep)sleep or hibernate time according to micros() is "stopped" as the CPU goes to sleep? I guess I would need a RTC and adjustments to the hal.cpp to get the correct time?.

In short: do we "loose time" during sleep/hibernate and what would be the best way to solve this aspect of low power sleeps/hibernate in a library as mentioned (I don't expect you to provide a complete solution but would like some guidance how to cope with this issue).
 
Thanks for your great library. I have started using it with a Teensy LC and was able to reach about 4.4 uA in hibernate for the Teensy LC itself. I'm using it for a LoRa node as mentioned here configured as described here (see how to build a Teensy TTN node). The node is working fine without sleep / hibernate. I tried adding some sleep / hibernate pauses in onEvent routine at the case EV_TXCOMPLETE

In itself this works OK, but jobs are delayed by the amount of time spent in deepsleep / hibernate. As the LMIC library uses the micros() function to determine if a job needs to be scheduled,I guess during a (deep)sleep or hibernate time according to micros() is "stopped" as the CPU goes to sleep? I guess I would need a RTC and adjustments to the hal.cpp to get the correct time?.

In short: do we "loose time" during sleep/hibernate and what would be the best way to solve this aspect of low power sleeps/hibernate in a library as mentioned (I don't expect you to provide a complete solution but would like some guidance how to cope with this issue).
yes that is correct micros will not reflect the sleep duration. If your using the timer to wake up then you can update the "systick_millis_count" variable by the timer amount.
 
****Never Mind I was just using sleep, its the same 12uA!!!****

Well, I have bad news for real low power with the Teensy 3.2. While the old Teensy 3.1 could be brought down to 12uA (Snooze hibernate), it looks like the Teensy 3.2 with the new 3.3V regulator can only be brought down to ~330uA @ 5V (Snooze hibernate). I thought I could by pass the regulator and power it from the 3.3V pin but it doesn't boot up most of the time. If anyone reads this and has got it working with powering it through the 3.3V pin let me know, seems that regulator doesn't like to be back powered, still need to read up on that.
 
Last edited:
I started with the MIC5528 since it is super small, 500 mA continuous current and only 38 microamp Iq (current draw with zero current load. But even this is too much for the electric Imp (Iq ~ 4 microA) and the STM32L4 (several power modes < 1 microAmp). So I switched to the NCP161, also super small, 450 mA continuous current and only 18 microAmp Iq. Still more than I would like. The STM32L4 has a shutdown mode which draw just 300 nA with the RTC and backup registers active, and 30 nA without. For ultra low Iq, the standard solution is to use a switching Buck converter, which can achieve Iq of ~5 microAmp, but at the cost of much larger board footprint. So the NCP161 is a nice compromise, which takes just a few square mm of board space at 18 microAmp minimum device current. I use the NCP161 on all of my custom Teensys.
 
Last edited:
I started with the MIC5528 since it is super small, 500 mA continuous current and only 38 microamp Iq (current draw with zero current load. But even this is too much for the electric Imp (Iq ~ 4 microA) and the STM32L4 (several power modes < 1 microAmp). So I switched to the NCP161, also super small, 450 mA continuous current and only 18 microAmp Iq. Still more than I would like. The STM32L4 has a shutdown mode which draw just 300 nA with the RTC and backup registers active, and 30 nA without. For ultra low Iq, the standard solution is to use a switching Buck converter, which can achieve Iq of ~5 microAmp, but at the cost of much larger board footprint. So the NCP161 is a nice compromise, which takes just a few square mm of board space at 18 microAmp minimum device current. I use the NCP161 on all of my custom Teensys.
Nice info, 450 mA cc and 18 microAmp Iq is nice, have you pushed that much current through the NCP161 yet?

So do you have any idea why the lp38691 the Teensy 3.2 uses does not alow me to by pass it and directly power the teensy with 3.3V? I see it has enable pin I wonder if it has to be disbaled for the bypass to work?
 
I use the NCP161 on my ESP8266 flight controller (powered by 5 V, 500 mA from a Boost converter). I haven't measured the current out but the ESP8266 uses at least 300 mA for wifi and more on startup. So I am pretty sure the spec is accurate.

I wonder if it has to be disbaled for the bypass to work

Maybe, but it might also have reverse voltage protection (a diode or blocking FET).
 
So I switched to the NCP161, also super small, 450 mA continuous current and only 18 microAmp Iq.

I chose the LP38691 based on its 500 mA *and* 10V input input spec.

Many chips like NCP161 are rated for 5.5V max input voltage. That's great if you never abuse them. However, experience over the last few years has shown many hobbyists do end up abusing Teensy with more than 5.5 volts input. Sometimes it ends up being a poorly made power supply or long wiring with some inductance, where a brief spike voltage spike can occur.

Unfortunately, the LP38691 does consume some static power. It shouldn't be anything like 0.33 mA, so perhaps something else is going on here? Maybe I need to dig into this?
 
Back
Top