Author Topic: RFM69 ListenMode  (Read 4945 times)

lionsburg

  • NewMember
  • *
  • Posts: 4
RFM69 ListenMode
« on: December 17, 2014, 03:47:25 PM »
Hi folks,

Has anyone tried running a RFM69 in Listen mode with any success? I've been trying to play around with this, and not having much luck. Normally, I'll see close to a 100% packet receiving rate but when switching into Listen mode, it drops to a disappointing  10% to 20%. This is running at 433mhz, FSK encoding, and any rate from 2kbs to 250kps.

Thanks,

-- Michael

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6534
  • Country: us
    • LowPowerLab
Re: RFM69 ListenMode
« Reply #1 on: December 18, 2014, 10:42:30 AM »
See this post, I shared some of my code. It worked fine. Remember listen mode turns your otherwise 100% RX mode into a variable less than 100% RX mode and the rest sleeping so if you transmit when it's not in RX your packet is lost. So with listen mode you are giving away RX time in exchange for some battery savings.

lionsburg

  • NewMember
  • *
  • Posts: 4
Re: RFM69 ListenMode
« Reply #2 on: December 29, 2014, 03:22:47 PM »
Thanks for the reply - the problem turned out to be an incorrect setting of some timeout values. Over 99% of the packets are now received with some decent power savings.

Now, the one really weird problem I'm seeing while using listen mode and a less sensitive RSSI threshold (register 0x29), is a packet will fail to transmit, no interrupt will be generated but the status register say something happened. Nothing appears over the air. If the code waits a 250 ms and retries the packet, everything works great. This only happens if the chip initiates a "cold" transmit (i.e. not in response to a received packet) -- maybe 20% of the time. If the chip is acking a packet, the failure-to-transmit is never seen.

A RSSI threshold of -110dbm to -120dbm everything works great, -100dbm or greater (going towards 0) will increase the frequency of the transmission failure.

Another data point, this failure is never seen when using a normal receive mode, only listen. The sequence to transmit is, listen mode is aborted, placed into standby mode, the fifo loaded up, and then placed into transmit mode.

My understanding the RSSI threshold is only for receiving, but some how this is triggering a bug with transmission?

-- Michael

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6534
  • Country: us
    • LowPowerLab
Re: RFM69 ListenMode
« Reply #3 on: December 29, 2014, 11:07:13 PM »
Yeah it's hard to say without really digging the datasheet and learning the listen mode really well by experimentation. What I found in my explorations is some things are not mentioned or just barely described in the datasheet and you discover them during debugging. It can get very tedious. The really hard things I've found with a logic analyzer, back in the days when I developed the library. It feels like it may be true for the listen mode as well. Or the datasheet may have more light here. I have not experimented with listen mode for too long. It was only until I realized the real benefit was not outweighing the costs of implementing the listen mode so I decided to keep it out of the main lib. But thanks for the updates, if you discover more things and have working code it would be great to share it here and maybe an augmented library could be added to the RFM69 lib, perhaps another header file with the extra features.

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: RFM69 ListenMode
« Reply #4 on: January 20, 2015, 01:26:09 PM »
I am playing with the RFM69 ListenMode to reduce the power consumption as good as possible.
One Moteino is in ListenMode (idle 200ms, RX 1ms) and powered with an AA battery.
The other Moteino is powered over a power cable and sends the messages to the LowPowerMotino.
To match the timings I just send a burst which consists of e.g. 27 packages which are all the same.

It looks very good so far!

But during my testing phase I encountered something strange.
Sending out one package with 7 bytes of payload, 3 preamble bytes, 2 sync bytes and 2 bytes CRC takes about 160ms.
I measured this time with the following code in the function "SendFrame"
Code: [Select]
setMode(RF69_MODE_STANDBY);
.....push data over spi.......
setMode(RF69_MODE_TX);
unsigned long txStart = millis();
while (digitalRead(2) == 0 && millis()-txStart < RF69_TX_LIMIT_MS /* 1000ms */);
DS("sent: ");DU(millis()-txStart,0);DNL();

