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

Status
Not open for further replies.
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.



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

Ok, so a power consumption guesstimate of .250mA is low but not as low as I would like to go.

How about if while the battery is in the standby state I put the Teensy 3.1 into Deep Sleep only calling it wake up every 24 hours and update the battery fuel gauge data and refresh the LCD. It will continue doing this until triggered to go into active mode. So every 24 hours the Sharp Memory LCD gets it pixel data updated and then we could use a CMOS 555 Timer that consumes .144 uA @ 5v to generate a square wave at .5Hz to send the Vcom refresh pulse to the Sharp Memory LCD.

Would that allow the Teensy 3.1 to stay in a deep sleep state for all but a second every 24 hours?

If so then that would bring the stand by current down to a few hundred uA for the Teensy 3.1 in deep sleep + the memory LCD + battery fuel gauge.

Is there any reason that type of setup would not work based on the info I have provided so far? The 555 timer can generate a pulse every .5 - 1 seconds right?

Here is a video showing the low power consumption of the new CMOS 555 Timers https://www.youtube.com/watch?v=T2WXy2wW_LI
 
Last edited:
Ok, so a power consumption guesstimate of .250mA is low but not as low as I would like to go.

.250mA is what my current library supports, i can say that I have achieved much lower than that but I can't show it now since it has the possiblity of locking up the teensy. Until i can figure that out .250mA is what you will have to live with:D.
 
.250mA is what my current library supports, i can say that I have achieved much lower than that but I can't show it now since it has the possibility of locking up the teensy. Until i can figure that out .250mA is what you will have to live with:D.

Does the Deep Sleep mode disable the USB chip? Eventually the chip will be installed in finished product and the USB chip would not really be needed in the final design so would eliminating that reduce power consumption below the .250mA or is it already take care of?

Also what frequency would the chip be running at with that .250mA power consumption guesstimate? 24 mhz or something slower?
 
Hi,
once again a short question.

After software bootloader change ...
Downloaded program: "blank.pde"
Teensy 3 active run (idle) current Is 13.07 ma. @ 24 Mhz <-------<<<<<
Teensy 3 active run (idle) current Is 18.8 ma. @ 48 Mhz <-------<<<<<
Teensy 3 active run (idle) current Is 25.4 ma. @ 96 Mhz <-------<<<<<
No connections are made to the Teensy 3

Is this the same with Teensy 3.1?
If so, why is my Teensy 3.1 using like 25ma @ 48 Mhz (LED off, nothing connected to it)?

Thx in advance
 
Does the Deep Sleep mode disable the USB chip? Eventually the chip will be installed in finished product and the USB chip would not really be needed in the final design so would eliminating that reduce power consumption below the .250mA or is it already take care of?
yes it does disable USB in any sleep mode.

Also what frequency would the chip be running at with that .250mA power consumption guesstimate? 24 mhz or something slower?
The clocks will be stopped in DeepSleep or Hibernate so nothing is being clocked at 24/48/96MHz.
 
Hi,
once again a short question.



Is this the same with Teensy 3.1?
If so, why is my Teensy 3.1 using like 25ma @ 48 Mhz (LED off, nothing connected to it)?

Thx in advance

I'm not sure, how are you measuring this? I haven't looked at the current consumption of the Teensy3.1 while running at full speed.
 
yes it does disable USB in any sleep mode.


The clocks will be stopped in DeepSleep or Hibernate so nothing is being clocked at 24/48/96MHz.

Thank you very much for the answers.

I think I can live with the .250mA power consumption. That gives me about 166 days of run time per amp hour of battery storage. I can program it turn the screen refreshing off and stay in deep sleep mode once the battery state of charge hits 10%.

So with this new method your still working on that provides a much lower seep current, if you do get it working how much lower could the deep sleep power consumption go?
 
I just took a multimeter in the Vin-line between battery+ and Vin.

Do I have to change the bootloader? Tried it, no change...
 
this new method your still working on that provides a much lower seep current, if you do get it working how much lower could the deep sleep power consumption go?

