Node running on supercaps and a solar panel.

[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).