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

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #30 on: June 14, 2015, 03:17:21 PM »
Yeah, just simple multimeter. You'll definitely see if the current jumps up to 16mA for non target nodes.

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #31 on: June 15, 2015, 09:22:02 AM »
BTW Ulli, if unlike me you have frequent traffic to the listening nodes you could consider a two step protocol where the listening node is only woken up and then pings the gateway for the next command.

This would drastically reduce the waking packet size (say fixed length packet, payload 1 byte, sync word 1 byte, preamble 1 byte etc) and therefore timeout2, hence reducing power consumption for other sleeping nodes.

ulli

  • Jr. Member
  • **
  • Posts: 82
Re: Ultra low power listening mode for battery nodes
« Reply #32 on: June 16, 2015, 11:51:57 AM »
BTW Ulli, if unlike me you have frequent traffic to the listening nodes you could consider a two step protocol where the listening node is only woken up and then pings the gateway for the next command.

This would drastically reduce the waking packet size (say fixed length packet, payload 1 byte, sync word 1 byte, preamble 1 byte etc) and therefore timeout2, hence reducing power consumption for other sleeping nodes.

I need a as short as possible latency of my command. Because it is a "IR-TX Satellite".
I do not think that it would be better to do a two "step protocol" because I need to send two commands which will be recognized by all satellites/clients.
1. waking packet
2. command packet


abraxas1

  • Newbie
  • *
  • Posts: 4
Re: Ultra low power listening mode for battery nodes
« Reply #33 on: June 23, 2015, 07:45:15 PM »
i like this approach to low power and wireless programming but am having trouble implementing it.
do i have to derive my own RFM69 class to use this? everything seems protected. but you call the original methods...
for instance,

libraries/23718_cb_personal_lib_listen/listen.cpp:20:13: error: 'select' is a protected member of 'RFM69'
    pRadio->select();
libraries/23718_cb_personal_lib_RFM69/RFM69.h:139:10: note: declared protected here
    void select();
libraries/23718_cb_personal_lib_listen/listen.cpp:46:15: error: no member named 'getAddress' in 'RFM69'; did you mean 'setAddress'?
        node = radio.getAddress();

this is educational for me and very interesting , so, thanks!


TomWS

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1755
Re: Ultra low power listening mode for battery nodes
« Reply #34 on: June 23, 2015, 09:31:07 PM »
@abraxas1, I think you should think of this thread as work in progress and focus on the more fundamental threads using Moteino in a low power way.  This particular thread is using a totally different approach and won't have a lot of support at the moment, while the more mainstream approaches will be good for most users and, if you learn those fundamentals, you'll be able to quickly pick this up once it has matured.

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #35 on: June 24, 2015, 01:29:55 AM »
Abraxas, I just made these two changes in the RFM69.cpp file (making select public and adding getAddress). You could probably derive from the class to do it more cleanly.

Tom is definitely right that this is a project report from me rather than code supported by Felix. That said I do run it on all my nodes in 'production' and I'm very happy with it.

Joe

abraxas1

  • Newbie
  • *
  • Posts: 4
Re: Ultra low power listening mode for battery nodes
« Reply #36 on: June 25, 2015, 08:25:28 PM »
thanks gents, was really wondering about that getAddress... :-)
i'm pretty experienced at hardware, just have avoided the OO in c++ for all these years since it came about. would rather work in Matlab and have simple c drivers.
i was just about to make those changes myself, as a way around  my compile "problem", so i guess i'm on track.
was hoping to get some tech like this in my project from early on, though i have a working system now, and ultra-low-power isn't a concern at this moment. but it seems to really boost overall system performance, and is damn neat.
i appreciate any updates on this work when the occasion arises.
wish this forum would notify me of updates to this thread though.

Mike


River

  • Newbie
  • *
  • Posts: 5
Re: Ultra low power listening mode for battery nodes
« Reply #37 on: July 15, 2015, 12:27:12 PM »
Hello joelucid / abraxas

I'm trying to implement this, so I copied the listen files and generated another library copied from felix original ones and renamed to RFM69ULP.

I've sucessfully pointed the right files and modified the select, unselect and setMode. But I'm having problems with getAddress function.
Tried to implement on my own but maybe I'm not on the right way.

Quote
listen.cpp:In static member function 'static void RFM69Listener::startListening(RFM69&, void*, uint8_t)'
listen.cpp:47:26: error: no matching function for call to 'RFM69::getAddress()'
listen.cpp:candidate is
RFM69ULP.h:getAddress(uint8_t)
RFM69ULP.h:candidate expects 1 argument, 0 provided
RFM69ULP.cpp:In member function 'void RFM69::getAddress(uint8_t)'
RFM69ULP.cpp:187:33: error: no matching function for call to 'RFM69::readReg(int, uint8_t&)'
RFM69ULP.cpp:candidate is
RFM69ULP.h:readReg(uint8_t)
RFM69ULP.h:candidate expects 1 argument, 2 provided

Attached you'll find the "modified" library
Many thanks in advance!
« Last Edit: July 15, 2015, 12:29:04 PM by River »

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #38 on: July 18, 2015, 05:35:20 AM »
River,

Your getAddress() implementation should not have an argument. I've added mine inline in RFM69.h:

uint8_t getAddress() { return _address; }

That should work.


TomWS

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1755
Re: Ultra low power listening mode for battery nodes
« Reply #39 on: July 19, 2015, 12:04:12 PM »
Well, I'm looking forward to seeing your numbers (and seeing the code you've been talking about for a while  ;)

