I've spent most of today implementing an idea I've had ready for some time. This solves a big issue for me so I thought I'd share it.

My battery driven nodes sleep most of the time. Once in a while they become active, measure and send the results to the gateway. The gateway ack's back potentially with a command which allows me to manage these nodes even though they're mostly asleep.

Some of my nodes measure very slow data - for example the sewage pit level or the lake water temperature. For the pit one measurement per hour is more than enough and for the water thermometer once every 10 minutes is sufficient. This allows the battery to last pretty much indefinitely - the estimated battery life for the sewage pit Moteino is around 20 years on 4x AA .

Now the downside is I need to wait for an hour to send commands to the sewage pit - no fun for an impatient person. So I'd like these nodes to actively listen for commands instead of only using ack's from the server. But I don't want to spend battery on that.

Enter the Listen mode of the RFM69HW - a topic that's been discussed a bit here. I combined this with some of the lessons I've learned in my wireless boot project:

The listen mode uses a duty cycle that can be defined over a broad range. Naturally I wanted a very low duty cycle to save power. On the other hand you don't want the process to take forever. So the client should never miss a packet that gets sent.

That requires that there be no gap in the transmission to the node which can be achieved using the same method I've used in the bootloader: not switching back to standby mode after transmitting packets. In that case the radio stays on leaving a continuous signal the client node can detect.

I'm now using a duty cycle of 0.64ms : 2620ms which means that the incremental power use of this scheme is largely negligible.

This mode (not switching to standby from tx) is a bit tricky. For one thing it doesn't work with encryption. Additionally PACKETSENT stays true after the first packet is sent successfully - so it requires hand tuned delays for additional packets.

But the end result is very nice: Within 3 seconds I can now access any node and it's pretty much free in terms of power budget. Check out the code attached and let me know what you think.

Usage:

Client:call startListening to enter listen mode.sleep the moteinoon wake up call receivedBytes to see if anything arrivedcall clearBuffer to be ready for the next transmitcall endListening to end listening mode. Afterwards reinitialize the RFM69 library to restore its settings.

Server:call send to transmit to the clientAfterwards reinitialize the RFM69 library.

BTW, practically speaking I use this just to issue one command: increase the update frequency to once every 4 seconds. Afterwards I can manage the moteinos via Ack's from the server and don't need to hog the spectrum.

Turns out there is a bug in the RFM69HW listen mode which causes the radio to stay in RX even after timeout if address filtering is used and a packet is received that doesn't belong to the node. This caused power waste in non target nodes - all of them wake up when the 3s burst comes and stay in receive for about half of the time.

I'm attaching a workaround which now uses software based address filtering.

I'm now seeing about 7 uA battery use for sleeping nodes which jumps up to 9 uA when the node briefly goes into receive. This is what the cheap ampere-meter shows - so not a true average. Theoretically listen mode should cost .64 / 2620 * 16ma = around 4 uA, so more than shown on the meter.

Turns out there is a bug in the RFM69HW listen mode which causes the radio to stay in RX even after timeout if address filtering is used and a packet is received that doesn't belong to the node. This caused power waste in non target nodes - all of them wake up when the 3s burst comes and stay in receive for about half of the time.

<snip>

I was wondering about this so I'm not surprised. What I am surprised about is why you haven't set up a 'SleepyTime' network Id. In this case there would be no traffic on that network except a wakeup call from the Gateway (nodes would only listen on it, and possibly Ack). Switching networks is trivial, uses hardware filtering, and the Gateway would only switch during the time that it had to wake up one of the nodes. It is true that all sleeping nodes would wake up, but it would only be for that short, 3 second transmission.

Joe, nice work, this could come in handy for others that want to do similar things.Thanks for sharing it, I am surprised you can get good results with such a low duty cycle.One thing you might watch out for is the TX duty cycle which has restrictions.

@Tom, yes you're right, I could try using the network ID to work around this issue. That said the current workaround isn't any worse. I had thought about switching frequency which would keep the normal channel clean. But since I'm only using this when I need to take control of the clients it's really not such a big deal.

Note that the other nodes don't stay awake for the 3 seconds with the current setup. Only for the rx timeout period which is about 20ms.

@felix, the key to making the low duty cycle work is the continuous transmission. I know the spec mentions something about a 1% duty cycle limitation but I've never seen this as a problem so I wonder if they are mentioning a regulatory constraint. Even with wireless boot and particularly if I need to downgrade to 19200 baud I have the gateway send for up to 30s at full power and it's never been a problem. During testing I've had nodes transmit at full power for minutes without ill effect.

@Tom, yes you're right, I could try using the network ID to work around this issue. That said the current workaround isn't any worse. I had thought about switching frequency which would keep the normal channel clean. But since I'm only using this when I need to take control of the clients it's really not such a big deal.

Note that the other nodes don't stay awake for the 3 seconds with the current setup. Only for the rx timeout period which is about 20ms.

Interesting that you think it wouldn't work any better. The sleeping node wouldn't even get a wake up signal if a different Network Id was used and the radio wouldn't stay in RX mode since there wouldn't be a SyncWord match on a 'normal' transmission. What am I missing? On a sparse network, you're probably right, but on a busy network with a lot of nodes, I have to believe letting the processor sleep until there is a 'real' wake up call has to be significant.