ummm... on the order of 10uA maybe lower, haven't measured it with a bare teensy yet, i'm measuring it with a board I made that has some stuff sucking up power also. Probably won't be for a while until I get this worked out, many other things to do also. Plus i need to talk to paul about this to see what he thinks the best route is.
 
Last edited:
I just took a multimeter in the Vin-line between battery+ and Vin.

Do I have to change the bootloader? Tried it, no change...

No sure why this is, like i said I haven't measured a teensy3.1 running at F_CPU. Maybe someone could confirm your numbers, I'm using my 3.1's on different project right now and can't measure this.
 
ummm... on the order of 10uA maybe lower, haven't measured it with a bare teensy yet, i'm measuring it with a board I made that has some stuff sucking up power also. Probably won't be for a while until I get this worked out, many other things to do also. Plus i need to talk to paul about this to see what he thinks the best route is.

No problem, I just wanted to get an idea of what may be possible sometime in the future.

And what is the latest power consumption in Deep Sleep?
 
Is there a way to have the teensy sleep, but have a pin remain in it's state (HIGH/LOW) while sleeping? or am I better off using a latching relay for something like this? (or is there another way to do it?)

What I'm after is to have a pin high or low which in turn signals an led to be on or off. I want to sleep the cpu for 30 seconds to save battery power but keep the led on or off during the sleep cycle.
 
Awesome; thank you!
The "low power"guide seems to have a lot of place holders, so I'm trying various libraries... so far one didn't work as it relied on files that I didn't have; and another actually drew slightly more when in it's "low power" mode... the really odd part was that I had a blinking led that worked; but the pin I Need to stay up was not being brought up to high at all... sadly, when using that library, serial output was disabled. I'll keep at it now that I know the pin will stay high/low during sleep. thank you!
 
Awesome; thank you!
The "low power"guide seems to have a lot of place holders, so I'm trying various libraries... so far one didn't work as it relied on files that I didn't have; and another actually drew slightly more when in it's "low power" mode... the really odd part was that I had a blinking led that worked; but the pin I Need to stay up was not being brought up to high at all... sadly, when using that library, serial output was disabled. I'll keep at it now that I know the pin will stay high/low during sleep. thank you!

The AVR Sleep Library won't work, did you try this low power library? I don't think there is any others for the teensy3.0/3.1 yet.
 
Right; the avr doesn't work, of course.
Yes, that's the library I tried; when put into 'deep sleep' and then out of sleep; it drew more power than when I left it alone. Perhaps the time/power it takes to recover back to full speed negates the time in sleep, just not 'slept' long enough; and the pin did not stay high... I'll keep at it. It is possible(read:likely) I have something wired less than optimally.
 
ummm... on the order of 10uA maybe lower, haven't measured it with a bare teensy yet, i'm measuring it with a board I made that has some stuff sucking up power also. Probably won't be for a while until I get this worked out, many other things to do also. Plus i need to talk to paul about this to see what he thinks the best route is.

Hey Duff, any progress on this lower 10uA low power mode on the Teensy 3.1?
 
prolly not for a while, the teensy core is pretty fluid right now, I'm waiting for 1.20 or 1.21 depending on what changes their might be. Some of the low power functionality is already in the core currently and suspect some of the sleep modes will be in core at some point also. But for now I need to focus on my wireless teensy SDI-12 data logger!
 
prolly not for a while, the teensy core is pretty fluid right now, I'm waiting for 1.20 or 1.21 depending on what changes their might be. Some of the low power functionality is already in the core currently and suspect some of the sleep modes will be in core at some point also. But for now I need to focus on my wireless teensy SDI-12 data logger!

Duff can you give me any advice on how to best try to accomplish the 10 uA sleep current consumption with the Teensy 3.1 microchip? I'm building out a custom board for a product and its going to be the same processor as the Teensy 3.1. I can live with the .250 mA deep sleep that is up and working now but the LCD screen and timer I'm using is only consuming about 20 uA which is really good so I can really benefit if I could get the micro to sleep closer to your 10 uA deep sleep setup.

