Author Topic: Ultra low power listening mode for battery nodes  (Read 66364 times)

Tomme

  • Newbie
  • *
  • Posts: 24
Re: Ultra low power listening mode for battery nodes
« Reply #165 on: April 18, 2016, 02:03:33 PM »
I think the main problem here is that the listening nodes would have to be awake a lot longer (the entire duration of a listen cycle) when they are woken up. For most folks, that's going to be more like 1-2s rather than 15ms. With the message burst you can sleep the radio/cpu after receiving the packet.

True, I'm more interested in using sleep modes for mesh networking so my thoughts always tend to head in that direction.  We're basically talking about the differences between bmac and xmac protocols here. I've been using the method (basically BMAC) I described in my previous post with a fair amount of success but as you've mentioned the power consumption overhead increases as more nodes join the network. I keep meaning to try XMAC but it works better when the sleep time is longer, which increases latency! No such thing as a free lunch I suppose.

Links to papers for those interested:
http://www.eecs.harvard.edu/~mdw/course/cs263/papers/bmac-sensys04.pdf
http://www.cse.wustl.edu/~lu/cse521s/Papers/x-mac.pdf

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5841
  • Country: us
    • LowPowerLab
Re: Ultra low power listening mode for battery nodes
« Reply #166 on: April 18, 2016, 02:15:33 PM »
Tomme,
I think snorp has just covered what I was about to say.
But IOW you want to keep the sleepy client as little time as possible in RX mode. That means that the burst from the master also has to be as short as possible to maximize chances of hitting the RX window of the client after the client has detected the burst and entered the extra RX receive-packet-or-timeout period. If the master burst packets are LONG, then either the client will timeout before it latches a new complete burst packet, or it has to spend more time waiting for it - neither of which we want. I think in most cases the client will go into initial RX, detect a part of a burst packet, then transition to extended RX to attempt to capture a packet, and then it actually receives a subsequent packet. The master will keep on sending since during the burst all it does is it continuously transmits packets (one way road). The payloads of the burst tell the client how long before the burst will end - so that a more useful two way channel communication can be done.

So basically listen mode is simply trying to wake a sleepy node, and tell it how long before the burst is over, and real transmission can start happening. Sorry if I over-repeat myself but some guys will find this useful in understanding how this actually works. Once a sleepy node is "woken", it can sleep for the rest of the burst period, then it can wake up again and sync with the master and do some real packet exchanges. Part of this mechanism is illustrated in the ListenMode examples which I posted in the ListenMode branch.

Tomme

  • Newbie
  • *
  • Posts: 24
Re: Ultra low power listening mode for battery nodes
« Reply #167 on: April 18, 2016, 02:34:36 PM »
I get what you are saying but Felix :). As I said I've been using longer preamble sequences successfully for a while, it suffers from scaling problems but it is nice and simple. I will probably move to something more similar to what you guys seem to be doing soon.

Have you considered having the target receiver node acknowledge when it receives the first "burst" packet? You could substantially improve contention in a larger network. A three second burst is all very well if you don't do it often but it isn't particularly feasible in a network where nodes need to route packets.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5841
  • Country: us
    • LowPowerLab
Re: Ultra low power listening mode for battery nodes
« Reply #168 on: April 18, 2016, 02:51:34 PM »
I think the 3s burst is to give the client up to 3 chances to latch a burst packet and wake up. We could reduce the sleep time of the listen cycle, so that we could use a 1s instead of 3s burst. But that would also mean increasing the relative RX time and hence reduce battery time. It's all a tradeoff. If you look at the listen code, you will see it's listening at a 1mhz offset from the main channel so as to not interfere with the main traffic.
An ACK is not feasible during a burst simply because the TX-RX transition of the master is too slow and we want a very linear interference free transmission to give a client a best chance to intercept the burst. The burst can of course be latched by multiple nodes - which would further complicate things if ACKs were involved. I think if you study the lib and examples it will become more apparent why things are done this way. If you hook up a current meter to your client while changing the RX/sleep duty cycle, and perhaps other settings, it will be even more plain why the settings are what they are. You can always change things around, but settings that work well were chosen to allow most people to get started and understand listen mode more easily.

Tomme

  • Newbie
  • *
  • Posts: 24
