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

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #90 on: September 06, 2015, 03:33:17 AM »
I can see on the oscilliscope that ListenResolIdle and ListenCoefIdle actually do control how long Listen-Mode's idle period lasts, but I'm starting to get the impression that the values set for ListenResolRx and ListenCoefRx are irrelevant.  Why?  Because once the Rx period of Listen-Mode is started, those values don't seem to influence how long the Rx period lasts.  Instead, once started, how long the Rx period lasts seems to be controlled by TimeoutRxStart, TimeoutRssiThresh, and PayloadReady.  Is that correct?  Or have I missed something? 

The clever thing about the RFM69's using the values TimeoutRxStart*16*Tbit and TimeoutRssiThresh*16*Tbit to set timer interrupts is that those values automatically change correctly whenever the datarate changes. 

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #91 on: September 06, 2015, 05:46:03 AM »
Quote
I can see on the oscilliscope that ListenResolIdle and ListenCoefIdle actually do control how long Listen-Mode's idle period lasts, but I'm starting to get the impression that the values set for ListenResolRx and ListenCoefRx are irrelevant.

That's correct. It's the misunderstanding just about anybody using listen mode seems to run into. The RX parameters control how long the radio looks for a signal (RSSI > Threshold) before deciding whether to go into RX. They can be much smaller than the duration of a whole packet. When the radio has switched into RX the timeout parameters control the size of the window.
 

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #92 on: September 06, 2015, 10:12:34 AM »
Quote
I can see on the oscilliscope that ListenResolIdle and ListenCoefIdle actually do control how long Listen-Mode's idle period lasts, but I'm starting to get the impression that the values set for ListenResolRx and ListenCoefRx are irrelevant.

That's correct. It's the misunderstanding just about anybody using listen mode seems to run into. The RX parameters control how long the radio looks for a signal (RSSI > Threshold) before deciding whether to go into RX. They can be much smaller than the duration of a whole packet. When the radio has switched into RX the timeout parameters control the size of the window.

When you said "the RX parameters" just then, were you referring to the two parameters ListenResolRx and ListenCoefRx  and only those two parameters?  I ask because the impression I'm starting to form (though I haven't yet collected enough data to confirm it) is that when the radio is looking for a signal (RSSI >= Threshold), it already is in Rx (and what I mean by that is that it is already consuming 16mA).   It's just that if (RSSI < Threshold) for a duration of TimeoutRxStart, then it can exit Rx early and commence Listen-Mode's idle period.  i.e. it's starting to look to me as though the values of ListenResolRx and ListenCoefRx actually never get used for anything at all, which if true seems rather  bizarre.  I may be jumping the gun in saying that, though.  Can you think of any scenarios where the particular values those variables are set to changes anything in any way?

Maybe instead of Rx, I should be calling it something like "the 16mA phase," which is when Rx and Rx related things seems to happen.  After the idle phase but prior to "the 16mA phase", the current ramps pretty rapidly as the Rx apparatus gets fired up and allowed to settle.

Except wait.  [Figurative lightbulb illuminates].  Now that I think of it, I've so far only tested with TimeoutRxStart = 0 (the default), so maybe there can exist a lower current phase that preceeds the 16mA phase when the RFM69 is just checking for whether RSSI has ever reached the threshhold.  That could be a match for what you're saying is happening.  With the default setting of zero for TimeoutRxStart that phase, if it exists, would be getting skipped over entirely.  So, thanks for the tip:  I'll try adding a large TimeoutRxStart to one of the next scope captures and see if the RFM69  shows a different pattern of current draw.  If ListenResolRx and ListenCoefRx only relate to that earlier RSSI phase, as you seem to be saying, then my having had TimeoutRxStart set to the default of zero would explain why ListenResolRx and ListenCoefRx have so far seemed like useless settings. 
« Last Edit: September 06, 2015, 11:06:34 AM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #93 on: September 06, 2015, 01:48:52 PM »
No, no. There are three phases in listen mode. 1. Idle, 2. RX and 3. actually trying to receive data. The current consumption in 2. and 3. is both 16 mA. You can configure how much evidence for the existence of data listen mode needs to move from 2. to 3.  - either RSSI exceeds threshold or node address matches (which causes the bug I had described). When in 3. the action is controlled by the timeouts. The RX listen parameters determine how long listen mode stays in stage 2 before moving back to 1. if no signal is found.

Clear now?

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #94 on: September 06, 2015, 02:47:07 PM »
After my last post I took some pictures.  Here are the first set of pictures I took.
ListenIdle = 102.5ms
ListenRx = 1.024ms
BitRate: 200Kbps
TimeoutRssiThresh = 0; (the default)
TimeoutRxStart = 0xFF;  implies 20.4ms

It's very repetitive and the 20.4ms seems to match.  ListenRx seems to play no role that I can see.

I'm using a 1 ohm sense resistor on the power line to the RFM69, so the legend is 1mV=1mA.



WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #95 on: September 06, 2015, 02:52:11 PM »
Here's the next batch.  Everything the same, except  this time:
[Edit: 
TimeoutRssiThresh = 0; (the default)
TimeoutRssiThresh = 0XFF;  ]