Just curious as to how you went about getting that.
 
Hey @duff, I'm sort of wondering how you get 10uA too. I want to throw my board into real lower power state when battery voltage drops and leave it there until USB charger plugged in so that I don't overdischarge the LiON battery we're using and wreck it. I've put the processor into VLLS0 power state with everything off that I can figure out and can't get power below about 250uA. Thing is that I have a lot of stuff hooked up to the Teensy and I know (and have measured) how driving even one GPIO pullup/down while sleeping can cost 100uA extra power. I've tried things like switching to BLPI clock mode running at low speed before going into VLLS0 but that didn't make any difference (which makes sense since all the clocks will be shut down in VLLS0 anyways).

I guess I was just wondering if there was some magic you did that you found made a difference. I wasn't sure, for instance, if the external 16MHz crystal oscillator goes off in VLLS0. Or if something has to be done with the USB regulator (even though of course USB is off). I'm driving my display and BLE chips off the Teensy 3.3V output and I've measured them pulling just 3uA in the sleep states they are in. So I think it's something internal. I have the RTC running off the external 32KHz crystal but that should only pull a couple of uA.

For what it's worth, I know it's not current draw from the MIN54. I've got two versions of the circuit one with the Teensy and all the peripherals and a version on a PCB with no MIN54 using JTAG loader and both pull the same current when "shut down" to within a few uA.

I'm just hoping you did something tricky I didn't think of to get the power that low. If not, then there must still be some external power draw I'm missing.
Fred
 
@froeber nice to know that driving one GPIO pin in sleep raises sleep current 100uA.

I'm hoping @Duff does stop by to drop some knowledge on us about this 10uA standby current consumption he has accomplished.

@froeber please do make sure to comeback and let us know if you do make any progress on getting the sleep current below .250uA.
 
I haven't really been looking at the low power stuff lately been working on my SDI-12 logger library, but I have just got some equipment to make accurate measurements at very low power. Once I can confirm my low power library compatible with all the new changes to the teensyduino core i'll be releasing what i've found concerning getting the teensy down to much lower power consumption. Sorry for being so terse, these are actually really advanced topics that I can't be responsible for beginners possibly thinking they bricked their teensy trying these things I've found.

froeber, i know you have really looked at this low power stuff in detail, so once I get rolling on this again i'll pm you if you would be willing to help me get these real low power settings figured out for the Teensy Arduino community so things work solidly.
 
Just an update. So, I was trying to come up with a super low power state that I could put the Teensy 3.0 processor into when our LiON battery got too low so that it would stop discharging until plugged into a charger. After much fiddling around and searching the Freescale Kinetis forums and trying to get power usage real low in VLLS0 power mode I changed my mind. I couldn't get power below 200 uA with all the peripheral connections we had to our Teensy 3.0. So I decided to use a HW battery disable circuit with a couple of FETs that allows power to be shut down by the MCU such that it doesn't power back up until USB is plugged in and Vusb powers the circuit back up. Problem solved. The power draw when shut down is only a few uA (we leave the Vbat connection to power the RTC). Of course, a down side that we don't care about is that about the only possible wakeup source for this is Vusb coming back.

I have to say that I have read with great interest all the postings by a Freescale engineer Phillip Drake. He posts a lot in the Freescale Kinetis forum. He indicates his main job is testing and documenting low power operations of the Kinetis processors. He wrote App Note 4503 which is useful for low power work. And he indicates that he still learns new stuff every day about getting things to work right. And he can talk to the chip designers which I can't. I've found low power work fairly frustrating because, for all the documentation there is, there are still lots of details missing. And with SW the devil is in the details.

For normal reduced power operation I got LLS mode running and VLPW mode. I couldn't get VLPS to run reliably. I'm using VLPW mode because I want the Watchdog timer to be active for reliability issues. But LLS mode did have lower power use. I based my code off of the great work in @duff's library.

Just thought I'd pass that along for what it's worth.
 
