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

street

  • Newbie
  • *
  • Posts: 9
RFM69 Listen Mode? [discussion+code]
« on: December 08, 2014, 04:53:12 PM »
Hi,

I'm trying to design a receiver to listen on a persistent basis with battery power so I'm trying to reduce the power consumption of the Rx. The transmissions it will be designed to hear will be infrequent (a few times a day) and will not be on a timer basis - they will be triggered by unpredictable sensor conditions. It would be possible to adopt an Ack with Retry Tx regime to support periodic Rx listening.

The low power modes available for Arduino and ATMEGA328P boards are really attractive and power control for the RFM69 variants Tx is pretty easy. As far as I know, power saving in the Rx mode isn't easy/currently supported. The RFM69 datasheets talk about a Listen Mode for the Rx where the Rx goes into idle mode (very low power ~ few uA) and periodically wakes up into Rx Mode (16mA). If it receives a valid signal and various configurable conditions are met, it comes out of Listen Mode and you can crack on to receive the message.

I can see that the Listen Mode settings are in this Cosa library (https://github.com/mikaelpatel/Cosa/blob/master/cores/cosa/Cosa/Wireless/Driver/RFM69.hh) do you think this could be incorporated in the/an RFM69 library?
EDIT: I see that these registers and values are already covered in RFM69registers.h . How is this implemented in the other .h and .cpp files to give a Listen Mode as an Rx option?

I'm a novice when it comes to library writing and the RFM69 comms protocols. I'm happy to try and do as much of this as possible but I'd like some help getting started. I have read the Arduino libraries guide but I really need a bridge between the RFM library, protocols and the datasheets.

Any help or guidance will be gratefully received and I hope anything I can get to work could be of use to other people.

street
« Last Edit: February 04, 2015, 12:32:13 PM by Felix »

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: RFM69xx Listen Mode?
« Reply #1 on: December 08, 2014, 06:02:29 PM »
I have to ask: why do you need to constantly receive on a battery operated mote?

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6404
  • Country: us
    • LowPowerLab
Re: RFM69xx Listen Mode?
« Reply #2 on: December 08, 2014, 08:48:25 PM »
As far as I know, power saving in the Rx mode isn't easy/currently supported. The RFM69 datasheets talk about a Listen Mode for the Rx where the Rx goes into idle mode (very low power ~ few uA) and periodically wakes up into Rx Mode (16mA). If it receives a valid signal and various configurable conditions are met, it comes out of Listen Mode and you can crack on to receive the message.
There is a listen mode indeed. I have not implemented that mode since it will not really buy you much. I have repeated this many times: to receive ANYTHING you have to be AWAKE (RX mode). That means the whole radio RX end is operating and using power (about 15ma or so). There's no magic bullet to avoiding that. In no radio receiver on this earth.
The listen mode allows you to switch between sleep and RX quickly. That also means you are in SLEEP Nms, RX Mms, SLEEP Nms, RX Mms and so on, you choose your duty cycle. But ... you cannot receive when you are in SLEEP. There, I just repeated that again :)

So to save space in the library and such, I left that part out. You can always add it yourself OR better... just implement that mode with the existing functionality in a custom sketch. Like ... sleep for Nms, then wakeup and activate the radio RX ... listen for Mms, then repeat. Simple eh? It's the same thing.

street

  • Newbie
  • *
  • Posts: 9
Re: RFM69xx Listen Mode?
« Reply #3 on: December 09, 2014, 11:44:36 AM »
@ TomWS, the Tx is attached to a  low power proximity sensor and the Rx is attached to a remote camera system which needs to be turned off most of the time. The proximity sensor is there to tell the Rx Arduino to power the camera system up and will also be used as a trigger for taking stills.

@Felix, thanks for your reply. I fully understand that no message can be received in idle or sleep mode, which is why I mentioned the Ack with Retry setting being useful. I appreciate that the library is more efficient without the listen function but I understand that in general it is more efficient to implement something like this in a library, rather than a sketch and the RFM69 series has good hardware support for this, which is why I'm hoping to do it. You say I can do it, which is encouraging. Please could someone give me a steer on how to go about implementing this?