This time around there's some variability in the length of the Rx period, and so I zoom in a few of those for measurements.
« Last Edit: September 06, 2015, 10:36:49 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #96 on: September 06, 2015, 02:52:49 PM »
And here's the last shot from the second batch in the post direclty above:


WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #97 on: September 06, 2015, 02:55:05 PM »
It looks to me in the second batch that when RSSI goes above threshold, it probably resets the timeout clock.  So, in a noisy environment, the Rx period could be teased out indefinitely, which definitely isn't what I want.

So far, I still don't see how ListenRx fits into this, if at all.  Maybe it will become more apparent if I made it longer.

I gotta run on a family outting for now.  I'll be back later.
« Last Edit: September 06, 2015, 10:37:30 PM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #98 on: September 06, 2015, 03:12:34 PM »
Quote
It's very repetitive and the 20.4ms seems to match.  ListenRx seems to play no role that I can see.

It looks to me like your RSSI threshold is set so low (meaning REG_RSSITHRESH value set too high) that listen mode always proceeds to phase 3. I've recently adjusted mine to 180 since with my old setting 200 I was also seeing frequent phantom detections.

Joe

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #99 on: September 06, 2015, 10:46:10 PM »
I was rushing to post before the family outing, and I just now noticed that I made a typo in my description above regarding the second set of pictures.  Now that I'm back I corrected it in situ by striking through the erroneous line and replacing it with the correct info. 

Thanks for the suggestion about changing the RSSI threshold value.  It had been set to 220 by RFM69.cpp.  I'll try raising the threshold as suggested (using 180 instead) and see what effect that has.
« Last Edit: September 06, 2015, 11:16:37 PM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #100 on: September 07, 2015, 02:04:20 AM »
WhiteHare, if you want to start from something that works for me - here is my current code.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #101 on: September 07, 2015, 12:56:49 PM »
Where is it that you're setting REG_RXTIMEOUT1 (aka TimeoutRssiThresh)?. 

For a plain-vanilla Listen-Mode, it seems to me that TimeoutRssiThresh only needs to be long enough to span the gap between packets, plus one or two bits on either side of it.  That way, if nothing is detected above the threshhold (180 does seem popular), then the node can go back to sleep.

As I'm not yet ready to do that optimziation, for the moment I will leave it disabled.

 
« Last Edit: September 07, 2015, 01:20:11 PM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #102 on: September 07, 2015, 01:51:07 PM »
I've never used the Rssi timeout. My theory was that in phase 3 by definition RSSI has been detected so there'd be no reason to set a timeout.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #103 on: September 08, 2015, 12:04:26 AM »
No, no. There are three phases in listen mode. 1. Idle, 2. RX and 3. actually trying to receive data. The current consumption in 2. and 3. is both 16 mA. You can configure how much evidence for the existence of data listen mode needs to move from 2. to 3.  - either RSSI exceeds threshold or node address matches (which causes the bug I had described). When in 3. the action is controlled by the timeouts. The RX listen parameters determine how long listen mode stays in stage 2 before moving back to 1. if no signal is found.

Clear now?

Almost clear.  Let's see if we can make it completely clear.  Through experimentation, I in fact did find that if I raised the RSSI threshold high enough (such that RSSI is never greater than treshhold), then indeed Rx does timeout after tListenRx amount of time, and then the RFM69 goes into idle mode for TListenIdle amount of time before the next Rx.  In my case, I had to set the RSSI threshhold to about 155, as 180 was still too sensitive.

On the other hand, suppose at some point RSSI > threshhold during the Rx.  Then, if and only if the pre-amble is detected (correct?) the tListenRx timer is aborted and the RegRxTimeout2 countdown timer is started.  If it reaches zero before 1.  data payload is ready, and 2. if no further preambles have been detected, then Rx is exited and TListenIdle is started.  However, if another pre-amble is detected before the data payload is ready and before the countdown timer reaches zero, then the countdown timer is reset to RegRxTimeout2, and the countdown starts over again.

Are those the correct details?
« Last Edit: September 08, 2015, 12:07:37 AM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #104 on: September 08, 2015, 01:44:41 AM »
Quote
On the other hand, suppose at some point RSSI > threshhold during the Rx.  Then, if and only if the pre-amble is detected (correct?) the tListenRx timer is aborted and the RegRxTimeout2 countdown timer is started.  If it reaches zero before 1.  data payload is ready, and 2. if no further preambles have been detected, then Rx is exited and TListenIdle is started.  However, if another pre-amble is detected before the data payload is ready and before the countdown timer reaches zero, then the countdown timer is reset to RegRxTimeout2, and the countdown starts over again.

I don't think a preamble needs to be detected before listen mode goes into phase 3. It's either only RSSI or network address match that triggers the phase change depending on ListenCriteria in RegListen1. The timer2 generally runs beginning with RSSI being detected.

I had never considered what you describe in your last sentence - but that would actually explain the bug I had described. It's certainly not what one would want as listen mode user since with a long burst of packets destined for another node you'd never go back to idle.