Re: Ultra low power listening mode for battery nodes
« Reply #169 on: April 18, 2016, 03:11:38 PM »
I understand why it was done the way it is. It is very much tailored for one application; an always on base station that only occasionally needs to communicate with nodes arranged in a star network. As soon as you move away from this you run into problems. When we start getting into situations where both sender and receiver are power constrained (and use listen mode) then a 3 second burst transmission is incredibly expensive in terms of power consumption.

If this comes across negatively, I apologise, I think that my requirements are just different to other peoples. I think that the sleep mode work that has already been done is great and will work for 90% of the situations that people are likely to encounter!

snorp

  • Jr. Member
  • **
  • Posts: 62
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #170 on: April 18, 2016, 03:18:41 PM »
I think the 3s burst is to give the client up to 3 chances to latch a burst packet and wake up. We could reduce the sleep time of the listen cycle, so that we could use a 1s instead of 3s burst.

Hmm, where is the 3s coming from? The code that I had (and TomWS's too) just used rx time + sleep time for the burst duration, which was set to about ~1s for me. It has always been reliable here without needing to send for a longer period.

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #171 on: April 18, 2016, 05:02:33 PM »
Quote
I think the 3s burst is to give the client up to 3 chances to latch a burst packet and wake up. We could reduce the sleep time of the listen cycle, so that we could use a 1s instead of 3s burst.

My code has a 3s burst but then also a 2.9s idle time. I find that nearly always wakes the mote. No need to try multiple times.

Joe

luisgcu

  • Newbie
  • *
  • Posts: 29
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #172 on: May 08, 2016, 10:25:35 PM »
I've separated Tom's listen mode from his ListenModeExtensions0 branch of RFM69_ATC (such that it inherits directly from RFM69). I added the ability to change the rx and idle durations for listen mode, disabled the AGC as Joe suggests, and changed the burst to send the time remaining instead of how far into the burst you are. There are also two simple wake/listen examples. I don't think the listen mode changes are nearly as invasive as the ATC ones, so maybe Felix would allow this (or similar) to be merged to RFM69?

https://github.com/snorp/RFM69_WL

(0) https://github.com/TomWS1/RFM69_ATC/tree/ListenModeExtensions

Hello ,
I am interested in use the low power listening  mode, so I decided to give a try to the  snorp branch of the  rfm69 library -->https://github.com/snorp/RFM69_WL, and it work  fine.
I tried to do the same test  with Felix  examples provided in the development library https://github.com/LowPowerLab/RFM69/tree/ListenMode but it won't work.. node go sleep ok..  I am monitoring the current while slepping..  it shows 1.6ua .. current start to increase in steps u to 94ua, then go down to 1.6ua .. the cycle is repeated, but the problem is  the sleeping node wont wake up when burst is sent from the other node .
not sure what I  am missing? I have repeated the test several times.. with no luck
is there any hardware connection that need to be set to get it working properly?
any program setting that need to be  adjusted ??
I am using moteinos  with RFM69w.

« Last Edit: March 26, 2019, 02:56:09 PM by Felix »
..Knowing other is wisdom,
knowing yourself is Enlightenment..

davegravy

  • Jr. Member
  • **
  • Posts: 56
  • Country: ca
Re: Ultra low power listening mode for battery nodes
« Reply #173 on: May 08, 2016, 10:55:35 PM »
I've separated Tom's listen mode from his ListenModeExtensions0 branch of RFM69_ATC (such that it inherits directly from RFM69). I added the ability to change the rx and idle durations for listen mode, disabled the AGC as Joe suggests, and changed the burst to send the time remaining instead of how far into the burst you are. There are also two simple wake/listen examples. I don't think the listen mode changes are nearly as invasive as the ATC ones, so maybe Felix would allow this (or similar) to be merged to RFM69?

https://github.com/snorp/RFM69_WL

(0) https://github.com/TomWS1/RFM69_ATC/tree/ListenModeExtensions

Hello ,
I am interested in use the low power listening  mode, so I decided to give a try to the  snorp branch of the  rfm69 library -->https://github.com/snorp/RFM69_WL, and it work  fine.
I tried to do the same test  with Felix  examples provided in the development library https://github.com/LowPowerLab/RFM69/tree/ListenMode but it won't work.. node go sleep ok..  I am monitoring the current while slepping..  it shows 1.6ua .. current start to increase in steps u to 94ua, then go down to 1.6ua .. the cycle is repeated, but the problem is  the sleeping node wont wake up when burst is sent from the other node .
not sure what I  am missing? I have repeated the test several times.. with no luck
is there any hardware connection that need to be set to get it working properly?
any program setting that need to be  adjusted ??
I am using moteinos  with RFM69w.

Not sure if it's related but mine only goes down to 6uA in listennode (running at 3v, regulator removed,  8mhz internal oscillator). I wasn't  aware of the snorp branch, I'm using the listennode branch from Felix's github, and it works fine for me.

luisgcu

  • Newbie
  • *
  • Posts: 29
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #174 on: May 08, 2016, 11:30:38 PM »
I've separated Tom's listen mode from his ListenModeExtensions0 branch of RFM69_ATC (such that it inherits directly from RFM69). I added the ability to change the rx and idle durations for listen mode, disabled the AGC as Joe suggests, and changed the burst to send the time remaining instead of how far into the burst you are. There are also two simple wake/listen examples. I don't think the listen mode changes are nearly as invasive as the ATC ones, so maybe Felix would allow this (or similar) to be merged to RFM69?

https://github.com/snorp/RFM69_WL

(0) https://github.com/TomWS1/RFM69_ATC/tree/ListenModeExtensions

Hello ,
I am interested in use the low power listening  mode, so I decided to give a try to the  snorp branch of the  rfm69 library -->https://github.com/snorp/RFM69_WL, and it work  fine.
I tried to do the same test  with Felix  examples provided in the development library https://github.com/LowPowerLab/RFM69/tree/ListenMode but it won't work.. node go sleep ok..  I am monitoring the current while slepping..  it shows 1.6ua .. current start to increase in steps u to 94ua, then go down to 1.6ua .. the cycle is repeated, but the problem is  the sleeping node wont wake up when burst is sent from the other node .
not sure what I  am missing? I have repeated the test several times.. with no luck
is there any hardware connection that need to be set to get it working properly?
any program setting that need to be  adjusted ??
I am using moteinos  with RFM69w.

Not sure if it's related but mine only goes down to 6uA in listennode (running at 3v, regulator removed,  8mhz internal oscillator). I wasn't  aware of the snorp branch, I'm using the listennode branch from Felix's github, and it works fine for me.

mmm.. I get it working after I  swapped the programs Listen node master---> from one moteino to the other.. I have to investigate what was that..  the only difference is one moteino has a pull down resistor on pin 3..
..Knowing other is wisdom,
knowing yourself is Enlightenment..

davegravy

  • Jr. Member
  • **
  • Posts: 56
  • Country: ca
Re: Ultra low power listening mode for battery nodes
« Reply #175 on: May 09, 2016, 07:34:25 AM »
Could be related to the radio hanging if you reset or rebooted the node while it was in listennode. Radio won't recover until its supply voltage drops really low and it can take a while for the moteino's 10uF supply capacitor to discharge. Have you tried swapping node/gateway back?

luisgcu

  • Newbie
  • *
  • Posts: 29
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #176 on: May 22, 2016, 07:07:39 PM »
Hello,
 I would like to know is anyone test the listen mode using low baud-rates?
it work fine as default settings on RFM69.CPP , but range distances are short.
 I tried  to change the below settings  without success..

 void RFM69::listenModeApplyHighSpeedSettings()
{
  if (!_isHighSpeed) return;
  writeReg(REG_BITRATEMSB, RF_BITRATEMSB_200000);
  writeReg(REG_BITRATELSB, RF_BITRATELSB_200000);
  writeReg(REG_FDEVMSB, RF_FDEVMSB_100000);
  writeReg(REG_FDEVLSB, RF_FDEVLSB_100000);
   writeReg( REG_RXBW, RF_RXBW_DCCFREQ_000 | RF_RXBW_MANT_20 | RF_RXBW_EXP_0 );
}
..Knowing other is wisdom,
knowing yourself is Enlightenment..

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #177 on: May 23, 2016, 04:23:58 AM »
If you use lower baud rates you need to increase the rx time because it will take longer to check for RSSI. This will make listen mode much more power hungry unfortunately. There is a formula in the data sheet that lets you calculate how long it needs to be.

At 1200 baud your talking several milliseconds instead of the 250 or so uS we've been using. I would recommend turning off AGC as well since that significantly increases RSSI detect time.

craigburden

  • Newbie
  • *
  • Posts: 13
Re: Ultra low power listening mode for battery nodes
« Reply #178 on: July 04, 2017, 08:35:43 AM »
Hello Everyone,

I have been trawling the forums for the solutions to my problems and this seems like the place to be!

So a quick overview of my system; I am developing an improved version of an existing system (The RF settings of which cannot be changed). The system uses FSK with a deviation of 165kHz and a bitrate of 26.5kbps. The devices are part of a mesh network that aims to get one device's messages a central device which can communicate with the outside world via GSM. All of the devices are battery powered and so power consumption is very important , however given how often transmission actually occurs I care less about power during transmission.

I have been experimenting a lot over the last few months with various RFM69 setups on our custom PCBs ( See the Thread here: https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/range-issues-with-rfm69xxw-on-custom-pcb) Since then we have designed a SX1231H tranceiver directly on our board which means no more module and less money! Yay :)

