Author Topic: RFM69 Listen Mode? [discussion+code]  (Read 13728 times)

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5908
  • Country: us
    • LowPowerLab
Re: RFM69 Listen Mode?
« Reply #15 on: December 28, 2014, 10:46:12 PM »
There are specific sequences when changing modes. I will refer you to the datasheet for details.

street

  • Newbie
  • *
  • Posts: 9
Re: RFM69 Listen Mode?
« Reply #16 on: December 30, 2014, 06:56:38 AM »
Hi Felix, thank you - I thought I had considered all the right parts of the datasheet but you were right to point me back to it. I have had another read and can't identify anything to do with sequencing from Rx to Standby to read the data except to reduce power consumption during the reading of the data. Is that the reason you put it in?

The other areas I looked at were:

- The end of the Listen function processes (seems to rely on the payloadReady interrupt to break out of the Listen mode in the event of a message being received);

- The DIO mapping of interrupts Table 22 removes the PayloadReady interrupt on DIO0 and removes the Timeout interrupt on DIO1. Are those reasons why you you should switch into standby to read the data in the FIFO?

I note that the Listen mode isn't mentioned in Table 22 - probably because it is made up of Rx mode and Idle (which is effectively Sleep mode with the RC oscillator running, so I presume DIO mapping is the same as Sleep mode). Does that mean that we need to switch into Standby to read the FIFO data with SPI to turn off those interrupts? Or, if its just a power saving measure, will the Listen mode duty cycle continue and be lower power consumption than the Standby mode (hence the
Code: [Select]
 if (isRX)	
      setMode(RF69_MODE_STANDBY);
)?

Sorry if there is a really obvious answer to all of this but I'd really appreciate a cue onto the part of the datasheet/module function I should be focussing on.

Thanks, street

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5908
  • Country: us
    • LowPowerLab
Re: RFM69 Listen Mode?
« Reply #17 on: December 30, 2014, 05:32:51 PM »
I may have confused you. The datasheet mentions explicitly you have to go through intermediary stages when you switch from one mode to another. I can't remember the specifics. I've done the homework when I created the lib and the code I gave you. Study that and refer to the datasheet for more details.
The main reason for switching to standby after an interrupt is to have a chance to read the data without another interrupt occurring.

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: RFM69 Listen Mode?
« Reply #18 on: January 17, 2015, 01:21:30 PM »
Hi street, how is your work going on?
I also need to implement the listen mode for power consumption optimizations.

Did you get any good results...a stable operation??

street

  • Newbie
  • *
  • Posts: 9
Re: RFM69 Listen Mode? [discussion+code]
« Reply #19 on: February 05, 2015, 11:37:50 AM »
Hi Ulli, sorry I missed your questions. I got Felix' sketch to work but changed the listen registers to match TomWS' suggested Rx/idle duty cycle. I got some results on short range at low power settings and Ack with resend settings (will have to check how many retries are worth setting). There were power savings but I can't remember what figures I got. Suffice to say, I think it's worth following up but I have been concentrating on my own PCB to connect the rfm69hw and atmega328p together. Once I have my hardware closer to its final configuration I will attempt to optimise the Listen settings, Tx power settings and retry regime, as I think these are the most important factors in power use and need to be optimised for each expected network lay down and scales of traffic. Please let us know how you are getting on. 

tavalin

  • Newbie
  • *
  • Posts: 3
Re: RFM69xx Listen Mode?
« Reply #20 on: February 27, 2015, 07:30:27 AM »
Hi Tom,

A listen window of around 40mS should 'catch' any device sending with retry (you might have to play with this somewhat).  At 16mA for Receive (in the RFM69HW) then 40mS on/460mS off would average to 800uA or, about 62 days running on AAA batteries...

I'm trying to do some battery calculations myself but based on your suggested cycle I'm getting an average of about 1.6mA, which is about twice what you thought the average should be.  Could you go through the calculation in case I missed something please?

Thanks

Edit: here's my numbers

total cycle time     500   milliseconds

rx time             45      milliseconds
rx current           16            milliamps
sleep time          455   milliseconds
sleep current     0.138   milliamps
      
average current per cycle   1.56558   mA   calculated as ((45*16)+(455*0.138)) / 500
« Last Edit: February 27, 2015, 08:03:34 AM by tavalin »

TomWS

  • Hero Member
  • *****
  • Posts: 1884
