Low Power "Green" Battery Operation Solutions For The Teensy 3.

Status
Not open for further replies.
Might be a good idea to tag your releases on github, so people can easily grab the stable or HEAD version as they prefer. Happy to help organize if I can, or work on additional features if a roadmap is documented so I know where to direct my efforts.

Thanks much for all your work on this I've been using the stable version in a couple of prototypes for the last few weeks and it's been exceptionally helpful.


Ya I know, I'm GitHub noob, so do you think I should have two versions on github? Not really sure what the protocol is for having different versions? I would still like to have the "bleeding edge" version along with a stable and proven version.

As far as a roadmap for future releases, I want to port over as many of the functionalities the teensy has to offer for reduced CPU, BUS and MEM speeds. I have got IntervalTimer (w/small mod to the core) and Hardware Serial's ported over and would like to get native SPI to work at reduced freq next. Also I'm working on speeding up going into and out of the various sleep modes and making them thread safe, I've been talking to kam42 about this, he helped me out with LowPower Timer also.:cool:

thanks,
duff
 
duff, really appreciate the postings on github.
Github is the magic place to share - and has made it so easy for sharing code like you are doing.
Usually its great to keep the "trunk" on the latest stable release - whatever that means to you - but it would be nice to have it mean its got some description about what is working.
For working/sharing in teams a branch is a really nice mechanism - usually something that compiles and some basic testing and the submission notes indicate what the push was about.
There is some discussion about a personal sandbox were all updates are pushed online, however personally, I work in stages - and when I'm satisfied with a specific stage I snapshot it locally with a zip. I only push it to the source control (github) when I'm happy with the code stability and comments.

I've had a look at your 2013/Aug reference and differenced it (I use WinMerge) with the latest on github and I like the latest on github as its referencing the latest teensy3 1.18 release.

In trying a modified DeepSleep_Simple / LLS mode I'm going from Vin=3.2V @31mA
with LPTMR_WAKE to somewhere between 1.2mA & 0.87mA when sleeping.
GPIO_WAKE --> stable 0.49mA
with RTCA_WAKE --> stable 0.57mA (but no 32KHz xtal)
Are these the type of readings you are getting?

I'm going to dig deeper into the peripherals turned on next.
In a past project before powering down I advertised to subsystems there was going to be a powerdown and they turned the peripheral off
I captured the state of the GPIOS
went to sleep
on wake up - restored the GPIOS, corrected for any clock issues
advertised the powerup to subsystems and they reinitialized the peripherals

cheers
 
In trying a modified DeepSleep_Simple / LLS mode I'm going from Vin=3.2V @31mA
with LPTMR_WAKE to somewhere between 1.2mA & 0.87mA when sleeping.
GPIO_WAKE --> stable 0.49mA
with RTCA_WAKE --> stable 0.57mA (but no 32KHz xtal)
Are these the type of readings you are getting?

Those are a little high, do you have anything connected to the Teensy that could be adding the extra power consumption? It should sleep at around 250uA. Also how are powering it? I see you are powering Vin at 3.2V, that is below the rated 5V that the Teensy regulator expects maybe this could be a problem, not sure. Also pin logic levels will only be as high as you power the Teensy, if you power it below 3.3V.

One thing I would be really interested in is if anyone that builds their own pcbs has measured the current consumption in sleep mode of the MK20 chip by itself or just minimal setup. The data sheets say it should sleep at something like 6uA in LLS sleep mode.
 
Hi @duff, I've been away from power issues with my app for a while and doing things like adding Bluetooth LE. I'm still currently using LLS low power mode. But I found the watchdog wasn't working. I found a bug with Teensy code for the watchdog but those are covered over in http://forum.pjrc.com/threads/25370-Teensy-3-0-Watchdog-Timer. The problem I have is that watchdog just doesn't/won't work in LLS mode and I'd like the protection it provides. So I'm thinking of going back to looking at VLPS mode. That's what a Freescale engineer I've been working with suggested.

Back last fall when I was working on this you and I seemed to be having similar issues with not being able to get VLPS mode working well. I was just wondering if anything has changed for you with that mode?

Thanks for any thoughts. Fred
 
