Power Off Sleep Circuit based on Real Time Clock (DS3231)

@zander

I think you are still a little confused as concerns the pico.  It does not matter one iota if the pico can be put into a very low powered deep sleep or not because we are not sleeping the pico at all,  the power is being entirely removed.   As such, the pico is ready for having the power removed right now and any future improvements that may be made to its deep sleeping are not relevant to the Davee circuit.

Whilst I did my testing in Python code, @davee showed some example C code to do the same thing, also on a pico, so yes its all programmable in C.

I enclose a picture of the circuit I put onto a pico breakout board (one from pimorini) that is squeezed between stacking header pins/sockets so that it can be directly mounted above or below the pico.

You may notice on my picture there was a usb micro port on the other end where the DS3231 board is attached,  (the DS3231 plugs into some right angles header sockets),  but sadly the blooming usb thing dropped off its backing board putting a temporary end to my longer term testing.  That usb board needs to be desoldered and replaced with a couple of wires to hook the battery to. 

Dave has very kindly sent me some more mosftets attached to backer boards and I intend to build another pico board similar to the one pictured but with a stouter usb or some other suitable connector for the battery power.  I will also make a more generic circuit board on an adafruit proto board to hook up any mc board

I was aware that the bat input to the DS3231 board could be powered but other batteries than the coin cell battery and that the bat circuit could power the DS3231 i2c circuit as well as a VCC, but as the object of the exercise is to awake the pico, and the pico (or other mc)  needs to issued an i2c command to close off the power then it makes sense to keep the i2c power being supplied via the 3V out of the pico to the VCC pin on the DS3231 board as its readily available. (at least on the DS3231 boards we used)

I think you are certainly right to say the Chronodot is a much better board to use and it would not have to be hacked (just augmented) but it does cost over 4 times as much, at least for the ones I looked at that are readily available to me in the UK. (but I think there are some Chinese clones of the Chronodot board too, and these are probably a bit cheaper.  One thing that may be of use with the Chinese DS3231 boards that we have to hack is that they come with an eprom that could be used to store data over power off cycles if desired.

The longer the time between needing the power to the pico (or whatever) then the more power saving is made with the power off technique as opposed to deep sleeping.  If you only need power once a day say, then you gain a days worth of whatever the deep sleep power current may be.  You seem to be going for the ultimate of seeking a lowest powered mc that does not even have a boot-loader.  Good luck with your alternative circuit designs, keep us posted on what you come up with.

@byron Not confused. I envision different requirements that include both the Dave circuit and a conventional RTC low-power circuit.

I am in awe of your soldering ability. I usually make a mess between needing glasses and 3.5X magnifiers to see, plus one hand to hold my shaking soldering hand. 

It's not so much that I NEED a conventional circuit, I freely admit Dave's circuit is the champion. You can't get lower than 0A. The recent postings were more for any followers that needed a conventional low-power solution, and I may need both. There may be times when I want to totally turn off a camera at a specific time, and other times, I need the camera board on so that motion or heat sensors can trip the camera. Having more tools in the bag is always nice than what may get used just in case.

Posted by: @zander

↑

I am in awe of your soldering ability. I usually make a mess between needing glasses and 3.5X magnifiers to see, plus one hand to hold my shaking soldering hand. 

Ah well, you did not see the magnifying headband thingy,  the smoking mosfet in my first attempt due to soldering up a wire in the wrong place, and fortunately you were not in earshot to hear a few ungentlemanly words being uttered. 

Hi Ron @zander,

PS> As usual, an entire conversation has appeared in the time it has taken me to type one answer, so there is are a couple of overlaps, but I don't see any disagreements, so please accept both @byron and I have made overlapping comments.

  Re:  do not know if the Dave solution even works on a PICO programmed in C 

The example code I gave at the start of this thread was all C++.

-------------------------

solution is only usable with an MPU/MCU that can be turned ON quickly enough.

The use case assumed was that the DS3231 would be programmed to boot the processor at the required time ... if the MCU takes (say) 3 seconds to boot, and the timing is critical, then surely it is trivial to set the DS3231 alarm to start the boot process 3 seconds early.

---------------------

re:

I2C Interface
The I2C interface is accessible whenever either VCC or VBAT is at a valid level.

I only watched the opening bit of the video, which talks about disconnecting the VCC pin. The aim of doing this is to reduce the continual current drain by DS3231 from the external MCU power (e.g. the Arduino or Pico battery). (I think they needed their MCU continually powered for low level data logging, which is a different use case)

This is a valid approach if your MCU is always powered, but it is totally unnecessary with the solution I proposed. Because I remove all power from the MCU, the only time power is applied to the Vcc pin is when the Pico is powered, and the DS3231 Vcc current drain is minute compared that of the Pico, and by definition is a very low proportion of the elapsed time. So disconnecting the DS3231 Vcc pin would have an insignificant effect on battery life with the arrangement I proposed.

So knowing that the Vcc may be left 'disconnected', eventhough the chip designer obviously thought it was a good idea to build the connectivity into the chip, doesn't make any difference to my (Byron's originally) use case.