Re: RFM69xx Listen Mode?
« Reply #21 on: February 27, 2015, 09:22:47 AM »
Hi Tom,

A listen window of around 40mS should 'catch' any device sending with retry (you might have to play with this somewhat).  At 16mA for Receive (in the RFM69HW) then 40mS on/460mS off would average to 800uA or, about 62 days running on AAA batteries...

I'm trying to do some battery calculations myself but based on your suggested cycle I'm getting an average of about 1.6mA, which is about twice what you thought the average should be.  Could you go through the calculation in case I missed something please?

Thanks

Edit: here's my numbers

total cycle time     500   milliseconds

rx time             45      milliseconds
rx current           16            milliamps
sleep time          455   milliseconds
sleep current     0.138   milliamps
      
average current per cycle   1.56558   mA   calculated as ((45*16)+(455*0.138)) / 500
Yes, you are much more correct than I was.  I'm not sure where I goofed up in my calculations.   I think I had mistakenly applied a duty cycle to RX mode.  In any case, my 'current' projections (no pun intended  ;) given your use case is 1.463 mA.  The difference being the sleep current.  With a standard Moteino (ie, has MCP1703 regulator) the sleep current should go to about 23uA (not 138uA).   

This would give you about 35 days running on AAA batteries, 81 days on AA.

Tom

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: RFM69 Listen Mode? [discussion+code]
« Reply #22 on: April 15, 2015, 02:56:02 PM »
OK guys, I spend some time to integrate the source code of Felix regarding the ListenMode of the RFM69 into my Project.

I got everything running and a stable connection between too devices.
The "master" device is powered over an USB power cord. It send burst messages to reach the "client" which is battery powered and in RFM69-ListenMode.
One burst takes as long as one RX/idle period of the client. After the client has received the message it sends an ACK back to the "master".
With this mechanism I have a stable protocol for the "master"/"client" configuration.

The ListenMode period is configured to be 1ms in RX mode and 262ms in idle mode.
Therefore I did reduce the RFM RX mode to a minimum and I still have a robust connection between master and client.

The problem is, the client stops working after 16 days due to an empty AA battery.
I am running the client from one AA battery with a MCP1640. The MCP stops working at 0.5 V!

The client is running with:
* Atmega@8Mhz in PowerDown (LowPower Lib)
* RFM69 in ListenMode
* IR Diode connected on a ULN2003V12DR
* periodically transmit battery voltage to the host (every 30min)
* ~4 IR events per day