Well that is interesting.
The Teensy3.1 Vin says 3.7V to 5.5V and when I use the DeepSleep_simple and sleep setting on GPIO_WAKE and set the voltage (+/- 0.1V)
3.8V -->stable 0.17mA
3.6V -->stable 0.17mA
3.4V --> 0.17 -->0.522mA

So interesting. Current usage is hard to track, but looking at the specs,
Teensy 3.1 Vin is to MK20 USB regulator VREGIN rated 2.7 to 5.5V and the
MK20 VDD is rated for 1.71 to 3.6V
so it would look like other circuitry is contributing to the jump.
The Mini54Tan (as available on Digikey which references Nuvoton NuMicro Mini51) specifies its LDO Vcc 2.7- 5.5V and seems to operate on internal 1.8V
The device has a selectable BOD (brown-out-detect) at 3.8/2.7/2.0V(default 2.0V)
and Operating Current at 10KHz Internal reference ~100uA, however powerdown can go to ~10uA
So perhaps there is something with its BOD setting.
 
The problem I have is that watchdog just doesn't/won't work in LLS mode and I'd like the protection it provides. So I'm thinking of going back to looking at VLPS mode. That's what a Freescale engineer I've been working with suggested.

Back last fall when I was working on this you and I seemed to be having similar issues with not being able to get VLPS mode working well. I was just wondering if anything has changed for you with that mode?

No VLPS but how about VLPW? Look at my Sleep function, though it will disable the systick if that matters for the watchdog? I think you gave me that idea about the systick actually :D. I'm seeing current consumption around 800uA if I don't disable any peripherals.
 
Well that is interesting.
The Teensy3.1 Vin says 3.7V to 5.5V and when I use the DeepSleep_simple and sleep setting on GPIO_WAKE and set the voltage (+/- 0.1V)
3.8V -->stable 0.17mA
3.6V -->stable 0.17mA
3.4V --> 0.17 -->0.522mA

So interesting. Current usage is hard to track, but looking at the specs,
Teensy 3.1 Vin is to MK20 USB regulator VREGIN rated 2.7 to 5.5V and the
MK20 VDD is rated for 1.71 to 3.6V
so it would look like other circuitry is contributing to the jump.
The Mini54Tan (as available on Digikey which references Nuvoton NuMicro Mini51) specifies its LDO Vcc 2.7- 5.5V and seems to operate on internal 1.8V
The device has a selectable BOD (brown-out-detect) at 3.8/2.7/2.0V(default 2.0V)
and Operating Current at 10KHz Internal reference ~100uA, however powerdown can go to ~10uA
So perhaps there is something with its BOD setting.

Hi,

I m also trying to get the best from teensy3 low power,
I was able to get 0.130ma on LLS mode (deep sleep). the VLPS doesnt seem very helpful, with 0.280ma avg.
I ask myself why are we so far from what is specced in the datasheets :
Low leakage stop mode current at 3.0 V : @ –40 to 25°C : 2.6 to 8.6 µa.
there is at least a 10x factor.
I know some components might drain current on the board + maybe the design of the board itself leads to "electrons leaks :) " but I also suspect the mini54 to consume a lot of power.
Paul, Is there a method like a modified bootloader we could use to point out if the mini 54 is the guilty part ?
Is there any software way to communicate with the mini54 from the MK20 ?
Depending the average consumption of the mini54 but it might be a good idea on later designs to reserve an output on the MK20 to shutdown completely the Mini54 (through a transistor that will leak 10 times more than the mini54 consumes ?? :-D).

Do you think there is any chance to get closer to datasheet , lets say between 10 to 30 µa in LLS mode with improving the software side or doing minor modification in the hardware ?

anyway, the teensy 3.1 coupled with hoperf RF22 is already a winners deal for low power mesh operations.
 
Hi,
I 'm having troubles getting the Teensy 3.1 in LLS mode.
Shouldn't this small piece of code do the trick?

void loop() {
pinMode(2, INPUT_PULLUP);
LP.DeepSleep(GPIO_WAKE, PIN_2);
}

This line of code works:
LP.DeepSleep(LPTMR_WAKE, 5000);

