4 ms·

The steady-state static draw is the current consumption that is always there even if nothing is going on. Everything else that happens is added on top of it, so

The steady-state static draw is the current consumption that is always there even if nothing is going on. Everything else that happens is added on top of it, so to speak. When the microcontroller is at sleep it will consume a certain amount to current to eg keep registers and RAM intact (otherwise it would become corrupt). It is also due to leakage currents from capacitors, and any leakage that might go out through GPIOs. Sensors also have a static draw when not in use. Batteries self-discharge. And so on. For example, a cc1310 system on chip has a 0.8uA current consumption when in deep sleep, but the real static draw is more than that. Periodically, the chip will run a little charge pump to energize RAM so that it doesn't evaporate (metaphor). There might also be a timer active, and that consumes 100uA. And so on. When the device wakes up to run at 24 MHz, it uses about 1.9mA, plus any peripherals (SPI 13+93uA, timer 113uA), plus any sensors or other hw peripherals. This might be very very short amount of time, like 10 ms every two hours-kind of short. So it turns out, that for a device that wakes very rarely, the static draw can be a significantly decrease lifetime. It's small, but it is _always_ there. It is hardware-dependent and is the "black art" within embedded development. It's very easy to reach arduino-levels, pretty easy to start using low-power modes, time/money-consuming and requires expertise to squeeze the last years/months out of the battery.

jcun4128 9y ago
Oh man thank you very much I' just starting to get into hardware/embedded systems coming from web and this is so cool. I don't know if this is uncool to ask I'm also late a few days to respond. With regard to connection to the web generally (to my knowledge) you need some way to communicate say send a POST request to some API and I'm not sure if this means that you need an OS which when I think of an OS you need to keep it on or even with sleep... I don't know. I don't know if you can design hardware/firmware meant to interface with the web, still be programmable and simple/light on resource without a full blown OS like raspberry pi. Anyway thanks much to learn.
- retSava 9y ago
  No problem, I'm happy to share what I've learned! Yeah, connecting to the web can be stressful to a small device, but it's very feasible. A basic OS that handles timers, a communication stack, a way to abstract tasks and communicate between them, can be quite small. Contiki OS for small devices can run on tiny devices - the amount of RAM and flash and CPU speed isn't much a limiting factor until you start with communication. Then you want RAM to hold queues of packets, neighbor tables, etc. You want flash to hold the code necessary to use the protocols you need. We support a range of devices at Thingsquare, eg the cc1310 with 128kB flash and for that we have space for a full-fledged IPv6 stack and all that's necessary for low-power wireless (ie specific radio duty cycling protocol, routing protocol, etc), our own libraries and abstractions to make it simpler for customers to use the system, with room left for customer application and drivers. Contiki OS is event-based, ie when it is not actively doing something, it simply waits (for something to happen on a physical pin, or radio event, or timer expiry) and can go to sleep. That way, and with lots of hard work to make everything efficient on every level, you save power. Raspberry pi and similar ones makes it simpler (lots of developers know the stuff, linux, etc) but has drawbacks (power, complex system, lack of low-level control and kernel timing requirements might not suffice, cost, IP, in some cases security, licensing, etc). Have a look at these: http://www.thingsquare.com/blog/articles/sensortag-power/ http://www.thingsquare.com/blog/articles/sensortag-power/ and http://www.thingsquare.com/blog/articles/ti-cc1350-power-consumption/ http://www.thingsquare.com/blog/articles/ti-cc1350-power-con...
  - jcun4128 9y ago
    Thanks a lot for the info/resources a lot of this not familiar to me at this time. The queues if packets/neighboring tables,etc... Yeah it's much easier from my lerspective/experience tojust throw on Python/PHP on there and do stuff granted that's more "webserver" I didn't mention databases but you could just write to filesystem (txt) and my intent was transmission. Contiki OS sounds cool Anyway I'll refer back to this post, thanks.

jcun4128 9y ago

Oh man thank you very much I' just starting to get into hardware/embedded systems coming from web and this is so cool. I don't know if this is uncool to ask I'm also late a few days to respond. With regard to connection to the web generally (to my knowledge) you need some way to communicate say send a POST request to some API and I'm not sure if this means that you need an OS which when I think of an OS you need to keep it on or even with sleep... I don't know. I don't know if you can design hardware/firmware meant to interface with the web, still be programmable and simple/light on resource without a full blown OS like raspberry pi. Anyway thanks much to learn.

retSava 9y ago
No problem, I'm happy to share what I've learned! Yeah, connecting to the web can be stressful to a small device, but it's very feasible. A basic OS that handles timers, a communication stack, a way to abstract tasks and communicate between them, can be quite small. Contiki OS for small devices can run on tiny devices - the amount of RAM and flash and CPU speed isn't much a limiting factor until you start with communication. Then you want RAM to hold queues of packets, neighbor tables, etc. You want flash to hold the code necessary to use the protocols you need. We support a range of devices at Thingsquare, eg the cc1310 with 128kB flash and for that we have space for a full-fledged IPv6 stack and all that's necessary for low-power wireless (ie specific radio duty cycling protocol, routing protocol, etc), our own libraries and abstractions to make it simpler for customers to use the system, with room left for customer application and drivers. Contiki OS is event-based, ie when it is not actively doing something, it simply waits (for something to happen on a physical pin, or radio event, or timer expiry) and can go to sleep. That way, and with lots of hard work to make everything efficient on every level, you save power. Raspberry pi and similar ones makes it simpler (lots of developers know the stuff, linux, etc) but has drawbacks (power, complex system, lack of low-level control and kernel timing requirements might not suffice, cost, IP, in some cases security, licensing, etc). Have a look at these: http://www.thingsquare.com/blog/articles/sensortag-power/ http://www.thingsquare.com/blog/articles/sensortag-power/ and http://www.thingsquare.com/blog/articles/ti-cc1350-power-consumption/ http://www.thingsquare.com/blog/articles/ti-cc1350-power-con...
- jcun4128 9y ago
  Thanks a lot for the info/resources a lot of this not familiar to me at this time. The queues if packets/neighboring tables,etc... Yeah it's much easier from my lerspective/experience tojust throw on Python/PHP on there and do stuff granted that's more "webserver" I didn't mention databases but you could just write to filesystem (txt) and my intent was transmission. Contiki OS sounds cool Anyway I'll refer back to this post, thanks.