Node running on supercaps and a solar panel.

[alexsh1]

Hi,

I'd like to share my experience of running a small sensor, which currently only reports voltage every 5 minutes on supercaps with the tiny solar panel.

My setup:

1. A stamp size atmega328p sensor with ATSHA204A. Sleeping consumption is around 5 uA.

2. The harvesting board by @ceech with two 10F supercaps.
   https://www.ebay.co.uk/itm/BQ25570-thermal-solar-energy-harvester/332071662285?hash=item4d510372cd:g:yG8AAOSwJ7RYXkVQ

3. a small solar panel.

The harvester is done on BQ25570 with 3.3v converter for sensors. It is harvesting as low as 100mV which is excellent - no need for a the sun to charge supercaps. Can also charge supercaps indoors.

In the beginning I fully charged supercaps to 5V and then disconnected the solar panel. Voltage was slowly dropping though my sensor did not sense it as it is connected to 3.3V converter. However, as soon as voltage dropped below 3.3V, the the sensor could see it dropping. The drop is around 0.2V a day, which means that from 5V to 2.9V without the solar panel disconnected, the sensor was sending voltage to controller every 5 minutes for more than 10 days!!! 10 days without a single change! Then as soon as I connected the solar panel, voltage recovered literally in minutes. See the graph below

Very impressive in my view. TO DO - I'll try to assemble a more complex weather node reporting 6-8 parameters to the controller with 10-15 minutes sleeping time to test this setup.

[alexsh1]

a few photos

It took 10-15 minutes in a bright room to charge supercaps with 0.5V (2 x 2.7V 10F caps in series)

[gohan]

What supercap where you using?

[Anticimex]

@alexsh1 that is awesome! Was this with signing enabled and with the receiver of your messages requesting signatures? Would be interesting to see what effect the atsha and signing algorithms would have on the consumption. The atsha is kept in dormant state unless it is needed.

[alexsh1]

@gohan 2 caps in series 10F x 2.7V

[alexsh1]

@anticimex No, this time I have use Sensebender GW Serial and have had a few issues with the computer going into a sleep mode. Therefore, I disabled signing for now. Testing signing would be the next step.

[gohan]

@alexsh1 what brand and where did you get them? I am running too a solar node but even with more capacitance than yours I am not getting that much runtime, probably because I am sending every 10 minutes temperature, humidity, tx pwr percentage, tx and rx rssi, battery % and supercap voltage

[alexsh1]

@gohan I cannot tell you about the brand. @ceech soldered those for me. I am going to test it with another node and see how much run time I'll get. I must also admit that the node is very-very low power.

[gohan]

I noticed there isn't much attached to it, so a real case scenario with a temp hum sensor could be more useful

[alexsh1]

@gohan I have a node with temp/hum/pressure/light/lightning sensor - I'll try this one.

Yes so far I have only tried reporting voltage. Let's see how other sensors can impact the run time.

[gohan]

I bet you will see a proportional drop according to the number of values you want to report. I am still stressing it a bit, so I think there may be margin to save some power by sending less important values with a lower frequency

[alexsh1]

I have got my hands on 30F 2.7V supercapacitor.

With it was charged for the first time, it only lasted sending 2583 times (1 time a minute voltage and an 20ms LED pulse and then sleeping; sleeping consumption is 4-5uA). The number is a bit disappointing. It is however connected via boost MCP1640 to provide the node with a stable 3.3V. I may try to get the supercapacitor connected directly to the node to see if I can extract more packets.

[Yveaux]

@alexsh1 Nice experiment
Thanks for reporting!

[NeverDie]

@alexsh1 said in Node running on supercaps and a solar panel.:

I may try to get the supercapacitor connected directly to the node to see if I can extract more packets.

That's your best choice, unless you're also running a PIR or something that requires a higher minimum voltage. In that case, you could switch to this boost converter, which has only 7ua quiescent current:
https://www.openhardware.io/view/285/33v-Boost-Converter-with-Pass-Through

[alexsh1]

@neverdie I think you are right. I have tinkered with your other boost converter - https://www.openhardware.io/view/279/Adjustable-Boost-Converter-with-Pass-Through

MCP1640's quiescent current is much higher 19uA.

Now, I'll try to run it from the supercapacitor directly. Pity that anything below 1.9V is going to be wasted (nrf24l01+ is unstable around 1.9V)

[alexsh1]

@gohan Just to let you know. I have been running this node with Si1132 + Si7021 + another sensor (reporting more than 6 values every 5-10 mins) for weeks now. I have just measured the caps = 4.8V (peak is around 5.2V) - it is late at night. In the morning the voltage will go up. I managed to find a very small, but efficient solar cell smaller than in the photo.