But the GPIO_WAKE method doesn't work.
Am I missing something ?! Is there anything to do except setting the input as INPUT_PULLUP?
There is nothing connected to the PIN 2.

Thx
 
Finally achieved low (enough) power!

@duff, I was going crazy trying to chase that low power issue I was having and posted about earlier. I tried your suggestion to use your VLPW code and found that it sometimes ran at about .8mA like you said right after download but if I unplugged and replugged in USB it went up to 3.5mA. After redoing my SW and HW to have just a Teensy 3.0 board with nothing connected but a serial=>USB board connected on UART0 for debug I found out that the problem was due to "back power" flowing in when in low power mode. The UART=>USB board propped up the voltage some on the GPIO pins and that ended up confusing the MIN54 to not go into a total low power mode.

Now, that was using TeensyDuino relelase 1.16 because I never upgraded to release 1.18 since I didn't see a reason to. Well I upgraded to 1.18 just to make sure I had the latest before reporting my findings and I found that the newer version of the MIN54 code that got loaded with that release made things work the way you suggested. I was sort of amazed (and also relieved). So that got me thinking about the connection to the MIN54 and what might be happening in low power. So I added code to make sure all the pins to the MIN54 were switched to Mux selection 0 (ie TSI input channels) vs their defaults (which for 4 of the pins are EZPORT connections). Amazingly I saw power drop by a factor of about 2. So my VLPW code dropped down to .4mA and my LLS code from .3mA to .15mA. All for just adding the code:
Code:
    PORTA_PCR0 = PORT_PCR_MUX(0);
    PORTA_PCR1 = PORT_PCR_MUX(0);
    PORTA_PCR2 = PORT_PCR_MUX(0);
    PORTA_PCR3 = PORT_PCR_MUX(0);

    PORTB_PCR2 = PORT_PCR_MUX(0);
    PORTB_PCR3 = PORT_PCR_MUX(0);
to my startup code.

So I just thought I would pass that along since I found your SW useful to give me ideas of different things to try in my hunt for my power problems.

Just for information I have found various interesting things along the way. So, one thing is that the Teensy board uses a 16MHz external crystal. All the Freescale boards use an 8MHz crystal. And if you look at the processor data sheet Table 14 you see that the faster crystal sucks 3x the power when it's running (.9mA vs .3mA). Doesn't affect things much in low power but it does when running. So, I'm not sure what advantage we get with a 16MHz crystal since it's divided down for almost every use. But it's what we have.

To see how power use was related to that crystal I tried changing my code to use a 32KHz crystal I have since I need the RTC and then ran in FEE mode (ie using the FLL vs PLL clock generator). That did cut a few mA out of my running power. Plus, since I only run F_CPU at 48MHz vs the 96MHz max I dropped the PLL/FLL output to 48MHz vs 96MHz to save some more power. I'm thinking I may take the time to change my code over to using FEE mode most of the time. The only time you need the PLL and PEE clock mode is if you want to use the USB interface since it needs the higher accuracy clock the PLL can generate. But if you are using USB then you have to be plugged in so power use isn't that big an issue.

Well, I mainly just wanted to thank you for your suggestion to try VLPW since that led me to find a solution to my problems after many other dead ends (I never even thought about the MIN54). Thanks. Fred
 
Thx for the reply duff,

PIN 2 is not connected to anything.
Driving it to ground isn't working, too. (As I understand driving PIN 2 to ground will wake the Teensy up again!?)

I downloaded the lib 2 days ago. Any changes in this version regarding GPIO_WAKE?

One more thing.
I just saw that my Teensy 3.1 (the black version ;) ) is drawing 24.8mA in idle at 48 MHz.
In this thread I saw it should draw like 18.8mA idle at 48MHz, LED off. ?

Sry for these "simple" questions, I would use google, but this is the only thread about this topic ;)
 
Last edited:
@duff or froeber, I am in need of a low power data logging option for temperature sensing using DS18B20 sensors in a streambed. This approach seems as though it would be ideal for me. Though, after so many posts, I am confused as to which files and parts to use. Could you please summarize for me the parts and method to getting the data logger operating?
 
