Ultra low power listening mode for battery nodes

[WhiteHare]

8.192ms sounds suspiciously close to when the atmega328p might be in the middle of waking up from a watchdog timer event.  Is that what's happening?  I'm not sure if new interrupts are detected during the wakeup phase.

[TomWS]

I'm wondering if anyone can shed any light on a interesting... quirk I've found while working with low power listening.

I'll start, quickly with my setup:

• Rx Time: 256 us
• Idle Time: 4096 us
• Signal Acceptance Criteria: RSSI >= threshold
• End of cycle action: Stay in Rx until Timeout or PayloadReady, resume listen mode in idle.
• RSSI Threshold: -75dBm (wanted to avoid interference while development)
• Timeout2 value: 51
• Bitrate: 55,555

The above set up works well; packets are received and power consumption is fairly low. However if I increase the idle time from 4.096 ms to say 8.192 ms it stops working, the RSSI is never detected as going above the threshold. If I increase the RX time a little, from 256 us to 384 us, it starts working again. Is there some relationship between the two that I am missing?

What are the exact values you're using in LISTEN1, LISTEN2, and LISTEN3 regs in both cases?

Tom

[Tomme]

8.192ms sounds suspiciously close to when the atmega328p might be in the middle of waking.....

I should say that there is nothing special about the 8192 us number. If I change it by a few increments, it still doesn't work. I'm also looking at the power consumption of the radio on a scope so I can see it entering/exiting idle and rx modes so I can see that the timings for both idle and rx are correct.

What are the exact values you're using in LISTEN1, LISTEN2, and LISTEN3 regs in both cases?
Tom

LISTEN1: 0x54   (0b01010100)
LISTEN2: 0x40 (4.1 ms) or 0x80 (8.2 ms)
LISTEN3: 0x04 (256 us) or 0x06 (384 us)

So:
256 us and 4.1 ms - works.
256 us and 8.2 ms - does not work.
384 us and 8.2 ms - works.

[TomWS]

8.192ms sounds suspiciously close to when the atmega328p might be in the middle of waking.....

I should say that there is nothing special about the 8192 us number. If I change it by a few increments, it still doesn't work. I'm also looking at the power consumption of the radio on a scope so I can see it entering/exiting idle and rx modes so I can see that the timings for both idle and rx are correct.

What are the exact values you're using in LISTEN1, LISTEN2, and LISTEN3 regs in both cases?
Tom

LISTEN1: 0x54   (0b01010100)
LISTEN2: 0x40 (4.1 ms) or 0x80 (8.2 ms)
LISTEN3: 0x04 (256 us) or 0x06 (384 us)

So:
256 us and 4.1 ms - works.
256 us and 8.2 ms - does not work.
384 us and 8.2 ms - works.

Thanks for the info, but, sorry, I'm not seeing it.  Joe is the maven on these settings but he's been tied up the last couple of days.  Maybe he'll be around tomorrow and can comment on it.

Tom

[joelucid]

I've found that you need at least 384uS with a 55kbit data rate. 256uS only works with 200kbit in my setup. So I'm actually surprised that you could sporadically get 256uS to work at 55kbit. There should be no connection to the idle period unless your tx burst is shorter than the idle period. 

[Tomme]

I've found that you need at least 384uS with a 55kbit data rate. 256uS only works with 200kbit in my setup. So I'm actually surprised that you could sporadically get 256uS to work at 55kbit. There should be no connection to the idle period unless your tx burst is shorter than the idle period.

I agree that there shouldn't be any connection to the length of the idle period but this experience seems to suggest otherwise, I will try to investigate a bit more.

[joelucid]

So I'm actually surprised that you could sporadically get 256us to work at 55kbit.

I'm currently rereading the rfm69cw spec because I'm implementing a manual listen style mode for a board with the AM1805 RTC. Please check page 14 (Receiver Specification). You can see there how the time from PLL locked state to RX ready depends on both the data rate and the RxBW:

TS_RE_AGC Receiver wake-up time, from PLL locked state, AGC enabled
RxBw = 10 kHz, BR = 4.8 kb/s, 3.0ms
RxBw = 200 kHz, BR = 100 kb/s, 163us

Add to that the 80us it takes to reach PLLlock and the 40us 2 bits of RX for RSSI detection take at 50khz and you can see pretty clearly that with 55khz 256us just shouldn't work

There are also a couple of other nuggets in there. Observe for example that:

Receiver wake-up time, from PLL
locked state to RxReady
RxBw = 10 kHz, BR = 4.8 kb/s, 1.7ms
RxBw = 200 kHz, BR = 100 kb/s, 96us

In other words RxReady is reached much quicker if automatic gain control is off.

Given these data points I'm going to try the following:

Listen mode nodes listen for wakeup signals using 300kbit and 500khz RxBw without AGC, resulting in total time in Rx to RSSI detection of less than 198us - potentially significantly less if receiver wake-up time reduces similarly from 200khz RxBW to 500khz RxBW as it does from lower RxBWs.

The expectation here is not to actually try to receive packets at these super aggressive settings (potentially underground). It's just to detect the gateways willingness to send packets. Once a node knows the gateway wants to send a packet it switches to rx using more conservative settings.

