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

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Ultra low power listening mode for battery nodes
« Reply #135 on: February 26, 2016, 01:11:53 AM »
@joelucid,

Puzzling, but real. Yes, OOK does not involve directly changing the carrier frequency, but the act of modulation does!  For a simplified explanation, just take the case of an "lighter" modulation scheme whereby the carrier strength is halved for a '1' bit.  Then a stream of 10101... at say 1Kbaud would be similar to amplitude modulation with a square wave of 1Khz.  This generates the familiar a.m. upper and lower sidebands around the central carrier.  Now imagine the depth of modulation increases - the sidebands get fatter. In the limit, the carrier is completely cutoff for the period of the '1' bit - the sidebands don't vanish at this point.

So you end up with a similar relationship as the FSK case - the faster you modulate, the broader the spectrum spreads.  Pass that through too narrow an Rx filter will loose signal entropy that will lead to decoding errors.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #136 on: February 26, 2016, 04:34:13 AM »
Quote
Puzzling, but real.

Interesting! Thanks for the explanation.

Tomme

  • NewMember
  • *
  • Posts: 24
Re: Ultra low power listening mode for battery nodes
« Reply #137 on: February 26, 2016, 11:41:29 AM »
The comparison isn't entirely fair because this mote is powered from 9V via a buck converter. But anyway: I'm measuring 590nA total average current in this mode. That's for a mote that's reachable in 1.5s on average at any time. Including 328p and radio sleep current etc.

How exactly are you achieving a current draw that is less than the RFM's idle current draw (1.2 uA)? Is that 590 nA at 9 V or are you sleeping the radio module for some amount of time?

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #138 on: February 26, 2016, 11:46:23 AM »
Quote
How exactly are you achieving a current draw that is less than the RFM's idle current draw (1.2 uA)? Is that 590 nA at 9 V or are you sleeping the radio module for some amount of time?

Both. It's 590nA at 9V and the radio is asleep at 100nA when I'm not detecting RSSI. I'm not using the radio's listen mode but have implemented a similar concept driven by the 328p. The 328p uses a low power RTC to make it possible to achieve such low currents.

Tomme

  • NewMember
  • *
  • Posts: 24
Re: Ultra low power listening mode for battery nodes
« Reply #139 on: February 27, 2016, 05:38:32 PM »
Just looking through the data sheet again and noticed that the crystal oscillator start-up time, TS_OSC, is typically 250 uS. Since this has to happen before the PLL lock (I assume) does this mean that theoretically we shouldn't be able to do better than 250 uS +80 uS + TS_RE?
« Last Edit: February 27, 2016, 05:51:19 PM by Tomme »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #140 on: February 28, 2016, 10:47:52 AM »
Quote
does this mean that theoretically we shouldn't be able to do better than 250 uS +80 uS + TS_RE?

I suspect no, since I'm using 256uS with 200kbit. They might just not include the oscillator start-up time in the RX period.

Tomme

  • NewMember
  • *
  • Posts: 24
Re: Ultra low power listening mode for battery nodes
« Reply #141 on: February 28, 2016, 02:18:16 PM »
I'm not sure I understand what you mean? Do you mean that we specify the RX period and the oscillator is automatically started 250 uS before the scheduled RX time?

I was using 256uS with 55 kbit successfully so I'm not sure what to think!

It's worth noting that the datasheet does say "The above timings represent maximum settling times, and shorter settling times may be observed in real cases".

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #142 on: February 28, 2016, 02:45:19 PM »
Quote
Do you mean that we specify the RX period and the oscillator is automatically started 250 uS before the scheduled RX time?

That was my guess. Oscillator startup definitely takes ~200-250uS. I've seen that in my manual listen mode implementation.


niranjan_187

  • NewMember
  • *
  • Posts: 5
Re: Ultra low power listening mode for battery nodes
« Reply #143 on: April 01, 2016, 10:18:07 AM »
Hi Joelucid,

I have been trying to get the wireless wake up stuff get going for quite some time, however, not yet being able to succeed with the same. I tried to use the library developed by you. So I follow the exact steps mentioned by you for client side and Server side, but still cant see anything working. Not sure if I am missing out on something.   

I would be thankful if you could guide me with the wireless stuff. If you have some example test code may be?

Thank you in advance.

snorp

  • Jr. Member
  • **
  • Posts: 62
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #144 on: April 06, 2016, 04:46:39 PM »
Joe, have you tried making any changes that would allow using encryption during listen mode? My understanding is that you disabled it initially because you have to reset the TX mode between packets during the burst, is that right? Would it be too slow to do that? I am not seeing anything in the datasheet that would prevent it from working otherwise, and was going to give it a shot.

It's not that big of a deal, but right now I don't use the listen mode to send any interesting info -- just wake up the node so it's ready receive a "normal" packet. But if I could avoid that step and just send the actual command in the burst (encrypted), that would be pretty nice.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Ultra low power listening mode for battery nodes
« Reply #145 on: April 06, 2016, 05:01:30 PM »
I wanted to avoid gaps in the burst so that the rx window could be as small as possible. You can certainly switch to standby and back between packets so that encryption works. But then your rx window needs to be at least as long as the gap in the burst.

snorp

  • Jr. Member
  • **
  • Posts: 62
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #146 on: April 06, 2016, 10:40:10 PM »
I wanted to avoid gaps in the burst so that the rx window could be as small as possible. You can certainly switch to standby and back between packets so that encryption works. But then your rx window needs to be at least as long as the gap in the burst.

Yeah, makes sense. I guess I'm not really interested in trading battery life for encrypted burst, so I'll leave it alone.

snorp

  • Jr. Member
  • **
  • Posts: 62
  • Country: us
Re: Ultra low power listening mode for battery nodes
« Reply #147 on: April 06, 2016, 10:44:49 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

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Ultra low power listening mode for battery nodes
« Reply #148 on: April 07, 2016, 08:07:31 AM »
snorp,
Definitely something I will be looking into. Thanks for sharing it!!

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Ultra low power listening mode for battery nodes
« Reply #149 on: April 07, 2016, 08:21:28 AM »
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
Good job on the integration!  One flaw in the current ATC code and carried into your is the RSSI_Threshold value:

Line 298  in the .cpp file has:
Code: [Select]
  writeReg(REG_RSSITHRESH, 200);
200 is WAY too high and you will be waking all the time due to spurious noise (DAMHIKT!).   I'm currently using a value of 160-170 depending on the environment.  This should probably be a settable parameter.

Keep this up and I can remove it from the ATC code!

Tom