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.]