The key is to have a low sleeping consumption, i.e. all sensors must sleep properly. In this case you get 4-8uA sleeping current and can live on supercaps for days without recharge.

[NeverDie]

@alexsh1 said in Node running on supercaps and a solar panel.:

I managed to find a very small, but efficient solar cell smaller than in the photo.

Please do tell: what did you find? And where?

[NeverDie]

@alexsh1 said in Node running on supercaps and a solar panel.:

MCP1640's quiescent current is much higher 19uA.

Or, better yet, just turn it on prior to your sensor readings, and then turn it off.

[alexsh1]

@neverdie you mean like using a mosfet or something?
It is used to supply 3.3v to atmega328p, I do not think I can just turn it off.

[alexsh1]

@neverdie sure - this is the one i am very much happy with. Previous one was not supplying enough juice to charge fully supercaps.

https://www.ebay.co.uk/itm/Polycrystalline-Solar-Panel-Cell-5v-30mA-0-15w-53mm-x-30mm-DIY-LED-Garden-Light/362000885812?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649

[NeverDie]

@alexsh1 said in Node running on supercaps and a solar panel.:

@neverdie you mean like using a mosfet or something?
It is used to supply 3.3v to atmega328p, I do not think I can just turn it off.

Sorry, I meant switch to "pass through".

[alexsh1]

@neverdie Yes, that's on my 'to do' list. However, right now I'd like to see how much I can extract from supercap directly wired to the node.

[gohan]

How much does the supercap self discharge?

[alexsh1]

@gohan I need to implement the voltage measurement (simple voltage divider) as I have a pass though buck converter so 3.3v is shown. All I can say now is that after a few charges self discharge really improved.

[gohan]

That is something you can do by leaving the supercap on a desk for 24 hours and a multimeter

[alexsh1]

@gohan not an option. Sorry

[alexsh1]

Did anyone try using 3V solar cell for 2.7V caps?
Seems a perfect fit - no need to use two supercaps in series

https://www.ebay.co.uk/itm/3V-x-500-ma-Mini-solar-panel-epoxy-encapsulated-virtually-indestructible-1-5W/171216986698?hash=item27dd53e24a:g:14YAAOxyRhBS1H0O

[alexsh1]

@neverdie Did you make any estimates running your mote on supercap? I cannot understand how come on RFM69HW (lowpowerlab), this guy managed to extract 14,111 packets transmitted https://lowpowerlab.com/forum/projects/a-solar-supercap-powered-moteino/

This is on 15F supercap.

[NeverDie]

@alexsh1 His numbers are 100% accurate.

[alexsh1]

@neverdie I am not questioning his numbers. I am trying to understand why with a normal transceiver (non-H) I am getting so much less. I must admit also that with BQ25570, I have 2x10F in series, which makes it 5F in total only vs 15F.

I should wait until my 30F cap runs out of juice and see how many packets I extracted

[gohan]

If you are happy with your setup to power the node, why are you bothering that much to send that many more packets if you actually don't need them anyway?

[alexsh1]

@gohan This is not about being happy. Engineering mind can never be satisfied

[alexsh1]

@gohan However, in the nutshell you are right. With a small solar battery (53mm x 30mm, 5V 0.15W), this is what I get:

and today is an extremely cloudy day (no sun at all). Harvesting works really well.

I implemented a voltage divider yesterday with 1.8M / 470k resistors. Now I can monitor voltage in Domoticz:
voltage at 22:00 yesterday - 4.797V
voltage at 12:00 today - 4.887V

[NeverDie]

Try running with your fuses set to xFF xDA xC2, That way your BOD will be turned off, you'll be running from the internal 8mhz resonator, and you'll be waking from sleep in <4uSec.

[alexsh1]

@neverdie I have already all that. I am using this node https://www.openhardware.io/view/76/Stamp-size-MySensor-node

Let's see when I have final results. I have this supercap AVX 30F with ESR = 0.02ohm (vs Vishay 15F ESR=1.8Ohm used with Moteino and BQ25570 at lowpowerlab)

EDIT: Another point is signing/encryption. This would affect supercap charge as the node would be transmitting more data to GW.

[gohan]

@alexsh1 I use a total of 20F 5.5V supercaps and they discharge much more during night most likely because the buck/boost converter is not very low power and supercaps are chinese quality, but as far as I can get 36/48h of runtime without solar charge I should be fine

[alexsh1]

