A solar supercap powered Moteino (15Farad charged by BQ25504)

[WhiteHare]

BTW I think you might need to protect against the power-up condition between 0V and 0.95V accidentally turning on the load switch (see figure 13, the shaded bit at the bottom). If that happens the main FET is turned off and it will stop charging and remain in that state.

Does the attached, revised schematic show the proper placement for the diode and resistor that you have in mind?

[perky]

Yep, if you use a silicon diode that would mean it needs at least 0.7V plus the load switch gate threshold before it will turn on.

Mark.

[WhiteHare]

I'm guessing that a suitable n-channel mosfet might work just as well as the load switch.  If I can find one of the spare ones I already own, I'll give it a try.

Beyond that, I'm just waiting for the breakout board to arrive for the Perky smart diode to see how that might fit into this.

Regardless, I'm quite pleased with how this has turned out.  I feel as though we are finally near the end.  Thanks for all your help! 

[WhiteHare]

Interestingly, SII also makes a voltage detector chip with a voltage sense pin that's separate from the chip's Vcc pin:  https://www.digikey.com/product-detail/en/sii-semiconductor-corporation/S-1002CA27I-M5T1U/1662-1084-1-ND/6601224

Now, SII's S-1000 voltage detector chip (which is what I last used in the prototype) allegedly has a current consumption of just 350na, which is supplied by the supercap.  In contrast, the S-1002 allegedly consumes 500na.  However, I wonder whether the S-1002 can be powered by the solar panel, while only its sense pin is wired to the supercap, and, if so, whether in that case the current drain on the supercap might be even lower than 350na?  350na isn't big compared to most supercap's, but since I'd like the Moteino to be able to run almost instantly (albeit briefly) after being exposed to even dim sunlight, I foresee using a much smaller cap as the startup cap that the Moteino might initially run from.  In that context, a constant drain of 350na on a much tinier cap might not seem so small....  So, for that reason, I think the S-1002 might be worth investigating.

[perky]

I'm guessing that a suitable n-channel mosfet might work just as well as the load switch.

A simple N-channel FET won't work I think, you need to turn off the top pass FET when there's a high on the comparitor's output. The load switch is a good solution. An interesting project.

Mark.

[WhiteHare]

Interestingly, SII also makes a voltage detector chip with a voltage sense pin that's separate from the chip's Vcc pin:  https://www.digikey.com/product-detail/en/sii-semiconductor-corporation/S-1002CA27I-M5T1U/1662-1084-1-ND/6601224

Now, SII's S-1000 voltage detector chip (which is what I last used in the prototype) allegedly has a current consumption of just 350na, which is supplied by the supercap.  In contrast, the S-1002 allegedly consumes 500na.  However, I wonder whether the S-1002 can be powered by the solar panel, while only its sense pin is wired to the supercap, and, if so, whether in that case the current drain on the supercap might be even lower than 350na?  350na isn't big compared to most supercap's, but since I'd like the Moteino to be able to run almost instantly (albeit briefly) after being exposed to even dim sunlight, I foresee using a much smaller cap as the startup cap that the Moteino might initially run from.  In that context, a constant drain of 350na on a much tinier cap might not seem so small....  So, for that reason, I think the S-1002 might be worth investigating.

More good news.  I just now tested out the S-1002 by powering it from a bench power supply at 2.5v and connecting the sense pin to a supercap.  It passed the first test, which is that it does work as expected as the voltage detector that it's meant to be: the output sense pin has the expected voltage on it depending on the supercap's voltage.  More importantly, though, I measured the current flowing into the sense pin from the supercap using the Dave Jones's uCurrent Gold, and it was only 73na.  That's a nice improvement over the alleged 350na of the S-1000 or the alleged 500na of the NCP300.  For that reason, and for only a few cents more than the S-1000 voltage detector, I think I'll go with the S-1002.  I can always choose cheaper parts later if it turns out to be complete overkill for the startup cap scenario, but this should help keep things as tight as can be in the event that's what's needed. 

[WhiteHare]

I built a new prototype that incorporates the S-1002, such that the S-1002 is powered by the solar panel rather than the supercap (as described above).  Works as expected.     Photo attached.