Street.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6404
  • Country: us
    • LowPowerLab
Re: RFM69xx Listen Mode?
« Reply #4 on: December 09, 2014, 12:34:21 PM »
Like I said, it's pretty easy to do it in a sketch. If you want to implement an interface/add that functionality to the library, then a good place to start is the datasheet. There are some registers that need to be set, listen mode is described on page 39 of the DS: http://www.semtech.com/images/datasheet/sx1231h.pdf

street

  • Newbie
  • *
  • Posts: 9
Re: RFM69xx Listen Mode?
« Reply #5 on: December 09, 2014, 12:45:39 PM »
Thanks, I have the datasheet - perhaps I just need to dive in and try something. One thing which is making me think I'll make a mistake is that the modes need to be changed from one to another in a particular sequence. Does  the library do this or is it handled in hardware once you set the registers?

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6404
  • Country: us
    • LowPowerLab
Re: RFM69xx Listen Mode?
« Reply #6 on: December 09, 2014, 03:19:37 PM »
The library doesn't do anything by itself, you have to make all the changes. The datasheet will mention if there is any sequence that needs to be followed or if the hardware will do anything automatically.

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: RFM69xx Listen Mode?
« Reply #7 on: December 09, 2014, 05:00:43 PM »
@ TomWS, the Tx is attached to a  low power proximity sensor and the Rx is attached to a remote camera system which needs to be turned off most of the time. The proximity sensor is there to tell the Rx Arduino to power the camera system up and will also be used as a trigger for taking stills.

<snip...>
Street.
Ok, thanks for the explanation.  So both TX & RX are battery powered.  What's the range between them?  And what kind of response time do you need on detecting movement and taking the snap?

Tom

street

  • Newbie
  • *
  • Posts: 9
Re: RFM69xx Listen Mode?
« Reply #8 on: December 09, 2014, 06:29:23 PM »
@ Felix, thank you.

@ TomWS, I'm budgeting a second or two to get a very short message across, eg address of Tx and an "I've been triggered" flag. Perhaps a battery health indication of there's no degradation of performance. I realise there's probably a calculation which then indicates the idle/Rx duty cycle which can service those response times for a given data rate etc. Not sure how to approach that part yet. Given that the Tx is so infrequent, it doesn't matter if it sends several repeat messages to try and ensure that the idle/Rx duty is worth having and actually helps minimise Rx power consumption. My ideal range is 100m in the open or low density woodland. Thanks for your interest.

Street

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: RFM69xx Listen Mode?
« Reply #9 on: December 09, 2014, 08:43:33 PM »
@ Felix, thank you.

@ TomWS, I'm budgeting a second or two to get a very short message across, eg address of Tx and an "I've been triggered" flag. Perhaps a battery health indication of there's no degradation of performance. I realise there's probably a calculation which then indicates the idle/Rx duty cycle which can service those response times for a given data rate etc. Not sure how to approach that part yet. Given that the Tx is so infrequent, it doesn't matter if it sends several repeat messages to try and ensure that the idle/Rx duty is worth having and actually helps minimise Rx power consumption. My ideal range is 100m in the open or low density woodland. Thanks for your interest.

Street
Assuming you have the same power source for your 'rx' and 'tx' sides.  The obvious answer is that it would be far better to have more false receive cycles than transmit cycles - the power difference being dramatically different between the two and I think that's the way you're leaning. 

So, given the response time you're willing to accept (1-2 seconds), it seems as if the receive interval would need to be less than your max response time (ie, you come out of sleep and listen for a very brief time and do this once a 1/2 second or so) and your tx cycle bursts until contact is made (ie, set a high retry count for send with retry) then you should have a good chance of triggering within your budgeted time - without  any changes to existing RFM69 library.

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...  Uh, how long do you want to leave this running without recharge/replacement of batteries???

Tom

street

  • Newbie
  • *
  • Posts: 9
Re: RFM69xx Listen Mode?
« Reply #10 on: December 11, 2014, 10:27:52 AM »
That sounds great - thank you. Is there a particular sketch you recommend using as a test bed for this from the library examples? I was going to use the TxRxBlinky one if there isn't something obviously better.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6404
  • Country: us
    • LowPowerLab