@gohan As you may see from the graph above my self discharge + sleep/tx consumption during the night dropped voltage from 4.851V at 21:00 (I charged supercaps initially) to 4.549V at 08:00. This is the rate of about 0.3V per 12 hours, I estimate that I have around 10 days without any charging before I run out of energy.

It took 4h 25mins on a cloudy day (see another graph) to get 2x10F in series supercaps fully charged to 5.047V

[gohan]

You are using a very efficient circuit and good quality supercaps, I loose about 1V in 12 hours

[alexsh1]

@gohan Did you try to measure your sleeping current?

[NeverDie]

@alexsh1 said in Node running on supercaps and a solar panel.:

I am using this node https://www.openhardware.io/view/76/Stamp-size-MySensor-node

If anything, you should have an advantage, since the nRF24L01 transmits at a faster bitrate, and using significantly less Tx power also.

[NeverDie]

Are you using the passive mode option for mysensors? If not, that could be part of what's draining you.

[alexsh1]

@neverdie said in Node running on supercaps and a solar panel.:

passive mode option for mysensors

I did notice there is an option:

#define MY_PASSIVE_NODE

What is the passive node option please?
I am not using it and yet I do not have any problems with draining

EDIT: I see now

    All transport-related checks and safety-mechanisms are disabled. 
    Requires that MY_NODE_ID is set, MY_PARENT_NODE_ID and MY_PARENT_NODE_IS_STATIC are optional. 
    Singing, registration, and OTA FW update are disabled. 

[alexsh1]

In my view disabling transport related checks is not an option.
Singing, registration, and OTA FW do take a lot of power. Especially OTA. It is slow and takes a lot of up time.

[NeverDie]

It sounds like you're happy already. Good luck!

[gohan]

If I remeber well, passive node is used when you have a very tiny node, with low memory that only send data one way, like RF433

[alexsh1]

@gohan OK, but I think the key here is to get consumption down to something meaningful - 5uA or something. The only down side when not using a passive node is that if GW is disconnected, node would not go to sleep, but will be trying to connect to GW. define MY_TRANSPORT_UPLINK_CHECK_DISABLED would disable the node sending more than MY_TRANSPORT_STATE_RETRIES times message

[gohan]

even if it drains the battery when the GW is dead, it is no big deal as you just have to wait for some sunlight

[alexsh1]

@gohan True! I was more talking about super small nodes working on CR1632. I have a few of these.

[alexsh1]

Another interesting set of graphs (voltage scale is wrong - please ignore):

This is with signing:

This is without signing:

[gohan]

It looks a little irregular to me, doesn't it?

[alexsh1]

@gohan Well, the point is that signing does take more tx time. Therefore, voltage does drop upto 0.2-0.3V.

I am not sure about irregularities though

[gohan]

Maybe it has to do with the harvesting chip. My graph looks like a sawtooth from day to day.

[NeverDie]

For this type of comparison, I think you're better off charging up the supercap in a standardized way and then running with the solar panel disconnected. Otherwise, how recently and how long the supercap was charged to full capacity can affect the rate of discharge.

[alexsh1]

@gohan there is no harversting - this is just 30F cap connected to a node.
I have two setups:

1. BQ25570 + 2x10F supercaps in series and a small solar panel connected to a node. This is an excellent setup which can last for days without recharging
2. 30F cap connected directly (initially I tried it via mcp1640) to a different node. The above graphs are from this setup.
   I am re-measuring it them right now as the code was wrong.

[Anticimex]

@alexsh1 with signing you also get message bursts. Not only is the max size data transmitted for every signed message, two more messages are exchanged; a nonce request (small) and a nonce (big).

[alexsh1]

@anticimex said in Node running on supercaps and a solar panel.:

@alexsh1 with signing you also get message bursts.

That's clearly visible on the graph.

[alexsh1]

@alexsh1 said in Node running on supercaps and a solar panel.:

I have got my hands on 30F 2.7V supercapacitor.

With it was charged for the first time, it only lasted sending 2583 times (1 time a minute voltage and an 20ms LED pulse and then sleeping; sleeping consumption is 4-5uA). The number is a bit disappointing. It is however connected via boost MCP1640 to provide the node with a stable 3.3V. I may try to get the supercapacitor connected directly to the node to see if I can extract more packets.

Supercap connected directly to the node stopped working at 2V.
I got about 8949 packets (10ms LED and sent voltage every minute. No signing). It has been running about 6 days.

[gohan]

basically you got 3 times packets sent without the booster?

[alexsh1]

@gohan That's correct and I am sure the result is not final