3 ms·

Such a solar panel is quite large/powerful and you can drive quite a lot on that, depending on how and where you deploy it. One of the most important factors on

Such a solar panel is quite large/powerful and you can drive quite a lot on that, depending on how and where you deploy it. One of the most important factors on how to make it live longer is to limit the steady-state static draw (ie ensure you go to sleep modes properly etc). Plug, but _just now_ our related post got to the first page: https://news.ycombinator.com/item?id=15354741 https://news.ycombinator.com/item?id=15354741

jcun4128 9y ago
Can you expand on that "limit the steady-state static draw" Don't you need to keep draining power produced by solar panels? What about the heat problem and decreasing efficiency of solar panels?
- retSava 9y ago
  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

Can you expand on that "limit the steady-state static draw" Don't you need to keep draining power produced by solar panels? What about the heat problem and decreasing efficiency of solar panels?

retSava 9y ago
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...