Re: RFM69 Listen Mode?
« Reply #11 on: December 11, 2014, 01:30:08 PM »
Hey guess what, I found some old stuff I experimented with for Listen Mode. I am just dumping here everything I got and it's up to you to figure it out and test it.
Basically there is a RFM69Ext library that you add in the same folder as RFM69.
Then there are 2 sketches, a listener and a sender. All in the ZIP file. I think it should give you a good head start as opposed to doing everything from scratch.
Please let us know how this goes.
Cheers

street

  • Newbie
  • *
  • Posts: 9
Re: RFM69 Listen Mode?
« Reply #12 on: December 11, 2014, 05:56:29 PM »
 :) @Felix, that's really supportive, thank you. I shall probably take longer to come back with findings than most on this forum as I'm just starting out in this area of coding, but I hope my efforts will benefit others. I'll probably be back with questions before answers!

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6404
  • Country: us
    • LowPowerLab
Re: RFM69 Listen Mode?
« Reply #13 on: December 11, 2014, 07:21:47 PM »
No problem, you're most welcome. I hope this works for you, do mind that the RFM library I developed that against has changed with some updates and bug fixes but it should work the same, it was a while ago.
The most important thing to understand is how the LIsten mode works, I think it's worth spending some time reading the datasheet, unce you get a good grasp of the radio, modes, packet engine and listen mode, then everything should come much easier. A lot of people want to do big things but they are not willing to do that hard homework.
In your case you're lucky and half of that is done :)

street

  • Newbie
  • *
  • Posts: 9
Re: RFM69 Listen Mode?
« Reply #14 on: December 28, 2014, 06:39:06 PM »
Hi, this may seem like slow progress but I have honestly had to go and find out what hexadecimal numbers are, what bitwise operators are and how they work etc, so you can imagine this isn't a quick process for me. I have got to looking at the RFM69Ext.cpp file and have noticed that in your interrupt handler you only switch to Standby mode if the radio was in Rx mode, not Listen mode. Please could you confirm if I have read this right and, if so, why you don't need to switch to Standby from Listen when the interrupt is called?

Thanks, street

Code: [Select]
void RFM69Ext::interruptHandler() {
  //pinMode(4, OUTPUT);
  //digitalWrite(4, 1);
  Serial.print("*");
  byte irq2 = readReg(REG_IRQFLAGS2);
  if ((_mode == RF69_MODE_RX || _mode == RF69_MODE_LISTEN) && (irq2 & RF_IRQFLAGS2_PAYLOADREADY))
  {
    byte isRX = _mode == RF69_MODE_RX;
    if (isRX)
      setMode(RF69_MODE_STANDBY);

    select();
    SPI.transfer(REG_FIFO & 0x7f);
    PAYLOADLEN = SPI.transfer(0);
    DATALEN = PAYLOADLEN - 3;
    PAYLOADLEN = PAYLOADLEN > 66 ? 66 : PAYLOADLEN; //precaution
    TARGETID = SPI.transfer(0);
    if(!(_promiscuousMode || TARGETID==_address || TARGETID==0)) //match this node's address, or broadcast addr 0x0 or anything in promiscuous mode
    {
      PAYLOADLEN = 0;
      unselect();
      //digitalWrite(4, 0);
      return;
    }
    SENDERID = SPI.transfer(0);
    byte CTLbyte = SPI.transfer(0);
   
    ACK_RECEIVED = CTLbyte & 0x80; //extract ACK-requested flag
    ACK_REQUESTED = CTLbyte & 0x40; //extract ACK-received flag
   
    for (byte i= 0; i < DATALEN; i++)
    {
      DATA[i] = SPI.transfer(0);
      Serial.print((char)DATA[i]);
    }
    Serial.println();
    unselect();
    if (isRX)
      setMode(RF69_MODE_RX);
  }

 
  Serial.print(_mode);
  Serial.print("*");
  Serial.print(irq2, HEX);
  Serial.print("*");
  //digitalWrite(4, 0);
}

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6404
  • 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: 6404
  • 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: 1925
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: 1925
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: 1925
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...