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

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #15 on: June 06, 2015, 01:20:27 PM »
Ulli, great to see another listen mode enthusiast! I'm pretty thrilled with the results I'm seeing so far. It's great to have the feel of a live node with the power use of a sleeping node. rg your questions:

Quote
* Did you also recognised the bug that the RFM do never set the "RF_IRQFLAGS2_PAYLOADREADY" flag in listen mode when a message was received.
   I always have to check if a package is available with "RF_IRQFLAGS2_FIFONOTEMPTY"

I actually map payload ready to the interrupt pin and handle all data reads in the interrupt handler. That works so I assume the irq flag will also be set in that case.

Quote
*  I did not understand why you do not want to switch after a TX back to STANDBY/ListenMode. What is the benefit of that?
   I am always in ListenMode for the defined cycle except when the client were asked for informations or ACK.

My clients are always in listen. This is only for the sender of the packet burst. I want a continuous carrier signal to be sent for the entire burst period so that there is no chance of the client missing it during the .64ms rx cycle. If you switch to standby after tx and back the transmitter ramps down, then ramps up again etc. The clients need to do a new AGC cycle which takes time (RXRESTARTDELAY e.g.) and so on. All this produces a gap during which a client might miss the burst.

When you stay in TX the transmitter never ramps down.

Quote
* Regarding your encountered bug of the listen mode. Thats very interesting. How did you recogniced that? I want to check if that also happens in my configuration...


I measured power consumption using an ampere meter and noticed that the current went up to 16mA for a large part of the burst period in the nodes that weren't the target of the burst. Effectively the module went into RX and never went back to idle until the end of the burst.

I think this might be related to my carpet bombing burst approach. Maybe the radio just keeps listening until there's a gap in the transmission.

Quote
Is the bug also there when I use Adressfiltering and encription?

The bug only happens when I use address filtering. In fact that seems to be the key: listen criteria is met, rx is left on and the radio just seems to continue listening until it finds a packet that matches the address or until the burst ends.

Encryption I can't use because you can't leave the TX on for multiple packages with encryption.   
« Last Edit: June 06, 2015, 01:28:08 PM by joelucid »

TomWS

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1800
Re: Ultra low power listening mode for battery nodes
« Reply #16 on: June 06, 2015, 04:37:18 PM »
Tom, when I measure the current of the moteino I see two patterns depending on whether the listener decides to keep the radio on or not. If the radio is on for 20ms instead of .6ms that shows as higher reading on the ampere meter. This is what I did and I could verify that the sleepers did not detect a signal and switched the radio off after .6 ms.
Thanks.
As for the chip prolonging the rx cycle even if the criteria hasn't been met in the hope that it might be later on - that behavior for me is inconsistent with the pretty precise wording of the spec. So I'll leave that experiment to you :)
I'll accept the 'challenge'!  I'll get to it when I finish up everything else... ::)
« Last Edit: June 06, 2015, 04:47:34 PM by TomWS »

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #17 on: June 08, 2015, 03:05:37 AM »
I gave this one more round of optimization:

I figure RSSI is best read when there is a white load on the line - so switched on RF_PACKET1_DCFREE_WHITENING and changed REG_SYNCVALUE to 0x5a5a. I'd like to say this improved things - but I couldn't really tell.

Disabling AGC didn't yield any benefits unfortunately.

I played with cutting down the duty cycle some more and it turns out 0.384 ms is enough to work reliably. I also had the idle cycle a little short for my 3 sec burst time which sometimes led to duplicate receives. So that's now at 2882 ms.

Overall that gives us 0.384 / 2882 = 0.0001332 for the duty cycle and an expected battery use of 2.1 uA. Which is close enough to nothing that I'm switching this on for all nodes.

Finally I added a node address of 255 as broadcast address. This is sometimes nice: when I want to see what's up I just broadcast a request for measurement and all nodes report back with their current data.

Enjoy attached.