froeber thanks for posting your experience and for your solution.
I've got it on my list to get to low power as well, and building low uA into my power usage model, so useful to have some real experience.
Here is a posting by Eric Styger on using the FRDM-KL25 that says he got there, and he had to cut the board to get there.
http://mcuoneclipse.com/2013/10/20/tutorial-using-the-frdm-kl25z-as-low-power-board/
The FRDM-KL25 is built to be able to test low power, so I think a similar approach would need to use the FRDM-KL20 board.

In a previous life with an mega128 I got to very low power for the mega128, but I did it by designing the software for the mode right up front, and it was a whole system design.
It taught me, like you are saying I need to think of it in the early stages of the project. This time I'm anticipating using the new Kinetis SDK Processor Expert
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=KINETIS_SDK
which Eric Styger gives some tutorials on. (http://mcuoneclipse.com)
The core of the Kinetis low power is the clocking and managing it.
My plan is to verify the low power upfront,
then switch between a high power run mode for use by the SPI and USB, and a low power run mode for normal operation,
The LowPowerRun which should be able to switch to a wait mode for power saving while processing
and then finally switch to a sleep mode with wakeup sources through the LLWU for getting to the lowest power state.

I'll post if I get there :)
 
Better results with better tools and more drastic measures

Here is a posting by Eric Styger on using the FRDM-KL25 that says he got there, and he had to cut the board to get there.
http://mcuoneclipse.com/2013/10/20/tutorial-using-the-frdm-kl25z-as-low-power-board/
The FRDM-KL25 is built to be able to test low power, so I think a similar approach would need to use the FRDM-KL20 board.
Neil, Thanks for the great link! And damn, how much easier things are with the right tools! That guy Eric Styger is using the Freescale Code Warrior toolset with their processor expert support. And it allows you to use a nice Gui to select all sorts of features that then "auto generate" the code for you. And there's a debugger. And... With Teensy we get none of those awesome things. We get the fairly bare bones Arduino IDE and nothing like the processor expert or debugger. And for low power we get libraries from nice people like Duff and stuff we write ourselves. And every tweak to modes is more code to write and different conditional compilation directives. BUT, Arduino costs $0 and list price for the professional version of the Code Warrior toolset that includes Processor expert is like $5K/seat. And that's the trade off. I've been in this business a long time as I suspect have you Neil and it's always wonderful to use the big $$ great toolsets. But too often we get stuck with the cheap low functionality tools and burning our own time instead.

Oh well, enough of that. What was most impressive with Eric's stuff were the results he was able to get. So, as I posted earlier, even with the lowest power mode of the K20 MCU we are using I couldn't get Teensy board power below 250 uA. And it should have been 10 uA or so. And Eric used the LLS low power mode that our processor also supports and got 2uA whereas I could never get much below 300uA. So, there must be one of those vampire power draws on our board that Eric found and eliminated on his board by cutting traces and removing components. I haven't gone to those lengths to try to track this down because I couldn't figure out what was really driving the power usage and I couldn't do all the easy "what if" tests that the processor expert tool allows. Maybe I'll revisit things.

So, one thing I do know is that the Freescale boards use 8MHz oscillators and our Teensy boards use a 16MHz oscillator. I'm not sure why Paul made the different choice but the 2x faster oscillator typically draws 3x the power from the data sheet details I could find. But I'm not sure I ever found the magic code to turn off the oscillator even though I tried the BLPI power mode Eric said lowered his power. Also, our board uses a higher performance M4 processor than the M0 processor on Eric's board. Now, I don't really need that extra performance but our processor does have EEPROM support that's real useful for our application.

So, after reading about Eric's exploits I'm wondering about putting some more time in to figuring out where the extra 200 to 300 uA current draw is going. And maybe at some point I'll try to figure out some more why I have to use VLPW mode and can't get reliable VLPS mode operation (where VLPW is specced at 500uA and VLPS at 20uA). But, for now I reached my low power goal of <1mA when sleeping -- interestingly the same as the goal Eric proposed for his documented exercise. So I think I'll wait to see if anyone else turns anything up. And thanks Neil for the reference to Eric's work!
Fred
 
Status
Not open for further replies.
Back
Top