Is a time of 160ms with a baudrate of 9.6kbps normal?
Just based on the baudrate it should be about 12ms.....(calculation)


Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6534
  • Country: us
    • LowPowerLab
Re: RFM69 ListenMode
« Reply #5 on: January 20, 2015, 01:47:31 PM »
160ms is too long, something else is going on, no idea what it could be. Hint: a logic analyzer can be a life saver when you run into something like this.

TomWS

  • Hero Member
  • *****
  • Posts: 1929
Re: RFM69 ListenMode
« Reply #6 on: January 20, 2015, 03:04:14 PM »
@ulli, Perhaps you're spending all your time in your interrupt handler handling the 27 redundant packages that are being sent and you can't get around to transmit because of it...

Just a thought...
Tom

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: RFM69 ListenMode
« Reply #7 on: January 20, 2015, 04:48:33 PM »
Good hint with the interrupts but I checked it..I temp. deactivated the interrupt...its not.
I found some wired things:
 * By changing the following
    { REG_FIFOTHRESH, RF_FIFOTHRESH_TXSTART_FIFONOTEMPTY | RF_FIFOTHRESH_VALUE },
       to
    { REG_FIFOTHRESH, RF_FIFOTHRESH_TXSTART_FIFOTHRESH |  0x02 },
    I get a TX timing of ~12ms instead of 160ms. It looks like the FIFO is waiting for additional data before it sends it out....??

 * If I am in ListenMode sometime I get RX interrupts with RF_IRQFLAGS2_PAYLOADREADY flag not set
    but the RF_IRQFLAGS2_FIFONOTEMPTY flag is set. If I check the available data in the FIFO everything was transmitted.
    It looks like just the RF_IRQFLAGS2_PAYLOADREADY was missed to be set...

 * If I transmit the burst of 27 Packages (sendWithRetry function) I only receive 14 packages with the standard moteino configuration (without any listenMode). But If I add a delay between the 27 packages of 10ms everything was transmitted....
    Have you ever tried this with the same result?

Some wired things :/
« Last Edit: January 20, 2015, 04:59:38 PM by ulli »

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: RFM69 ListenMode
« Reply #8 on: January 21, 2015, 01:59:17 PM »
First issue is solved.
If you have 0xAA in the message you want to transmit, it causes the described error. And additionally the RFM69 detects an incoming message if it has an 0xAA in his FIFO......  >:(

lionsburg

  • NewMember
  • *
  • Posts: 4
Re: RFM69 ListenMode
« Reply #9 on: January 22, 2015, 01:12:45 PM »
Interesting..  0x55 and 0xaa are part of the packet preamble. (See the "3.4.13. Bit Synchronizer" section.)

HopeRF does have a listen demo available:

http://www.hoperf.com/docs/guide/768.htm

There's a couple of odd things about the code. The Listen bit and Sleep opcode is used to enter listen mode instead of what's listed in the documentation - Listen Bit + Standby. The other thing, the code doesn't just switch issue the opcode to switch between listen & transmit - it also reloads several registers at the same time. The demo feels a bit hastily thrown together. Either way, it might be worth checking out.

-- Michael

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: RFM69 ListenMode
« Reply #10 on: January 25, 2015, 08:14:59 AM »
lionsburg: Thanks for that hint. With that code I could improve my function...better reproducibility!

But you are right the code looks very hastily thrown together.

lionsburg

  • NewMember
  • *
  • Posts: 4
Re: RFM69 ListenMode
« Reply #11 on: April 04, 2015, 11:44:05 PM »
I have a work around for the missing packet transmit and interrupt while trying to use listen mode:

After going into standby to the abort listen mode (with the appropriate flags set), go back into receive mode, and then back into standby mode, then proceed as normal for transmitting a packet. Yes, that's two additional mode changes, but it does appear to fix the problem. My guess is the standby to receive mode switch might clean up any lingering listen mode state that the first standby/abort doesn't clear out.

-- Michael