ulli

  • Jr. Member
  • **
  • Posts: 82
Re: Ultra low power listening mode for battery nodes
« Reply #18 on: June 08, 2015, 04:04:58 PM »
I do not understand why whitening can improve your listen mode??
Regarding the different sync words, I could imagine that you have another traffic on the frequency which uses the same sync words like you had configured before? That could increase your current consumption because the rfm module may reacts for foreign transmissions?

The minimum RX time in the listen mode is of course a function of your configured bitrate and the configured RX listen timeout time.
What bitrate and RX timeout time do you use?

I think we could decrease the current consumption more if we could get a PayloadReady flag after receiving messages, because otherwise the RFM will always stay in RX mode as long as the RX timeout is not exceed!


What do you think?

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #19 on: June 08, 2015, 04:57:29 PM »
Quote
I do not understand why whitening can improve your listen mode??

My sense that this might help comes from section 3.4.9 in the datasheet:  "The RSSI sampling must occur during the reception of preamble in FSK, and constant 1 reception in OOK.".

With the listen scheme I think that condition cannot be satisfied with such short rx times. So the question becomes why should RSSI detection be done during preamble? Well I don't know exactly how RSSI detection works - but I do know that the preamble is white and it seems intuitive to me that it would help to have a signal that isn't nailed to one side of the spectrum. Thus the change. Admittedly not a very strong basis to justify a change that I can't really prove is useful .. anyway.

Quote
Regarding the different sync words, I could imagine that you have another traffic on the frequency which uses the same sync words like you had configured before? That could increase your current consumption because the rfm module may reacts for foreign transmissions?

Well that would be ok and expected. But what's unexpected is the reaction to a very specific signal that I generate myself: a burst sequence but targeted at another node. In that case I would expect listen mode to verify the criterion "RSSI detected" and keep RX on after the sub ms period. It should now look for packets until the 20ms timeout is over or payload is available. Since the burst is for another node no packet will match and the radio should go into idle after 20ms.

But what happens is it stays in RX for seconds - until the burst is over. Way longer than 20ms. This clearly is not consistent with the spec. Thus the workaround of running in promiscuous mode.

Quote
The minimum RX time in the listen mode is of course a function of your configured bitrate and the configured RX listen timeout time.
What bitrate and RX timeout time do you use?

Bitrate is Felix standard 55555.  RX listen timeout is ~20ms. Given that I use "RSSI detected" as exit criterion the second part of your statement is actually incorrect. The minimum time in RX is exactly what I program it to be. The question is can the radio detect RSSI during that time? And how much time does the radio stay in RX if RSSI has been detected until timeout or payload available. In my last post I gave the minimum rx period that still works for RSSI detection at 55555baud.

RSSI detection would be quicker at higher bitrates - but I also want things to be reliable. I use 200kbit/s in my bootloader, but that also dynamically degrades to 55555bit/s / 19200bit/s. That seems difficult to do here.

Quote
I think we could decrease the current consumption more if we could get a PayloadReady flag after receiving messages, because otherwise the RFM will always stay in RX mode as long as the RX timeout is not exceed!

I don't know about your system - but in mine it's far more often the case that there is no packet for the listener than that there is. So I'm trying to optimize for that case with the very short duty cycle. My rx timeout is so long that it will always include one full packet. So if the signal comes from a gateway burst I will get PayloadReady and the radio is put into idle before timeout.

I don't understand how we could further reduce power consumption? Actually I'm happy with power consumption but I would love to get a shorter idle period. About 3 seconds burst time is a bit lame.

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #20 on: June 08, 2015, 05:09:16 PM »
Just to sum up: the key to ultra low power is to establish as quickly as possible if there is any signal on the line. If there is you can invest more resources to find out if it is for you. If not you want to hit the snooze button and return to your dreams.
« Last Edit: June 08, 2015, 05:11:05 PM by joelucid »

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #21 on: June 12, 2015, 01:49:34 AM »
Here's one week of battery data from my water thermometer:



