I can not find anything in the documentation that says you can but I am desperately hoping there is a way to do this that someone knows about!! I messed up big time! I didn’t realize that system.sleep leaves the 3v3 pin high (I should have known this based on its description). Anyway. I have a remote solar powered project that updates a LOT. the handshaking associated with deep sleep proved to be a bit high, so I switched to regular sleep. During summer our beta test units where swimming in power. But now that fall is here I see we are using way too much power. The issue is I was lazy and powered all the sensors off the 3v3 pin I am really hoping these is a way to do this. Although its not a complete loss, our units can all be salvaged, but it will require some serious white wiring Along these same lines: Can anyone confirm that 8mA is available on each GPIO pin up to ~200mA total, thats what I am reading, would like to confirm.
I would also like the send yet another thank you to ScruffR for alerting me to the fact that my units were drawing way way too much power via publishing his observed battery life on an unrelated thread which tipped me off to my own stupidity!
@SirT, not sure about turning off the 3.3v on the Electron but the STM32 can supply a max of 25ma on a GPIO pin with a total package current of 120ma. The best way to control the 200ma of current to your peripherals is to use a MOSFET controlled by a single GPIO pin. I believe another member asked this question in another post:
Thanks ScruffR and peekay123! I’m only pulling down 3 to 5 mA of current with my sensors so I will go to what I should have done to begin with and drive the sensors off a GPIO pin.
@SirT, one little thing to remember is that when the Electron goes into deep sleep, the GPIO pins will “float”, ie. neither high or low is guaranteed. This may not be an issue for your peripherals but do keep it in mind.
@frlobo peekay123’s idea would have been good if I had caught my mistake early in the design phase. However, at this point the first round of PCBs are fully populated and installed in their housings so adding a new component is not desirable. I thought I might run into this type of snafu so during desigh I DID take two GPIO pins to my external connector and leave them unconnected. As such I can fix this issue with a single trace cut and adding one jumper wire to the back of my connector, so not too bad! Also, my sensors draw such low current that I don;t need a FET to switch the higher current 3v3 pin, I can get away with powering them off GPIO pins (less components to buy).
@SirT, powering off a GPIO should be ok if you draw less than 20ma. Please do let us know how your fix works. It would also be nice to know what kind of sensors you are powering for other members who may want to do the same. I might change the title of this post slightly by taking out the (please say yes) part and replacing it with “alternate solution found” or something.
@peekay123 Sure thing! You guys have been a great help so anything I can do I’m game. The two OTS sensors I am using are:
HX711 load cell amp:
and the SHT10x temp/humidity:
Plus one more custom job that only draws uA.
The load cell I am using with the amp also draws uA separately. So total current is less than 1.5mA for the load cell amp plus some number of uA for the others. So even adding a fudge factor for in-rush I should be fine with a single GPIO pin as supply for all these.
Hmmm. Well I implemented this change on a unit and it now takes up MORE power not less. Before I was losing 0.3% SoC for each turn-on, read, and publish loop. Now, I am losing 1.1% each time, almost 4X more! Thats the opposite of what I expected and does not make any sense Im setting the pinMode to OUTPUT and setting it high, then setting it back low at the end of the loop. Is there something I am missing, is there some inefficiency I am missing? Is it powering through an internal pull-up or something (I didnt think they was the case in OUTPUT mode)? This is a very unexpected result.
@SirT, that is weird. I would need to see your schematics to see if there is an unplanned return path. Let me remind you that GPIO pins in deep sleep mode don’t keep their states so there may be a path to 3.3v via the pin.
Ah HA!!! @peekay123 you were very close! It was the code for the temp sensor. SHT1X.ccp was leaving the data pin in OUTPUT mode and HIGH. This was feeding back through a pull-up. That may be the most useful piece of info anyone else gets out this thread! The SHT1X import code works amazingly well but it does have that little fluke about it
did it you fix that issue? Did you successfully reduce your power-consumption?
anyway, is it really necessary to stay online all the time?
I have a solar-powered monitoring application that wakes up, makes a quick check.
If the value changed (and beeing verified …) the electron pushes the data.
If the value is (almost) the same, the electron stays offline (or even goes into deep sleep)
If the value didn’t change for a specific time (lets say 1 hour) we go online anyway:
Hey, I’m still here! Is there any firmware update for me?
If the battery is low, we may stretch the sleep period and allow longer periods of offline cycles
Anyway, what kind of solar panel and battery did you use?
I use a 6V 4.5W mono panel, even during foggy days it fully charges within hours. I switched to a 18650 cell with 3400 mAh, with the power-saving methods mentioned above I reach up to 3 weeks of monitoring without a solar panel.
@joky
I did! I was able to reduce my power consumption by about %30 by switching to GPIO control instead of running off 3v3 One thing I had to do was at the end of my code, I changed all GPIO pins to Output and set them LOW. It seems like system.sleep lets a pin float a bit if it is left as in Input. Now I am losing 0.3% SoC every three updates instead of every update (my updates are every 20 in so this is huge). I am using the LiPo battery that comes in the Electron kit and two of these:
They charge up very well and very fast. The reason power management became such an issue is we are trying to operate during Seattle fall/winter conditions
One thing I will take a closer look at is my use of SLEEP_NETWORK_STANDBY. Given my updates are every 20 min we are sensitive to the data cost of any handshaking, but I think me using this is taking a pretty big power hit. So I really need to balance power vs data optimally.
I am really hoping these is a way to do this. Although its not a complete loss, our units can all be salvaged, but it will require some serious white wiring 