-------------------------

Personally, I only built a quick prototype as a 'proof of concept' demonstrator, basically to @Byron 's requirement of a system that booted the MCU, and completely powered it off in between. I tested it with a Pico, which again was in line with Byron's plans, albeit he wants to use the Pico W, to provide WiFi during its 'wake' periods.

-----------------------

The DS3231 card described was available locally at under £4 delivered, including the coin cell, and only took a few minutes to remove the unwanted components. I do not require any single pin lifts, which is feasible, but trickier than simply removing resistors.

It may not be the prettiest solution, but it works and I couldn't even buy the parts to put them on a homebrew PCB for that. However, most of the findings of my short study should be easily transferable to any similar implementation, including Chronodot. 

--------------

Obviously there are lots of other things that can be considered depending on the specific project.

In some circumstances, it may be useful to have the MCU in a low power state for logging data, but that was not my aim here.

In other circumstances the 'usual' Arduino or Python environments may bring a lot of unneccesary baggage, so reducing or replacing the boot code is a perfectly valid project extension that could be appropriate to almost any MCU.

They are beyond the scope of what I decided to look at, but obviously I am delighted that you have been able to find some interesting research to expand on. I am sure there will be interest in whatever you decide to build and publish.

------------

And as a PPS, note that the approach I have suggested could be extended to include 'wake up' events from sources other than the DS3231. The complexity and capability would depend upon the specific source and its characteristics. Of course, any processor will take a little time to boot, though putting numbers to the amount of time required is another study in its own right. Clearly, this approach is unsuitable for something needing an 'instant' response.

Take care and best wishes, Dave

@davee Dave, I am not sure why you feel the need to reply, my comments were just an addition to the knowledge bank. We all agree your solution like all similar solutions, is the least power solution. There may be followers of the topic who need a low power but not off solution like me and I was adding to that knowledge bank.

In my use case, I may use both a conventional RTC as well as a totally powered-off solution. I suspect that will mean 2 RTCs, but I haven't looked at it closely enough to be sure. I might get by with a single RTC if I can implement a camera using a PICO with a working sub mA power drain or another chip with similar specs.

The example I mentioned is an example of an always-on but at low power and appears to be the champion of that approach.

I hope our combined research benefits others as much as it has benefited me.

@davee Dagnabit, I see where my fuzzy brain messed up again.

It would be ideal if the power-off method could be triggered to turn on by one of several sensors, let's say, a radar motion sensor and/or a heat sensor. The turn-on would need to be very quick, let's say a second or so because an animal such as a fox trotting across the sensor path at slightly more than a human walking speed of 5 ft per second would be mostly out of frame. Obviously, this will depend on 2 factors, angular speed across the sensor path and distance from the camera. My gut feeling is the camera needs to fire in less than 2 seconds from the fox tripping the sensor. Game trails tend to be fairly narrow so the camera will not be able to be placed very far from the target path, maybe 6 ft but could be as much as 10 and as little as 2.

I hope this explains my use case better. Obviously, there is no need for an RTC in this case unless it is deemed useful to have the camera armed for only certain time windows each day.