This is using a alkaline 9v battery. You can see how I frequently installed new versions around last weekend as I was ironing out bugs and improving listen mode. Since beginning of the week Vin has been consistently at 8.46V.

It's a somewhat used battery but at 8.46V it's still at the steep beginning of the discharge curve. So everything points to me actually getting many years of battery life with this Moteino while in listen mode.

River

  • Newbie
  • *
  • Posts: 5
Re: Ultra low power listening mode for battery nodes
« Reply #22 on: June 12, 2015, 07:47:38 AM »
Hello Joelucid,

Please, first excuse my novice ideas...

I have sleeping nodes each one wakes after 50 seconds sleeping and send a message to the "master" node if they must change an output the master  sends back and the node act accordingly.

If I understand your method, this means that the node is listening and I can change the outputs near real time without sacrifice battery life?
I will test your solution and see if I can implement successfully..

Thank you for sharing this!

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: Ultra low power listening mode for battery nodes
« Reply #23 on: June 12, 2015, 11:31:38 AM »
Hi Joe,

Turns out there is a bug in the RFM69HW listen mode which causes the radio to stay in RX even after timeout if address filtering is used and a packet is received that doesn't belong to the node. This caused power waste in non target nodes - all of them wake up when the 3s burst comes and stay in receive for about half of the time.
If you have the label "RegRxTimeout1" set to 0, I think the descriped issue will occure. Did you doublecheck to set the label to 0x10 for example?
By the way, could you help me to understand the calculation stated in the docs. (TimeoutRssiThresh*16*T bit)
If I want a Timout of 10ms, what value do I have to set in the Timeout label?

What value are you currently using for "RSSITHRESH"?

Code: [Select]
My rx timeout is so long that it will always include one full packet.
I would recommend to use twice the packagelength, to be sure that in any case you will receive one full package.
« Last Edit: June 12, 2015, 11:36:16 AM by ulli »

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #24 on: June 12, 2015, 11:38:50 AM »
River,

Yes you could use listen mode that way. It depends on how much traffic you want to send to your clients, you latency requirements and your power budget. The length of the idle cycle (currently around 3 seconds) limits the overall traffic you'll be able to send since the sender needs to send a continuous signal for that length to transfer one packet. So with what I posted you can send 1 packet every 3 seconds. You maximum latency will also be 3 seconds and battery use practically negligible.

If you need more throughput or less latency you can sacrifice more battery life for a shorter idle period. For example go to 300ms and spend an average of 21uA on listen mode, which would still be quite acceptable (around 0.4 mAh per day).

You'd also need to implement an ack mechanism so you can be certain that the action was performed by the client.

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #25 on: June 12, 2015, 12:03:38 PM »
Ulli,

I set timeout2 which I thought was more appropriate since RSSI by definition was already detected.  This does work for traffic from other networks where the timeout does hit. But this is a good idea to try as workaround.

I think Tbit is the time it takes for 1 bit to be sent so you can calculate baed on the baud rate you're using.

I use 180 as RSSI threshold which translates to -90.

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: Ultra low power listening mode for battery nodes
« Reply #26 on: June 13, 2015, 08:55:08 AM »
Hi,

