Hi Tom,
Three more comments to "close my project" in my brain. Thanks in advance again.
FIRSTSubsequently, however, I and others discovered hang up states that occurred that didn't seem to have a universally reliable solution
In my actual project (NRF24), if a TX node detects that it has done 3 tries to send a packet t the RX node without success (without getting the ackpayload) it resets itself and the NRF24 (by re-configuring it. I don't find necessary to reset it "electricaly")
Also, RX node takes care about the last good data from each TX node. If RX node detects that it hasn't recieved anything from any TX node in the last 4 x cycle time (each node with its cycle time) it will reset itself (also by software (watchdog or reconfiguring the NRF24)). I mean, if RX node "detects" that it hasn't recieved anything ... it thinks that it is the guilty node, so it resets itself.
Does it possible to reconfigure RFM69 by software?, will I need to use mandatorily reset pin? , or will I need full power off / power on the RFM69 ?
Or is it better to implement a listen mode in your sketch by radio.sleep not to get "these hang up states" ? It will be easier to use library's listen mode and reset the RFM69 if it can be reset by "software"
SECONDI have totally converted to external hardware timer which ALWAYS works and is very low power. I have set up most motes to work on a 10 minute cycle which seems to be a good compromise between data sample resolution and battery life
I think that I have understood you, but just in case .... I think that the way that you have described needs a gateway that it is always connected to power. I mean, to connect to your nodes, it has to send a "10 minutes burst", does it? Or, probably, does the node the responsible of getting data from the gateway, so it is the gateway that it is always listening ? Both ways, I think that you need a gateway that is always consuming power (if it is in RX mode, it will consume about 15-16mA). Or do I missunderstand you ? How do you send data from nodes to the gateway ?
Note: When I turn ON a sprinkler valve, I can comfortably wait for the 10 minute cycle to start the irrigation. Once the valve is open, however, I switch to a fast, Listen Mode Timer that yields a 14 second (5 x 2.8 second) cycle so that I can turn OFF a valve in a hurry if need be.
good way to do it !!!!
THIRDAnd finally, about cycle time.
The most battery efficient Listen Mode Sleep cycle is the maximum time slot, which is approximately 2.8 seconds (very brief RX and then ~2.8 second sleep).
Project: 4 TX nodes that send data every 60 minutes, 1 RX gateway in listen mode during X seconds cycle time
- TX power for 1 hour:
- TX time: 4 nodes x X seconds send burst x 50mA / 3600
- Sleeping: 4 nodes x (3600 - X) x 5uA / 3600
- RX power for 1 hour: (3600 / X) is total cycles in 1 hour
- RX time: [0.000256 seconds * 16mA / 3600] * (3600 / X)
- Idle time: [(X - 0.000256) seconds * 6uA / 3600] * (3600 / X)
- Total with X = 3 seconds : 0.1666666 + 0.0199833 + 0.0013653 + 0.0059994 = 0.1940146 mAh
- Total with X = 1 second : 0.0555555 + 0.0199944 + 0.0040960 + 0.0179984 = 0.0976443 mAh
- Total with X = 0.1 seconds: 0.0055555 + 0.0199994 + 0.0409600 + 0.0059846 = 0.0724995 mAh
I can't see in a project where all nodes (RX and TXs) are powered with solar panels why 3 seconds is better than 1 second.
I see that with less cycle time your RX consumption will be bigger, but your TX consumption will be less.
This calculation depends on how many TX nodes you have got, don't it?
And your cycle time depends on how many TX nodes you have, the response-time that you need and where do you need low battery power (TX node, RX node or both).
Anyway, this power consumption is much much less than with NRF24 as its gateway needs to be constantly in RX mode, so you spend continuosly 12mA
Tom, please, tell me your opinion of these comments, thanks.