Author Topic: Is "Listen Mode" demonstrated in any of the official demo sketches?  (Read 7914 times)

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #30 on: September 17, 2015, 06:49:48 PM »
My point is ... you can only receive when you listen.
So .. nice battery savings, but that also means you'd only receive an average of 1 out of 1000 packets sent to it, when you listen 1 out of 1000 units of time, right?

Notionally, yes, you have approximately the right idea.  Not that it matters (well, at least to me), but technically the "on average" number would be closer to 1 out of 500 packets, if the transmission start time was random.  If you were wanting to transfer a lot of data but only using listen mode to receive it at one packet a second, I would guess you would be worse off, because each waking of the arduino takes about 2.1ms of wasted current during warm-up on an 8mhz atmega328p and at least some time and current are lost in the process of going into PowerDown sleep.  On the other hand, if the time between packets is normally greater than 2.1ms, maybe you wouldn't be worse off.... I'm not sure.  Is anyone currently putting the arduino to sleep while waiting for the next packet when a train of packets is expected to arrive and then waking up "just in time" to process it?  I'm not sure it would be worth the effort, but maybe.  The big savings seem to happen from being in a deep sleep for a long time at the lowest current possible, and that tends to overshadow smaller optimizations.

I think a smaller Rx window could probably be achieved, which would be a desirable improvement for less wasted Rx current over time or reduced latency but the same cost in Rx current by having shorter cycles.  How much smaller it could be I don't know.  Actually, it's easy to shorten the Rx window--it's getting a non-continuous Tx cycle that's short enough to hit it reliably that gets harder.  Right now when a proper packet is received at 200Kbps, DIO0 goes high 100 microseconds before the Rx current starts its fall to the idle current level, so with that as my only datapoint, I'm doubtful that an Rx current window of a mere 100uSec or less would be possible in Listen Mode.  How much longer than 100uSec it would need to be, though, I'd be curious to know.   On the other hand, the Rx windows just for detecting the start of a Tx  could be less than 100uSec, provided that it can be "stretched" to wider by the timeouts when the start of a Tx is detected within that smaller window.  64uSec would be the absolute shortest limit that Listen Mode can be programmed for.  @Joe and/or @Tom: are you already at the 64uSec limit?

At present I'm simply using sendFrame in a tight loop.  To get less of a gap between Tx's, to hit smaller Rx windows every time, I'd need to open that up and optimize at a finer granularity within it to get a tighter gaps between packets but still remain non-continuous.   Cutting the Rx window duration in half might not be too hard.  I may wait, though, until I'm sure I have a definite need for that.
« Last Edit: September 17, 2015, 09:37:09 PM by WhiteHare »

TomWS

  • Hero Member
  • *****
  • Posts: 1925
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #31 on: September 17, 2015, 08:25:39 PM »
@Joe and/or @Tom: are you already at the 64uSec limit?
No.  In the Library I posted we have a multiplier of 4 @ 64uS for RX = 256uS (High Speed mode), and 11 @262000 Idle = 2.882 seconds or a ratio of 11 something thousand to 1.  A bit of energy savings there...  :)

Tom
« Last Edit: September 17, 2015, 08:36:40 PM by TomWS »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #32 on: September 17, 2015, 09:59:22 PM »
Come to think of it, I was working from the assumption that I wanted to get 100% hitrate, but for something like a soil moisture sensor, where the exact frequency of the update isn't so important, maybe you could get by with a 64uSec Rx window, and if you fire enough packets at it (the shorter the better and the more tightly spaced the better), eventually one of them should snag it, even if they aren't as short or as fast as what would be ideal for a 100% hit rate.  Anyhow, just a theory, as I haven't tried going that low.  If the problem were relaxed in that manner, then it would only take a few experiments with the existing setup to get a feel for how small a window can still be hit with the present version packets within a reasonable length of time. 
« Last Edit: September 18, 2015, 12:54:18 AM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #33 on: September 18, 2015, 01:36:27 AM »
Quote
maybe you could get by with a 64uSec Rx window

I systematically tested the minimum rx window for both Felix 55555baud setting and for my 200kbaud with a continuous burst. At Felix setting 6@64uS is the minimum, at 200kbaud 4@64uS. It would probably make sense to try 300kbaud. That might enable us to shorten a bit more but given the small improvement between 55k/200kbaud probably not by much.

But we should really try Ulli's suggestion (wait until fifo empty instead of manual delay). That would send a lot more packets per time for small packets and therefore significantly reduce rx power consumption when receiving a packet.
« Last Edit: September 18, 2015, 01:47:23 AM by joelucid »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #34 on: September 18, 2015, 06:32:45 AM »
So, just to be clear, at 200K data rate with a cointinuous burst, you're getting 100% hits at 4x64us, and 0% hits at 3x64us (in both cases with the same value in RegRxTimeout2)? 
« Last Edit: September 18, 2015, 06:37:58 AM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #35 on: September 18, 2015, 06:37:19 AM »
100% yes. 0% maybe not quite, but it was very unreliable.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #36 on: September 18, 2015, 07:23:42 AM »
100% yes. 0% maybe not quite, but it was very unreliable.

Was that with a 1 byte preamble and a 1 byte sync word or the chip defaults (3 byte preamble, and a 4 byte sync word) or something else?  Not sure if it's relevant, but the chip defaults would take 280us to receive for just the preamble and sync word alone, and so maybe at this small scale that starts becoming a factor.  I can't claim to be intimately familiar with every aspect of  the datasheet, so offhand I couldn't really say whether or not its just coincidence.  Felix's RF69 library defaults to a 2 byte node address, but I don't recall offhand whether or not it changes the default number of bytes for preamble or sync word.
« Last Edit: September 18, 2015, 07:35:55 AM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #37 on: September 18, 2015, 07:35:15 AM »
Quote
Not sure if it's relevant, but the chip defaults would take 280us to receive for just the preamble and sync word alone, and so maybe at this small scale that starts becoming a factor.

Not really relevant. Remember the 1st phase is only RSSI detection, so it doesn't really matter.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #38 on: September 18, 2015, 08:06:53 AM »
That's what's puzzling.  Since your burst is continuous, wouldn't the first phase conditions be met all the way down to 64us?  And if that's true, and there's no change in RegRxTimeout2, then shouldn't it still get your packet at 64us?  In short, what's keeping it from working just as well at less than 4x64us?  It would seem that some unknown factor (well, unknown to me at least) is getting in the way.
« Last Edit: September 18, 2015, 08:26:44 AM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #39 on: September 18, 2015, 11:02:50 AM »
FWIW, I just now ran the experiment on my simplistic setup with address filtering on.  With ListenIdle=1sec, I still observed packets received when ListenRx is 9x64us (not at 100% hit rate, so not ideal but still useable for triggering sensor updates if you didn't mind waiting).  I was able to observe some packets get through at 7x64us, but only by reducing ListenIdle to 4.1ms, so I wouldn't call it practical.  At 6x64us and below, however, I didn't observe any packets received, at least not within the timeframe that I was looking.

I think it's probably better, though, to have 100% hitrate and just expand ListenIdle if more energy savings are desired.  Without thinking about it too hard, I get the impression that would save the most energy, and it obviously leads to more predictability.  On the other hand, for really long sleep intervals that are greater than 63seconds, it might save nearly half the energy.
« Last Edit: September 18, 2015, 11:40:57 AM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 867
Re: Is "Listen Mode" demonstrated in any of the official demo sketches?
« Reply #40 on: September 18, 2015, 03:11:11 PM »
It just takes time to switch the radio into RX and measure RSSI.