Battery for my sonar mote lasts about 10 days. Goes from about 4.08 volts to 3.55. I've put in a new sensor and 3 different batteries. Standard software, motenio with flash chip. What really is amazing is my weather shield with motenio has been running for months with no charge .
I think the sonar draws about 6mA
Standard sketch?
So you're not sleeping the FLASH?
Quote from: Kylix on March 01, 2019, 06:21:14 AM
I think the sonar draws about 6mA
It draws quite a bit, but it should only be enabled for readings, not ALL THE TIME. The sketch does that for you.
I bought flash chips from you and soldered them on and was hoping to be able to do a wireless flash, but that doesn't seem to work either. Not sure what I am doing at this point. Maybe the flash is the problem. Having to recharge this every 9 days or so isn't a good thing.
Something is draining your battery, likely the FLASH.
Look at other sketches for the FLASH sleeping code.
If you sleep everything, it will last much longer.
For OTA you have to have the node in RX mode.
I realize this is old, but I had the same issue and just got around to troubleshooting instead of powering the Sonar Mote directly from a wall wart. Hopefully this ends up helping someone else who runs into a similar issue.
In my environment the gateway is not always replying with an ACK in a timely fashion (still need to figure out why). In the case of the Sonar Mote, this section of code from the default example then causes a slight issue:
if (radio.sendWithRetry(GATEWAYID, buff, sendLen))
{
prevDistance = distance;
DEBUG(" - ACK:OK! RSSI:");
DEBUGln(radio.RSSI);
}
else DEBUGln(" - ACK:NOK...");
digitalWrite(LED_BUILTIN, LOW);
sendLoops = SENDLOOPS-1; //reset send loop counter
When an ACK is not received for whatever reason (in my case it is just too slow), the prevDistance is never set to the distance read in the current loop. This means the next loop will read the current distance and subtract from the prevDistance set the last time an ACK was received, then try to send an update. If the ACK is not received during this loop, the prevDistance is not updated and the next loop will do the same. Repeat this process until an ACK is finally received or the battery dies from sending over and over.
I'm not sure if the above is really the behavior we want, since the retry # and ack wait timeout can be tweaked. Battery updates are also sent every so often even if distances do not change beyond the threshold to send. I suppose in the event that the sump pump is not actually functioning, you would want to keep trying to send over and over so something gets through to the gateway and an alert fires.
Solving the actual root cause will be to get the ACKs sending from the gateway in a timely fashion, but until then I tweaked the code a bit to set the prevDistance to the distance of the current read even when no ACK is received. Since my gateway is actually getting the packet and the ACK is slow, it works for now until I get the gateway itself sorted.
if (radio.sendWithRetry(GATEWAYID, buff, sendLen, 2, 120))
{
DEBUG(" - ACK:OK! RSSI:");
DEBUGln(radio.RSSI);
}
else DEBUGln(" - ACK:NOK...");
prevDistance = distance;
digitalWrite(LED_BUILTIN, LOW);
sendLoops = SENDLOOPS-1; //reset send loop counter
}