So, as of now, the current drains imposed upon the supercap (i.e. reverse current flow through the diode and current flow into the voltage detector's sense pin) are minuscule.

[WhiteHare]

I want the capacitor with the smallest capacitance that's still sufficient to serve as the startup cap, because the smallest capacitance will take the least amount of time for the solar panel to charge.  Unfortunately, the bootloader is getting in the way: it's slow and just takes far too long to realize when nothing is going to be uploaded, and all the while the atmega is running and draining the startup cap.  So, at least for now, it appears I'll need to excise the bootloader so that I don't need an oversized capacitor just for the atmega to stay alive long enough to get past the bootloader phase.

[perky]

Can you use a spare pin on the MCU and replace the timeout waiting for serial activity with a read of that port state? You'd need to fit a link when loading but it'll be super quick to boot.

Mark.

[WhiteHare]

That would work.  Has anyone already done that and posted it, or would I have to hack the bootloader code?  My earlier thought was that just excising the bootloader would be the easiest solution, but I'm open to alternatives if they're equally easy.

[WhiteHare]

So, at least for now, and for expediency, I decided to excise the bootloader.  As an experiment, though, I wrote a simple sketch which does only one thing, and that is turn on the LED that's on pin 9.  With no bootloader installed, I expected it would turn on almost instantaneously after I applied power, but actually not.  There's still a significant delay between applying power and the LED lighting up.  Not sure what that's about.  I guess that's just unavoidable delay when atmega328p powers up?  Very annoying, to say the least.

[Edit1: I just now used an o-scope to quantify the problem.  Between power-on and the LED lighting up, it is 2.1 seconds.  Argh.  So, I may have been wrong to blame the bootloader for the long delay because it's a 2.1 second delay even with the bootloader removed from the equation. 

In case it matters, the fuse settings I'm using for the atmega328p are: 0xFF 0xDA 0xC2  ]

[Edit2: The datasheet seems to only talk about startup times with BOD enabled.  However, my BOD is disabled, and I'm running from the 8Mhz internal resonator clock.  I wonder if it would start up faster if I gave the atmega328p a reset immediately after applying power to it?    If BOD were enabled, then the startup time would be just 6 clock cycles, according to the datasheet (see Table 13-12 of the DS).  On the other hand, I don't know whether it's the chip that's slow to power up, or whether the compiler generated some weird code that adds further delay that's not in my source code.  I suppose I could try enabling the BOD through the fuse settings and see if that makes any difference...] 

[Edit3: Nope.  Setting fuses to enable BOD at 1.8V didn't reduce the apparent startup time.]

[WhiteHare]

Good news!  After installing Optiboot 6.2, pin 9 now goes HIGH almost instantly after applying power.  No bootloader hacking required.   

According to Bill Westfield, who is the maintainer of Optiboot, "The optiboot bootloader has a 'fast start' feature that causes it to bypass the bootloader for a reset cause by poweron. "

[Edit:  Measuring it on an oscilliscope, using Optiboot 6.2, it now takes 15ms from the event of applying power to the event of pin 9 going HIGH.  I figure that's 120,000 clock cycles (i.e. 15ms divided by (1/8,000,000)), which nonetheless still seems rather high, doesn't it? ]

[ChemE]

Time to hack together Optiboot 6.2.1 then 

[WhiteHare]

Time to hack together Optiboot 6.2.1 then 

I had some further exchange with Bill Westfield after my last post, and he says, "Optiboot does the power-on check VERY early, so almost all the startup time is consumed by the hardware reset and oscillator start (controlled by the fuses)."  So, I take that to mean it's already very close to optimal.

Now for the really GREAT NEWS:  With Optiboot 6.2 installed, I was able to power up an ATMEGA328p--and by that I mean, from completely powered off to pin 9 going HIGH--from a mere 1,100uF capacitance charged to 2.0v.  Well, why is that great news?  Because my mini solar panel can charge that 1,100uF of capacitance to that voltage in the blink of an eye.

Now for the ultimate question: how much charged capacitance will I need to not only start the ATMEGA328p, but also send the first packet on the RFM69?  I haven't yet done that experiment, but that's where I'm heading with this.

[perky]

Are you abandoning the large cap version now then? I'm a little confused, I though that was needed to keep it going for a day..

Mark.