The latest updates I've put in my node seem to have addressed the power drain issue (he said, keeping his fingers crossed).  It's running now and I'll post the results in a few weeks (that's probably when my PCBs will be here) when it's run long enough to be meaningful.

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #40 on: July 21, 2015, 05:16:30 AM »
I ran a couple of tests prototyping this setup:

When running without WDT but with radio in listen mode I measure a sleep current of 1.1uA. Running at 200kbaud I was able to cut down the listen period to 0.256 ms for an average power consumption for the receive spikes of 0.256ms / 2882ms * 16ma = 1.4uA. With that the total average sleep current is 2.5uA.

It's actually pretty amazing: I now have to short 3.3V against GND to get the Moteino to reset - the 10uF cap on the board powers the processor in sleep for what seems like an eternity ;)

Joe
« Last Edit: July 21, 2015, 05:18:30 AM by joelucid »

TomWS

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1755
Re: Ultra low power listening mode for battery nodes
« Reply #41 on: July 21, 2015, 06:48:44 AM »
I ran a couple of tests prototyping this setup:

When running without WDT but with radio in listen mode I measure a sleep current of 1.1uA. Running at 200kbaud I was able to cut down the listen period to 0.256 ms for an average power consumption for the receive spikes of 0.256ms / 2882ms * 16ma = 1.4uA. With that the total average sleep current is 2.5uA.

It's actually pretty amazing: I now have to short 3.3V against GND to get the Moteino to reset - the 10uF cap on the board powers the processor in sleep for what seems like an eternity ;)

Joe
Yes, pretty impressive.  Good work!  I did expect the opposite effect, waking the AVR via WDT periodically rather than the radio, but, I guess the 'secret sauce' is that you can achieve a much lower duty cycle with the radio than with an 8 second max WDT timeout...

What's your range at 200KBaud (and with what Tx power level and which type RFM69 - W or HW)?

Tom

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Ultra low power listening mode for battery nodes
« Reply #42 on: July 21, 2015, 07:33:04 AM »
Quote
I guess the 'secret sauce' is that you can achieve a much lower duty cycle with the radio than with an 8 second max WDT timeout...

No that's not it - the WDT circuit on the atmega328p itself uses about 4uA at 3V. That's the problem. Without WDT the chip uses much less than 1uA, so the 1.1uA power consumption is primarily RFM69HW in listen mode (or basically just its RC Oscillator running).

I can reach almost all my nodes at 200kbaud using the RFM69HW at full transmit power (haven't tested this mode at lower transmit power settings yet). This is the weekend home, so the distances are not huge - maybe 60m for the longest distance to the gateway. The one exception is the moteino in the sewage pit which is about 40 cm below ground with a metal lid on top, so it has a right to be stubborn when the ground is wet. When it is the bootloader selects the 19200baud profile because nothing else works reliably.

I think all of this should work very nicely although there is still a lot of work to do. The nodes will get a command with the wakeup call - so there will be no ack required to receive commands. I'll have all the coin cell nodes work on a separate frequency and eliminate the carrier sense code in send frame. Since it will never be busy doing acks the receiving node should always be ready to receive and I expect very low packet loss. Without acks I won't have retransmits but since the server requested the node updates it will know which updates are missing (effectively the updates are acks from the clients to the server).

All of this should minimize active time for the nodes and thus maximize battery life.

The largest piece of work is the boot loader which is anything but low power at the moment. This will require a major redesign.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5303
  • Country: us
    • LowPowerLab
Re: Ultra low power listening mode for battery nodes
« Reply #43 on: July 21, 2015, 07:50:00 AM »
joe, nice scheme you got there.
How do you manage to synchronize the different baud rates?
Any chance you could share your baud settings (working ones)?
For the node in the pit, you can run some 50ohm typical coax to an antenna above grade and that should make that node very "loud".

TomWS

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1755
Re: Ultra low power listening mode for battery nodes
« Reply #44 on: July 21, 2015, 07:58:25 AM »
Quote
I guess the 'secret sauce' is that you can achieve a much lower duty cycle with the radio than with an 8 second max WDT timeout...

No that's not it - the WDT circuit on the atmega328p itself uses about 4uA at 3V. That's the problem. Without WDT the chip uses much less than 1uA, so the 1.1uA power consumption is primarily RFM69HW in listen mode (or basically just its RC Oscillator running).

I can reach almost all my nodes at 200kbaud using the RFM69HW at full transmit power (haven't tested this mode at lower transmit power settings yet). This is the weekend home, so the distances are not huge - maybe 60m for the longest distance to the gateway. The one exception is the moteino in the sewage pit which is about 40 cm below ground with a metal lid on top, so it has a right to be stubborn when the ground is wet. When it is the bootloader selects the 19200baud profile because nothing else works reliably.

I think all of this should work very nicely although there is still a lot of work to do. The nodes will get a command with the wakeup call - so there will be no ack required to receive commands. I'll have all the coin cell nodes work on a separate frequency and eliminate the carrier sense code in send frame. Since it will never be busy doing acks the receiving node should always be ready to receive and I expect very low packet loss. Without acks I won't have retransmits but since the server requested the node updates it will know which updates are missing (effectively the updates are acks from the clients to the server).

All of this should minimize active time for the nodes and thus maximize battery life.

The largest piece of work is the boot loader which is anything but low power at the moment. This will require a major redesign.
I forget your wakeup protocol.  Does the gateway send to a specific node?  Presumably all nodes wake up but only the one that was addressed responds while the others go back to sleep?

By the way, while you're redesigning your bootloader, see if there is a way to do it (in low power mode) without external flash  ;D

Tom