Author Topic: Is "Listen Mode" demonstrated in any of the official demo sketches?  (Read 25433 times)

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
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.
« Last Edit: August 24, 2015, 07:19:44 AM by WhiteHare »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #1 on: August 24, 2015, 07:20:51 AM »
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.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #2 on: August 24, 2015, 09:02:11 AM »
@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
« Last Edit: September 13, 2015, 11:04:14 AM by TomWS »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #3 on: August 24, 2015, 09:16:10 AM »
Thanks.  If it's "tricky to do right," then all the more reason to start with a working sketch.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #4 on: August 24, 2015, 09:37:22 AM »
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.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #5 on: August 26, 2015, 11:24:42 AM »
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.]

« Last Edit: August 26, 2015, 02:54:16 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #6 on: August 26, 2015, 01:41:19 PM »
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.
« Last Edit: August 26, 2015, 02:40:44 PM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #7 on: August 26, 2015, 02:00:49 PM »
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.
« Last Edit: August 27, 2015, 07:58:59 AM by joelucid »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #8 on: August 26, 2015, 04:27:01 PM »
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.
« Last Edit: August 26, 2015, 04:32:30 PM by WhiteHare »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #9 on: August 26, 2015, 04:30:28 PM »
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.
« Last Edit: August 26, 2015, 04:33:11 PM by Felix »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #10 on: August 26, 2015, 04:41:19 PM »
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.
« Last Edit: August 26, 2015, 06:36:56 PM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #11 on: August 26, 2015, 05:51:50 PM »
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.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #12 on: August 26, 2015, 06:57:15 PM »
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.
« Last Edit: August 29, 2015, 12:32:51 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #13 on: August 26, 2015, 07:34:18 PM »
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.

« Last Edit: August 26, 2015, 07:57:58 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #14 on: August 26, 2015, 09:13:59 PM »
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!
« Last Edit: August 26, 2015, 09:40:25 PM by WhiteHare »