I worked a bit on the config with the infos of Joe and he is right I gues . The data whitening looks like it inproves the transmission in ListenMode.
I now have the following config which workes great so far. (latency of ~300ms of each command from the master montino to the client)
Code: [Select]
/* 0x03 */ { REG_BITRATEMSB, RF_BITRATEMSB_55555},
/* 0x04 */ { REG_BITRATELSB, RF_BITRATELSB_55555},
/* 0x0D */ { REG_LISTEN1, RF_LISTEN1_RESOL_IDLE_4100 | RF_LISTEN1_RESOL_RX_64 | RF_LISTEN1_CRITERIA_RSSI | RF_LISTEN1_END_10 },
/* 0x0E */ { REG_LISTEN2, 0x40 }, -> 262ms
/* 0x0F */ { REG_LISTEN3, 0x05 }, ->0,320ms
/* 0x2A */ { REG_RXTIMEOUT1, 0x11 }, -> 5ms
/* 0x2B */ { REG_RXTIMEOUT2, 0x20 }, -> 9,2 ms (max 32 bytes payload)
/* 0x37 */ { REG_PACKETCONFIG1, RF_PACKET1_FORMAT_VARIABLE | RF_PACKET1_DCFREE_WHITENING /*RF_PACKET1_DCFREE_OFF*/ |
    RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON |
    RF_PACKET1_ADRSFILTERING_NODEBROADCAST },
/* 0x29 */ { REG_RSSITHRESH, 0xE4 /*MAX*/ }

But I still have a question for my understanding:
We set up the RX time with the label REG_LISTEN3. For example to a RX time of 0,320ms.
And we also set up a Timeout for RSSI detection with the label "RegRxTimeout1" -> Doc says "Timeout duration between Rx request and RSSI detection"
--> How long do I really now have to stay in RX mode (high power consumption) when no transmission can be detected?
The 0,320 ms or the Timeout(RegRxTimeout1) duration?

Thanks a lot!
« Last Edit: June 13, 2015, 09:13:35 AM by ulli »

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #27 on: June 13, 2015, 03:18:55 PM »
Ulli the way I read the spec is that the listen exit actions only get considered once the listen criteria has been met. With our parameters that means once rssi has been detected. So no RSSI no rx after the .320ms ex period. Only then will the radio continue to receive until a timeout or payload ready occurs.

This is also why I think one doesn't need to set timeout1 which measures time between switching to rx and RSSI detection: we'll only get there if the acceptance criteria has been met - which means RSSI was already detected.

Have you measured your current consumption? I see that your using address filtering and so I would expect you to hit the bug I had described where the radio will continue in rx  in non target nodes until end of burst. Are you keeping the burst radio in tx?

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #28 on: June 13, 2015, 04:17:06 PM »
Ulli, I gave it one more shot with address filtering. I still get the same problem even with timeout1 set. You should really measure if you don't get the same problem.

BTW, I think your timeout2 is set way too tight. You don't know where in the packet your rx cycle hits - so you might need to wait for the next one. Then there are a couple of bytes of overhead (3x preamble, 2x network, size, node, crc). Finally there might be pauses between packets.

Also your RSSI threshold is very low which will likely result in phantom signal detection and increased battery use. 
« Last Edit: June 13, 2015, 04:31:33 PM by joelucid »

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: Ultra low power listening mode for battery nodes
« Reply #29 on: June 14, 2015, 06:34:46 AM »
Quote
Ulli the way I read the spec is that the listen exit actions only get considered once the listen criteria has been met. With our parameters that means once rssi has been detected. So no RSSI no rx after the .320ms ex period. Only then will the radio continue to receive until a timeout or payload ready occurs.
Ah, got it! I tought when it is checking the RSSI value, the module already is in RX mode...

Quote
Ulli, I gave it one more shot with address filtering. I still get the same problem even with timeout1 set. You should really measure if you don't get the same problem.
Did you measure the current with a simple multimeter? I will give it a try later and let you know...

Quote
BTW, I think your timeout2 is set way too tight. You don't know where in the packet your rx cycle hits - so you might need to wait for the next one. Then there are a couple of bytes of overhead (3x preamble, 2x network, size, node, crc). Finally there might be pauses between packets.
Also your RSSI threshold is very low which will likely result in phantom signal detection and increased battery use.
You are right, I just did the calculation with the payload... :-/
I will set it to ~20ms --> 0x43 and the rssi threshold to -90

Great support :)
Also your RSSI threshold is very low which will likely result in phantom signal detection and increased battery use. 
[/quote]