Based on my rough excel calculation the client should run ~ one year :(
Does anybody have some hints what I have done wrong? Or what can still be improve?

TomWS

  • Hero Member
  • *****
  • Posts: 1884
Re: RFM69 Listen Mode? [discussion+code]
« Reply #23 on: April 15, 2015, 07:16:56 PM »
OK guys, I spend some time to integrate the source code of Felix regarding the ListenMode of the RFM69 into my Project.

I got everything running and a stable connection between too devices.
The "master" device is powered over an USB power cord. It send burst messages to reach the "client" which is battery powered and in RFM69-ListenMode.
One burst takes as long as one RX/idle period of the client. After the client has received the message it sends an ACK back to the "master".
With this mechanism I have a stable protocol for the "master"/"client" configuration.

The ListenMode period is configured to be 1ms in RX mode and 262ms in idle mode.
Therefore I did reduce the RFM RX mode to a minimum and I still have a robust connection between master and client.

The problem is, the client stops working after 16 days due to an empty AA battery.
I am running the client from one AA battery with a MCP1640. The MCP stops working at 0.5 V!

The client is running with:
* Atmega@8Mhz in PowerDown (LowPower Lib)
* RFM69 in ListenMode
* IR Diode connected on a ULN2003V12DR
* periodically transmit battery voltage to the host (every 30min)
* ~4 IR events per day

Based on my rough excel calculation the client should run ~ one year :(
Does anybody have some hints what I have done wrong? Or what can still be improve?
Need some more info:
1. What voltage are you boosting to?
2. Which power pin are you driving with the boosted voltage?
3. When you say 'AtMega' running at 8MHz, what processor, exactly are you using?  What fuse settings are you using?
4. Which RFM69 are you using W or HW?
5. How is the COM pin on the ULN2003 powered?   What is the interface to the IR diode?

Observation 1: 45mA surge at the Moteino power pin will pull ~125mA from your battery (assumption 1.5V battery, 3.3V load).
Observation 2: Have you counted how many retries the receiver makes before it gets an Ack from your gateway?  You may be overwhelming the receiver with your burst and the receiver is trying to transmit during the entire time and the gateway is missing the sends.

Just a couple of quick thoughts on the matter...

Tom

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: RFM69 Listen Mode? [discussion+code]
« Reply #24 on: April 16, 2015, 04:07:46 PM »
Thanks Tom for your feedback.

1. What voltage are you boosting to?
Quote
Currently from 1.5V AA battery to 3.3V. I was also thinking about to reduce the boosting voltage to 2V. Atmega and RFM69 would work in that condition based on the datasheets.
Would that be a good idea to reduce the power consumption? But I am not sure if that would work with the IR diode.

2. Which power pin are you driving with the boosted voltage?
Quote
Just direct the Atmega328p VCC & ACC & AREF + RFM69 + ULN

3. When you say 'AtMega' running at 8MHz, what processor, exactly are you using?  What fuse settings are you using?
Quote
Atmega328p
  low_fuses=0xE2
  high_fuses=0xDA
  extended_fuses=0x07

4. Which RFM69 are you using W or HW?
Quote
The HW version. But I am using your (TomWS) setPowerLevel function to reduce the output power. I set it to 0.

5. How is the COM pin on the ULN2003 powered?   What is the interface to the IR diode?
Quote
I directly connect the ULN input pins to the Atmega and the ULN output goes through the IR diode + 33Ohm Resistor to the 3.3V boosted voltage.
 The COM pin is also directly connected to the 3.3V boosted voltage.


Have you counted how many retries the receiver makes before it gets an Ack from your gateway?  You may be overwhelming the receiver with your burst and the receiver is trying to transmit during the entire time and the gateway is missing the sends.
Quote
Most of the time I just need one burst. When the client receives a mesage it waits till the rssi value goes below a certain limit.
-> Moteino standard canSend function
When the rssi is below the limit it sends the ACK just once and than it goes back to sleep mode.

I additionally changed the MODE-STANDBY lines in the moteino library to MODE-SLEEP to further reduce the power consumption.....looks like it also works with sleep modes. Do you expect any other side effects? I did not find any in the datasheet of the RFM.
« Last Edit: April 16, 2015, 04:13:58 PM by ulli »

TomWS

  • Hero Member
  • *****
  • Posts: 1884
Re: RFM69 Listen Mode? [discussion+code]
« Reply #25 on: April 16, 2015, 07:09:07 PM »
I see a couple of issues, whether they're related to your battery life issue, I can't say, but should be addressed:
Thanks Tom for your feedback.

1. What voltage are you boosting to?
Quote
Currently from 1.5V AA battery to 3.3V. I was also thinking about to reduce the boosting voltage to 2V. Atmega and RFM69 would work in that condition based on the datasheets.
Would that be a good idea to reduce the power consumption? But I am not sure if that would work with the IR diode.
I'm not sure what you mean here.  Do you mean that you'll run the processor and radio at 2.0volts?  I have no experience with this but I doubt you'll get full power out of the radio at this power.
Quote
2. Which power pin are you driving with the boosted voltage?
Quote
Just direct the Atmega328p VCC & ACC & AREF + RFM69 + ULN
AREF should not be tied to a power pin.  Unless you are configuring for External Reference, AREF would be an output and should just have a filter cap on it.
Quote
3. When you say 'AtMega' running at 8MHz, what processor, exactly are you using?  What fuse settings are you using?
Quote
Atmega328p
  low_fuses=0xE2
  high_fuses=0xDA
  extended_fuses=0x07
high_fuse = 0xDA is a problem.  You're selecting the wrong boot start address ($3C00).  Moteino with the DualOptibootLoader would use 0xDC ($3E00).
Quote

4. Which RFM69 are you using W or HW?
Quote
The HW version. But I am using your (TomWS) setPowerLevel function to reduce the output power. I set it to 0.
If you're using the ATC library then I'd recommend that you use a value of 32, rather than 0.  0 will not change the PA settings and, depending on how those are set up, you may be driving more power than you think.   The ATC library purposefully left the range from 0-31 pretty much as the original RFM69 library did so existing code wouldn't be affected by the changes in the new library.  32 will give you the Minimum power output available on an HW.
Quote
5. How is the COM pin on the ULN2003 powered?   What is the interface to the IR diode?
Quote
I directly connect the ULN input pins to the Atmega and the ULN output goes through the IR diode + 33Ohm Resistor to the 3.3V boosted voltage.
 The COM pin is also directly connected to the 3.3V boosted voltage.


Have you counted how many retries the receiver makes before it gets an Ack from your gateway?  You may be overwhelming the receiver with your burst and the receiver is trying to transmit during the entire time and the gateway is missing the sends.
Quote
Most of the time I just need one burst. When the client receives a mesage it waits till the rssi value goes below a certain limit.
-> Moteino standard canSend function
When the rssi is below the limit it sends the ACK just once and than it goes back to sleep mode.
Ok, so the node wakes up SOMETIME during the Gateway's burst (duration could be max), waits for quiet RSSI, and then sends to the Gateway?  Does the Gateway receive the packet using receiveDone() or as an Ack to sendwithRetry()?  Potentially the node's radio could be awake for the entire duration of the Gateway's burst, correct?  How often does the Gateway send - I'm talking about the interval between bursts?
Quote

I additionally changed the MODE-STANDBY lines in the moteino library to MODE-SLEEP to further reduce the power consumption.....looks like it also works with sleep modes. Do you expect any other side effects? I did not find any in the datasheet of the RFM.

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: RFM69 Listen Mode? [discussion+code]
« Reply #26 on: April 18, 2015, 01:20:47 PM »
I attached my current circuit. I think this helps the discussion :)

1. What voltage are you boosting to?
Quote
I'm not sure what you mean here.  Do you mean that you'll run the processor and radio at 2.0volts?  I have no experience with this but I doubt you'll get full power out of the radio at this power.
I mean, would it not be better for the efficiency of the voltage booster to reduce the output boost voltage to 2 V instead of 3.3V.
The components RFM69, Atmega328p would work with 2V as well. Or is the power consumption still the same due to higher currents?

2. Which power pin are you driving with the boosted voltage?
Quote
AREF should not be tied to a power pin.  Unless you are configuring for External Reference, AREF would be an output and should just have a filter cap on it.
See pdf attached...

3. When you say 'AtMega' running at 8MHz, what processor, exactly are you using?  What fuse settings are you using?
Quote
high_fuse = 0xDA is a problem.  You're selecting the wrong boot start address ($3C00).  Moteino with the DualOptibootLoader would use 0xDC ($3E00).
I do have the standard bootloader, without OTA flashing....But I guess it is not an issue because the 0xDC is just a bootloader size of 512 and I have 1024 with 0xDA. To safe memory I could of course also use your 0xDC, do not I?

4. Which RFM69 are you using W or HW?
Quote
If you're using the ATC library then I'd recommend that you use a value of 32, rather than 0.  0 will not change the PA settings and, depending on how those are set up, you may be driving more power than you think.   The ATC library purposefully left the range from 0-31 pretty much as the original RFM69 library did so existing code wouldn't be affected by the changes in the new library.  32 will give you the Minimum power output available on an HW.
I use the functions enclosed in the powerFkt.cpp file
Would really give me a value of 32 the minimum output power?

5. How is the COM pin on the ULN2003 powered?   What is the interface to the IR diode?
Quote
Ok, so the node wakes up SOMETIME during the Gateway's burst (duration could be max), waits for quiet RSSI, and then sends to the Gateway?  Does the Gateway receive the packet using receiveDone() or as an Ack to sendwithRetry()?  Potentially the node's radio could be awake for the entire duration of the Gateway's burst, correct?  How often does the Gateway send - I'm talking about the interval between bursts?

Absolutely right!
I receive the burst message like the following
 * poll() {
      receiveDone() // I changed the receive done to set the RFM to MODE_SLEEP instead of MODE_STANDBY if a msg is available in the buffer
      "add received Command to a RingBuffer which will be executed in the next poll circle"
      "add sendACK command  to a RingBuffer which will be executed in the next poll circle"
    }
  * "sendACK will be executed in the poll with the standard moteino RFM send(..) command"
  *  send(...) {
       .....
       while (!canSend() && (TIMING::millis()-now) < RF69_CSMA_LIMIT_MS) receiveDone();
       .....
       sendFrame(...)
 }

I hope I described it well enough.

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: RFM69 Listen Mode? [discussion+code]
« Reply #27 on: April 20, 2015, 03:00:25 PM »
Does anybody have some hints to reduce the power consumption?
I am stumped...