OK, I didn't understand that at all. That may change things a lot ... for me. I'll have to try to spend some time messing with that.
And as promised, for what it's worth, the battery calcs for the kiosk unit:
In my imagined scenario mentioned above, each transmission cycle by the kiosk unit uses 120mA for about 15ms and 40mA for about 35ms. In the worst case that it needs to transmit for over 10 seconds (I used 12 seconds for the calcs), it would transmit 240 times. That would require about 0.213mAh. When not in use, sleeping per day at 300uA would require about 7.2mAh per day.
Average would be about 7.23mAh, so a 2500mAh battery theoretically should last 12 months.
Even with the kiosk unit being used three times a day, it should last about four months. As I expect only sporadic use of about once a week, this unit's battery should not be a limiting factor for transmission times.
@jremington - Thinking about it, I'll probably just stay with my manual relay ideas, as I don't know how much work it would take to figure out the mesh fabric to see if any sleep functions would be able to work to save battery life. I think you mentioned that might not be possible. But the manager might be pretty helpful even if just to simplify my send and receives if I can still use the same sleep modes. Baby steps ... .
BTW, for anyone else that stumbles across this and is interested, although I found the same or similar values in other places, I got the sleep values from this video "Low power FEATHER 32u4 RADIO @adafruit LIVE", located here: https://www.youtube.com/watch?v=WJRLuWbZ6WM
I'm working on how to put RHReliableDatagram to sleep now. I see no problem to implement it, but need to test the various scenarios to see how to minimize current draw.
Sweet!!! But I think I need a new computer. Everything just started crapping out this morning, unable to load sketches, com numbers changing, and over 20 minutes just to do a reboot. Maybe I trashed a couple of the boards and that messed with the com ports on the computer. It occurred right after trying to mimic buttons by taking a wire from ground to the pads on the feather. Can't see how that would trash anything ... and my computer is old and sad anyway . I'll let you know if I make any progress.
@bobf I ran into a problem too. The Feather M0 native USB serial doesn't work well or at all with deep sleep modes, and seems unusable for debugging.
USB serial is not needed for the project implementation, but it is extremely convenient for debugging, so the Adafruit Feather M0 seems to be a poor choice for this sort of project. Unless one opts for a more expensive debugger such as J-Link, with the associated learning curve. So I'm reconsidering where to go with my project.
As I'm sure you have considered, a solar panel would certainly help with battery life.
@jremington From what I understood, sleep mode always kills the serial port to save more battery life. I've seen a number of comments about that. Not likely, but If you find a way to override that, let me know.
@jremington - So just recalling the serial port( Serial.begin(xxxxx) would not re-init it on wakeup? That seems irritating! Oh, and the reason I'm trying to avoid solar panels is just to keep the units to a minimal size. They are being placed out in the forest on public property. The only thing that will keep them from being trashed or stolen by riffraff is obscurity. Solar panels just make it a bit more difficult to camouflage. If I can keep my interventions down to six months or more using one or two moderately small batteries like 18650s, I can live without using panels.
The RF95 driver in RadioHead has no mention of sleep modes for the processor, but in principle it is not hard to implement.
I've done so for the M0, putting it to sleep while waiting for received packets, and the mesh network works, except that exactly every second transmitted packet is received.
There are some weird comments in the RF95 code about skipped interrupts, and the need to clear radio IRQ flags twice, with inconsistent approaches and no clear explanation.
I'm using the ArduinoLowPower library, and suspect problems with it also.
I have used the SAMD21 with my library too. There was no need to write\clear the IRQs register twice nor has there been with any of the other Micros I have used.
Missing every other packet would be a 'bug' that would be spotted very early in the life of a library.
The comments in the code clearly indicate that missed packets had been detected, with apparently unknown causes, but thanks for looking.
My current problem is that introducing sleep mode causes exactly every other packet to be missed. I suspect and am looking at possible problems with the low power library, which has known issues.
Problem solved, it was an open issue in ArduinoLowPower library, noted and fixed four years ago, but the fix has still not been committed. Thanks to Mike Sklar of the Adafruit forum!
In deep-sleep listening mode, the Feather M0 board draws about 24 mA, which is consistent the report in post #32 above, and is essentially just the radio current draw.
I was just testing a change to some basic transmit and receive examples, the packet number sent was part of the packet, this allows the receiver to keep a count on missed packets.
At settings of SF11, Bandwidth 250Khz, with transmitter and receiver 1M apart on my bench, of 10,000 packets sent, 9,991 were received error free, with 9 CRC errors. So no missed packets. Tested with Arduino DUEs.
The library does only clear the IRQ registers once as part of the receive function.
.
would not re-init it on wakeup? That seems irritating! Oh, and the reason I'm trying to avoid solar panels is just to keep the units to a minimal size. They are being placed out in the forest on public property. The only thing that will keep them from being trashed or stolen by riffraff is obscurity. Solar panels just make it a bit more difficult to camouflage. If I can keep my interventions down to six months or more using one or two moderately small batteries like 18650s, I can live without using panels.