LowPowerLab Forum
Hardware support => RF - Range - Antennas - RFM69 library => Topic started by: WhiteHare on August 23, 2015, 11:09:35 PM
-
It seems quite essential if a receiver is operating on battery power. Otherwise the battery could be used up much too quickly from constantly sitting in Rx mode waiting to receive a packet. So, if there isn't an official demo sketch, there really should be.
For instance, would it be realistic to have a 100uSecond Listen Window every 100ms? That way the receiver would only be in Rx mode 0.1% of the time, and would hopefully reduce the 16mA Rx current to ~16uA, which is much less of a strain on batteries. Yet, you could wake up your MCU within 100ms, so there'd be no perceptible response delay if you wanted it to do something (e.g. turn on a light).
Significantly, while in "listen mode", the arduino on the Moteino can remain asleep in full powerdown until a valid packet is received. So, that saves power too.
With this approach, except when action is required, the airwaves remain quiet. However, when action is required, the transmitter will need to hit one of the windows when the receiver is listening. With a 100uSecond listening window, you might need to transmit a packet once every 50uSecond or so to be certain of hitting a listening window. Is that realistic?
I only see two alternatives to "listening mode":
- Be in Rx mode all the time, which will drain batteries much more quickly, or
- Have the slave poll the master. So, in this example, the entire Moteino (including Arduino) would need to wake up every 100ms, send a packet to the master to find out if it would be turning on or not. If not, fall back to sleep again. Although this will take less energy than being in Rx mode all the time, this is going to create a lot of traffic on the airwaves that "listening mode" can avoid, and it will require more energy as well: Tx energy and also power for running the arduino to do the Tx's.
Neither of those two alternatives seems anywhere near as good as "listening mode."
Is "Listen Mode" demonstrated in any of the official LowPowerLab demo sketches? It's a generic solution to a generic problem, so, if not, it really should be.
-
Not in a video no.
But plenty of discussion and code in the forum.
See these posts (first one has code I implemented):
https://lowpowerlab.com/forum/index.php/topic,775.msg4640.html
https://lowpowerlab.com/forum/index.php/topic,1136.0.html
https://lowpowerlab.com/forum/index.php/topic,793.msg6557.html
The native hardware "Listen mode" of the RFM69 is a bit tricky to do right, that's why I did not endorse it specifically. So while you will find code and useful discussions in the threads above, you might find that you can do the same thing with what you already have in the RFM69 lib, ie put your radio in RX only for the amount of time needed, then sleep, then repeat the cycle. This way you effectively have a Listen mode where you control the RX duty cycle.
-
@WhiteHare, I'll be posting an update to my RFM69_ATC library in the next few days that adds listen mode extensions based on work discussed in the thread: https://lowpowerlab.com/forum/index.php/topic,1136.0.html
I'll include examples of both node and gateway implementations in the update. I'm not sure exactly when I'll update, however, as I'm trying to find time to finish the production version of the Mote using the library.
Tom
UPDATED: 9/13/15, updated library with ListenMode extensions: https://github.com/TomWS1/RFM69_ATC/tree/ListenModeExtensions
-
Thanks. If it's "tricky to do right," then all the more reason to start with a working sketch.
-
Yeah I actually posted the code I used to investigate listen mode. It works, but the tradeoff made it seem not worth it. I always think of the acceptance factor. I consider listen mode an advanced topic for the average Arduino/Moteino user. Anything advanced is possible for those that want to have or try it, but I'd rather focus on the most usable and easier to understand modes, which still support all the functions of a radio, and doesn't create a massive amount of support for me and users in this community.
-
So, stripping Felix's experimental code down to the bare minimum and partially annotating it, the following four line incantation will set Listen Mode parameters, such that RFM69 alternates between listening for 8.192mSec and idling for 64mSec (sorry the indentations didn't paste very well here):
writeReg(REG_LISTEN1, 0x94); // REG_LISTEN1 = RFM69 Internal Register 0x0D
// Listen Mode settings.
// 0x94 = binary: 10 01 0 10 0
// Structure is as follows (cf. page 65 of RFM69 Datasheet):
// ListenResolIdle = bits 7-6: 10 implies 4.1mSec
// ListenResolRx = bits 5-4: 01 implies 64uSec
// ListenCriteria = bit 3: 0 implies: Signal strength above RSSI threshold
// No requirement that syncAddress is matched
// ListenEnd = bits 2-1: 10 implies "chip stays in Rx mode until PayloadReady or Timeout interrupt occurs. Listen mode then resumes in Idle state. FIFO content is lost at next Rx wakeup."
// Unused: bit 0
//--------------------------------------------------------------------------------------
// ListenResolX. Listen Rx resolution or Listen Idle resolution.
// Three choices: '01'= 64usec, '10' = 4.1msec, or '11' = 262msec
// (Cf. RFM69 Datasheet, Table 17)
//--------------------------------------------------------------------------------------
// Also contains 1 bit for ListenCriteria (see RFM69 datasheet Table 18)
writeReg(REG_LISTEN2, 0x10); /// REG_LISTEN2 = RFM69 Internal Register 0x0E
// ListenCoefX for ListenIdle. Value = 1 to 255, inclusive. Default: 0xF5
// Used for computing ListenIdle. ListenIdle = ListenCoefX*ListenResolX.
// ListenIdle is amount of time spent between Rx intervals.
// Felix's example: 0x40: 64*4.1ms = ~262ms idle
// Given: ListenResolIdle = 4.1mSec
// Given ListenCoefX = 0x10 = 16
// Therefore, ListenIdle = 16 * 4.1mSec = 64mSec.
writeReg(REG_LISTEN3, 0x80); // REG_LISTEN3 = RFM69 Internal Register 0x0F
// ListenCoefX for ListenRx. Value = 1 to 255, inclusive. Default: 0x20
// Used for computing ListenRx. ListenRx = ListenCoefX*ListenResolX.
// ListenRx is time duration of Rx interval.
// Felix's example: 0x20: 32*64uSec = ~2mSec RX
// Given: ListenResolRx 64uSec
// Given: ListenCoefX = 0x80 = 128
// Therefore, ListenRx = 128*64uSec = 8192uSec = ~8.2ms
writeReg(REG_RXTIMEOUT2, 0x1F); // "needed otherwise will always be in RX mode" (?) I don't see this referred to in the RFM69 Datasheet, so I'm not sure yet as to whether this is really needed or whether it is just leftover from Felix's experiments. TBD.
Then, if the RFM69 is in idle mode, the following two line incantation will initiate Listen Mode:
writeReg(REG_OPMODE, RF_OPMODE_SEQUENCER_ON | RF_OPMODE_STANDBY);
writeReg(REG_OPMODE, RF_OPMODE_SEQUENCER_ON| RF_OPMODE_LISTEN_ON | RF_OPMODE_STANDBY);
Boda bing, boda boom.
As noted above, I don't yet know whether the fourth line is vestigial or not.
Last night I briefly tried Felix's experimental code, given as a zip download in the other thread (thanks!), and at least on the surface it seems to work. You can open its serial monitor and send packets to it from a Node. As expected, it will alternate between receiving them and not receiving them, depending on whether in Rx or not of Listen Mode. For simplicity of investigating the Listen Mode, I tempoarily disabled the arduino sleeping at 1 second intervals. Ideally the Arduino would awaken (maybe it already would) when a processed packet is received and waiting in the FIFO for the Arduino to read. So, more to be investigated there as well in terms of which pin on the RFM69 gets wired to which interrupt pin on the Arduino, etc, for that to work, and whether the Moteino is already wired up for that (I'm assuming so) or whether that might require a jumper. It occurs to me now that maybe that's what the fourth line is about(?), or is it purely a timer? I need to recheck Felix's experimental code to see whether the Arduino is currently reading packets by polling or whether it's already interrupt driven. [I might not have time for quite a while to go further, so these are brain dump notes to my future self, or anyone else who may wish to lend a hand to accelerate discovery, on where to pick up the thread.]
-
I see from Table 2 of the Datasheet that "Duty Cycle of transmission at +13dBm output" is 1%. Unfortunately, just by itself that's rather vague guidance, and I don't see that the Datasheet answers what the longest possible sustained Tx time is. Is it send one packet and then cool off for the next 99 potential packet transmissions before Tx'ing the next packet? Anyone happen to know? The answer to that may affect what the shortest Rx window can be in Listen Mode if you plan to Tx a packet repetitively so as to be guaranteed of hitting the very next Rx window. In that case, the smallest Rx period would be 101x the duration of the intended packet transmission. If it were any shorter, the Rx window might fall between packet transmissions and not be completely hit by a packet.
If nobody knows, then I guess I'll just assume that in order to be conservative.
To avoid the perception of annoying latency, the idle period probably should not be longer than 100ms. So, this 1% duty cycle may ultimately limit how much power savings Listen Mode can offer without accepting perceptible latency as a trade-off.
-
I've ignored this statement and have never had a problem. I use a ~ 3000ms : 250us duty cycle. I've had the rfm69hw send at full power for minutes without any ill effects.
-
I hooked up a test rig using a 3.3v 8Mhz Pro Mini and a RFM69W so that I could intercept the current going to the RFM69W and thereby check whether I was getting the expected results from the Listen Mode.
I used a uCurrent Gold on the milliamp setting, so I hope that rules out immediate objections about burden voltage.
Results were surprising. First of all, the idle interval between the Rx intervals was variable. Then, the length of the Rx period was quite variable as well: from about 2ms up to about 7ms. Most surprising of all was the amount of current drawn, which was far higher than makes sense. It seems to be drawing about 60mA while in Rx, and something like 15mA while in idle. That doesn't make any sense (unless the module is counterfeit, but would that even make any sense? Isn't the RFM69W already a knock off of the Semtech original? Besides, I got it directly from the US Anarduino distributor so that I could run this test). Maybe I just received a bad module or something. Anyone else done any o-scope measurements and noticed this kind of thing?
I powered the Pro Mini board from two new AA batteries that were meaqsuring 3.1V while running the test. I powered the Radio from the Vcc on the board and board ground. I should probably retry by powering the radio directly from the battery to rule out the Pro Mini board as a contributing factor to the bizarre measurement.
-
I can tell you with confidence the RFM69 modules use genuine Semtech silicon ;)
This is verified by myself.
Otherwise I wouldn't use these radios.
So ... to verify your findings, I would check another module and if the results are repeats then there's 2 possibilities:
- your uCurrent is faulty (between the RFM69 and uCurrent I would bet my money on RFM69)
- the radio just acts that way
If you look in the library and read the datasheet (sometimes useful) there are certain required transitions between states which could well explain these findings.
-
I don't think it's the uCurrent Gold because I first tried it with just a 1ohm sense resistor and got similar results. I'll try to narrow it down, but thought I'd post just in case it looks familiar to anyone. Also, others might be curious as to how it looks on an o-scope.
BTW, do you mean that the die itself is literally from Semtech? i.e. HopeRF just packages it under their brand?
Anyhow, I suppose I could try it more indirectly on a Moteino by putting the Arduino into Deep PowerDown after setting up Listen Mode and then measuring total current into the Moteino. It looks as though the RFM69HW, which are the Moteino's that I have, should have the same 16mA while in Rx--well, according to its Datasheet anyway. I wish I would have thought of that beforehand, as it might have saved me some hassle wiring up the RFM69W.
-
Listen mode with 328p in powerdown takes about 1.1uA. Plus the spikes when the radio wakes up. Depending on the duty cycle you can stay below 3uA total.
-
Right. The datasheet confirms you, saying that 1.2uA is typical for IDDIDLE (Table 4, Page 12).
I suspect the much higher, more worrisome current may be coming as a result of a floating, undefined digital pin (Pro Mini D2 connected to RF69W DIO0), so I may try setting that or possibly disconnecting, as it may not serve a purpose in this particular test to have it connected.
By the way, powering the radio directly from the battery made no difference.
-
Yup, I unsoldered the floating pin, and, well, at least the Rx currents make sense now. And the time intervals apear to be more regular. Now it's mainly the idle current that's crazy. So, at least some progress toward ironing this out....
I suspect one or more pins used for SPI aren't getting properly initialized.
-
Yup, that fixed it. Just had to define Chip Select as OUTPUT using pinMode. Now it all seems to be working right.
Time intervals are now regular. Idle current isn't even visible, at least not at milliamp resolution, which is correct.
Idle time period is about 65mSec, which is only slightly longer than the 62mSec that was specified. Receive current is at 16mA, which maps spot-on to what the Datasheet says it should be. Rx current is sustained for about 9.5ms, which is a bit longer than the 8.2ms that theory predicted for Rx proper, but perhaps that includes some settle time at the beginning before true receiving is commenced. So, make note of that extra time at 16mA when doing predictive current consumption calculations.
It works!
-
Here's an update. If I set both ListenRx and ListenIdle to each be 64 microseconds, then the transition times into ListenRx seems to decrease (see snapshot below) quite a bit, and that's a good news, because it means less current wasted while preparing to Rx. The bad news is that you may have to measure whatever your cycle is in order to know how long that transition time, and thus energy drain, may be. Based on two datapoints so far (the one below and the one above), the transition time doesn't appear to be a fixed constant.
-
What exactly does the value in register 0x2B (AKA RegRxTimeout2) denotes? It is defined as "Timeout duration between RSSI detection and PayloadReady" and its default value is 0x00 (meaning "disabled"). I have confirmed using an oscilliscope that if it is left disabled while in Listen Mode, then once Rx is entered Rx will continue forever, regardless of what the duration for Rx was set to using RegListen1 and REgListen3. That is truly bizarre. It doesn't cycle between Rx and idle, even though in Listen Mode, as I would have expecteted. Why not? Moreover, there appears to be no guidance as to what register 0x2B's value should be set to. Anyone happen to know?
[Aside:, a closer read of the SX1231H datasheet reveals that the duration specified for TListenRx *includes* the time spent starting up the receiver. So, what is that value? Well, it appears I'm on my own to calculate that from the values shown shown in one of Figures 18, 19, or 20, depending on which mode I'm in. A pity there's no library function to compute the value of that. ]
-
BTW, I notice Freescale sells a SIP (MKW01Z128) which basically combines this Semtech radio with an ARM Cortex M0+. So, perhaps it has additional documentation. Surely somebody would have documented register 0x2B better than it is on the datasheet alone, especially as it relates to Listen Mode?
-
The SX1231J datasheet, not "H", may hold an essential clue. It says RegRxTimeout2 denotes TimeoutRssiThresh. "Timeout interrupt is generated TimeoutRssiThresh*16*Tbit after Rssi interrupt if PayloadReady interrupt doesn’t occur." Does this determine the actual Rx period (excluding Rx startup time) within TListenRx?
-
BTW, I notice Freescale sells a SIP (MKW01Z128) which basically combines this Semtech radio with an ARM Cortex M0+.
Interesting find! I was not aware about this one. Semtech must be licensing the radio chips to others, like Freescale in this case.
At a glance I see some slight differences, probably a SX1231 non H variant - output is topped at 17dBm, and it has a max 600kbps data rate, double that of the other 1231 radios I've seen before. Price is right in quantity but low stocks everywhere.
-
BTW, I notice Freescale sells a SIP (MKW01Z128) which basically combines this Semtech radio with an ARM Cortex M0+. So, perhaps it has additional documentation. Surely somebody would have documented register 0x2B better than it is on the datasheet alone, especially as it relates to Listen Mode?
Can you please include a link to the SIP package? All I can find is the 60 pin LGA.
Tom
-
BTW, I notice Freescale sells a SIP (MKW01Z128) which basically combines this Semtech radio with an ARM Cortex M0+. So, perhaps it has additional documentation. Surely somebody would have documented register 0x2B better than it is on the datasheet alone, especially as it relates to Listen Mode?
Can you please include a link to the SIP package? All I can find is the 60 pin LGA.
Tom
http://cache.freescale.com/files/microcontrollers/doc/ref_manual/MKW01xxRM.pdf
-
There's also this:
http://cache.freescale.com/files/rf_if/doc/ref_manual/MC12311RM.pdf
which is the same idea, but an older effort using an 8-bit MCU. Not quite as sexy, but maybe cheaper and more available.
-
BTW, I notice Freescale sells a SIP (MKW01Z128) which basically combines this Semtech radio with an ARM Cortex M0+. So, perhaps it has additional documentation. Surely somebody would have documented register 0x2B better than it is on the datasheet alone, especially as it relates to Listen Mode?
Can you please include a link to the SIP package? All I can find is the 60 pin LGA.
Tom
http://cache.freescale.com/files/microcontrollers/doc/ref_manual/MKW01xxRM.pdf
I guess I misunderstood what you meant when you said "sells a SIP". I expected to find a Single Inline Package. What did you mean by the term?
Tom
-
BTW, I notice Freescale sells a SIP (MKW01Z128) which basically combines this Semtech radio with an ARM Cortex M0+. So, perhaps it has additional documentation. Surely somebody would have documented register 0x2B better than it is on the datasheet alone, especially as it relates to Listen Mode?
Can you please include a link to the SIP package? All I can find is the 60 pin LGA.
Tom
http://cache.freescale.com/files/microcontrollers/doc/ref_manual/MKW01xxRM.pdf
I guess I misunderstood what you meant when you said "sells a SIP". I expected to find a Single Inline Package. What did you mean by the term?
Tom
System in package
-
Starting with demo code and hacking the extension library, I'm now at the point where I have the Moteino's RFM69 constantly in Listen Mode such that it's in Rx for 1ms out of every second, with the arduino asleep. Setup this way I estimate average current consumption is about 16uA, or about a 1000x reduction, as compared to having the radio in Rx mode all the time. There is additional power savings from keeping the arduino in deep sleep rather than having it wake up every 8 seconds. I could reduce power consumption by an additional factor of 67 by stretching out the idle period between Rx windows to 67 seconds, but the tradeoff would be greater latency in responding to commands. For some applications, like weather sensors, that may not matter. For some remote controlled applications, though, it would be too long. Either way, Listen-Mode can serve the purpose of an ultra low power wake-up radio, if so desired.
Now that I have address filtering turned on, I'm hoping I can lower the RSSI sensitivity threshhold and thereby gain back some range. At least in my view, the two biggest selling points for the RFM69 radio (and thus the Moteino) are range and Listen-Mode.
-
Starting with demo code and hacking the extension library, I'm now at the point where I have the Moteino's RFM69 constantly in Listen Mode such that it's in Rx for 1ms out of every second, with the arduino asleep. Setup this way I estimate average current consumption ia about 16uA, or about a 1000x reduction, as compared to having the radio in Rx mode all the time.
Nice savings, but that also means you'd only receive an average of 1 out of 1000 packets sent to it, right?
-
My point is ... you can only receive when you listen.
So .. nice battery savings, but that also means you'd only receive an average of 1 out of 1000 packets sent to it, when you listen 1 out of 1000 units of time, right?
-
Nice savings, but that also means you'd only receive an average of 1 out of 1000 packets sent to it, right?
It really depends on the app logic. For example when I trigger a wireless install then yes, I'll send on average 4500 packets to the listen client until it wakes up. But it then very efficiently receives the update no longer using listen mode. So on average it receives a much higher ratio of packets.
Also if you can narrow the time when you might receive a packet (say using a RTC, or switch to listen mode for 50ms after each update) you can significantly reduce missed packets.
But yeah, the laws of physics still apply ;)
-
@Felix, I think one clarification that may be useful is that Listen Mode (at least in this form) is used to allow the system to go to the lowest possible power state and still permit waking in almost real time so that useful communication can take place AFTER waking.
While useful information can be sent in the ListenMode packet, as you point out, it's rather sparse, time-wise. However, it is also very short (a second or so depending on the parameters) and relatively quick to establish a meaningful communication link.
Tom
-
My point is ... you can only receive when you listen.
So .. nice battery savings, but that also means you'd only receive an average of 1 out of 1000 packets sent to it, when you listen 1 out of 1000 units of time, right?
Notionally, yes, you have approximately the right idea. Not that it matters (well, at least to me), but technically the "on average" number would be closer to 1 out of 500 packets, if the transmission start time was random. If you were wanting to transfer a lot of data but only using listen mode to receive it at one packet a second, I would guess you would be worse off, because each waking of the arduino takes about 2.1ms of wasted current during warm-up on an 8mhz atmega328p and at least some time and current are lost in the process of going into PowerDown sleep. On the other hand, if the time between packets is normally greater than 2.1ms, maybe you wouldn't be worse off.... I'm not sure. Is anyone currently putting the arduino to sleep while waiting for the next packet when a train of packets is expected to arrive and then waking up "just in time" to process it? I'm not sure it would be worth the effort, but maybe. The big savings seem to happen from being in a deep sleep for a long time at the lowest current possible, and that tends to overshadow smaller optimizations.
I think a smaller Rx window could probably be achieved, which would be a desirable improvement for less wasted Rx current over time or reduced latency but the same cost in Rx current by having shorter cycles. How much smaller it could be I don't know. Actually, it's easy to shorten the Rx window--it's getting a non-continuous Tx cycle that's short enough to hit it reliably that gets harder. Right now when a proper packet is received at 200Kbps, DIO0 goes high 100 microseconds before the Rx current starts its fall to the idle current level, so with that as my only datapoint, I'm doubtful that an Rx current window of a mere 100uSec or less would be possible in Listen Mode. How much longer than 100uSec it would need to be, though, I'd be curious to know. On the other hand, the Rx windows just for detecting the start of a Tx could be less than 100uSec, provided that it can be "stretched" to wider by the timeouts when the start of a Tx is detected within that smaller window. 64uSec would be the absolute shortest limit that Listen Mode can be programmed for. @Joe and/or @Tom: are you already at the 64uSec limit?
At present I'm simply using sendFrame in a tight loop. To get less of a gap between Tx's, to hit smaller Rx windows every time, I'd need to open that up and optimize at a finer granularity within it to get a tighter gaps between packets but still remain non-continuous. Cutting the Rx window duration in half might not be too hard. I may wait, though, until I'm sure I have a definite need for that.
-
@Joe and/or @Tom: are you already at the 64uSec limit?
No. In the Library I posted we have a multiplier of 4 @ 64uS for RX = 256uS (High Speed mode), and 11 @262000 Idle = 2.882 seconds or a ratio of 11 something thousand to 1. A bit of energy savings there... :)
Tom
-
Come to think of it, I was working from the assumption that I wanted to get 100% hitrate, but for something like a soil moisture sensor, where the exact frequency of the update isn't so important, maybe you could get by with a 64uSec Rx window, and if you fire enough packets at it (the shorter the better and the more tightly spaced the better), eventually one of them should snag it, even if they aren't as short or as fast as what would be ideal for a 100% hit rate. Anyhow, just a theory, as I haven't tried going that low. If the problem were relaxed in that manner, then it would only take a few experiments with the existing setup to get a feel for how small a window can still be hit with the present version packets within a reasonable length of time.
-
maybe you could get by with a 64uSec Rx window
I systematically tested the minimum rx window for both Felix 55555baud setting and for my 200kbaud with a continuous burst. At Felix setting 6@64uS is the minimum, at 200kbaud 4@64uS. It would probably make sense to try 300kbaud. That might enable us to shorten a bit more but given the small improvement between 55k/200kbaud probably not by much.
But we should really try Ulli's suggestion (wait until fifo empty instead of manual delay). That would send a lot more packets per time for small packets and therefore significantly reduce rx power consumption when receiving a packet.
-
So, just to be clear, at 200K data rate with a cointinuous burst, you're getting 100% hits at 4x64us, and 0% hits at 3x64us (in both cases with the same value in RegRxTimeout2)?
-
100% yes. 0% maybe not quite, but it was very unreliable.
-
100% yes. 0% maybe not quite, but it was very unreliable.
Was that with a 1 byte preamble and a 1 byte sync word or the chip defaults (3 byte preamble, and a 4 byte sync word) or something else? Not sure if it's relevant, but the chip defaults would take 280us to receive for just the preamble and sync word alone, and so maybe at this small scale that starts becoming a factor. I can't claim to be intimately familiar with every aspect of the datasheet, so offhand I couldn't really say whether or not its just coincidence. Felix's RF69 library defaults to a 2 byte node address, but I don't recall offhand whether or not it changes the default number of bytes for preamble or sync word.
-
Not sure if it's relevant, but the chip defaults would take 280us to receive for just the preamble and sync word alone, and so maybe at this small scale that starts becoming a factor.
Not really relevant. Remember the 1st phase is only RSSI detection, so it doesn't really matter.
-
That's what's puzzling. Since your burst is continuous, wouldn't the first phase conditions be met all the way down to 64us? And if that's true, and there's no change in RegRxTimeout2, then shouldn't it still get your packet at 64us? In short, what's keeping it from working just as well at less than 4x64us? It would seem that some unknown factor (well, unknown to me at least) is getting in the way.
-
FWIW, I just now ran the experiment on my simplistic setup with address filtering on. With ListenIdle=1sec, I still observed packets received when ListenRx is 9x64us (not at 100% hit rate, so not ideal but still useable for triggering sensor updates if you didn't mind waiting). I was able to observe some packets get through at 7x64us, but only by reducing ListenIdle to 4.1ms, so I wouldn't call it practical. At 6x64us and below, however, I didn't observe any packets received, at least not within the timeframe that I was looking.
I think it's probably better, though, to have 100% hitrate and just expand ListenIdle if more energy savings are desired. Without thinking about it too hard, I get the impression that would save the most energy, and it obviously leads to more predictability. On the other hand, for really long sleep intervals that are greater than 63seconds, it might save nearly half the energy.
-
It just takes time to switch the radio into RX and measure RSSI.