TomPS: I've never thought Listen Mode was useful and I'm counting on you to prove me wrong.

The sleeping node wouldn't even get a wake up signal if a different Network Id was used and the radio wouldn't stay in RX mode since there wouldn't be a SyncWord match on a 'normal' transmission.

Actually the way I'm using Listen mode is that the receiver detects only whether RSSI is > -90 for 0.64 ms and then either goes back to sleep or switches into RX for 20 ms to see if there's a packet for it. During that 0.64ms phase there is no sync word detection yet obviously and so the radio would stay in RX anyhow.

The radio stays in RX until either payload available or timeout occurs. If the radio immediately receives a packet on the right network with a wrong target node id that is actually quicker than seeing and ignoring a packet on the wrong network first and hanging around until timeout occurs.

Because of the very low duty cycle regular packet interference isn't much of an issue for sleepy nodes. More problematic is interference of regular traffic by the burst sequences. Both can be solved by moving to a different frequency.

Wrt the usefulness of listen mode: that really depends if you can wake up and read out RSSI manually as quickly as the chip does in listen mode. I haven't tried it - but I'm very happy with how reliably this extreme duty cycle works for me with listen mode.

Ok, I've moved the sleepy frequency by 4mhz, introduced a new network id. I'm now using another node instead of the gateway to send the wakeup packet burst. So now there's no interference between regular traffic and wakeup bursts. See attached.

The sleeping node wouldn't even get a wake up signal if a different Network Id was used and the radio wouldn't stay in RX mode since there wouldn't be a SyncWord match on a 'normal' transmission.

Actually the way I'm using Listen mode is that the receiver detects only whether RSSI is > -90 for 0.64 ms and then either goes back to sleep or switches into RX for 20 ms to see if there's a packet for it. During that 0.64ms phase there is no sync word detection yet obviously and so the radio would stay in RX anyhow.

AHA! It didn't 'sync' in that the RX was only 0.64mS, somehow I was seeing this as 6.4mS, which should be enough time for SyncAddressMatch. Ok, now I 'get it'. Thanks for the explanation. It would be interesting to see just how often your node wakes up with an RSSI > -90 from transmissions on the main 'network'. Given the transmit power and receive sensitivity of these radios, I would expect high RSSI levels even if shifted 4MHz.

The radio stays in RX until either payload available or timeout occurs. If the radio immediately receives a packet on the right network with a wrong target node id that is actually quicker than seeing and ignoring a packet on the wrong network first and hanging around until timeout occurs.

Because of the very low duty cycle regular packet interference isn't much of an issue for sleepy nodes. More problematic is interference of regular traffic by the burst sequences. Both can be solved by moving to a different frequency.

Wrt the usefulness of listen mode: that really depends if you can wake up and read out RSSI manually as quickly as the chip does in listen mode. I haven't tried it - but I'm very happy with how reliably this extreme duty cycle works for me with listen mode.

I'm still stuck in thinking that SyncAddressMatch provides some useful capability and, if I do try ListenMode, I'll experiment with that. This code provides a good starting point for those experiments. I think this is good work and will be useful to others, including me. Thanks for sharing.

My cfg is the following:The "master" device is powered over an USB power cord. It send burst messages to reach the "client" which is battery powered and in RFM69-ListenMode.One burst takes as long as one RX/idle period of the client. After the client has received the message it sends an ACK back to the "master".With this mechanism I have a stable protocol for the "master"/"client" configuration.

The ListenMode period is configured to be 1ms in RX mode and 262ms in idle mode.Therefore I did reduce the RFM RX mode to a minimum and I still have a robust connection between master and client.

I am currently running a test how long the client survives with 2x AA batteries...

O have a few questions:* Did you also recognised the bug that the RFM do never set the "RF_IRQFLAGS2_PAYLOADREADY" flag in listen mode when a message was received. I always have to check if a package is available with "RF_IRQFLAGS2_FIFONOTEMPTY"* I did not understand why you do not want to switch after a TX back to STANDBY/ListenMode. What is the benefit of that? I am always in ListenMode for the defined cycle except when the client were asked for informations or ACK.* Regarding your encountered bug of the listen mode. Thats very interesting. How did you recogniced that? I want to check if that also happens in my configuration... Is the bug also there when I use Adressfiltering and encription?

if you want to use SyncAddressMatch your busy cycle needs to be an order of magnitude larger to allow the address to be read. Hence a no go for ultra low power environments.

Yeah, that's how I first read it too, but then got to thinking that once a carrier is detected and the packet engine starts receiving, the radio will stay in RX mode as long as it takes to receive and check the packet for sync match (if that's the criteria). Unless you've done this experiment and know this is not the case, I think I'll still try it 'at some point' in the future. Still, as I said, this is very useful work!

Tom, when I measure the current of the moteino I see two patterns depending on whether the listener decides to keep the radio on or not. If the radio is on for 20ms instead of .6ms that shows as higher reading on the ampere meter. This is what I did and I could verify that the sleepers did not detect a signal and switched the radio off after .6 ms.

As for the chip prolonging the rx cycle even if the criteria hasn't been met in the hope that it might be later on - that behavior for me is inconsistent with the pretty precise wording of the spec. So I'll leave that experiment to you