Particle Electron Power Consumption Analysis Suyash Kumar July 6, 2016 All, DIY 4 Comments Particle Electron Power Consumption How much power does the Particle Electron consume? When designing a solar-powered IoT project, it is always important to have a good real-world sense for how much power your devices are going to use. I hadn’t been able to find good data on the Particle Electron’s power consumption across its different sleep (and transmitting) modes, so I decided to go ahead and gather some data myself. I’ll summarize high level findings below, but read on for more information about how these tests were done and for access to the raw power data (sampled every 1s). The solar weather powered weather logger from a previous blog post was used as a test bed for this project (pictured below). TL;DR Results Please also see discussion and detailed results sections below to get a better idea of power use and tradeoffs. Mode Mean Power Use (W) SLEEP_NETWORK STANDBY 0.27 System.Sleep 0.08 SLEEP_MODE_DEEP [Not Measurable] Transmit to ThingSpeak (POST) 0.70 Transmit to Particle (Publish) 0.53 (but for long durations, see detailed discussion) Note that when using System.sleep and SLEEP_MODE_DEEP, significant (several kB) of data needs to be used to reconnect to the network on wake. Mode Avg Transmit Duration (s) Energy per Transmit (W*h) Particle Publish 51.67 0.0076 POST to ThingSpeak 11 0.0021 Note that there are 2 second stabilization delays in each of the transmits measured in the table above. Methods For these tests, I used a Drok USB power gauge to measure power consumption by a Particle Electron without its sidekick LiPo battery attached. A video of the setup was taken, and the voltage and current information was extracted from the seven segment display in the video using an image processing library I wrote. The raw data (sampled once a second) was then fed into Matlab along with time intervals during which the device was actually awake (manually extracted by watching the videos). A Matlab script was then used to gather various statistics from the data. The analysis scripts, raw sampled data, and analysis output can be found on Github here. Three trials were performed: Sleep_NetworkSTBY_Particle (use the SLEEP_NETWORK_STANDBY sleep mode and use particle.publish) Sleep_Network_STBY_ThingSpeak (use the SLEEP_NETWORK_STANDBY sleep mode and send data to ThingSpeak) Sleep_ThingSpeak (use the basic System.Sleep mode and send data to ThingSpeak) All trials first waited 1 second, took and transmitted temperature and humidity measurements, waited another second, and then entered their respective sleep modes. The exact code can be found here. Analysis Results Detailed analysis results with mean power use (and standard deviation) for each awake and asleep interval can be found in the analysis text files here. Discussion Clearly SLEEP_MODE_DEEP saves the most power on the Electron, but it comes at the cost of being unable to save much data while in sleep (when it wakes up, it wakes up as if from reset) and at the cost of spending several kB of data every time it wakes up to reconnect to the network. This is probably the best mode if you transmit infrequently and don’t have to hold anything in memory (say, you just wake up to take and transmit a measurement before going back to sleep). Next is the typical System.sleep() call, which shuts down the modem and puts the processor into a halt mode. This uses less power than leaving the modem on and holds information in memory but still must spend data reconnecting to the network when it wakes up. This is a good middle ground up from the deep sleep mode. Finally we have the sleep mode with SLEEP_NETWORK_STANDBY enabled. Sleep mode halts the processor but does not turn off the modem and leaves the connection live. This mode uses much less power than when fully operating (up to ~0.35W less) but does not have to use data reconnecting to the network on wake. This mode is ideal if you need power conservation, transmit often, and/or have a tight data budget. Something else worth discussing is the trade-offs between Particle.publish and sending HTTP POST data to a service like thingspeak. In these tests, publishing to particle used less power (avg 0.53 W) but it took much longer to transmit (up to 71 seconds vs. ~15 seconds), though this could be because of modem re-connection times (future tests without re-connection could confirm this). It is also reported that Particle.publishes use less data than HTTP POST requests likely because they use streams. 4 Responses Bryce Loop September 9, 2016 How much data were you sending per publish (Why were your respective publish times so long?) Reply Andrea Poma February 26, 2018 Hi Suyash, I have a sunpower 4.4v 4.4w 1A panel. The output is 5.2v and 0,7/0,8A. I attach a lipo 3.7v 2.4A battery and a pcb usb. Everything seems working fine when I’m trying to chage a standard smartphone and after few hours the phone is full, only the battery is lasting much less compared with wall charger (50%). Do you know if could be related to the low voltage of the panel, the isolation of wires, or the quality of the pcb (consider I have tried with several ready-made pcb with same results) or it is normal the charge quality is such worst when using 3.7v battery? Thanks in advance for your help Reply Voltaic Systems February 26, 2018 Hi Andrea, There are a lot of variables here and it is out of scope of the Particle discussion. Here are a couple of places to look for more information: https://www.voltaicsystems.com/blog/lithium-ion-charge-controller/ https://www.voltaicsystems.com/blog/direct-charging-solar-review/ Reply Andrea Poma February 26, 2018 Thanks Suyash, I really appreciate your help. I will ask there Leave a Reply Cancel Reply Your email address will not be published.CommentName* Email* Website This site uses Akismet to reduce spam. Learn how your comment data is processed.