@duff or froeber, I am in need of a low power data logging option for temperature sensing using DS18B20 sensors in a streambed. This approach seems as though it would be ideal for me. Though, after so many posts, I am confused as to which files and parts to use. Could you please summarize for me the parts and method to getting the data logger operating?

not sure what you are talking about in so far as "getting the data logger operating"? Do you mean how to put the teensy3 into low power?
 
Sorry for being too vague. Yes, the part I need help with is getting the teensy3 into low power mode. What parts do I need and which program file is the best to use?
 
Sorry for being too vague. Yes, the part I need help with is getting the teensy3 into low power mode. What parts do I need and which program file is the best to use?


you can download my library and check out the examples: https://github.com/duff2013/LowPower_Teensy3

Or you can implement the various sleep modes yourself by looking at the library but if you just want something that works out of the box use the library. I'm assuming you know how to add libraries to arduino?

regards,
duff
 
Duff,

Impressive work on this library!
I am trying to maintain USB communication with a Teensy 3.0, with reduced power consumption. My intent is to add diodes (when they arrive) to allow power from the USB, but for now the Teensy is battery powered by 3 AA cells. In the future, the meter will rarely be used with USB, so I desire to greatly improve the battery life, while maintaining the ability to connect via USB. The Teensy interfaces with a pulse output, once every few seconds from a flow meter - on pin 9. When the input pulse is received, I intend to use the real time clock to provide a time. I have a program that provides this functionality, but desire to reduce power consumption. I recently downloaded your library, and modified the basic sleep to accept an interrupt on pin 9. The program also produces text to confirm the operation. Serial printed text during setup is received, and is also received once, the first time that the interrupt occurs. After this first time, one can hear the computer confirmation that the port attaches and detaches. Even though serial communication is set up in this example program, it seems that USB cannot be used with sleep. Is this correct?

I have also tried the same using the Sleep_advanced program as a starting point. In this case, after uploading the program, the USB port is not accessible through serial monitor, the windows computer suggests there are no USB devices attached. Code to blink the onboard led indicates that the Teensy is operating, and accepting interrupt inputs as programmed . Is there some minor detail that I have missed in the code attached below? Is it possible to maintain a USB connection after sleep?

Arduino 1.05-r2, Teensy 1.18, Win 8.


**********************************************************/
#include*<LowPower_Teensy3.h>



TEENSY3_LP LP = TEENSY3_LP();
//*allows*use*of*the*serial*port*at*speeds*below*24MHz
HardwareSerial_LP Uart_lp = HardwareSerial_LP();



void setup() {
**pinMode(LED_BUILTIN, OUTPUT);
**digitalWrite(LED_BUILTIN, HIGH);
**delay(1000);
**digitalWrite(LED_BUILTIN, LOW);
**delay(500);
***digitalWrite(LED_BUILTIN, HIGH);
***delay(1000);
***digitalWrite(LED_BUILTIN, LOW);
****delay(500);
*******
*
****/*****************************************************
*******Start*off*at*2MHz*so*the*IntervalTimer_LP*class*
*******BUS*clock*configuration*is*initialized*at*the*same
*******BUS*frequency*as*Sleep*BUS*clock.
**********************************************************/
****LP.CPU(TWO_MHZ);
****/*****************************************************
*******Start*serial*port*using*2MHz*CPU*speed.
**********************************************************/
****Uart_lp.begin(57600);
*****
****delay (5000);
****Uart_lp.print("Sleep Advanced \n");
****Uart_lp.flush();
****
****pinMode(9, INPUT);
****attachInterrupt(9, callbackhandler, RISING);
}

void loop() {
****/*****************************************************
*******Sleep*for*5*secs,*thanks*to*the*IntervalTimer_LP*class
**********************************************************/
****LP.Sleep();
****Uart_lp.println("Wakey Wakey");
****Uart_lp.flush();
}

void callbackhandler() {
****digitalWrite(LED_BUILTIN, HIGH);
****delay(100);
****digitalWrite(LED_BUILTIN, LOW);
*****delay(100);
****digitalWrite(LED_BUILTIN, HIGH);
****delay(100);
****digitalWrite(LED_BUILTIN, LOW);
****
****Uart_lp.print ("CallBack");
****Uart_lp.flush();
}
 