This is particularly attractive for RTC nodes which won't need a regular wakeup burst to stay in sync. Going just by the RX power consumption and assuming a 3s idle window we come out at:

0.000198s / 3s * 16mA = 1uA which would be pretty phenomenal for a node that can be reached in 1.5s on average.

Joe

[TomWS]

There are also a couple of other nuggets in there. Observe for example that:

Receiver wake-up time, from PLL
locked state to RxReady
RxBw = 10 kHz, BR = 4.8 kb/s, 1.7ms
RxBw = 200 kHz, BR = 100 kb/s, 96us

In other words RxReady is reached much quicker if automatic gain control is off.

I'm missing the AGC connection in this quote...

Tom

[joelucid]

I'm missing the AGC connection in this quote...

That's the point. Only the other quote refers to measurements with AGC enabled:

TS_RE_AGC Receiver wake-up time, from PLL locked state, AGC enabled
RxBw = 10 kHz, BR = 4.8 kb/s, 3.0ms
RxBw = 200 kHz, BR = 100 kb/s, 163us

Disabling AGC almost cuts the wake-up time in half.

[WhiteHare]

The datasheet gives the formulas for the different timings just below Figure 20, and so with the help of the corresponding figure you can sum up the time intervals that are of interest to you.  However, I was never certain what the "." meant in the formulas.  For example,
"RSSI sample time: Trssi = 2 x int(4.RxBw.Tbit)/(4.RxBw) (aka TS_RSSI)"

Does "." mean multiplication?  Maybe their notation is just sloppy, but it does say  "2 x int" instead of "2.int"

Does anyone here know what "." means?

As was mentioned by Perky in a different thread, it would be nice if there were a spreadsheet to aid in quickly calculating the numbers (time intervals) of interest, but to construct one the meaning of "." in the formulas needs to be clarified.  If we all had such a spreadsheet, it would be much easier to do "what-if" comparisons, as well as cross-check one's own computations.

[WhiteHare]

In other words RxReady is reached much quicker if automatic gain control is off.

Also, less noise if you default to G1, which might translate into fewer false positives, since you're relying on RSSI to assess  the transmitter's intention to send.

Thanks for sharing your math.  The energy savings make for a compelling case to do it that way.

Will you also be keeping the AM1805 in close enough sync with the sender's  RTC (or maybe visa versa), so that the the sender doesn't have to spray packets over the full 3 second interval, but instead over a much narrower window that the receiver is likely to be actually listening? 

[joelucid]

"RSSI sample time: Trssi = 2 x int(4.RxBw.Tbit)/(4.RxBw) (aka TS_RSSI)"

In another section they give RSSI as 2.Tbit. And in the text they say RSSI detection takes two bits. So apparently . is x. Still pretty funky formula ...

Will you also be keeping the AM1805 in close enough sync with the sender's  RTC (or maybe visa versa), so that the the sender doesn't have to spray packets over the full 3 second interval, but instead over a much narrower window that the receiver is likely to be actually listening?

Once the sender has an RTC that's the plan.

[joelucid]

Listen mode nodes listen for wakeup signals using 300kbit and 500khz RxBw without AGC, resulting in total time in Rx to RSSI detection of less than 198us - potentially significantly less if receiver wake-up time reduces similarly from 200khz RxBW to 500khz RxBW as it does from lower RxBWs.

The expectation here is not to actually try to receive packets at these super aggressive settings (potentially underground). It's just to detect the gateways willingness to send packets. Once a node knows the gateway wants to send a packet it switches to rx using more conservative settings.

I've got this running now. For starters I just have the mote send an update whenever it finds via RSSI detection that the gateway wants to talk to it. The gateway can then send any command with the ACK to that update.

The comparison isn't entirely fair because this mote is powered from 9V via a buck converter. But anyway: I'm measuring 590nA total average current in this mode. That's for a mote that's reachable in 1.5s on average at any time. Including 328p and radio sleep current etc.

Use a lithium 9V (1200mAh, 1% self-discharge per year) and the battery should last you 120 years. That's including self discharge. That's what I call a lifetime mote and the revival of the 9V battery. 

[WhiteHare]

Just a thought, but you may want to run your RSSI detection in OOK Rx mode, as it appears there would be less chance of a false positive resulting from noise:  https://lowpowerlab.com/forum/index.php/topic,1468.msg11931.html#msg11931

[joelucid]

Just a thought, but you may want to run your RSSI detection in OOK Rx mode, as it appears there would be less chance of a false positive resulting from noise:  https://lowpowerlab.com/forum/index.php/topic,1468.msg11931.html#msg11931

If I wanted to reduce the rxbw I can do that using fsk just as well. However that increases RSSI detection time. Just as a lower bitrate does. Actually I find the whole concept of rxbw for ook a bit puzzling since by definition the signal doesn't have any frequency deviation.

It's a trade-off: higher rxbw gives much quicker RSSI detection but then more false positives. I only very sporadically get false positives so max rxbw works best. Until every household has one of my thermometers :-)