I have been experimenting a lot with listen mode and rx mode. Regardless of the listen mode configuration I see a significant drops in range. I am using the low power version and I see around 120m when purely in RX mode, however when going into Listen I struggle to get above 70m. I have tried every possible combination of longer RX times, AGC on and off, antenna impedances and ACG algorithms. I just can't get it to be a higher range. Note that all of those tests have been with a RSSIANDSYNC condition, meaning my RX time has had to be rather large which obviously isn't great for power consumption. After a good read of this thread today I am set on using RSSIONLY rather and setting timeout2 (Something I didn't do when I experimented with this before). I have started experimenting with this today in my building (Not the field that the above ranges were determined on). It doesn't seem much better range wise.

My listen config is:
rfm_reg(WRITE REG_LISTEN1,RF_LISTEN1_RESOL_RX_64|RF_LISTEN1_RESOL_IDLE_262000|RF_LISTEN1_CRITERIA_RSSI|RF_LISTEN1_END_00);
rfm_reg(WRITE REG_LISTEN2,10);   //IDLE ~2s
rfm_reg(WRITE REG_LISTEN3,10);   //RX  0.64ms
rfm_reg(WRITE REG_RXTIMEOUT2, 20); // Timeout ~12ms

Ignore my syntax, I am using Felix's H file on my pic microcontroller with SPI functions I wrote.  By my logic that should be okay given my setup? I have been testing with a RSSI threshold of 255 because I want to ensure that the device was attempting to receive the opportunity for now. The other issue I have with this radio is the lack of a relative RSSI threshold, I have no idea what a good absolute threshold is given that I don't control the environment the devices will be in. I also have no idea what the current sensitivity is given the bitrate and deviation, can anyone point me in the right direction?

And then I have one last curve ball, the device is a fire detector and a crucial part of the operation is regular temperature sampling meaning I cannot disturb that process. So the way I deal with that right now is to use the FIFONOTEMPTY flag rather than the PACKETREADY flag as it is not cleared provided by listen end is set to stay in full RX (Which obviously sucks for power). I have started playing the CLC (Configurable Logic Cell) in my PIC microcontroller which may allow me to latch a momentary IRQ pulse, meaning I can use the PACKETREADY flag rather. Am I correct in saying that I can then change my listen end to return to listen? provided that I am sure I will process the packet before the next RX wake up?

I'm sorry for the information over load I am just struggling to get this to work. Plus I hope that some if not all of these are helpful to others.

I am very happy to share my code too if anyone things they may need it?

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #179 on: July 04, 2017, 12:26:51 PM »
I have been testing with a RSSI threshold of 255 because I want to ensure that the device was attempting to receive the opportunity for now. The other issue I have with this radio is the lack of a relative RSSI threshold, I have no idea what a good absolute threshold is given that I don't control the environment the devices will be in. I also have no idea what the current sensitivity is given the bitrate and deviation, can anyone point me in the right direction?
It may sound counter-intuitive, and it isn't what the library seems to recommend, but I think the current consensus opinion (well, three of us anyway) is to leave RSSI threshhold at 255.  JoeLucid has written about why that works, and it's motivated by the reasons you say. 

Have you tried adding more pre-amble?  That might help with your range.  Joe and at least one other (was it Perky?) did some range experiments, and, IIRC, found that 4 is a good number of pre-amble bytes before diminishing returns.  However, you could  certainly go higher.
« Last Edit: July 04, 2017, 12:39:27 PM by WhiteHare »