Closed bandigore closed 8 years ago
Power consumption is already pretty low. OpenLog automatically goes to sleep when a serial char is not received for more than 500ms:
See line 454: https://github.com/sparkfun/OpenLog/blob/master/firmware/OpenLog_Firmware/OpenLog/OpenLog.ino#L454
I believe current is around 1.5mA during sleep/idle and ~15mA when 100% logging.
Closing out. Let me know if you have other thoughts.
In the power save mode the processor should be using less than 1 ua. Add in the crystal and the regulator and I would think it would be possible to achieve an OpenLog sleep mode of under 100 ua. I need to get way under the 1.5 ma. I haven't really looked at the code in any kind of depth yet. If you can point me to where the current sleep/idle is implemented, I'll try to find some time to tinker with a deeper sleep mode.
Thanks,
John
On Thu, Aug 18, 2016 at 12:15 PM, Nathan Seidle notifications@github.com wrote:
Closed #206 https://github.com/sparkfun/OpenLog/issues/206.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sparkfun/OpenLog/issues/206#event-760144132, or mute the thread https://github.com/notifications/unsubscribe-auth/APXHEZ3KRft4qhTD4B02myv6cH7mLzqhks5qhIU9gaJpZM4Jf9yT .
John der Kinderen WNWN: "Win Win; Waste Not Want Not" www.wnwn-llc.com 207 671 0522
Hi John,
Code relating to powering bits down is here: https://github.com/sparkfun/OpenLog/blob/master/firmware/OpenLog_Firmware/OpenLog/OpenLog.ino#L206
Also a tutorial I wrote awhile ago may be helpful to you: https://www.sparkfun.com/tutorials/309
I suspect the microSD card may be a vampire draw of unknown amounts (varying mfgs may have varying draws). I agree the regulator may be part of the draw but the quiescent current should be minimal.
Let me know if you find any places for improvement! I would love to make things better.
Thanks! It's a great little tool, but needs a few refinements. I'll see what I can squeeze in in between my other commitments.
John
On Aug 22, 2016 6:24 PM, "Nathan Seidle" notifications@github.com wrote:
Hi John,
Code relating to powering bits down is here: https://github.com/sparkfun/ OpenLog/blob/master/firmware/OpenLog_Firmware/OpenLog/OpenLog.ino#L206
Also a tutorial I wrote awhile ago may be helpful to you: https://www.sparkfun.com/tutorials/309
I suspect the microSD card may be a vampire draw of unknown amounts (varying mfgs may have varying draws). I agree the regulator may be part of the draw but the quiescent current should be minimal.
Let me know if you find any places for improvement! I would love to make things better.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sparkfun/OpenLog/issues/206#issuecomment-241570060, or mute the thread https://github.com/notifications/unsubscribe-auth/APXHEYVlV79hQvYO50fTqZ6VEJdz_WgSks5qiiGOgaJpZM4Jf9yT .
I think what I'll try first is to completely shut down between writes. What would be the consequences of turning power on and off repeatedly (say every few minutes)?
John
On Aug 22, 2016 7:58 PM, "John der Kinderen" johndk@wnwn-llc.com wrote:
Thanks! It's a great little tool, but needs a few refinements. I'll see what I can squeeze in in between my other commitments.
John
On Aug 22, 2016 6:24 PM, "Nathan Seidle" notifications@github.com wrote:
Hi John,
Code relating to powering bits down is here: https://github.com/sparkfun/OpenLog/blob/master/firmware/Ope nLog_Firmware/OpenLog/OpenLog.ino#L206
Also a tutorial I wrote awhile ago may be helpful to you: https://www.sparkfun.com/tutorials/309
I suspect the microSD card may be a vampire draw of unknown amounts (varying mfgs may have varying draws). I agree the regulator may be part of the draw but the quiescent current should be minimal.
Let me know if you find any places for improvement! I would love to make things better.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sparkfun/OpenLog/issues/206#issuecomment-241570060, or mute the thread https://github.com/notifications/unsubscribe-auth/APXHEYVlV79hQvYO50fTqZ6VEJdz_WgSks5qiiGOgaJpZM4Jf9yT .
The unit already shuts down if no characters are received after 500ms, so no consequences? :) Please have at it and let us know!
I'll let you know how it goes. I don't mean an idle state, but a no-power state. It seems that should be more energy efficient if it doesn't cause side effects.
John
On Aug 23, 2016 11:39 AM, "Nathan Seidle" notifications@github.com wrote:
The unit already shuts down if no characters are received after 500ms, so no consequences? :) Please have at it and let us know!
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sparkfun/OpenLog/issues/206#issuecomment-241775478, or mute the thread https://github.com/notifications/unsubscribe-auth/APXHEaJndMXgnsYH8qMLJ3q-V_kTLUMRks5qixQ5gaJpZM4Jf9yT .
So are there any solution that can make much more power save now?
Is there any way to optimize the power consumption of OpenLog? I am operating on battery power over long periods and need to conserve every electron. Compared to my other components, OpenLog is quite power hungry.
I've thought of turning the power off between log writes (about every 30 sec). But I'm not sure if this will gain me anything with the (assumed additional) power use during initialization.
My thought is to optimize power consumption by shutting down all unused portions of the processor. I know this is possible on the newer chips, but not sure about this one. Maybe you've already done this?
Also great would be to add a sleep mode and be able to turn off the LEDs.