Like many forum visitors, I’m developing a battery-powered Imp project. In order to select an appropriately sized power source, I need to know what level of current is drawn and for how long. The basic current drawn by the Imp is defined in the spec as follows:
Mode 1 (M1): sleep, 6uA
Mode 2 (M2): 5mA typ, 400mA max for 4.8mS
Mode 3 (M3): 80mA typ, 400mA max for 4.8mS
From the information above I assume the steady state current draw will be no more than 6uA in M1, 5mA in M2 and 80mA in M3. Cool, I can design to that no worries.
My confusion on the current draw topic relates to the 400mA max for 4.8mS spec, specifically when and how often this occurs. I’m not entirely familiar with Imp operation but I assume current draw would change depending on what the Imp was trying to do: connect to an access point, transmit data, receive data, disconnect from an access point etc. This was handy but it’s for a competitors device: http://www.rtx.dk/Files/Billeder/RTX_T/RTX411%20Documentation/RTX4100_Application_Note_Current_consumption_AN1.pdf
I spent many hours today searching the Electric Imp website for definitive guidance on what current is drawn when however I’ve come up more-or-less empty handed. Does such a document exist?
The peak current spec for the imp001 is padded, to allow for future card revisions to use more power if necessary (ie, if you’re designing a slot, we recommend 400mA capability).
If you look in the imp002 spec, you’ll see that the peak current for that is 250mA; this is actually what an imp001 takes. The time you will see this for 4.8ms is during maximum packet size transmit at 802.11b 1Mbps modulation.
The RTX appnote is very nice. We have plenty of internal measurements for wake times, power profiles, etc but no pretty doc like that. We should probably make one!
btw, our testing with a full measurement cycle (wake, connect to WPA2, DHCP, DNS, TCP, TLS, send data to server and sleep), measured in our office, it’s around 0.1C per cycle.
Thanks for clarifying the peak current spec, I’ll use 250mA in calcs then.
0.1C? Charge? 0.1 A for 1 sec?
Indeed, as if you didn’t have enough to do, here’s killer Imp app note for the todo list :
oscilloscope captures, timings and average charge requirements for best/typical/worst case draw for all states in the Imp state diagram.
cycle repetition timings (frame intervals) for regular events (e.g. how often does the Imp transmit when connected to an AP in the Active or in the power save mode (an Active sub-state?, it’s not shown in the state diagram), I imagine the internal timing of the burst transmission would be documented in point 1).
average charge requirements for all functions that have an appreciable affect on current draw (e.g. power save mode).
With the above developers could potentially build a power budget based on how they intend to program their Imp which would make specification of power supply requirements much easier. The only options available to developers of low power projects I can see at the moment is to:
A/ rent an oscilloscope and code, measure, code, measure, then specify power source requirements, or
B/ perform calculations based on specs, prototype and perform long term operation/power source verification tests, redesign, prototype, perform verification tests and so on.
Point A is easily achievable if resources are readily available and will yield the best results. Point B may be a costly exercise as well, depending on how lucky you were with your first round of calcs (you might be in the ballpark).
Am I off with the fairies? Is there a simpler way?
It’s a bit hard to do best/worse case on imp states, because the power consumption will vary with code, and “worst case” SoC power is a hard thing to predict even on simple setups - eg it’ll depend on exact peripheral use and code sequences. You have to test your application.
In terms of “regular events”, imp-initiated ones are so infrequent and small that they are essentially noise. However, if you are in powersave mode and the network you’re on has a lot of broadcast traffic… that’ll take some power. How much depends on how much traffic and the intervals. Again, this makes more difference than anything under the imp’s control.
Really, option A and B is what you need to do to make a good product. There’s no substitute for testing. For the first 5 iPhones I owned the power budget, so I’m very familiar with battery life estimation…
