Node running on supercaps and a solar panel.

[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