Is it possible to maintain a USB connection after sleep?


Hi Christopher,

Try not running at 2 MHZ, and put a delay in after sleep. You will have to reopen the serial monitor also.

Code:
#include <LowPower_Teensy3.h>

TEENSY3_LP LP = TEENSY3_LP();
// allows use of the serial port at speeds below 24MHz
HardwareSerial_LP Uart_lp = HardwareSerial_LP();

elapsedMillis time;

void callbackhandler() {
  digitalWrite(LED_BUILTIN, HIGH);
  delay(100);
  digitalWrite(LED_BUILTIN, LOW);
}

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(9, INPUT);
  attachInterrupt(9, callbackhandler, RISING);

  //LP.CPU(TWO_MHZ);/***** this will disable USB *****/

  Uart_lp.begin(9600);
  Uart_lp.print("Sleep Advanced \n");
  Uart_lp.flush();
  delay(500);
}

void loop() {
  /*****************************************************
   * Sleep 
   *****************************************************/
  LP.Sleep();/***** this will disable USB until waken*****/
  Uart_lp.println("Wakey Wakey");
  Uart_lp.flush();
  time = 0;
  while(time < 10000) {
    Serial.println("USB enabled");
    delay(100);
  }
}

If you want to run your teensy at speeds lower than F_CPU the USB will be disabled using this library. Also any sleep mode will disable it also. While writing this library the USB has been one of the biggest issue i've dealt with. Keep in mind that all the teensy's different functionalities are configured for using the cpu, bus and mem at F_CPU, F_BUS and F_MEM. Care needs to be taken when running at these reduced speeds. Thats what the HardwareSerial_LP classes or the IntervalTimer_LP Class in the library try to resolve.

Also i should mention some things about the "Sleep" function. Part of the entry routine is to put the processor into VLPR (2MHZ) mode before going to sleep or more specifically "VLPW" mode. You must take this into account in that the processor is running at a slower speed so all the things I've stated above apply to this sleep mode also.

My recommendation for anyone trying to use these low power features would be, get your application running how you want first then add in the low power routines after. You must consider the performance you need to accomplish your task then tailor your power considerations accordingly because they can greatly reduce the performance you might need.
 
Last edited:
IMG_20140428_131109_906-002.jpg

I ended up finding the Teensy 3.1 for my application that is using Sharp's Ultra Low Power LCD Screens that require large amounts of SRAM since each pixel on the LCD screen requires 1 bit of memory. I'm using their 2.7 inch 400x240 pixel display which requires about 12000 bytes of SRAM for screen buffering.

This 2.7 inch screen only consumes 50 μW when displaying a static image. Hence power consumption is approximately only 1% of that of conventional transmissive TFT LCDs of the same size and even compared to conventional reflective displays the Memory LCD needs only a tenth of the power. . http://www.sharpmemorylcd.com/2-7-inch-memory-lcd.html

Here is a video showing the screens and how they operate. https://www.youtube.com/watch?v=eAoC818Mxy4

I'm using the Teensy 3.1 + Sharp LCD + Battery fuel gauge.

I want to put the Teensy 3.1 into deep sleep modes when the battery is not being used but I want to keep the Sharp LCD powered on while the Teensy 3.1 is in deep sleep so the battery status info is always being displayed and maybe have the Teensy 3.1 wake ever 24 hours to update the screen.

The plan is to have the Teensy 3 wake up via a button based interrupt and maybe a change in input our output current if that is possible.

My real question is what do you guys think is the best way to use the low power mode on the Teensy 3 while keep the Sharp Memory LCD powered up displaying static battery status info while the battery is in deep sleep mode. Do I need an external chip for refreshing the LCD while the Teensy is in deep sleep?

Below is some data on how the sharp display needs to be refreshed.

sharp also has an appnote on this display:
http://www.sharpmemorylcd.com/resources ... n_Info.pdf


on page 10:
This polarity-inversion flag enables a periodic polarity inversion
on the panel to keep a latent charge from building up within the
Liquid Crystal cells.


on page 12:
as long as the panel has power and VCOM is toggled periodically.
Sharp recommends keeping maximum time between VCOM toggles to no more
than one second, and refreshing data every two hours, to prevent stuck
pixels.


