Wireless programming AND long sleep

[KanyonKris]

Is it possible to have both wireless programming AND long sleeps (to reduce power)? Starting with Felix' wireless programming sketches I've added an 8 second sleep to the remote node to save power. I've played around with some retries, timeouts and ACK timeouts but I have yet to send a new program to the remote Moteino. Felix' code notes that the remote Moteino needs to check the radio.ReceiveDone frequently enough to catch the gateway sending a new program, and I think with my long sleep the odds are really bad that the gateway will be sending when the remote is listening once every 8 seconds.

So, any ideas?

I've wondered if I could tweak the gateway more so it's transmitting as many requests as possible for 8 seconds to catch the remote listening. Or do I just need to add more listen time to the remote? Is there a mode to have the receiver listening with low power such that when the Moteino wakes up in 8 seconds I can ask the radio if it heard anything?

I'd like to have both low power and wireless programming but if they just don't mix I'll choose low power since once I get the program working right I shouldn't have to touch it. And if I do need to reprogram the Moteino it's not obnoxiously inaccessible so it wouldn't be awful to remove it from it's mount.

[Felix]

As you might guess, the radio will not receive anything when it's sleeping. It has to be in RX mode.
You could put everything else to sleep and leave the radio in RX mode, then when a packet is received it will wake the micro via the D2(INT0) interrupt. But that's a huge 15mA constant power draw.

So you have to get smart about sleeping and wireless programming. You could do this: wake the micro/radio every X seconds, send any data, then listen for a short period of time - say 20-30ms. The gateway would sense the data received from this node and know that this node is scheduled for an update and immediately send that wireless programming token to start the whole process. So you'd need a little queuing system in place. You'd need a good battery to support a 30-60 second burst of transmissions on the target node, so coin cells might not be a great choice here.

I'll eventually get to doing this myself, just busy with other things right now...

[KanyonKris]

Felix, thanks for the feedback. I like your idea of having the remote Moteino transmit then listen a little while for commands (i.e a new program) from the gateway. Yes, I'll need to add code to handle the queuing, but it doesn't seem like it would be terribly complicated. I'll start tinker with this over the holiday.

Yes, needs good battery power. I've already abandoned the coin cells in favor of 3 AAA, should be enough.

[Felix]

3xAAA should definitely be enough. And there's probably other ways of doing this, but one way or another the target node has to listen at some point, long enough that it can capture the request from a central gateway node, and short enough that you still get good battery life. I think with my suggested method most of the complexity resides with the gateway, which has to have some kind of queue which takes an ID and a HEX dump for each node to be programmed and then always check for received node ID and when one matches an ID in the queue try to send the HEX - I would make it work for any node, where I could schedule a new sketch upload for several nodes in a row. The nodes that are listening for a wireless token could indicate they do so by sending some extra token in a regular data package ... ie say if the data is ASCII then include something like "[WPE]" (wireless programming enabled). To save even more power the node could listen every N transmissions, not on every transmission.... depending how critical it is to get the update as soon as possible.