Simple little power study I did which showed a 25% reduction in power consumption simply using GHI’s power management features.
Very interesting! I’m surprised at the ~50% power saving just by using Thread.Sleep.
Edit: I forgot to ask… any idea of what battery life you can expect using the Hibernate method?
@ Duke Nukem - Very interesting indeed.
Did I read the graph correctly that even in hibernate mode the circuit was still drawing about 30mA? And the averaged current,(including the active state current) is much higher. With that kind off current it would still not really be very good for a sensor running on coin cell of even penlight batteries. I’m wondering what is still drawing so much current.
It is also important to note that you are measuring the current on the high side input (probably 12V) That means the actual current on the 3V3 is probably even higher, unless the power is dissipated by the regulators and circuitry on the power module. It would be interesting if you could measure the actual current used by each on the modules and the mainboard itself to find out which is still using so much current.
Actually the Sleep and Timer methods were about equally as bad (maybe a really small almost unperceivable advantage to the Timer method but alignment of the planets could change), the Hibernate was clearly the better power management method.
You wouldn’t want to run this device using a coin battery as the gas sensor is a power hungry battery killer as it has to heat its sensor coil to get a reading, but I wanted it for the cool factor for the presentation (gas sensors in the petroleum industry always perk up interest). Perhaps after the presentation I’ll take the gas sensor off and see how much more I can drop the power requirements and even try with some different mainboards and see how much of a different that makes as right now I’m using a Spider. I just thought it would be interesting to throw ‘power’ out there for conversation.
I’ll try to remember to post this project (base device and remote device) to code share so other folks can play with it.
I took the easy man’s method and simply measured the current the power supply (wall wart 12v 1.2A) was supplying to the device. Given all methods were using the same power supply setup I thought it was a reasonable compare for discussion purposes.
Excellent write up.
theres already a thread about power somewhere, imho the main stumbling block for net mf and internet of things, Im going to play with a msp430 but geez I will miss the mf environment.
I think there is a couple of tripping points for IoT and power would be on that list, as well as configuration, connectivity and remote update are also problems that don’t have easy answers yet. Also it seems that communication protocols get more and more complex or otherwise bigger, and more and more convoluted and yet less and less security. There is a head shift coming that will better fit IoT. What IoT devices do might be simple and small, but all the pieces required to support that are neither simple or small.
The more I read these kind of messages I mire I think an arduino gadgeteer board is a must have… Check out my other thread on the forum…
@ Duke Nukem - To your list I’d add size and cost.
@ godefroi why would I want to that?
To the list you posted, I’d add size and cost as issues facing IoT. The more you can drive these down, the more “things” will show up on your “internet”.
I see Gadgeteer as a huge cost savings, while the modules etc cost more, I can assemble prototypes and code them up far faster than I could any other way and at my billing rate that means big cost savings. Cost of production runs and getting prototypes to final production builds is a huge problem for every platform.
I don’t see size as an issue initially given the objective is to take a Gadgeteer prototype and hand it over to @ Gus or someone like Gus and have them reduce it down to a single board for run production (was talking to someone today about that). You can tune your sizing a bit depending on how much money you want to spend on components and manufacturing. The same approach can be made in helping with power etc. Hardware dudes never cease to amaze me with how creative they can be building a given device when it comes to layout and component selection and perhaps that does feedback into code changes or creating additional drivers/wrappers etc but that is a good thing if it makes the final result better.
Ultimately the more Gadgeteer modules there are, the more things I can prototype (I have a lot of mainboards, modules etc), hopefully someday we get to the point where going from prototype to production is easier with Gadgeteer given we are working with known modules and perhaps even someday we can even automate that step where it takes your design and it churns out a production ready layout (the ultimate Visual Studio plugin for the designer). In short I have a dream…
@ Duke Nukem - I guess if your ultimate goal is large scale production. For wiring up my own house, though, they’re bulky and expensive.
Commercial offerings are normally what I’d classify as “horrifyingly expensive” though often sized conveniently, the BOM isn’t usually much of an influence on cost.