and on page 13:
In either implementation, the positive and negative inversion
intervals should be kept as equal as possible, and intervals should
not exceed one second.



my interpretation is that the data (12000 bytes) should be resent
at least every few hours, but that the display polarity needs to
be inverted at least one per second.
 
Last edited:
Thanks Michael, but when the screen is not in deep sleep mode showing static images it will be showing real time battery status info that will be refreshed every .5 or 1 seconds. so the RePaper LCD's would not work in that situation due to their low refresh rates.
 
Last edited:
. You will have to reopen the serial monitor also.

Duff,

I greatly appreciate your quick response. The code that you posted worked, and I was able to re-open serial monitor during the delay, and observe the re-opened connection.
In my original program, I was using the serial monitor to collect and store the data file. For my case, re-opening the serial monitor every few seconds probably will not work. I will probably use the dual power concept with two diodes, where an analog pin attached to VUsb through a voltage divider is used to determine if the processor can enter sleep. While connected to USB and collecting data, I will let the processor run full speed. When on battery the information will be sent to a LCD, then allow the processor to sleep.

Thanks !
 
my interpretation is that the data (12000 bytes) should be resent
at least every few hours, but that the display polarity needs to
be inverted at least one per second.

hi solardude,

you could use the either RTC or Low Power Timer (LPTMR) to wake up every second, toggle that pin and go back to deep sleep. Also if you are using the "time" library you need to resync it every time you wake from sleep since the systick is disabled during deep sleep, not sure if you are displaying current time also.

Thats a pretty cool little display i must say.

duff
 
hi solardude,

you could use the either RTC or Low Power Timer (LPTMR) to wake up every second, toggle that pin and go back to deep sleep. Also if you are using the "time" library you need to resync it every time you wake from sleep since the systick is disabled during deep sleep, not sure if you are displaying current time also.

That's a pretty cool little display i must say.

duff

Duff thank you so much for writing back. I see that you have dove deep into the low power modes for the Teensy 3.1 chip so your the man I should be talking to about this.

So no I'm not displaying time on the screen and I have no plans on doing that in the future also so hopefully that makes things a little more simple.

Can you tell me more about the Low Power Timer (LPTMR) feature. Does that allow the main Micro to stay in Deep Sleep while the LPTMR does the toggling of the pin every second? If so that sounds like the perfect solution.

Any ideas on what kind of deep sleep power consumption we would be looking at for just the Teensy 3.1 board if it were in Deep Sleep and the LPTMR was doing the toggling every second?

The Sharp Displays are very cool and efficient indeed. I mainly wanted them because they were easily to see in direct sunlight and they have super low power consumption which is great for battery powered applications. This is the same type of screens they are using the Pebble Watch and a few others that have not make it to market yet but have been successfully Kickstarted.

The screens come in a few different sizes:

DSC02345.jpgIMG_20131121_132702_047.jpg
 
Last edited:
Can you tell me more about the Low Power Timer (LPTMR) feature. Does that allow the main Micro to stay in Deep Sleep while the LPTMR does the toggling of the pin every second? If so that sounds like the perfect solution.
No none of the sleep modes currently support this, definitely not any deep sleep mode. What you will have to do is wakeup, toggle the pin then go back to sleep. The LPTMR timer just wakes the teensy, toggling is up to you.


Any ideas on what kind of deep sleep power consumption we would be looking at for just the Teensy 3.1 board if it were in Deep Sleep and the LPTMR was doing the toggling every second?
If you just toggle a pin every second the power consumption should be pretty low, probably around the stated .250mA + whatever else you have connected, your fuel gauge should give you all that meta data? The only thing i can think of now that would consume extra power is when the toggle pin is high, it all depends what it is connected to it, you will have to do some tests. Maybe if it works like this, make your transistions LOW->HIGH->LOW?

To save power try to make any processing in between sleeps as fast as possible, so optimize your code the best you can. I'm assuming your using my library(beta)?, the "DeepSleep" routine has callback function that would be perfect for your pin toggling. The deep sleep examples will show you this.

duff
 
Status
Not open for further replies.
Back
Top