LowPowerLab Forum

Hardware support => Low Power Techniques => Topic started by: joelucid on June 04, 2015, 04:35:32 PM

Title: Ultra low power listening mode for battery nodes
Post by: joelucid on June 04, 2015, 04:35:32 PM
Guys,

I've spent most of today implementing an idea I've had ready for some time. This solves a big issue for me so I thought I'd share it.

My battery driven nodes sleep most of the time. Once in a while they become active, measure and send the results to the gateway. The gateway ack's back potentially with a command which allows me to manage these nodes even though they're mostly asleep.

Some of my nodes measure very slow data - for example the sewage pit level or the lake water temperature. For the pit one measurement per hour is more than enough and for the water thermometer once every 10 minutes is sufficient. This allows the battery to last pretty much indefinitely - the estimated battery life for the sewage pit Moteino is around 20 years  on 4x AA :).

Now the downside is I need to wait for an hour to send commands to the sewage pit - no fun for an impatient person. So I'd like these nodes to actively listen for commands instead of only using ack's from the server. But I don't want to spend battery on that.

Enter the Listen mode of the RFM69HW - a topic that's been discussed a bit here. I combined this with some of the lessons I've learned in my wireless boot project:
 
The listen mode uses a duty cycle that can be defined over a broad range. Naturally I wanted a very low duty cycle to save power. On the other hand you don't want the process to take forever. So the client should never miss a packet that gets sent.

That requires that there be no gap in the transmission to the node which can be achieved using the same method I've used in the bootloader: not switching back to standby mode after transmitting packets. In that case the radio stays on leaving a continuous signal the client node can detect.

I'm now using a duty cycle of 0.64ms : 2620ms which means that the incremental power use of this scheme is largely negligible.

This mode (not switching to standby from tx) is a bit tricky. For one thing it doesn't work with encryption. Additionally PACKETSENT stays true after the first packet is sent successfully - so it requires hand tuned delays  for additional packets.

But the end result is very nice: Within 3 seconds I can now access any node and it's pretty much free in terms of power budget. Check out the code attached and let me know what you think.

Usage:

Client:
call startListening to enter listen mode.
sleep the moteino
on wake up call receivedBytes to see if anything arrived
call clearBuffer to be ready for the next transmit
call endListening to end listening mode. Afterwards reinitialize the RFM69 library to restore its settings.


Server:
call send to transmit to the client
Afterwards reinitialize the RFM69 library.


Joe

Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on June 04, 2015, 04:39:13 PM
BTW, practically speaking I use this just to issue one command: increase the update frequency to once every 4 seconds. Afterwards I can manage the moteinos via Ack's from the server and don't need to hog the spectrum.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on June 05, 2015, 12:14:02 PM
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.

I'm attaching a workaround which now uses software based address filtering.

I'm now seeing about 7 uA battery use for sleeping nodes which jumps up to 9 uA when the node briefly goes into receive. This is what the cheap ampere-meter shows - so not a true average. Theoretically listen mode should cost .64 / 2620 * 16ma = around 4 uA, so more than shown on the meter.

Joe
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on June 05, 2015, 02:07:11 PM
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.

<snip>
I was wondering about this so I'm not surprised.  What I am surprised about is why you haven't set up a 'SleepyTime' network Id.  In this case there would be no traffic on that network except a wakeup call from the Gateway (nodes would only listen on it, and possibly Ack).  Switching networks is trivial, uses hardware filtering, and the Gateway would only switch during the time that it had to wake up one of the nodes.  It is true that all sleeping nodes would wake up, but it would only be for that short, 3 second transmission.

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: Felix on June 05, 2015, 04:00:37 PM
Joe, nice work, this could come in handy for others that want to do similar things.
Thanks for sharing it, I am surprised you can get good results with such a low duty cycle.
One thing you might watch out for is the TX duty cycle which has restrictions.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on June 05, 2015, 06:44:14 PM
@Tom, yes you're right, I could try using the network ID to work around this issue. That said the current workaround isn't any worse. I had thought about switching frequency which would keep the normal channel clean. But since I'm only using this when I need to take control of the clients it's really not such a big deal.

Note that the other nodes don't stay awake for the 3 seconds with the current setup. Only for the rx timeout period which is about 20ms.

Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on June 05, 2015, 06:49:30 PM
@felix, the key to making the low duty cycle work is the continuous transmission. I know the spec mentions something about a 1% duty cycle limitation but I've never seen this as a problem so I wonder if they are mentioning a regulatory constraint. Even with wireless boot and particularly if I need to downgrade to 19200 baud I have the gateway send for up to 30s at full power and it's never been a problem. During testing I've had nodes transmit at full power for minutes without ill effect.

Joe
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on June 05, 2015, 09:03:24 PM
@Tom, yes you're right, I could try using the network ID to work around this issue. That said the current workaround isn't any worse. I had thought about switching frequency which would keep the normal channel clean. But since I'm only using this when I need to take control of the clients it's really not such a big deal.

Note that the other nodes don't stay awake for the 3 seconds with the current setup. Only for the rx timeout period which is about 20ms.
Interesting that you think it wouldn't work any better.  The sleeping node wouldn't even get a wake up signal if a different Network Id was used and the radio wouldn't stay in RX mode since there wouldn't be a SyncWord match on a 'normal' transmission.  What am I missing?  On a sparse network, you're probably right, but on a busy network with a lot of nodes, I have to believe letting the processor sleep until there is a 'real' wake up call has to be significant.

Tom
PS: I've never thought Listen Mode was useful and I'm counting on you to prove me wrong.   :-\

Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on June 06, 2015, 04:45:54 AM
Quote
The sleeping node wouldn't even get a wake up signal if a different Network Id was used and the radio wouldn't stay in RX mode since there wouldn't be a SyncWord match on a 'normal' transmission.

Actually the way I'm using Listen mode is that the receiver detects only whether RSSI is > -90 for 0.64 ms and then either goes back to sleep or switches into RX for 20 ms to see if there's a packet for it. During that 0.64ms phase there is no sync word detection yet obviously and so the radio would stay in RX anyhow.

The radio stays in RX until either payload available or timeout occurs. If the radio immediately receives a packet on the right network with a wrong target node id that is actually quicker than seeing and ignoring a packet on the wrong network first and hanging around until timeout occurs.

Because of the very low duty cycle regular packet interference isn't much of an issue for sleepy nodes. More problematic is interference of regular traffic by the burst sequences. Both can be solved by moving to a different frequency.

Wrt the usefulness of listen mode: that really depends if you can wake up and read out RSSI manually as quickly as the chip does in listen mode. I haven't tried it - but I'm very happy with how reliably this extreme duty cycle works for me with listen mode.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on June 06, 2015, 06:14:57 AM
Ok, I've moved the sleepy frequency by 4mhz, introduced a new network id. I'm now using another node instead of the gateway to send the wakeup packet burst. So now there's no interference between regular traffic and wakeup bursts. See attached.
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on June 06, 2015, 09:15:59 AM
Quote
The sleeping node wouldn't even get a wake up signal if a different Network Id was used and the radio wouldn't stay in RX mode since there wouldn't be a SyncWord match on a 'normal' transmission.

Actually the way I'm using Listen mode is that the receiver detects only whether RSSI is > -90 for 0.64 ms and then either goes back to sleep or switches into RX for 20 ms to see if there's a packet for it. During that 0.64ms phase there is no sync word detection yet obviously and so the radio would stay in RX anyhow.
AHA!  It didn't 'sync' in that the RX was only 0.64mS, somehow I was seeing this as 6.4mS, which should be enough time for SyncAddressMatch.  Ok, now I 'get it'.  Thanks for the explanation.    It would be interesting to see just how often your node wakes up with an RSSI > -90 from transmissions on the main 'network'.  Given the transmit power and receive sensitivity of these radios, I would expect high RSSI levels even if shifted 4MHz. 
The radio stays in RX until either payload available or timeout occurs. If the radio immediately receives a packet on the right network with a wrong target node id that is actually quicker than seeing and ignoring a packet on the wrong network first and hanging around until timeout occurs.

Because of the very low duty cycle regular packet interference isn't much of an issue for sleepy nodes. More problematic is interference of regular traffic by the burst sequences. Both can be solved by moving to a different frequency.

Wrt the usefulness of listen mode: that really depends if you can wake up and read out RSSI manually as quickly as the chip does in listen mode. I haven't tried it - but I'm very happy with how reliably this extreme duty cycle works for me with listen mode.
I'm still stuck in thinking that SyncAddressMatch provides some useful capability and, if I do try ListenMode, I'll experiment with that.  This code provides a good starting point for those experiments. I think this is good work and will be useful to others, including me.  Thanks for sharing.

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on June 06, 2015, 09:59:13 AM
Tom to test whether interference still exists I did a burst at the old frequency and checked whether the new sleepers would wake up. They didn't.

if you want to use SyncAddressMatch your busy cycle needs to be an order of magnitude larger to allow the address to be read. Hence a no go for ultra low power environments.
Title: Re: Ultra low power listening mode for battery nodes
Post by: ulli on June 06, 2015, 10:45:51 AM
Hi,

I am happy to hear that somebody else is working on the listen mode!

My cfg is the following:
The "master" device is powered over an USB power cord. It send burst messages to reach the "client" which is battery powered and in RFM69-ListenMode.
One burst takes as long as one RX/idle period of the client. After the client has received the message it sends an ACK back to the "master".
With this mechanism I have a stable protocol for the "master"/"client" configuration.

The ListenMode period is configured to be 1ms in RX mode and 262ms in idle mode.
Therefore I did reduce the RFM RX mode to a minimum and I still have a robust connection between master and client.

I am currently running a test how long the client survives with 2x AA batteries...

O have a few questions:
* 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 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.
* 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...
   Is the bug also there when I use Adressfiltering and encription?

Thanks in advance.
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on June 06, 2015, 11:05:43 AM
A couple of questions...
Tom to test whether interference still exists I did a burst at the old frequency and checked whether the new sleepers would wake up. They didn't.
To clarify, by 'wake up' do you mean the node thought it was getting a wake up message or did you probe the interrupt line to see if the burst was causing any interrupts?
if you want to use SyncAddressMatch your busy cycle needs to be an order of magnitude larger to allow the address to be read. Hence a no go for ultra low power environments.
Yeah, that's how I first read it too, but then got to thinking that once a carrier is detected and the packet engine starts receiving, the radio will stay in RX mode as long as it takes to receive and check the packet for sync match (if that's the criteria).  Unless you've done this experiment and know this is not the case, I think I'll still try it 'at some point' in the future.  Still, as I said, this is very useful work!

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on June 06, 2015, 12:56:25 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.

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 :)
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.   
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS 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... ::)
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.

Title: Re: Ultra low power listening mode for battery nodes
Post by: ulli 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?
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on June 12, 2015, 01:49:34 AM
Here's one week of battery data from my water thermometer:

(http://i.imgur.com/KTDEnhS.jpg)

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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: River 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!
Title: Re: Ultra low power listening mode for battery nodes
Post by: ulli 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: ulli 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!
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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?
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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. 
Title: Re: Ultra low power listening mode for battery nodes
Post by: ulli 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]
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: ulli 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

Title: Re: Ultra low power listening mode for battery nodes
Post by: abraxas1 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!

Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS 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
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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
Title: Re: Ultra low power listening mode for battery nodes
Post by: abraxas1 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

Title: Re: Ultra low power listening mode for battery nodes
Post by: River 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!
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.

Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS 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
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS 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
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: Felix 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".
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS 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
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on July 21, 2015, 08:04:19 AM
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".
Yeah, you can use the u.fl connector that Felix provided the footprint for  ;)

Seriously, this is a very nice feature of the Mega.  Hint to add to feature list for R5.
Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: Felix on July 21, 2015, 08:15:43 AM
Tom, the cheapest and easiest way to get an antenna away from Moteino is till just bare coax soldered to ANT and GND. The UFL is for modularity, but those connectors add to the cost quite a bit and hence they are not populated, but people can add one if they want to. For the rest of Moteinos the space is pretty tight, i have to worry about other things on there, and not sure how many people would take advantage of it. Even without the dedicated footprint coax is a good compromise and with a little care, a UFL can still be connected between the AND and GND pads on the bottom. Scraping some GND pour provides extra solder surface. It's not ideal I know but it's possible.
It's a tough call where to make the divide between the features of the different Moteino variants. It's like options on cars right?
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 21, 2015, 09:35:36 AM
 
Quote
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

I support both a broadcast mode and addressing specific nodes. You'll recall that I can't rely on address filtering by the rfm69 since due to a bug that leads to longer receive windows than specified in listen mode. So yes, all nodes wake up and the ones that aren't targeted go back to sleep immediately.

I plan to use broadcasts to trigger measurements to minimize erroneous wake ups.

The bootloader will always work without external flash since that's the reason it exists. In fact this whole project is really just fodder for my first PCB project and since I'm trying to build something that's both useful and a bit scalable I've decided for a battery optimized Moteino that can be optionally used as standalone thermometer. So the space for the external flash will optionally host the si7021.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 21, 2015, 10:04:01 AM
Felix,

Rg synchronization: currently I initiate the boot process at a baud rate that works. Then both sides switch to the highest baud rate. When they don't receive anything both sides downgrade to the next slower profile after a certain timeout. The client downgraded to the next lower profile if packet loss rate is too high.

All this means lots of traffic from client to server when they are not yet in synch - clearly a no go for coin cells. I'll need to rework this - will probably have client communicate to server at safe baud rate and have it select the baud rate the server should respond at. Server to client speed is what matters and with that approach I can sequence the process into a long chain of request, response, sleep cycles.

I'll send the profiles later. I know I can have an external antenna for the pit - but I like having at least one challenging node ;)
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 21, 2015, 11:42:47 AM
Here are my profiles. The 55kbaud one is yours. the 300kbaud one I don't use because already with 200kbaud flashing is the bottleneck for the bootloader.

Code: [Select]
const uint8_t profiles[][5] = {


#if 0
// CFG0: 28kb  1750 ms

  { RF_BITRATEMSB_300000, RF_BITRATELSB_300000,
RF_FDEVMSB_100000, RF_FDEVLSB_100000,
RF_RXBW_DCCFREQ_000 | RF_RXBW_MANT_16 | RF_RXBW_EXP_0 },
// sleep server 1800
// timeout client 10

#endif
 
// CFG1: 28kb 2200 ms 
  { RF_BITRATEMSB_200000, RF_BITRATELSB_200000,
RF_FDEVMSB_100000, RF_FDEVLSB_100000,
RF_RXBW_DCCFREQ_000 | RF_RXBW_MANT_16 | RF_RXBW_EXP_0 },
// sleep server 2400
// timeout client 10

// CFG2: 28kb 7100 ms
  {
  RF_BITRATEMSB_55555, RF_BITRATELSB_55555,
  RF_FDEVMSB_50000, RF_FDEVLSB_50000,
  RF_RXBW_DCCFREQ_010 | RF_RXBW_MANT_16 | RF_RXBW_EXP_2 },
// sleep server 8500
// timeout client 30

// CFG3: 28kb 18500 ms
  {
  RF_BITRATEMSB_19200, RF_BITRATELSB_19200,
  RF_FDEVMSB_50000, RF_FDEVLSB_50000,
  RF_RXBW_DCCFREQ_010 | RF_RXBW_MANT_16 | RF_RXBW_EXP_2 } // (BitRate < 2 * RxBw)
// sleep server 23000
// timeout client 50

};
Title: Re: Ultra low power listening mode for battery nodes
Post by: ulli on July 21, 2015, 02:52:07 PM
I already have developed a function which let me deactivate the functionality I do not use on ultra low power moteinos.
It also includes the WDT. I use the RFM69 DIO0 on a INT0 pin of the Atmega to wake everything up.

Code: [Select]
/*******************************************************************************
*
* Argument  Description
* =========  ===========
*
* 2. adc ADC module disable control:
* (a) ADC_OFF - Turn off ADC module
* (b) ADC_ON - Leave ADC module in its default state
*
* 3. timer2 Timer 2 module disable control:
* (a) TIMER2_OFF - Turn off Timer 2 module
* (b) TIMER2_ON - Leave Timer 2 module in its default state
*
* 4. timer1 Timer 1 module disable control:
* (a) TIMER1_OFF - Turn off Timer 1 module
* (b) TIMER1_ON - Leave Timer 1 module in its default state
*
* 5. timer0 Timer 0 module disable control:
* (a) TIMER0_OFF - Turn off Timer 0 module
* (b) TIMER0_ON - Leave Timer 0 module in its default state
*
* 6. spi SPI module disable control:
* (a) SPI_OFF - Turn off SPI module
* (b) SPI_ON - Leave SPI module in its default state
*
* 7. usart0 USART0 module disable control:
* (a) USART0_OFF - Turn off USART0  module
* (b) USART0_ON - Leave USART0 module in its default state
*
* 8. twi TWI module disable control:
* (a) TWI_OFF - Turn off TWI module
* (b) TWI_ON - Leave TWI module in its default state
*
*******************************************************************************/
void TurnOffFunktions(bod_t bod, adc_t adc, ain_t ain, timer2_t timer2, timer1_t timer1, timer0_t timer0, spi_t spi, usart0_t usart0, twi_t twi, wdt_t wdt) {
// Temporary clock source variable
unsigned char clockSource = 0;

if(bod == BOD_OFF) {
// turn off brown-out enable in software
MCUCR = bit (BODS) | bit (BODSE);  // turn on brown-out enable select
MCUCR = bit (BODS);        // this must be done within 4 clock cycles of above
}

if (timer2 == TIMER2_OFF) {
if (TCCR2B & CS22) clockSource |= (1 << CS22);
if (TCCR2B & CS21) clockSource |= (1 << CS21);
if (TCCR2B & CS20) clockSource |= (1 << CS20);

// Remove the clock source to shutdown Timer2
TCCR2B &= ~(1 << CS22);
TCCR2B &= ~(1 << CS21);
TCCR2B &= ~(1 << CS20);

power_timer2_disable();
} else if(timer2 == TIMER2_ON) {
if (clockSource & CS22) TCCR2B |= (1 << CS22);
if (clockSource & CS21) TCCR2B |= (1 << CS21);
if (clockSource & CS20) TCCR2B |= (1 << CS20);

power_timer2_enable();
}

if (ain == AIN_OFF) {
DIDR1 |= (1 << AIN1D) | (1 << AIN0D);
} else if(ain == AIN_ON) {
DIDR1 &= ~((1 << AIN1D) | (1 << AIN0D));
}

switch(adc) {
case ADC_OFF:
ADCSRA &= ~(1 << ADEN);
DIDR0 |= (1 << ADC5D) | (1 << ADC4D) | (1 << ADC3D) | (1 << ADC2D) | (1 << ADC1D) | (1 << ADC0D);
power_adc_disable();
break;
case ADC_ON:
power_adc_enable();
DIDR0 &= ~((1 << ADC5D) | (1 << ADC4D) | (1 << ADC3D) | (1 << ADC2D) | (1 << ADC1D) | (1 << ADC0D));
ADCSRA |= (1 << ADEN);
break;
case ADC0_OFF:
DIDR0 |= (1 << ADC0D);
if((DIDR0 & 0x3F) == 0x3F) {
ADCSRA &= ~(1 << ADEN);
power_adc_disable();
}
break;
case ADC0_ON:
power_adc_enable();
DIDR0 &= ~(1 << ADC0D); //Just Turn ADC0 on
ADCSRA |= (1 << ADEN);
break;
case ADC2_OFF:
DIDR0 |= (1 << ADC2D);
if((DIDR0 & 0x3F) == 0x3F) {
ADCSRA &= ~(1 << ADEN);
power_adc_disable();
}
break;
case ADC2_ON:
power_adc_enable();
DIDR0 &= ~(1 << ADC2D); //Just Turn ADC0 on
ADCSRA |= (1 << ADEN);
break;
default: break;
}

if (timer1 == TIMER1_OFF) {
power_timer1_disable();
} else if(timer1 == TIMER1_ON) {
power_timer1_enable();
}

if (timer0 == TIMER0_OFF) {
power_timer0_disable();
} else if(timer0 == TIMER0_ON) {
power_timer0_enable();
}

if (spi == SPI_OFF) {
SPCR &= ~(1<<SPE);
power_spi_disable();
} else if(spi == SPI_ON) {
power_spi_enable();
SPCR |= (1<<SPE);
}

if (usart0 == USART0_OFF) {
UCSR0B &= ~((1<<RXEN0) | (1<<TXEN0));
power_usart0_disable();
} else if(usart0 == USART0_ON) {
power_usart0_enable();
UCSR0B |= (1<<RXEN0) | (1<<TXEN0);
}

if (twi == TWI_OFF) {
TWCR &= ~(1<<TWEN);
power_twi_disable();
} else if(twi == TWI_ON) {
power_twi_enable();
TWCR |= (1<<TWEN);
}

if (wdt == WDT_OFF) {
wdt_reset();
wdt_disable();
WDTCSR |= (1<<WDCE) | (1<<WDE);
WDTCSR = 0x00;
/* } else {
wdt_enable();
WDTCSR |= (1 << WDIE);
*/
}

}

@joelucid: How do you proceed on your low power moteino when they are receiving a burst which has a duration of e.g. 3 seconds.
Is the low power moteino waiting for e.g. 3 sec as worst case (RX: 3sec->16mA) till it can send the ACK or the requested information back to your gateway?
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 21, 2015, 03:16:18 PM
Quote
@joelucid: How do you proceed on your low power moteino when they are receiving a burst which has a duration of e.g. 3 seconds.
Is the low power moteino waiting for e.g. 3 sec as worst case (RX: 3sec->16mA) till it can send the ACK or the requested information back to your gateway?

Well as soon as a Moteino wakes up it goes right back to sleep for 3s to ensure that the burst is over and then it reports back to the server. It certainly doesn't sit in receive @ 16 mA for 3s.
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on July 21, 2015, 04:52:27 PM
Quote
@joelucid: How do you proceed on your low power moteino when they are receiving a burst which has a duration of e.g. 3 seconds.
Is the low power moteino waiting for e.g. 3 sec as worst case (RX: 3sec->16mA) till it can send the ACK or the requested information back to your gateway?

Well as soon as a Moteino wakes up it goes right back to sleep for 3s to ensure that the burst is over and then it reports back to the server. It certainly doesn't sit in receive @ 16 mA for 3s.
Now that's interesting.  Ulli, it was a good question and with your answer Joe, it seems as if you must go back to sleep but no longer in Listen Mode but this time with WDT wakeup a few seconds later?  And how do multiple nodes avoid collision when they finally reply to the gateway?

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 21, 2015, 05:11:35 PM
I actually do stay in listen mode - that's not a problem since the listen window won't be hit until the WDT hits. I do have to use the WDT for that delay obviously. From an energy budget point of view that's not relevant since its 4uA with a duty cycle of say 3s : 180s.

Collisions are unlikely to happen since the burst lasts 3s. At 200kbaud a packet takes say 2ms. Remember there are no acks. Even with a large number of nodes the probability that their randomly distributed 2ms windows overlap during a 3s interval is exceedingly small. If it does happen it won't happen next time.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 21, 2015, 05:27:06 PM
I should add that I'm planning to use an extra Moteino for the burst collection. It'll be the bathroom fan controller which is AC powered and therefore powered to take on that role. I don't want the whole network to be down during the burst collection. So the gateway will continue to do its thing. The bathroom fan Moteino will send the burst and collect answers on a separate frequency. When all answers are in it will relay them to the gateway.

But that's icing on the cake. If you just want to deploy a bunch of thermometers the given scheme will work without this luxury. If however you want to be able to open your garage while the thermometers are being polled having an extra Moteino is the way to go :)
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on July 21, 2015, 06:57:48 PM
I actually do stay in listen mode - that's not a problem since the listen window won't be hit until the WDT hits.
Why is that?  ISTM that if a burst of packets produce a hit, then subsequent packets within the same burst may produce a hit also since the listen window is slightly narrower than the burst width (as I understand it).
Quote
I do have to use the WDT for that delay obviously. From an energy budget point of view that's not relevant since its 4uA with a duty cycle of say 3s : 180s.
Understood, just confirming.
Quote
Collisions are unlikely to happen...
Boy, if I only had a nickle...  ;)

Tom
BTW, I think the bathroom fan is an excellent place to hide your burst collector.  Very secure - who would think of looking there?
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 22, 2015, 02:42:58 AM
Quote
Why is that?  ISTM that if a burst of packets produce a hit, then subsequent packets within the same burst may produce a hit also since the listen window is slightly narrower than the burst width (as I understand it).

Yes, true. In the current prototype you could get hit twice. In my "production system" I  have a much shorter second sleep period since I collect results at the gateway which can collect while the bathroom fan bursts ;). But for the new system the burst collector receives at the higher baud rate so the sleep period is necessary and things will be a tiny bit better by switching listen mode off before sleeping.

Quote
Boy, if I only had a nickle...  ;)

Let's get systematic: the size of the send window is 2 : 3000, call it 3 : 3000 or 1 : 1000 for easy calculation. The probability that there is no overlap with n senders should be 1000! / (1000-n)! / 1000^n. With 10 senders that's 0.955.

That's ok but worse than I thought. Some busy spinning might be in order to wait until the air is clean. Or I'll wait a bit longer than the burst window. With a 6 second send window you'd have 0.985 for the probability of no overlap. Will have to experiment a bit with that.

Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 22, 2015, 02:53:14 AM
Ah just thought of the solution to the collision problem: I'll have a counter in each burst packet. That way a client knows when in the burst it woke up and can time it's response. I'll just cut the response window into n slices and have each node respond during one of them.

No collisions, no busy spinning, faster response after burst end - everybody happy :)

Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on July 22, 2015, 08:14:27 AM
Ah just thought of the solution to the collision problem: I'll have a counter in each burst packet. That way a client knows when in the burst it woke up and can time it's response. I'll just cut the response window into n slices and have each node respond during one of them.

No collisions, no busy spinning, faster response after burst end - everybody happy :)
Well, I was pulling your chain in the previous post, because, as you say, this is not mission critical stuff and you'll get the data on the next cycle.  Having said that, yes, I do like this particular solution.  Good job!

Now given that you've adjusted the response window according to when in the burst the recv occurs, you can also resolve the multiple recv per burst issue by shutting off listen until the response is sent.

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on July 22, 2015, 08:20:51 AM
No collisions, no busy spinning, faster response after burst end - everybody happy :)
I forgot to mention in my previous post, it's always good to keep your bathroom fan happy!  DAMHIKT!

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 22, 2015, 12:54:16 PM
Quote
Well, I was pulling your chain in the previous post, because, as you say, this is not mission critical stuff and you'll get the data on the next cycle. 

Well it did surprise me how large the collision probability turned out to be. So thanks for motivating me to calculate it. I'm looking forward to more real life tests - if we can actually build 5 year thermometers using a cr2032 that'd be pretty cool.

They'll be around 10 Euros each - so you can just plaster your home with them ...
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on July 23, 2015, 09:22:47 AM
...I'll just cut the response window into n slices and have each node respond during one of them.
Do you mean that each node will have a specific time slot to respond and they'll 'know' when to schedule the time slot based on when they detected the burst (from the counter you're adding)?

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 23, 2015, 12:25:14 PM
Quote
Do you mean that each node will have a specific time slot to respond and they'll 'know' when to schedule the time slot based on when they detected the burst (from the counter you're adding)?

Yeah that was the idea.

Timing differences in the WDT and internal 8mhz resonator between nodes could be a challenge. To work around that nodes could learn the specifics of their clocks by looking at a couple of burst packages.

Or you just make the slices large enough so that the tolerances don't matter. The farther away from the burst the slice is, the larger the slice needs to be so that the tolerances don't lead to collisions because the larger the accumulated discrepancy between the clocks.


Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 24, 2015, 10:49:15 AM
It's really too bad how little energy you can use with a coin cell and a 200uF cap (and I agree much larger has its own disadvantages). Realistically you get maybe 5ms @ 25mA if you want to be able to run the battery down to 2.6V (idle) for the cap alone. Add a couple of mA for the coin cell.

So 200kbaud seems like a must to me. And for the bootloader it's strictly one request, one response packet. A full app (32k - 4k bootloader) would take 672 packets. Recharge the cap 5x per second and an update will take a bit longer than 2 minutes.

It's too bad because the overall energy expenditure is much larger than necessary due to all those request packets since we can't batch responses.
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on July 29, 2015, 08:53:57 AM
Well, here's the latest and, I think, the last iteration.  I've tied the Si7021 power (along with I2C pullups) to a GPIO pin and connected CapVSense to A1.  It's interesting that the bulk of the circuitry on this design is dedicated to the moment a battery is inserted into the circuit board  :o

And for the next 'n' months the hardware is idle.  Go figure...

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: EloyP on July 29, 2015, 11:10:46 AM
Probably nothing you guys don't know already but JeeLabs' JCW has just written a post on powering sensors with coin cell batteries:

http://jeelabs.org/2015/07/29/could-a-coin-cell-be-enough/

Very high level but it's a good introduction.

Cheers,

Eloy Paris.-
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on July 30, 2015, 10:28:16 AM
Here's the battery data from the last 19 days.  This is for the Version 1 prototype and doesn't include my initial, uh, 'mess-ups' in getting the Mote started.  From this data, I wouldn't be surprised if my mess-ups drained off about 50% of the battery's life.  Even in this chart you can see a couple of cases where the gateway was offline and the node was doing multiple retries on sends.  I've since fixed this, as it no longer retries. It sends once, requesting Ack (to get its RSSI feedback), and then goes to sleep.

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 31, 2015, 04:58:14 PM
What's the update frequency?
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on August 01, 2015, 12:00:54 AM
What's the update frequency?
TH sampling occurs once per 10 minutes (based on Mote internal RC 8MHz clock).  Async push to the Gateway.  Mote status update (battery and transmit levels) occurs every 6 samples (once per hour).

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: ulli on August 07, 2015, 12:57:00 PM
Hi,

I currently also work on a new circuit design to further reduce the power consumption of my battery powered moteino. I plan to do something similar with Toms circuit a few replies above.

I understood your posts in that why, that a more or less constant current consumption results in better battery life than current peaks  caused by the Listening Mode or frequently transmissions.
--> So, the target is to make the current consumption as smooth as possible with a well defined cap, which buffers the transmissions and listening mode current peaks?

What do you think about using the IRLML6402 Mosfet instead of SI2365? (No supplier is available which makes sense for me)
It has a very low on resistance and should work with 3.3V on/off.
http://www.irf.com/product-info/datasheets/data/irlml6402.pdf

Am I right?
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on August 07, 2015, 02:12:06 PM
Hi,

I currently also work on a new circuit design to further reduce the power consumption of my battery powered moteino. I plan to do something similar with Toms circuit a few replies above.

I understood your posts in that why, that a more or less constant current consumption results in better battery life than current peaks  caused by the Listening Mode or frequently transmissions.
--> So, the target is to make the current consumption as smooth as possible with a well defined cap, which buffers the transmissions and listening mode current peaks?

What do you think about using the IRLML6402 Mosfet instead of SI2365? (No supplier is available which makes sense for me)
It has a very low on resistance and should work with 3.3V on/off.
http://www.irf.com/product-info/datasheets/data/irlml6402.pdf

Am I right?
Assuming your power supply is at least 3V, then, yes, that MOSFET will be fine.  It's too bad the data sheet doesn't show the drain current vs Vgs at lower currents, but it appears to be more than enough for this application.

If you can fit a larger cap than I used, it would be much much better.  200uF is really not enough to isolate the pulsed load from the battery and I can see 40mA spikes at the battery when the RFM69W is transmitting at full power (my code automatically dials back the transmit level, but this is the worst case condition). 

In the scope trace below, you can see the blue trace is the CR2032 which starts at 3.0V but then falls to about 2.4V during the transmit (and recovery) time while the yellow trace is across the 200uF cap & RFM69W falls below 2.0V.  The purple trace is the difference of the two voltages across a 10 ohm resistor, 400mV or 40mA.  It's brief and the battery recovers quickly, but if you can use a supercap or, at least, something substantially larger than 200uF you'd be better off.  Of course, I'm using the same coin cell that I've been abusing for weeks so I'm not sure how a fresh one will behave.  This one keeps on working and I'll keep abusing it until it stops  :D

In any case, I'm happy with the circuit and have sent it to OSH Park for fab.  I'll let you know (and post the design files) when I have the PCB running (probably within two weeks).

Tom




Title: Re: Ultra low power listening mode for battery nodes
Post by: ulli on August 09, 2015, 07:14:31 AM
Thats a good point. I am using 2x AA batteries which should work down to 1.8V due to the limit of the RFM Module and the Atmega.
Addi tonally the capacitor have to be way bigger than I thought before to also provide enough energy for the transmission. -> voltage drop must be minimized.
Do you think the Mosfet will also work with 1.8V. The Datasheet shows a VGS(max) of 1.2V...Doesn´t it mean that I can use it down to 1.2V control voltage of the Gate?

Looking forward to your final design and test results.
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on August 09, 2015, 09:34:24 AM
Thats a good point. I am using 2x AA batteries which should work down to 1.8V due to the limit of the RFM Module and the Atmega.
Addi tonally the capacitor have to be way bigger than I thought before to also provide enough energy for the transmission. -> voltage drop must be minimized.
Do you think the Mosfet will also work with 1.8V. The Datasheet shows a VGS(max) of 1.2V...Doesn´t it mean that I can use it down to 1.2V control voltage of the Gate?

Looking forward to your final design and test results.
Ulli, if you're using AA batteries  then you don't need the switches. Your mote will power up without any problem.  The switches and caps are there to limit the power surge to a coin cell battery which doesn't deal well with the high current surge. AA will literally last for years.  Basically the shelf life of the battery.

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: Felix on August 09, 2015, 08:27:33 PM
Thats a good point. I am using 2x AA batteries which should work down to 1.8V due to the limit of the RFM Module and the Atmega.
Don't count on the RFM HW boards from HopeRF to go down to 1.8V as claimed in the datasheet. The fact is that the switcher they use is a 2.4V GaAs device (the SC70 chip). So only the RFM69-W which don't have that part will probably be reliable down to 1.8V. On the RFM69HW you probably don't care anyway since it's a 100mW TX device and you use it for the power not for saving the battery to the absolute maximum.
Title: Re: Ultra low power listening mode for battery nodes
Post by: ulli on August 13, 2015, 03:54:07 PM
This is an interesting question since if the pulsed load hurts it would make sense to put a resistor in front of the load. This might make sense anyway since it would cause the system to restart if it gets stuck in receive etc instead of damaging the battery. I'm currently running a test to verify this.

Sorry for the late feedback...
As already stated, I use 2xAA batteries. I further need to reduce the power consumption due to a current module lifetime of only 3 month in ListenMode with a few infrared transmissions.
You are right that I do not need the cap for limiting the power surge/voltage drop like it is on a coin cell battery.
I am thinking about your cap solution with an additional series resistor to reduce the current peaks. I think current peaks(Listen 4µA -> RX 25mA) reduces the lifetime of a AA battery, doesn´t it?
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on August 13, 2015, 04:13:47 PM
Quote
current module lifetime of only 3 month in ListenMode

There must be something else going on - this is not due to ListenMode if correctly implemented. I'm using listen mode on all my battery nodes and there is no significant impact on battery life.

For example I've been running a DHT22 based thermometer using 2x lithium aaa for at least a month. During that time vcc has dropped from 3.63V to 3.62V. 
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on August 13, 2015, 04:19:07 PM
This is an interesting question since if the pulsed load hurts it would make sense to put a resistor in front of the load. This might make sense anyway since it would cause the system to restart if it gets stuck in receive etc instead of damaging the battery. I'm currently running a test to verify this.


Sorry for the late feedback...
As already stated, I use 2xAA batteries. I further need to reduce the power consumption due to a current module lifetime of only 3 month in ListenMode with a few infrared transmissions.
You are right that I do not need the cap for limiting the power surge/voltage drop like it is on a coin cell battery.
I am thinking about your cap solution with an additional series resistor to reduce the current peaks. I think current peaks(Listen 4µA -> RX 25mA) reduces the lifetime of a AA battery, doesn´t it?
The cited quote is actually joelucid's, not mine, but, in any case, AA can handle much larger current surges than 25mA (probably in the order of hundreds of mA) keeping in mind that they are probably not as 'elastic' as coin cells WRT to using mAH precisely because the chemistry is 'consumed' quickly due to the AA's low ESR.  It also depends on whether you're using Lithium or Alkaline AAs.

Capacitors will help supply pulsed power, but, unless they are very large value caps, there is probably negligible effect on AA battery life (plus or minus) if caps in the order of 10-200uF are used in this application.  The secret to this ultra-low-power listen mode implementation was Joe's realization that, in listen mode, he could set the duty cycle to an very low value using very high data rate (making the RX time very low, and the idle time 1000 10,000 times longer).  That, and the fact, which I totally missed, that Idle Mode in the radio consumes 25% less power than Idle with WDT in the 328P.

You also won't need the power sequencing switches since the AAs can provide enough power at startup to get around the initial high current required by the uninitialized radio while the coin battery can't possibly supply this amount of short term power.

Tom
UPDATE: corrected duty cycle...
Title: Re: Ultra low power listening mode for battery nodes
Post by: ulli on August 13, 2015, 04:31:46 PM
Thanks for the quick response.
I use Alkaline AAs and I attached my circuit maybe there is a design issue?
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on August 13, 2015, 05:02:06 PM
Thanks for the quick response.
I use Alkaline AAs and I attached my circuit maybe there is a design issue?

Ulli,

I would recommend grabbing a simple ampere-meter and measuring your idle currents. If you measure anything more than 10uA while sleeping there's something seriously wrong.

AA batteries should have at least around 2000mAh capacity. If you use them up in 90 days you're drawing 2000mAh in 90 * 24h or an average of 930uA. That's way too high. Either you're not sleeping your 328p correctly or the ULN2003V12DR has unreasonable idle currents.
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on August 13, 2015, 06:50:30 PM
Thanks for the quick response.
I use Alkaline AAs and I attached my circuit maybe there is a design issue?
Ulli, I would add to Joe's comments with:
1. are you sure ALL inputs to the ULN2003 are pulled to ground when Idle?
2. Have you set the fuses to run on internal clock at 8MHz?
3. Is A0 programmed to be a Digital Input (not Output)?
4. How often and what duty cycle is the IR LED pulsed?

Tom


Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on August 14, 2015, 09:38:23 AM
For example I've been running a DHT22 based thermometer using 2x lithium aaa for at least a month. During that time vcc has dropped from 3.63V to 3.62V.
@Ulli, I've gathered Battery data for a Mote I deployed in April.  This Mote measures the water level in a man-made stream I have, uses two AAA Lithium batteries and, even running with WDT sleep (not Listen Mode) cycles, the voltage actually started lower (3.473 when deployed) and has worked its way up as high as 3.641, to 3.527 at 6:48 this morning (130 days later).  The initial voltage was low due to start up configuration loading as I fiddled with it and most of the variation over time has been probably due to temperature variations as opposed to any real drain on the batteries. 

This Mote uses RFM69HW and, since I had to change over to a different, more distant, Gateway about a month ago, this Mote has to transmit at full power to reach it reliably for the last month.

Net: Reinforcing what Joe had to say, I'd say you've got something wrong in your setup.

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: ulli on August 14, 2015, 01:26:40 PM
Thanks for the quick response.
I use Alkaline AAs and I attached my circuit maybe there is a design issue?
Ulli, I would add to Joe's comments with:
1. are you sure ALL inputs to the ULN2003 are pulled to ground when Idle?
2. Have you set the fuses to run on internal clock at 8MHz?
3. Is A0 programmed to be a Digital Input (not Output)?
4. How often and what duty cycle is the IR LED pulsed?

Tom

I checked your comments above.
1. No changes in power consumption after setting all inputs to Low with:
Code: [Select]
pinMode(A3, OUTPUT);
digitalWrite(A3, LOW);
2. Yes i set the fuses to
Code: [Select]
low_fuses=0xE2
high_fuses=0xDA
extended_fuses=0x07
(The 16MHz quarz and Caps are soldered, but not used
3. No changes in Power consuption after setting A0 after RFM69 reset to input
Code: [Select]
pinMode(RFM69_ResetPin, INPUT);
4. The frequency is 38khz. I calculated one packet is taking 25ms. ~ 5 transmissions a day
   --> I expect no relevance over lifetime

I measured the power consumption with a multimeter in idle mode. To get more stable  results I set the following register
Code: [Select]
/* 0x0E */ { REG_LISTEN2, 0xFF },
/* 0x0F */ { REG_LISTEN3, 0x01 },

-> in idle mode I need 28µA (with WDT enabled)
-> in idle mode I need 24µA (without WDT enabled)
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on August 14, 2015, 03:36:41 PM
-> in idle mode I need 28µA (with WDT enabled)
-> in idle mode I need 24µA (without WDT enabled)
The 4uA delta makes sense with and without WDT.  The real question is, where is the 24uA being consumed?   But even this doesn't add up to the poor battery life you've gotten.  One more question:  When you send to the gateway, do you send with retry and, if so, how many tries?  I've totally stopped sending with retry on the coin cell Mote (although I do request an Ack - I need this to be able to get the received RSSI back from the Gateway).

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on August 16, 2015, 03:17:19 PM
Quote
On a somewhat related note, I have had my TTH Mote stop responding to wake up bursts on two occasions in the last week.  I normally generate the wake up burst every ten minutes from my gateway but I can also generate a wake up burst from my Snooper.  I tried this as well, but this also did not wake up the mote.  I'll have to put a scope on it to see if its still going through listening cycles when it's not responding, but wondering if you've seen this at all.

I've only run motes in listen mode without WDT for testing. My current "Production" setup is still listen mode + WDT. Sometimes I can't manually reach listening motes - but it's always been motes that are hard to reach anyway. But I don't nearly have the same sample set as you with regular 10 minute listen wakeups. 
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on August 17, 2015, 08:00:40 AM
I've only run motes in listen mode without WDT for testing. My current "Production" setup is still listen mode + WDT. Sometimes I can't manually reach listening motes - but it's always been motes that are hard to reach anyway. But I don't nearly have the same sample set as you with regular 10 minute listen wakeups.
Ah, ok.  Some of the code I saw in a recent file of yours makes sense now - basically a counting loop with WDT sleep.  So if a wake up burst hasn't happened within the counting window, you treat it as a 'wake up' anyway, yes?

I think I'll rework my Mote to add this counter and also change my BOD bits to 1.8V BOD, rather than disabled.  This way, if the voltage falls below 1.8V during transmit, it has a chance of recovering...  I'll happily exchange 20uA (for the BOD circuit) for this safety factor while awake.  With my version 2 circuit I can keep the radio completely powered off if I find that the voltage is too low on startup to risk a transmission.  I can then go into an extended recovery period until there seems to be enough power to, at least, report the low battery condition...

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on September 04, 2015, 01:24:32 PM
@felix, the key to making the low duty cycle work is the continuous transmission. I know the spec mentions something about a 1% duty cycle limitation but I've never seen this as a problem so I wonder if they are mentioning a regulatory constraint. Even with wireless boot and particularly if I need to downgrade to 19200 baud I have the gateway send for up to 30s at full power and it's never been a problem. During testing I've had nodes transmit at full power for minutes without ill effect.

Joe

Since bad news doesn't get better with time, I may as well just say it: I'm quite sure there is going to be a regulatory constraint on duty cycle, no matter where you live, and it would be because you're jamming the channel if operating in continuous mode for an extended period of time.  This realization first dawned on me a couple years ago when I was range testing a bit-bang OOK that I built out of very primitive $1 parts.  The datarate was very low, and so to speed up the testing for lost packets, I decided to send them one after another with only a perfunctory break in-between.  As it happens, my wife later reported that she couldn't open the garage door to park her car.  She had concluded the opener must be broken, so she parked outside.  Ooops!

As an alternative, for the RFM69, I was planning to use an accurate clock to try to send the packets only around the time when the radio might be ready to receive them, but I haven't yet thought through any of the details on how to make that work.  Perhaps the receiver node uses the packet's time of arrival to sync more precisely when it falls asleep, so that drift over time doesn't cause a failure.  It's a slightly tougher problem to solve, but now that you've got the simpler case working, you may want to consider it or some other method.  Or not.  It's really up to you whether you want to be compliant or not.  For instance, if you're using it only in a deep cave, then it obviously wouldn't matter.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on September 04, 2015, 05:15:19 PM
Quote
Since bad news doesn't get better with time, I may as well just say it: I'm quite sure there is going to be a regulatory constraint on duty cycle, no matter where you live, and it would be because you're jamming the channel if operating in continuous mode for an extended period of time

I use 433 MHz in Germany which AFAIK does not have a duty cycle limitation. The 915 MHz band in the US also does not have a duty cycle constraint. Even there was one if you burst 3s every 5 minutes you'd be at 1%.

If listen mode weren't cheaper than the WDT I'd be more interested to look at alternatives.

Joe
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on September 05, 2015, 12:26:30 PM
Quote
As an alternative, for the RFM69, I was planning to use an accurate clock to try to send the packets only around the time when the radio might be ready to receive them

I've looked at a couple of HW options for this today. Maybe the most promising is this (http://abracon.com/Precisiontiming/AB08X5-RTC.PDF). If Tino had one of these on board and each node had an assigned second period each minute during which it should listen average battery would come down significantly below 1uA. Which would truly give you a decade even on cr2032.
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on September 05, 2015, 02:34:42 PM
Quote
As an alternative, for the RFM69, I was planning to use an accurate clock to try to send the packets only around the time when the radio might be ready to receive them

I've looked at a couple of HW options for this today. Maybe the most promising is this (http://abracon.com/Precisiontiming/AB08X5-RTC.PDF). If Tino had one of these on board and each node had an assigned second period each minute during which it should listen average battery would come down significantly below 1uA. Which would truly give you a decade even on cr2032.

Those might be nice if you were thinking of putting a clock on each sensor node, given how low their current drain is.  If you have the capability to go that direction, which is sounds like you do, then it becomes a much simpler ballgame.

At least in the past, it seemed like the most accurate clocks were the ones that used TXO's. However, I don't suppose you would need that level of accuracy if you were putting RTC's on each node.
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on September 05, 2015, 04:33:24 PM
Quote
As an alternative, for the RFM69, I was planning to use an accurate clock to try to send the packets only around the time when the radio might be ready to receive them

I've looked at a couple of HW options for this today. Maybe the most promising is this (http://abracon.com/Precisiontiming/AB08X5-RTC.PDF). If Tino had one of these on board and each node had an assigned second period each minute during which it should listen average battery would come down significantly below 1uA. Which would truly give you a decade even on cr2032.

I stand corrected then.  That would make sense out of a product like http://www.silabs.com/Support%20Documents/TechnicalDocs/Si4463-61-60-C.pdf (http://www.silabs.com/Support%20Documents/TechnicalDocs/Si4463-61-60-C.pdf), which relies on a 1 second long repetitive preamble sent to a low power wakeup receiver (which itself wakes up very briefly once a second to sample the airwaves so as to determine whether or not the pre-amble is there, and then wakes up the entire receiver if it is).

I once looked up the FCC rules for 433Mhz (Part 15, Section 15.231) , and with a few exceptions it was highly restrictive as to both transmit power and duty cycle.  Apparently 902Mhz-928Mhz is governed by Part 15, Section 15.249, but I haven't yet delved into that.
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare 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. 
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.
 
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare 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. 
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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?
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare 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.


Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on September 06, 2015, 02:52:49 PM
And here's the last shot from the second batch in the post direclty above:

Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare 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.

 
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare 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?
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on September 08, 2015, 08:31:40 AM
On the other hand, suppose at some point RSSI >  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.



I was trying to give it the benefit of the doubt, but if it turns out there's not even any preamble detection going on, then it might be even worse than that: perhaps a simple noise source might keep the RFM69 in Rx mode indefinitely.   :'(

I haven't yet tried the address matching part, to see if a mismatch would knock it out of the loop or at least prevent a reset of the countdown.  Does it do anything at all?

It might help if there were a way to see the same RF signal that the chip is seeing, or at least some kind of real-time RSSI, while all this is going on. 

Of course, it would help even more if there were better documentation than the few crumbs of information that are in the datasheet!
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on September 08, 2015, 08:43:00 AM
But that can't be true given your scope traces and also what I have seen: if RSSI threshold is too low you will jump into phase 3 but it will abort after timeout 2 strikes. So at worst there are specific scenarios under which the timeout doesn't trigger - one of which may be that there is a continuous burst of real rfm69 originating packets for another node. Whether that's driven by preamble or something else.

Noise by itself does not trigger this behavior.
Title: Re: Ultra low power listening mode for battery nodes
Post by: xavier on December 07, 2015, 05:28:48 PM
hey Joe - I'm trying to use the sample code you posted (page 3) with my moteino+RFM915 but somehow the client never wakes up.

I modified send and startListening so they use the 915 register values (RF_FRFMSB_915, RF_FRFMID_915 and RF_FRFLSB_915 in startListening and in send) but no luck so far.

Any suggestions on how to debug to see what is going on or if I missed anything obvious?

Thanks!

X

Update 1: updated code to show I'm using latest version as posted on previous page

I init my radio as follow just fyi:
Code: [Select]
void xRadioLib::initWithDefaults() {
    _radio.initialize(_frequency,_nodeId,_networkId);
    if (_is_Rfm69Hw) {
        Serial.println("Setting up high power");
        _radio.setHighPower();
    }
    _radio.encrypt(_ENCRYPTKEY);

    _radio.readAllRegs();
   
    _radio.sleep(); //sleep right away to save power

    Serial.print( "Initializing Radio NodeId:" );Serial.print( _nodeId );Serial.print(" and NetworkId: "); Serial.println(_networkId);
}

//to set client in Listen mode
void xRadioLib::setRadioInListenMode(bool on){
    if (on)
        RFM69Listener::startListening( _radio, _buffer, _bufferSize);
    else {
        RFM69Listener::clearBuffer();     //this just sets the size to 0, buffer is still available and is null terminated
        RFM69Listener::endListening(_radio);
        //reset our settings:
        this->initWithDefaults();
    }
   
}

void xRadioLib::wakeUpNode( uint8_t targetNode, uint16_t boostPeriod, bool highspeed)
{
  detachInterrupt( RF69_IRQ_NUM );
  radio.encrypt( 0 );
  radio.setMode( RF69_MODE_STANDBY );

  radio.writeReg( REG_PACKETCONFIG1, RF_PACKET1_FORMAT_VARIABLE | RF_PACKET1_DCFREE_WHITENING | RF_PACKET1_CRC_ON | RF_PACKET1_CRCAUTOCLEAR_ON  );
  radio.writeReg( REG_SYNCVALUE1, 0x5A );
  radio.writeReg( REG_SYNCVALUE2, 0x5A );

  radio.writeReg( REG_FRFMSB, RF_FRFMSB_915 + 1 );
  radio.writeReg( REG_FRFMID, RF_FRFMID_915  );
  radio.writeReg( REG_FRFLSB, RF_FRFLSB_915 );

  if( highspeed ) {
    radio.writeReg( REG_BITRATEMSB, RF_BITRATEMSB_200000);
    radio.writeReg( REG_BITRATELSB, RF_BITRATELSB_200000);
    radio.writeReg( REG_FDEVMSB, RF_FDEVMSB_100000 );
    radio.writeReg( REG_FDEVLSB, RF_FDEVLSB_100000 );
    radio.writeReg( REG_RXBW, RF_RXBW_DCCFREQ_000 | RF_RXBW_MANT_16 | RF_RXBW_EXP_0 );
  }

 
 
  radio.setMode( RF69_MODE_TX );
 
  uint32_t time = millis();
  uint32_t m;
  while( (m = millis()) - time <= boostPeriod ) {

    noInterrupts();
    // write to FIFO
    radio.select();
    SPI.transfer(REG_FIFO | 0x80);

    SPI.transfer( size + 3);

    SPI.transfer( targetNode );

    uint16_t diff = m - time;
    SPI.transfer( diff & 0xff );
    SPI.transfer( (diff & 0xff00) >> 8 );

    for (uint8_t i = 0; i < size; i++)
        SPI.transfer(((uint8_t*) buffer)[i]);
    radio.unselect();
    interrupts();
//    uint32_t txStart = millis();
//    while (digitalRead(RF69_IRQ_NUM) == 0 && millis() - txStart < RF69_TX_LIMIT_MS); // wait for DIO0 to turn HIGH signalling transmission finish
//    radio.setMode( RF69_MODE_STANDBY );
   
    delayMicroseconds( 2000 );
   
   
  }
  radio.setMode( RF69_MODE_STANDBY );
}

Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on December 08, 2015, 04:16:28 AM
Quote
Any suggestions on how to debug to see what is going on or if I missed anything obvious?

If you want to work with the sample code I posted, please build a simple example that only changes the frequency in my code and otherwise doesn't copy or change anything. Then post the full client and server code you wrote so I can see what you're doing.

If you want to pick up smth that just works with 915Mhz radios you might want to try Tom's RFM69 replacement library which as I recall already implements listen mode and works with 915mhz radios.
Title: Re: Ultra low power listening mode for battery nodes
Post by: xavier on December 08, 2015, 12:05:28 PM
thanks. Will try. I must have screwed up something obvious though since even the basic sample code (gateway et node) don't seem to work - I get only a few packets received and the RSSI is 0...I'll try to get the basic sample code working first  or change boards... thanks!
Title: Re: Ultra low power listening mode for battery nodes
Post by: xavier on December 08, 2015, 03:00:24 PM
ok so for now I got my moteinos to talk to each other (seems I was using 2 different versions of the RFM69 library) - the Listen code is still not working but would like to try Tom's code - Anyone knows where the updated RFM69 lib with Tom's changes for the listen mode are posted?

I found this from Felix: https://lowpowerlab.com/forum/index.php/topic,775.0.html but can't seem to find any RFM69Ext.h on the net...
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on December 08, 2015, 08:06:37 PM
ok so for now I got my moteinos to talk to each other (seems I was using 2 different versions of the RFM69 library) - the Listen code is still not working but would like to try Tom's code - Anyone knows where the updated RFM69 lib with Tom's changes for the listen mode are posted?

I found this from Felix: https://lowpowerlab.com/forum/index.php/topic,775.0.html but can't seem to find any RFM69Ext.h on the net...
You want this branch (https://github.com/TomWS1/RFM69_ATC/tree/ListenModeExtensions) along with Felix's latest RFM69 library (which provides the necessary virtualization).  There are example files in the ATC library that use ListenMode (see the examples with the _WL extension -ie, "With Listenmode")

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: xavier on December 09, 2015, 12:45:24 PM
thanks Tom - I had a quick look but the sample code does not seem to compile using the latest from Felix and your branch for the ATC files. I'm using IDE 1.6.6 and getting the following errors:

/Users/xavier/Documents/Arduino/libraries/RFM69/RFM69_ATC.cpp: In member function 'virtual void RFM69_ATC::select()':
/Users/xavier/Documents/Arduino/libraries/RFM69/RFM69_ATC.cpp:117:3: error: '_SREG' was not declared in this scope
   _SREG = SREG;
   ^
/Users/xavier/Documents/Arduino/libraries/RFM69/RFM69_ATC.cpp: In member function 'void RFM69_ATC::sendFrame(uint8_t, const void*, uint8_t, bool, bool, bool, int16_t)':
/Users/xavier/Documents/Arduino/libraries/RFM69/RFM69_ATC.cpp:223:48: error: 'RFM69_CTL_RESERVE1' was not declared in this scope
     SPI.transfer(RFM69_CTL_SENDACK | (sendRSSI?RFM69_CTL_RESERVE1:0));  // TWS  TODO: Replace with EXT1
                                                ^
/Users/xavier/Documents/Arduino/libraries/RFM69/RFM69_ATC.cpp:232:39: error: 'RFM69_CTL_RESERVE1' was not declared in this scope
       SPI.transfer(RFM69_CTL_REQACK | RFM69_CTL_RESERVE1);     // TWS: ASK for ACK + ASK for RSSI
                                       ^
/Users/xavier/Documents/Arduino/libraries/RFM69/RFM69_ATC.cpp: In member function 'virtual void RFM69_ATC::interruptHook(uint8_t)':
/Users/xavier/Documents/Arduino/libraries/RFM69/RFM69_ATC.cpp:284:34: error: 'RFM69_CTL_RESERVE1' was not declared in this scope
   ACK_RSSI_REQUESTED = CTLbyte & RFM69_CTL_RESERVE1; // TWS: extract the ACK RSSI request bit (could potentially merge with ACK_REQUESTED)

To fix the _SREG I added a definition in RFM69.h since this is where the __SPSR is defined

For the RFM69_CTL_RESERVE1 issue it seems your branch does not have it defined in RFM69_ATC but the file in the RFM69 branch does have it so I just copied it from there.

Things seem to work alright now although it seems sometimes the node gets stuck in sleeping mode and never wakes up after a while. If I restart a node I do get the wakeup for the gateway somehow does not receive any data after the first wakeup burst and then it seems to work after the second wake up.

Anyhow, I'm still looking at the code but this is a very neat feature! Hopefully you'll add it to the RFM69 library. Thanks again for sharing!
Title: Re: Ultra low power listening mode for battery nodes
Post by: xavier on December 09, 2015, 01:22:45 PM
it seems radio.listenReceivedOffset() returns an overflow after a while - havent had a chance to check out why but that's why the loop gets stuck. Once you comment that out and add a delay of 500ms in sleepUntilPacket after the wakeup to give the radio.init on the gateway to recover everything works like a charm! Really neat indeed. 
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on December 09, 2015, 02:28:06 PM
it seems radio.listenReceivedOffset() returns an overflow after a while - havent had a chance to check out why but that's why the loop gets stuck. Once you comment that out and add a delay of 500ms in sleepUntilPacket after the wakeup to give the radio.init on the gateway to recover everything works like a charm! Really neat indeed.
I'll take a look at the problems you've reported but I won't be able to get to it for a while.  I'm glad that you've figured it out and have it running!  Good job!

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: snorp on February 12, 2016, 10:04:37 PM
Things are all hosed up now with the ListenModeExtensions branch because Felix's RFM69 master has a RFM69_ATC class as well. I guess there aren't plans to put the listen mode stuff there, so maybe we need a RFM69_WL (LM?)...
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on February 13, 2016, 09:11:00 AM
Things are all hosed up now with the ListenModeExtensions branch because Felix's RFM69 master has a RFM69_ATC class as well. I guess there aren't plans to put the listen mode stuff there, so maybe we need a RFM69_WL (LM?)...
Your choices appear to be:
1. Install the RFM69_ATC library with ListenMode extensions and copy the RFM69_ATC cpp & h files to the RFM69 library folder or...
2. Install the RFM69_ATC library with ListenMode extensions and remove the RFM69_ATC cpp & h files from the RFM69 library folder

Note that the ListenMode extension library also contains the SPI Transaction extensions and will soon be updated with the latest listen mode 'timer' capability (where 'soon' is a nebulous term without any official commit date).

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: xavier on February 13, 2016, 01:44:08 PM
snorp : you can try the attached version, it worked for me (#1 from Tom's reply) - do note though i could not make the wireless programming work w that version - haven't had a chance to look into it though

Tom: what's the timer capabilities you're talking about? :-)
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on February 13, 2016, 02:49:34 PM
Tom: what's the timer capabilities you're talking about? :-)
See thread: https://lowpowerlab.com/forum/index.php/topic,1325.0.html which describes the method and implied power savings.

Basically you setup the RFM69 in ListenMode with a super sensitive RSSI trigger so the RFM69 generates an RX interrupt as soon as the Listen Idle Timer times out.  Joe has thoroughly tested it, but I haven't integrated it into the RFM69_ATC library yet.   I have parts due in on Tuesday that will allow me to test it (assuming I get the code modified  ;)

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: Tomme on February 20, 2016, 08:04:32 AM
I'm wondering if anyone can shed any light on a interesting... quirk I've found while working with low power listening.

I'll start, quickly with my setup:

The above set up works well; packets are received and power consumption is fairly low. However if I increase the idle time from 4.096 ms to say 8.192 ms it stops working, the RSSI is never detected as going above the threshold. If I increase the RX time a little, from 256 us to 384 us, it starts working again. Is there some relationship between the two that I am missing?
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on February 20, 2016, 09:15:49 AM
8.192ms sounds suspiciously close to when the atmega328p might be in the middle of waking up from a watchdog timer event.  Is that what's happening?  I'm not sure if new interrupts are detected during the wakeup phase.
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on February 20, 2016, 10:51:18 AM
I'm wondering if anyone can shed any light on a interesting... quirk I've found while working with low power listening.

I'll start, quickly with my setup:
  • Rx Time: 256 us
  • Idle Time: 4096 us
  • Signal Acceptance Criteria: RSSI >= threshold
  • End of cycle action: Stay in Rx until Timeout or PayloadReady, resume listen mode in idle.
  • RSSI Threshold: -75dBm (wanted to avoid interference while development)
  • Timeout2 value: 51
  • Bitrate: 55,555

The above set up works well; packets are received and power consumption is fairly low. However if I increase the idle time from 4.096 ms to say 8.192 ms it stops working, the RSSI is never detected as going above the threshold. If I increase the RX time a little, from 256 us to 384 us, it starts working again. Is there some relationship between the two that I am missing?
What are the exact values you're using in LISTEN1, LISTEN2, and LISTEN3 regs in both cases?

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: Tomme on February 20, 2016, 02:56:14 PM
8.192ms sounds suspiciously close to when the atmega328p might be in the middle of waking.....

I should say that there is nothing special about the 8192 us number. If I change it by a few increments, it still doesn't work. I'm also looking at the power consumption of the radio on a scope so I can see it entering/exiting idle and rx modes so I can see that the timings for both idle and rx are correct.

What are the exact values you're using in LISTEN1, LISTEN2, and LISTEN3 regs in both cases?
Tom

LISTEN1: 0x54   (0b01010100)
LISTEN2: 0x40 (4.1 ms) or 0x80 (8.2 ms)
LISTEN3: 0x04 (256 us) or 0x06 (384 us)

So:
256 us and 4.1 ms - works.
256 us and 8.2 ms - does not work.
384 us and 8.2 ms - works.
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on February 20, 2016, 05:09:51 PM
8.192ms sounds suspiciously close to when the atmega328p might be in the middle of waking.....

I should say that there is nothing special about the 8192 us number. If I change it by a few increments, it still doesn't work. I'm also looking at the power consumption of the radio on a scope so I can see it entering/exiting idle and rx modes so I can see that the timings for both idle and rx are correct.

What are the exact values you're using in LISTEN1, LISTEN2, and LISTEN3 regs in both cases?
Tom

LISTEN1: 0x54   (0b01010100)
LISTEN2: 0x40 (4.1 ms) or 0x80 (8.2 ms)
LISTEN3: 0x04 (256 us) or 0x06 (384 us)

So:
256 us and 4.1 ms - works.
256 us and 8.2 ms - does not work.
384 us and 8.2 ms - works.
Thanks for the info, but, sorry, I'm not seeing it.  Joe is the maven on these settings but he's been tied up the last couple of days.  Maybe he'll be around tomorrow and can comment on it.

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on February 21, 2016, 02:01:22 AM
I've found that you need at least 384uS with a 55kbit data rate. 256uS only works with 200kbit in my setup. So I'm actually surprised that you could sporadically get 256uS to work at 55kbit. There should be no connection to the idle period unless your tx burst is shorter than the idle period. 
Title: Re: Ultra low power listening mode for battery nodes
Post by: Tomme on February 21, 2016, 05:32:48 AM
I've found that you need at least 384uS with a 55kbit data rate. 256uS only works with 200kbit in my setup. So I'm actually surprised that you could sporadically get 256uS to work at 55kbit. There should be no connection to the idle period unless your tx burst is shorter than the idle period.

I agree that there shouldn't be any connection to the length of the idle period but this experience seems to suggest otherwise, I will try to investigate a bit more.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on February 22, 2016, 03:41:02 AM
Quote
So I'm actually surprised that you could sporadically get 256us to work at 55kbit.

I'm currently rereading the rfm69cw spec because I'm implementing a manual listen style mode for a board with the AM1805 RTC. Please check page 14 (Receiver Specification). You can see there how the time from PLL locked state to RX ready depends on both the data rate and the RxBW:

Quote
TS_RE_AGC Receiver wake-up time, from PLL locked state, AGC enabled
RxBw = 10 kHz, BR = 4.8 kb/s, 3.0ms
RxBw = 200 kHz, BR = 100 kb/s, 163us

Add to that the 80us it takes to reach PLLlock and the 40us 2 bits of RX for RSSI detection take at 50khz and you can see pretty clearly that with 55khz 256us just shouldn't work

There are also a couple of other nuggets in there. Observe for example that:

Quote
Receiver wake-up time, from PLL
locked state to RxReady
RxBw = 10 kHz, BR = 4.8 kb/s, 1.7ms
RxBw = 200 kHz, BR = 100 kb/s, 96us

In other words RxReady is reached much quicker if automatic gain control is off.

Given these data points I'm going to try the following:

Listen mode nodes listen for wakeup signals using 300kbit and 500khz RxBw without AGC, resulting in total time in Rx to RSSI detection of less than 198us - potentially significantly less if receiver wake-up time reduces similarly from 200khz RxBW to 500khz RxBW as it does from lower RxBWs.

The expectation here is not to actually try to receive packets at these super aggressive settings (potentially underground). It's just to detect the gateways willingness to send packets. Once a node knows the gateway wants to send a packet it switches to rx using more conservative settings.

This is particularly attractive for RTC nodes which won't need a regular wakeup burst to stay in sync. Going just by the RX power consumption and assuming a 3s idle window we come out at:

0.000198s / 3s * 16mA = 1uA which would be pretty phenomenal for a node that can be reached in 1.5s on average.

Joe
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on February 22, 2016, 07:21:56 AM
There are also a couple of other nuggets in there. Observe for example that:

Quote
Receiver wake-up time, from PLL
locked state to RxReady
RxBw = 10 kHz, BR = 4.8 kb/s, 1.7ms
RxBw = 200 kHz, BR = 100 kb/s, 96us

In other words RxReady is reached much quicker if automatic gain control is off.
I'm missing the AGC connection in this quote...

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on February 22, 2016, 08:15:14 AM
Quote
I'm missing the AGC connection in this quote...

That's the point. Only the other quote refers to measurements with AGC enabled:

Quote
TS_RE_AGC Receiver wake-up time, from PLL locked state, AGC enabled
RxBw = 10 kHz, BR = 4.8 kb/s, 3.0ms
RxBw = 200 kHz, BR = 100 kb/s, 163us

Disabling AGC almost cuts the wake-up time in half.
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on February 22, 2016, 09:00:52 AM
The datasheet gives the formulas for the different timings just below Figure 20, and so with the help of the corresponding figure you can sum up the time intervals that are of interest to you.  However, I was never certain what the "." meant in the formulas.  For example,
"RSSI sample time: Trssi = 2 x int(4.RxBw.Tbit)/(4.RxBw) (aka TS_RSSI)"

Does "." mean multiplication?  Maybe their notation is just sloppy, but it does say  "2 x int" instead of "2.int"

Does anyone here know what "." means?

As was mentioned by Perky in a different thread, it would be nice if there were a spreadsheet to aid in quickly calculating the numbers (time intervals) of interest, but to construct one the meaning of "." in the formulas needs to be clarified.  If we all had such a spreadsheet, it would be much easier to do "what-if" comparisons, as well as cross-check one's own computations.

Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on February 22, 2016, 10:17:47 AM
In other words RxReady is reached much quicker if automatic gain control is off.

Also, less noise if you default to G1, which might translate into fewer false positives, since you're relying on RSSI to assess  the transmitter's intention to send.

Thanks for sharing your math.  The energy savings make for a compelling case to do it that way.

Will you also be keeping the AM1805 in close enough sync with the sender's  RTC (or maybe visa versa), so that the the sender doesn't have to spray packets over the full 3 second interval, but instead over a much narrower window that the receiver is likely to be actually listening? 
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on February 23, 2016, 02:25:05 AM
Quote
"RSSI sample time: Trssi = 2 x int(4.RxBw.Tbit)/(4.RxBw) (aka TS_RSSI)"

In another section they give RSSI as 2.Tbit. And in the text they say RSSI detection takes two bits. So apparently . is x. Still pretty funky formula ...

Quote
Will you also be keeping the AM1805 in close enough sync with the sender's  RTC (or maybe visa versa), so that the the sender doesn't have to spray packets over the full 3 second interval, but instead over a much narrower window that the receiver is likely to be actually listening?

Once the sender has an RTC that's the plan.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on February 24, 2016, 12:29:08 PM
Quote
Listen mode nodes listen for wakeup signals using 300kbit and 500khz RxBw without AGC, resulting in total time in Rx to RSSI detection of less than 198us - potentially significantly less if receiver wake-up time reduces similarly from 200khz RxBW to 500khz RxBW as it does from lower RxBWs.

The expectation here is not to actually try to receive packets at these super aggressive settings (potentially underground). It's just to detect the gateways willingness to send packets. Once a node knows the gateway wants to send a packet it switches to rx using more conservative settings.

I've got this running now. For starters I just have the mote send an update whenever it finds via RSSI detection that the gateway wants to talk to it. The gateway can then send any command with the ACK to that update.

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.

Use a lithium 9V (1200mAh, 1% self-discharge per year) and the battery should last you 120 years. That's including self discharge. That's what I call a lifetime mote and the revival of the 9V battery.  :D
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on February 25, 2016, 04:31:16 PM
Just a thought, but you may want to run your RSSI detection in OOK Rx mode, as it appears there would be less chance of a false positive resulting from noise:  https://lowpowerlab.com/forum/index.php/topic,1468.msg11931.html#msg11931
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on February 25, 2016, 11:55:04 PM
Quote
Just a thought, but you may want to run your RSSI detection in OOK Rx mode, as it appears there would be less chance of a false positive resulting from noise:  https://lowpowerlab.com/forum/index.php/topic,1468.msg11931.html#msg11931

If I wanted to reduce the rxbw I can do that using fsk just as well. However that increases RSSI detection time. Just as a lower bitrate does. Actually I find the whole concept of rxbw for ook a bit puzzling since by definition the signal doesn't have any frequency deviation.

It's a trade-off: higher rxbw gives much quicker RSSI detection but then more false positives. I only very sporadically get false positives so max rxbw works best. Until every household has one of my thermometers :-)
Title: Re: Ultra low power listening mode for battery nodes
Post by: emjay 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on February 26, 2016, 04:34:13 AM
Quote
Puzzling, but real.

Interesting! Thanks for the explanation.
Title: Re: Ultra low power listening mode for battery nodes
Post by: Tomme 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?
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: Tomme 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?
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: Tomme 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".
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.

Title: Re: Ultra low power listening mode for battery nodes
Post by: niranjan_187 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: snorp 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: snorp 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.
Title: Re: Ultra low power listening mode for battery nodes
Post by: snorp 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 (https://github.com/snorp/RFM69_WL)

(0) https://github.com/TomWS1/RFM69_ATC/tree/ListenModeExtensions
Title: Re: Ultra low power listening mode for battery nodes
Post by: Felix on April 07, 2016, 08:07:31 AM
snorp,
Definitely something I will be looking into. Thanks for sharing it!!
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS 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 (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
Title: Re: Ultra low power listening mode for battery nodes
Post by: snorp on April 07, 2016, 10:10:02 AM
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.

Thanks for the tip! I assume an interrupt will only be generated if the CRC check passes, so is there any way to know that these spurious wakeups are occurring? I guess disabling the CRC might wake me up for any random garbage?

Anyway, I'll make the RSSI threshold runtime-adustable. What about the RXTIMEOUT2 value? I don't know if I really understand what that one does. That's how long we wait for a full packet after the RSSI threshold is triggered? Seems like that one should be adjustable too.
Title: Re: Ultra low power listening mode for battery nodes
Post by: Felix on April 07, 2016, 11:29:52 AM
@snorp:

Regarding RegRxTimeout2:
0x2B RegRxTimeout2 0x00 Timeout duration between RSSI detection and PayloadReady (DS page 61 (http://www.semtech.com/images/datasheet/sx1231h.pdf))
You can monitor the Timeout interrupt that occurs if the RSSI threshold is triggered but no payloadready interrupt is triggered (see page 70 last table row), I think that would be a good indication we're getting noise. I lowered it to 180 and it seems to work fine.
I would like to attempt to integrate your work directly into the RFM69 lib so we could use the ATC as well, otherwise not sure how that tandem could work.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on April 07, 2016, 01:19:00 PM
Snorp, thanks for racing ahead with this - that's great. The timeout2 is what one would ideally use to detect noise triggered RSSI awakenings. Be aware though that I never got that to fully work. Search this thread and I think another thread in this board for the infamous listen mode bug.

What happens is that prolonged periods of noise just keep the radio in rx even though timeout2 is set. I have a workaround that maps RSSI to dio0 and does its own timeout management. But it's much more involved than the simple listen mode code I used to have.

If you can figure out how to fix that problem without remapping dio0 you might be up for Joe's coveted Listen Mode Medal (tm). :-)

The bug can easily be triggered by sending a burst using a wrong bitrate.
Title: Re: Ultra low power listening mode for battery nodes
Post by: snorp on April 07, 2016, 03:27:23 PM
Indeed, monitoring the RSSI/RX state with the threshold set to 200db we are constantly woken up by noise (no moteino transmitting). With RXTIMEOUT2=75, I see RSSI last about ~35µs (though sometimes almost a ms!), and RX is consistently around 340-370µS. I never see the timeout bit set in this scenario. If I set RXTIMEOUT2=0 (disable the timeout) the results are dramatically worse, and we spend about 24ms :o in RX. If I set RXTIMEOUT2=1, the results are similar to when it's set to 75, but I do get the timeout bit set. It seems like there is a minimum RX duration that cannot be shortened by using the timeout interrupt. That doesn't really explain why the timeout bit isn't set at higher values, though.

In any case, setting the RSSI threshold to 170db seems to avoid waking up from the noise in my office.

EDIT: I forgot to mention, if I listen at 5.5kbit there are significantly fewer wakeups at 200db. Same results otherwise.
Title: Re: Ultra low power listening mode for battery nodes
Post by: Felix on April 07, 2016, 04:52:39 PM
@snorp,
I published a new RFM69 branch (https://github.com/LowPowerLab/RFM69/tree/ListenMode) which includes the ListenMode based on your work (https://github.com/snorp/RFM69_WL). I merged your changes into the RFM69 library itself. Finally it looks like RFM69 is officially getting close to receiving ListenMode, yay, thanks again for sharing your work!

I wrapped all the ListenMode specifics into #defines. The purpose of the wrapping is the allow compiling sketches without ListenMode to save ~2k, not sure if there's a better way of doing that without using inheritance or a utility class (where you pass the radio object into it).

Please try my library and see how it works. I tried a bunch of different settings and I tweaked them to what worked best at 915mhz, I assume they will work even better at 433mhz.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on April 07, 2016, 06:19:02 PM
Quote
I wrapped all the ListenMode specifics into #defines. The purpose of the wrapping is the allow compiling sketches without ListenMode to save ~2k, not sure if there's a better way of doing that without using inheritance or a utility class (where you pass the radio object into it).

Arduino typically uses compiler/linker settings which put each function into its own section and eliminate all functions not referenced. Are you finding that code size increases even if you don't call any listen mode functions?
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on April 07, 2016, 07:31:10 PM
Quote
In any case, setting the RSSI threshold to 170db seems to avoid waking up from the noise in my office.

More correct would likely be saying that you rarely wake up. It might be once a week or once a month but you will get signals strong enough to wake you. With a normal battery that's ok. With a coin cell it can easily kill your mote since vcc will be driven so low that the mote can't restart when the BOD kicks in. Hence my workaround.

Same issue as the low rssi threshold in rfm69 leading to incorrect automatic gain control and overly cranked up rx amplifier.

The best solution probably involves using timeouts provided they can be made to work and dynamically adjusting rssithresh.
Title: Re: Ultra low power listening mode for battery nodes
Post by: Felix on April 07, 2016, 10:45:26 PM
Quote
I wrapped all the ListenMode specifics into #defines. The purpose of the wrapping is the allow compiling sketches without ListenMode to save ~2k, not sure if there's a better way of doing that without using inheritance or a utility class (where you pass the radio object into it).

Arduino typically uses compiler/linker settings which put each function into its own section and eliminate all functions not referenced. Are you finding that code size increases even if you don't call any listen mode functions?
I was expecting to see this too. Yes the code size is the same with or without calling ListenMode code. I am using 1.0.6.
Title: Re: Ultra low power listening mode for battery nodes
Post by: snorp on April 08, 2016, 10:40:43 AM
@Felix

The stuff in the ListenMode branch looks mostly ok to me. I made some other changes after you pulled my repo, maybe you would like to integrate those too? Or I can? I fixed the setting of REG_LNA (which you correctly commented out), and introduced a push/pop mechanism for setting the listen and burst configurations. That way we don't have to clumsily reinitialize the entire radio. This ends up simplifying re-enabling of the encryption too, since we don't have to save the key in order to set it after RFM69::initialize() clobbers it.

Also I can confirm the ~2k code size savings by not building the listen mode stuff. The build does use -ffunction-sections and --gc-sections, which is supposed to avoid this kind of nonsense, so I'm not sure what's going on. Ugh.
Title: Re: Ultra low power listening mode for battery nodes
Post by: davegravy on April 12, 2016, 09:51:16 AM
In the listening mode node example on github there is:

Code: [Select]
 LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);

In my application I want the node to wakeup either when there's a transmission to it OR after 1 hour to take a measurement, and ideally I don't want to rely on the gateway to "wake" the node up with a transmission for those hourly wakeups.

Is there a way to do this? I can't put 8s sleeps in a loop, right? because (I'm assuming) there's no low-power means to determine after each 8s sleep if we've woken up due to received data or because 8s has elapsed...
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on April 12, 2016, 01:24:10 PM
In the listening mode node example on github there is:

Code: [Select]
 LowPower.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);

In my application I want the node to wakeup either when there's a transmission to it OR after 1 hour to take a measurement, and ideally I don't want to rely on the gateway to "wake" the node up with a transmission for those hourly wakeups.

Is there a way to do this? I can't put 8s sleeps in a loop, right? because (I'm assuming) there's no low-power means to determine after each 8s sleep if we've woken up due to received data or because 8s has elapsed...
You can put in a WDT loop so, instead of SLEEP_FOREVER, you could sleep for n x 8Seconds while the radio is still in listen mode.  This works if you catch the wakeup packet in an interrupt handler for the radio (you'll have to temporarily replace the standard one) and use its existence to know that you woke up from a packet rather than the 8 second timeout.  Disable WDT on return.

The disadvantage of this is that you have WDT power consumption plus the brief processor run times every 8 seconds - this is probably much less than the power consumed by WDT.  You wouldn't have this power consumed in a pure ListenMode setup.

Tom

Title: Re: Ultra low power listening mode for battery nodes
Post by: Tomme on April 18, 2016, 08:45:55 AM
I just took a look at the listen mode branch and I wondered why the burst transmission (to wake the node) uses multiple transmissions?
Title: Re: Ultra low power listening mode for battery nodes
Post by: Felix on April 18, 2016, 09:21:37 AM
I just took a look at the listen mode branch and I wondered why the burst transmission (to wake the node) uses multiple transmissions?
Because the client has to be "latched" whenever it wakes up into RX mode. The master continuously transmits for at least the listen window (3s in this implementation). If the master only periodically transmits then client might not intercept it right in time. When the client wakes up for the RX part of the cycle, and a transmission is detected - the RSSI threshold is exceeded and it will trigger a longer RX period in which it expects a packet to be received. If it receives a valid packet it will trigger the packet received interrupt and wake the MCU. If it doesn't - then either it was just noise that woke it up (should be a very rare occurrence) or the packet could not be properly reiceved - in which case the RSSI timeout interrupt is triggered and the radio returns to it's normal listen cycle (sleep a long time in very low power mode, then wake up in RX mode for a very short time, then repeat).

Makes sense?
Title: Re: Ultra low power listening mode for battery nodes
Post by: Tomme on April 18, 2016, 11:57:34 AM
Sorry, should have been clearer. Why not just use a larger preamble to extend the length of 1 packet rather than lots of packets? I use an idle time of 15.36 ms and an rx time of 0.384 as I need lower latency. At 55.5 kbps, 111 preamble bytes takes just under 16ms, ensuring that any receiving nodes will have woken up during preamble.

I guess with lots of small packets other nodes that are woken by packets that aren't addressed to them can return to sleep after the first packet.
Title: Re: Ultra low power listening mode for battery nodes
Post by: snorp on April 18, 2016, 12:38:21 PM
Sorry, should have been clearer. Why not just use a larger preamble to extend the length of 1 packet rather than lots of packets? I use an idle time of 15.36 ms and an rx time of 0.384 as I need lower latency. At 55.5 kbps, 111 preamble bytes takes just under 16ms, ensuring that any receiving nodes will have woken up during preamble.

I guess with lots of small packets other nodes that are woken by packets that aren't addressed to them can return to sleep after the first packet.

I think the main problem here is that the listening nodes would have to be awake a lot longer (the entire duration of a listen cycle) when they are woken up. For most folks, that's going to be more like 1-2s rather than 15ms. With the message burst you can sleep the radio/cpu after receiving the packet.
Title: Re: Ultra low power listening mode for battery nodes
Post by: Tomme on April 18, 2016, 02:03:33 PM
I think the main problem here is that the listening nodes would have to be awake a lot longer (the entire duration of a listen cycle) when they are woken up. For most folks, that's going to be more like 1-2s rather than 15ms. With the message burst you can sleep the radio/cpu after receiving the packet.

True, I'm more interested in using sleep modes for mesh networking so my thoughts always tend to head in that direction.  We're basically talking about the differences between bmac and xmac protocols here. I've been using the method (basically BMAC) I described in my previous post with a fair amount of success but as you've mentioned the power consumption overhead increases as more nodes join the network. I keep meaning to try XMAC but it works better when the sleep time is longer, which increases latency! No such thing as a free lunch I suppose.

Links to papers for those interested:
http://www.eecs.harvard.edu/~mdw/course/cs263/papers/bmac-sensys04.pdf (http://www.eecs.harvard.edu/~mdw/course/cs263/papers/bmac-sensys04.pdf)
http://www.cse.wustl.edu/~lu/cse521s/Papers/x-mac.pdf (http://www.cse.wustl.edu/~lu/cse521s/Papers/x-mac.pdf)
Title: Re: Ultra low power listening mode for battery nodes
Post by: Felix on April 18, 2016, 02:15:33 PM
Tomme,
I think snorp has just covered what I was about to say.
But IOW you want to keep the sleepy client as little time as possible in RX mode. That means that the burst from the master also has to be as short as possible to maximize chances of hitting the RX window of the client after the client has detected the burst and entered the extra RX receive-packet-or-timeout period. If the master burst packets are LONG, then either the client will timeout before it latches a new complete burst packet, or it has to spend more time waiting for it - neither of which we want. I think in most cases the client will go into initial RX, detect a part of a burst packet, then transition to extended RX to attempt to capture a packet, and then it actually receives a subsequent packet. The master will keep on sending since during the burst all it does is it continuously transmits packets (one way road). The payloads of the burst tell the client how long before the burst will end - so that a more useful two way channel communication can be done.

So basically listen mode is simply trying to wake a sleepy node, and tell it how long before the burst is over, and real transmission can start happening. Sorry if I over-repeat myself but some guys will find this useful in understanding how this actually works. Once a sleepy node is "woken", it can sleep for the rest of the burst period, then it can wake up again and sync with the master and do some real packet exchanges. Part of this mechanism is illustrated in the ListenMode examples which I posted in the ListenMode branch (https://github.com/LowPowerLab/RFM69/tree/ListenMode).
Title: Re: Ultra low power listening mode for battery nodes
Post by: Tomme on April 18, 2016, 02:34:36 PM
I get what you are saying but Felix :). As I said I've been using longer preamble sequences successfully for a while, it suffers from scaling problems but it is nice and simple. I will probably move to something more similar to what you guys seem to be doing soon.

Have you considered having the target receiver node acknowledge when it receives the first "burst" packet? You could substantially improve contention in a larger network. A three second burst is all very well if you don't do it often but it isn't particularly feasible in a network where nodes need to route packets.
Title: Re: Ultra low power listening mode for battery nodes
Post by: Felix on April 18, 2016, 02:51:34 PM
I think the 3s burst is to give the client up to 3 chances to latch a burst packet and wake up. We could reduce the sleep time of the listen cycle, so that we could use a 1s instead of 3s burst. But that would also mean increasing the relative RX time and hence reduce battery time. It's all a tradeoff. If you look at the listen code, you will see it's listening at a 1mhz offset from the main channel so as to not interfere with the main traffic.
An ACK is not feasible during a burst simply because the TX-RX transition of the master is too slow and we want a very linear interference free transmission to give a client a best chance to intercept the burst. The burst can of course be latched by multiple nodes - which would further complicate things if ACKs were involved. I think if you study the lib and examples it will become more apparent why things are done this way. If you hook up a current meter to your client while changing the RX/sleep duty cycle, and perhaps other settings, it will be even more plain why the settings are what they are. You can always change things around, but settings that work well were chosen to allow most people to get started and understand listen mode more easily.
Title: Re: Ultra low power listening mode for battery nodes
Post by: Tomme on April 18, 2016, 03:11:38 PM
I understand why it was done the way it is. It is very much tailored for one application; an always on base station that only occasionally needs to communicate with nodes arranged in a star network. As soon as you move away from this you run into problems. When we start getting into situations where both sender and receiver are power constrained (and use listen mode) then a 3 second burst transmission is incredibly expensive in terms of power consumption.

If this comes across negatively, I apologise, I think that my requirements are just different to other peoples. I think that the sleep mode work that has already been done is great and will work for 90% of the situations that people are likely to encounter!
Title: Re: Ultra low power listening mode for battery nodes
Post by: snorp on April 18, 2016, 03:18:41 PM
I think the 3s burst is to give the client up to 3 chances to latch a burst packet and wake up. We could reduce the sleep time of the listen cycle, so that we could use a 1s instead of 3s burst.

Hmm, where is the 3s coming from? The code that I had (and TomWS's too) just used rx time + sleep time for the burst duration, which was set to about ~1s for me. It has always been reliable here without needing to send for a longer period.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on April 18, 2016, 05:02:33 PM
Quote
I think the 3s burst is to give the client up to 3 chances to latch a burst packet and wake up. We could reduce the sleep time of the listen cycle, so that we could use a 1s instead of 3s burst.

My code has a 3s burst but then also a 2.9s idle time. I find that nearly always wakes the mote. No need to try multiple times.

Joe
Title: Re: Ultra low power listening mode for battery nodes
Post by: luisgcu on May 08, 2016, 10:25:35 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 (https://github.com/snorp/RFM69_WL)

(0) https://github.com/TomWS1/RFM69_ATC/tree/ListenModeExtensions

Hello ,
I am interested in use the low power listening  mode, so I decided to give a try to the  snorp branch of the  rfm69 library -->https://github.com/snorp/RFM69_WL (https://github.com/snorp/RFM69_WL), and it work  fine.
I tried to do the same test  with Felix  examples provided in the development library https://github.com/LowPowerLab/RFM69/tree/ListenMode (https://github.com/LowPowerLab/RFM69/tree/ListenMode) but it won't work.. node go sleep ok..  I am monitoring the current while slepping..  it shows 1.6ua .. current start to increase in steps u to 94ua, then go down to 1.6ua .. the cycle is repeated, but the problem is  the sleeping node wont wake up when burst is sent from the other node .
not sure what I  am missing? I have repeated the test several times.. with no luck
is there any hardware connection that need to be set to get it working properly?
any program setting that need to be  adjusted ??
I am using moteinos  with RFM69w.

Title: Re: Ultra low power listening mode for battery nodes
Post by: davegravy on May 08, 2016, 10:55:35 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 (https://github.com/snorp/RFM69_WL)

(0) https://github.com/TomWS1/RFM69_ATC/tree/ListenModeExtensions

Hello ,
I am interested in use the low power listening  mode, so I decided to give a try to the  snorp branch of the  rfm69 library -->https://github.com/snorp/RFM69_WL (https://github.com/snorp/RFM69_WL), and it work  fine.
I tried to do the same test  with Felix  examples provided in the development library https://github.com/LowPowerLab/RFM69/tree/ListenMode (https://github.com/LowPowerLab/RFM69/tree/ListenMode) but it won't work.. node go sleep ok..  I am monitoring the current while slepping..  it shows 1.6ua .. current start to increase in steps u to 94ua, then go down to 1.6ua .. the cycle is repeated, but the problem is  the sleeping node wont wake up when burst is sent from the other node .
not sure what I  am missing? I have repeated the test several times.. with no luck
is there any hardware connection that need to be set to get it working properly?
any program setting that need to be  adjusted ??
I am using moteinos  with RFM69w.

Not sure if it's related but mine only goes down to 6uA in listennode (running at 3v, regulator removed,  8mhz internal oscillator). I wasn't  aware of the snorp branch, I'm using the listennode branch from Felix's github, and it works fine for me.
Title: Re: Ultra low power listening mode for battery nodes
Post by: luisgcu on May 08, 2016, 11:30:38 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 (https://github.com/snorp/RFM69_WL)

(0) https://github.com/TomWS1/RFM69_ATC/tree/ListenModeExtensions

Hello ,
I am interested in use the low power listening  mode, so I decided to give a try to the  snorp branch of the  rfm69 library -->https://github.com/snorp/RFM69_WL (https://github.com/snorp/RFM69_WL), and it work  fine.
I tried to do the same test  with Felix  examples provided in the development library https://github.com/LowPowerLab/RFM69/tree/ListenMode (https://github.com/LowPowerLab/RFM69/tree/ListenMode) but it won't work.. node go sleep ok..  I am monitoring the current while slepping..  it shows 1.6ua .. current start to increase in steps u to 94ua, then go down to 1.6ua .. the cycle is repeated, but the problem is  the sleeping node wont wake up when burst is sent from the other node .
not sure what I  am missing? I have repeated the test several times.. with no luck
is there any hardware connection that need to be set to get it working properly?
any program setting that need to be  adjusted ??
I am using moteinos  with RFM69w.

Not sure if it's related but mine only goes down to 6uA in listennode (running at 3v, regulator removed,  8mhz internal oscillator). I wasn't  aware of the snorp branch, I'm using the listennode branch from Felix's github, and it works fine for me.

mmm.. I get it working after I  swapped the programs Listen node master---> from one moteino to the other.. I have to investigate what was that..  the only difference is one moteino has a pull down resistor on pin 3..
Title: Re: Ultra low power listening mode for battery nodes
Post by: davegravy on May 09, 2016, 07:34:25 AM
Could be related to the radio hanging if you reset or rebooted the node while it was in listennode. Radio won't recover until its supply voltage drops really low and it can take a while for the moteino's 10uF supply capacitor to discharge. Have you tried swapping node/gateway back?
Title: Re: Ultra low power listening mode for battery nodes
Post by: luisgcu on May 22, 2016, 07:07:39 PM
Hello,
 I would like to know is anyone test the listen mode using low baud-rates?
it work fine as default settings on RFM69.CPP , but range distances are short.
 I tried  to change the below settings  without success..

 void RFM69::listenModeApplyHighSpeedSettings()
{
  if (!_isHighSpeed) return;
  writeReg(REG_BITRATEMSB, RF_BITRATEMSB_200000);
  writeReg(REG_BITRATELSB, RF_BITRATELSB_200000);
  writeReg(REG_FDEVMSB, RF_FDEVMSB_100000);
  writeReg(REG_FDEVLSB, RF_FDEVLSB_100000);
   writeReg( REG_RXBW, RF_RXBW_DCCFREQ_000 | RF_RXBW_MANT_20 | RF_RXBW_EXP_0 );
}
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on May 23, 2016, 04:23:58 AM
If you use lower baud rates you need to increase the rx time because it will take longer to check for RSSI. This will make listen mode much more power hungry unfortunately. There is a formula in the data sheet that lets you calculate how long it needs to be.

At 1200 baud your talking several milliseconds instead of the 250 or so uS we've been using. I would recommend turning off AGC as well since that significantly increases RSSI detect time.
Title: Re: Ultra low power listening mode for battery nodes
Post by: craigburden on July 04, 2017, 08:35:43 AM
Hello Everyone,

I have been trawling the forums for the solutions to my problems and this seems like the place to be!

So a quick overview of my system; I am developing an improved version of an existing system (The RF settings of which cannot be changed). The system uses FSK with a deviation of 165kHz and a bitrate of 26.5kbps. The devices are part of a mesh network that aims to get one device's messages a central device which can communicate with the outside world via GSM. All of the devices are battery powered and so power consumption is very important , however given how often transmission actually occurs I care less about power during transmission.

I have been experimenting a lot over the last few months with various RFM69 setups on our custom PCBs ( See the Thread here: https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/range-issues-with-rfm69xxw-on-custom-pcb) Since then we have designed a SX1231H tranceiver directly on our board which means no more module and less money! Yay :)

I have been experimenting a lot with listen mode and rx mode. Regardless of the listen mode configuration I see a significant drops in range. I am using the low power version and I see around 120m when purely in RX mode, however when going into Listen I struggle to get above 70m. I have tried every possible combination of longer RX times, AGC on and off, antenna impedances and ACG algorithms. I just can't get it to be a higher range. Note that all of those tests have been with a RSSIANDSYNC condition, meaning my RX time has had to be rather large which obviously isn't great for power consumption. After a good read of this thread today I am set on using RSSIONLY rather and setting timeout2 (Something I didn't do when I experimented with this before). I have started experimenting with this today in my building (Not the field that the above ranges were determined on). It doesn't seem much better range wise.

My listen config is:
rfm_reg(WRITE REG_LISTEN1,RF_LISTEN1_RESOL_RX_64|RF_LISTEN1_RESOL_IDLE_262000|RF_LISTEN1_CRITERIA_RSSI|RF_LISTEN1_END_00);
rfm_reg(WRITE REG_LISTEN2,10);   //IDLE ~2s
rfm_reg(WRITE REG_LISTEN3,10);   //RX  0.64ms
rfm_reg(WRITE REG_RXTIMEOUT2, 20); // Timeout ~12ms

Ignore my syntax, I am using Felix's H file on my pic microcontroller with SPI functions I wrote.  By my logic that should be okay given my setup? I have been testing with a RSSI threshold of 255 because I want to ensure that the device was attempting to receive the opportunity for now. The other issue I have with this radio is the lack of a relative RSSI threshold, I have no idea what a good absolute threshold is given that I don't control the environment the devices will be in. I also have no idea what the current sensitivity is given the bitrate and deviation, can anyone point me in the right direction?

And then I have one last curve ball, the device is a fire detector and a crucial part of the operation is regular temperature sampling meaning I cannot disturb that process. So the way I deal with that right now is to use the FIFONOTEMPTY flag rather than the PACKETREADY flag as it is not cleared provided by listen end is set to stay in full RX (Which obviously sucks for power). I have started playing the CLC (Configurable Logic Cell) in my PIC microcontroller which may allow me to latch a momentary IRQ pulse, meaning I can use the PACKETREADY flag rather. Am I correct in saying that I can then change my listen end to return to listen? provided that I am sure I will process the packet before the next RX wake up?

I'm sorry for the information over load I am just struggling to get this to work. Plus I hope that some if not all of these are helpful to others.

I am very happy to share my code too if anyone things they may need it?
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on July 04, 2017, 12:26:51 PM
I have been testing with a RSSI threshold of 255 because I want to ensure that the device was attempting to receive the opportunity for now. The other issue I have with this radio is the lack of a relative RSSI threshold, I have no idea what a good absolute threshold is given that I don't control the environment the devices will be in. I also have no idea what the current sensitivity is given the bitrate and deviation, can anyone point me in the right direction?
It may sound counter-intuitive, and it isn't what the library seems to recommend, but I think the current consensus opinion (well, three of us anyway) is to leave RSSI threshhold at 255.  JoeLucid has written about why that works, and it's motivated by the reasons you say. 

Have you tried adding more pre-amble?  That might help with your range.  Joe and at least one other (was it Perky?) did some range experiments, and, IIRC, found that 4 is a good number of pre-amble bytes before diminishing returns.  However, you could  certainly go higher.
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 04, 2017, 04:47:16 PM
Hey Craig,

as you can tell if you've spent some time on this thread I've spent a lot of energy on listen mode. And for me the end result is that listen mode is so broken on the SX1231H that it can't be used as is.

I haven't come to this conclusion lightly. I've developed workarounds for most of the first order bugs. But with listen mode the chip just becomes increasingly less functional as you apply the workarounds. I've also contacted Semtech and talked to a representative. But the more detailed my questions became the less inclined he became to find answers  ;).

The issues are subtle - everything will seem fine but after a week your first node drops off. Or everything runs fine for months but when you have a loud noise signal your radios will wake up and never go to sleep again, draining the battery. It just depends on how many levels of workarounds you already have implemented.

So here's my current assessment: the only reliable way to make use of listen mode is to set RSSI thresh to 0 so it never triggers and just use the PllLock irqs as wakeup timer. That only gives you a cheap and imprecise clock, but you can implement your own listen mode on top. I have listen mode as timer running on maybe 20 nodes around the clock. It never fails.

Here's what I've come up with as listen mode replacement. It has the added benefit of using only standard radio features - none of the hacks I had used earlier (e.g the uninterrupted stream of wake-up packets):

- Client uses listen mode as wakeup timer to wake up every n ms and switches the radio to RX using a given RSSI thresh. Wait for 2 bits and see if the RSSI irq triggers.
- Server switches the radio to TX when trying to wakeup a client. Staying in TX for > n ms sends a stream of preamble which the client detects via RSSI.
- Server then puts radio into standby and waits a couple of ms. Finally sends real payload.
- Client probes for the server to stop sending preamble by detecting RSSI every m ms.
- When preamble no longer sent client switches to RX and receives packet.

This works well.

You'll have to actively manage RSSI thresh for this to work. Just keep slowly lowering the thresh until you get ghost RSSI detects and then quickly dial up.

Quote
Regardless of the listen mode configuration I see a significant drops in range. I am using the low power version and I see around 120m when purely in RX mode, however when going into Listen I struggle to get above 70m.

The radio needs to see the full packet with enough preamble. I don't know what your wake-up packets look like - but you'll need to take that into account. I initially used an uninterrupted stream of packets, ensuring that if RX starts mid packet RSSI would be detected and the next packet received. Another approach would be one packet with a really long preamble - however keeping the receiver longer in RX. I think the approach above combines the best of both methods.

Joe

Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 04, 2017, 04:54:18 PM
Attached is my "manual listen mode" implementation. It uses my radio lib but might still be useful as example of how to do it.

Joe
Title: Re: Ultra low power listening mode for battery nodes
Post by: craigburden on July 05, 2017, 05:00:16 AM
Hi Joe,

Thank you so much for the speedy reply, but to be honest it isn't the news I was hoping for this morning!

So I guess this leaves me with two options (Well... three but I don't like the third).

Option 1:

The one major advantage our devices have is that they are waking up every second (Using the micro's internal WDT) to sample temperature and so I could write some code to check and manage the state of the radio. So basically I could use listen mode as I have it setup now with a RSSI threshold of 255. I could even turn RSSI off if that is an option. This would of course mean the radio would wake up for the full duration of the timeout2 every time but at least that means the issue of needing to see the preamble for a good RSSI reading may not be an issue? Of course this makes it a whole lot more power intensive than if the RSSI was working as it should. The fact that we wake up regularly I could check the radio state and potentially correct for it having gotten stuck in RX for example? This only works because I am not reliant on the radio for wake ups. I know that my packet takes 4.2ms to send including the 3 byte preamble, so I could set my timeout 2 such that I am on for around 10ms meaning I can pick up over 2 packets (I could reduce this if it doesn't seem to affect range).

Option 2:

Instead of using listen mode, I create the same listen mode setup as I described in option 1 however manually. I could put the radio in RX mode every second wake up for example and leave the radio on for 10ms. Again this is not ideal for power and requires a lot more of the micro's resources to manage.

Option 3:

Find a new micro like the SI4463 or the CMT2300AW. In terms of the time frame I have to get all of this done in, I really don't like this option as I would need to design new circuitry etc.



With regard to the transmission sequence you have recommended, I can move to something similar with a very large preamble as a wakeup type message. But I am not entirely sure that this would be sacrificing the backward compatibility that we would really like to keep. The previous system used the MRF49XA which is what the RFM12B is cloned off. I would need to ensure that those devices are able to handle the long preamble given that they expect 3 byes currently and we are not able to reprogram them. Do you recommend increasing the normal preamble length for each packet or just to send a large preamble for wakeup purposes.
As you may have deduced so far, the current system doesn't use a specific wakeup message. Rather it just starts streaming repeated data once a fire is detected.

I am going to range test the listen mode code I have now, and aim for using option one. Do you have any advice?
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 06, 2017, 10:52:51 AM
Quote
So basically I could use listen mode as I have it setup now with a RSSI threshold of 255. I could even turn RSSI off if that is an option. This would of course mean the radio would wake up for the full duration of the timeout2 every time but at least that means the issue of needing to see the preamble for a good RSSI reading may not be an issue?

I've not tried listen mode with address match - that might well work better. But with RSSI as I said I could never quite get it to work right.

Quote
The fact that we wake up regularly I could check the radio state and potentially correct for it having gotten stuck in RX for example?

Yeah - well that's what I tried. I used the RSSI detect irq to wake the MCU and the supervised the RX process of the radio, switching it out of listen mode if it got stuck. But listen mode sometimes doesn't like that and will leave the chip in a state where it will immediately cancel RX once the RSSI thresh hits during listen mode. I had a workaround for that, too. But that led to listen mode not longer even triggering a PLLLock irq.

Quote
Instead of using listen mode, I create the same listen mode setup as I described in option 1 however manually.

Yeah, better chances I think. You can do RSSI detect as I suggested in the example.

Quote
Find a new micro like the SI4463 or the CMT2300AW.

I actually like the SX1231H, listen mode issues notwithstanding. I have a gateway supporting adaptive bitrates and frequency hopping, with pretty amazing range. You don't need to give up on the chip.

Quote
The previous system used the MRF49XA which is what the RFM12B is cloned off. I would need to ensure that those devices are able to handle the long preamble given that they expect 3 byes currently and we are not able to reprogram them. Do you recommend increasing the normal preamble length for each packet or just to send a large preamble for wakeup purposes.

I only use the large preamble as wakeup signal only. No need to increase it for normal packets. The receiver doesn't really care how much preamble it gets as long as its enough to allow the bit synchronizer to synch the bitrates. That however is important so you need to ensure that whatever mode you design the receiver always sees the full 3 bytes.

Joe
Title: Re: Ultra low power listening mode for battery nodes
Post by: craigburden on July 10, 2017, 07:15:59 AM
So I hacked together a quick version this mode where I put the transceiver in RX mode when I wake up for a period of time (6ms currently, as that is about 1.5x a packet length) and then process the packet if there is one. This is giving me the full range at long last with a almost workable current draw. I have some trickery to get it a bit lower.

I am very interested in implementing the RSSI check you have used however I am again unsure as to how to determine the threshold value. Is there no formula or something that defines the sensitivity? Is the only way to scale it by hand and in order to find the correct value? My concern is that the RF environment in the office is obviously very different to where our devices are used so is that a sensible method? I guess regardless of the environment there will be a point at which all of them will trigger falsely.

My hope is to make the power even if the device were to wake up everytime still a workable value, which is currently where I stand, and then make it such that if it didn't wake up falsely the current is greatly reduced.

Thank you so much for the help! It is wonderful finally having someone who has played with listen mode to talk to!
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on July 10, 2017, 08:48:52 AM

The issues are subtle - everything will seem fine but after a week your first node drops off. Or everything runs fine for months but when you have a loud noise signal your radios will wake up and never go to sleep again, draining the battery. It just depends on how many levels of workarounds you already have implemented.


Have you ruled out your power source (in your case, typically button cells if I'm not mistaken) as a contributing factor?  Just wondering if you encountered the same problems with a more stable voltage source.

As usual, you have great information to share.  Thanks!
Title: Re: Ultra low power listening mode for battery nodes
Post by: craigburden on July 10, 2017, 09:53:09 AM
Have you ruled out your power source (in your case, typically button cells if I'm not mistaken) as a contributing factor?  Just wondering if you encountered the same problems with a more stable voltage source.

As usual, you have great information to share.  Thanks!

Yes I have ruled that out, we use one or two AA alkaline cells in parallel so current draw isn't a issue. Plus our boost converter is capable of 300mA at 3.3v. I have tried it on a bench supply too, it didn't seem to make a difference. But good thought!

And thank you, I really enjoy having this forum. Previously we use transceivers that were rather obscure and I would spend ages troubleshooting these problems alone which really slows the progress! I will write up a what I learnt post some time to hopefully help others
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on July 10, 2017, 10:27:48 AM
Actually, I was directing that particular question at Joe (I guess I should have been more clear about that), but I'm glad that you answered it for your situation also.  The more datapoints the better!
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 10, 2017, 10:29:54 AM
Quote
I am very interested in implementing the RSSI check you have used however I am again unsure as to how to determine the threshold value. Is there no formula or something that defines the sensitivity? Is the only way to scale it by hand and in order to find the correct value? My concern is that the RF environment in the office is obviously very different to where our devices are used so is that a sensible method? I guess regardless of the environment there will be a point at which all of them will trigger falsely.

Yeah you have to tune it dynamically. A predefined value can only be used if you have such a strong signal that you can set your thresh a massive distance from the sensitivity and have room for e.g. noise issues.

Something like this: whenever you get a ghost activation increase the threshold by one and wait a second. Whenever you haven't had a ghost activation in 10 minutes decrease the threshold by one. The waiting period prevents racking up the threshold too high for an intermittent noise source. And waiting 10 minutes to decrease means that you'll only get one ghost activation every 10 minutes in equilibrium.

But yeah it's a challenging problem. In my gateway I have a similar problem where I need to detect whether a signal exists at a given bitrate to enable multiple clients to send at differing bitrates. There I use address match instead of RSSI because the gateway  is mains powered and I didn't want to manage RSSI for 50 channels x 5 bitrates.

Joe
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 10, 2017, 10:32:48 AM
Quote
Have you ruled out your power source (in your case, typically button cells if I'm not mistaken) as a contributing factor?  Just wondering if you encountered the same problems with a more stable voltage source.

I have had these issues with coin cells and also with 9V battery powered moteinos. I have one moteino with removed regulator running from 2x aaa lithium which has never had the issue.
Title: Re: Ultra low power listening mode for battery nodes
Post by: ChemE on July 10, 2017, 11:34:46 AM
I have had these issues with coin cells and also with 9V battery powered moteinos. I have one moteino with removed regulator running from 2x aaa lithium which has never had the issue.

That makes me think the LDO is the cause...
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on July 10, 2017, 12:09:29 PM
That makes me think the LDO is the cause...

Well, something is causing it, but who knows what. 

Actually, Joe's "manual" way of doing it shouldn't require a whole lot more current (percentage wise at least), and it has the benefit of making the code more portable to different radios that may not have a built-in listen mode. 
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on July 10, 2017, 01:45:43 PM
That makes me think the LDO is the cause...
Doesn't follow.  The coin cell units didn't have LDO VR either.  However, both the coin cell and 9V unit with VR would have a higher ESR and the 2xAAA lithium would have a higher voltage (3.4-3.6 typ).

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on July 10, 2017, 02:20:05 PM
Say, Tom, you have been using listen mode quite a bit and for quite a long time now, if I'm not mistaken.  Have you too encountered the kind of issues with it that Joe has described?
Title: Re: Ultra low power listening mode for battery nodes
Post by: joelucid on July 10, 2017, 03:19:30 PM
Quote
Actually, Joe's "manual" way of doing it shouldn't require a whole lot more current (percentage wise at least), and it has the benefit of making the code more portable to different radios that may not have a built-in listen mode.

Also my more recent motes all have a clock xtal for frequency hopping. And a "listen mode" implementation that's synchronized and lets the gw reach its clients exactly when they're listening is much more powerful and can be implemented in compliance with the regulations. That's where I see this going in my stack - so I don't have much of a need to further mess around with native listen mode.

Quote
Doesn't follow.  The coin cell units didn't have LDO VR either.  However, both the coin cell and 9V unit with VR would have a higher ESR and the 2xAAA lithium would have a higher voltage (3.4-3.6 typ).

Correct. And actually due to the limited transient response LDO's often produce quite a bit of a voltage spike down when a pulse load hits. So it's not impossible there's a connection here. Perversely a directly connected lithium aaa often provides a much more stable power supply than a regulator. I had to remove the LDO from a recent project since it would create such a pronounced drop on sudden load that the BOD got triggered (this with a LDO with lots of reserves current wise and fairly big bulk cap).

Joe
Title: Re: Ultra low power listening mode for battery nodes
Post by: TomWS on July 10, 2017, 06:38:35 PM
Say, Tom, you have been using listen mode quite a bit and for quite a long time now, if I'm not mistaken.  Have you too encountered the kind of issues with it that Joe has described?
LOL!  I gave up on Listen Mode before Joe did.  He is a persistent bugger!  I'm not.  I got a few hangs that killed my motes and drained my batteries and that was enough for me.  I'm a very dedicated fan of TPL5010s!  KISS the Listen Mode goodbye!

Communicating with the GW on a scheduled basis works for me for virtually all my battery powered motes.  If I enter a mode in which I need to communicate more often than the TPL timer (like I just turned on a Sprinkler Valve that may need to be turned off right away) I'll switch to use Listen Mode as a 2.8 second timer only and only during this critical period.

Tom
Title: Re: Ultra low power listening mode for battery nodes
Post by: WhiteHare on July 11, 2017, 12:51:11 PM
I've been using PllLock as a timer on my solar experiments for some time now, and it seems rock solid for at least that purpose. I mention it as a supporting confirmation of Joe's recommendation.
Title: Re: Ultra low power listening mode for battery nodes
Post by: craigburden on July 12, 2017, 02:08:20 AM
Yeah you have to tune it dynamically. A predefined value can only be used if you have such a strong signal that you can set your thresh a massive distance from the sensitivity and have room for e.g. noise issues.

Something like this: whenever you get a ghost activation increase the threshold by one and wait a second. Whenever you haven't had a ghost activation in 10 minutes decrease the threshold by one. The waiting period prevents racking up the threshold too high for an intermittent noise source. And waiting 10 minutes to decrease means that you'll only get one ghost activation every 10 minutes in equilibrium.

But yeah it's a challenging problem. In my gateway I have a similar problem where I need to detect whether a signal exists at a given bitrate to enable multiple clients to send at differing bitrates. There I use address match instead of RSSI because the gateway  is mains powered and I didn't want to manage RSSI for 50 channels x 5 bitrates.

Joe

Hi Joe,

That is a great plan I will start thinking about it and getting a version of code together! I will be sure to place limits on the values to ensure I don't end up with a threshold of 0 on some nodes because of funny bugs! I just want to come up with a scheme that will attempt to avoid incrementing the threshold to random, once off noise. Because that could cause the threshold to jump up quite high before the decrementing has a chance to happen. If it could increment everytime it woke up, it could increment really high in the first 10 minutes and then very slowly come down again which is okay I guess, but I just would feel more comfortable with that process being a little quicker :)

I will let you guys know what I come up with!
Title: Re: Ultra low power listening mode for battery nodes
Post by: craigburden on July 19, 2017, 08:01:16 AM
Hello Everyone,

So I have been working hard on this solution. I have become stuck on the the check for RSSI. I have been trying to use the RXtimeout1 to trigger a pin interrupt on DIO4 for my micro to signal it that it should shutdown the receiver etc because the RSSI threshold was not exceeded. The problem I am finding after a lot of scoping is that regardless of the RSSI treshold I get a very short pulse from the DIO4 pin which my micro of course interprets as a IRQ. This is seems to happen everytime the receiver is woken up. On the other hand I scope DIO0 which I have configured to be the RSSIthreshold IRQ. There I see the same little spike. However when the RSSI threshold is exceeded I see a much longer signal appear (Interestingly enough it is around 100us after the short spike which is still there).

This leads me to two conclusions, first off the IRQ pulses from the SX1231H are a bit dodgy they still spike slightly when not triggered (presumably when the condition is checked internally?) This could be solved by something like a small decoupling cap with a pulldown resistor to remove those little spikes. But I don't want to adjust my circuit board further... Secondly, perhaps the Timeouts do not work unless in listen mode?

Of course using the built in time outs is really great in terms of my program flow, because I can turn on the receiver and a timer at the same time, then go on doing the other things that need to happen. At some point the SX will let the micro know that the RSSI has timed out and it can be shutdown. Otherwise I finish all my other stuff and then sit in a loop until my desired radio on time is met as per the timer. If the timeout outs don't work it is a bit more complicated because I would need to start a much shorter timer to handle the RSSI timeout and then if the IRQ is triggered I can stop the timer and leave the radio on. But if the timer triggers first then I shutdown the radio. It just means two IRQs rather than one as well as some additional annoying logic and micro resources.

Does anyone have any ideas?
Title: Re: Ultra low power listening mode for battery nodes
Post by: snorp on August 30, 2017, 04:15:13 PM
The issues are subtle - everything will seem fine but after a week your first node drops off. Or everything runs fine for months but when you have a loud noise signal your radios will wake up and never go to sleep again, draining the battery. It just depends on how many levels of workarounds you already have implemented.

Joe, may I ask how you came to this conclusion? My blinds have had terrible battery performance (like ~3 months or so on AAs), and I've finally decided to look into fixing it now that they've sat dead for a few months. My nodes never became unresponsive unless the battery was dead, so I don't know if I'm seeing what you're seeing. Did you have a way to monitor a deployed node to see that it slipped into a high-power state? Were you able to reproduce it on a table?

I do sometimes see interesting numbers on the meter here on the table, but nothing that would explain the exceptionally crappy battery life of the blinds. I'm using 512uS RX with 2s idle time. My crappy $15 meter shows between 4-6 uA normally, but now and then it will get into a state where it alternates between that and about 50uA every second. I assume maybe that's due to noise?  Even if it were averaging 50uA it wouldn't explain my battery life issue, so I think it's probably my motor driver leaking....
Title: Re: Ultra low power listening mode for battery nodes
Post by: zingbat on February 15, 2018, 11:12:11 AM
It sounds like the state of the art on low power listening is to implement something like Joe’s suggested “manual listen mode”. Wondering if anyone has done this using Felix’s standard RFM69 library, or some other fully implemented/available approach? I would love to not reinvent the wheel.

Thanks!
Jeff
Title: Re: Ultra low power listening mode for battery nodes
Post by: Felix on February 15, 2018, 01:29:26 PM
I have users who use ListenMode without a problem.
Also see the other blinds project with ListenMode (https://lowpowerlab.com/forum/projects/battery-powered-solar-recharged-automated-blinds/). Specs and details in his shop (https://www.tindie.com/products/blebson/blind-automation-moteino-shield-with-solar-charger/).
Title: Re: Ultra low power listening mode for battery nodes
Post by: zingbat on February 16, 2018, 03:10:52 AM
Ah, great to know it can work reliably. Thanks!
Title: Re: Ultra low power listening mode for battery nodes
Post by: brolly759 on February 27, 2018, 11:58:27 PM
Any news on changes, average current over time or any libraries recommended ?
Title: Re: Ultra low power listening mode for battery nodes
Post by: blebson on March 15, 2018, 12:38:05 AM
I have users who use ListenMode without a problem.
Also see the other blinds project with ListenMode (https://lowpowerlab.com/forum/projects/battery-powered-solar-recharged-automated-blinds/). Specs and details in his shop (https://www.tindie.com/products/blebson/blind-automation-moteino-shield-with-solar-charger/).

My personal implementation is working great though I am hearing about some users having issues waking their board during listening mode. During my development I had multiple Moteino R4 boards stop waking from sleep mode but figured it was due to the R4 design and was fixed in the R5 and R6 with the extra cap. I had enough extra Moteinos to spare so I just loaded my code on other ones and the 4 I've been using have been solid for 4-5 months now.
Title: Re: Ultra low power listening mode for battery nodes
Post by: LukaQ on March 15, 2018, 12:54:53 AM
in the R5 and R6 with the extra cap.
what extra cap?
Title: Re: Ultra low power listening mode for battery nodes
Post by: ChemE on March 15, 2018, 07:46:55 AM
Can't recall the details off the top of my head but there were discussions about another cap needed on the reset line and Felix did end up adding another passive.  I had not retained the fact that it was all tied to listen mode.  I'm sure someone will be along soon with much more information.
Title: Re: Ultra low power listening mode for battery nodes
Post by: Felix on March 15, 2018, 12:14:25 PM
The extra cap was added to the DTR/reset circuit and should not have anything to do or impact ListenMode.
Reports of freezing/not waking from ListenMode have been reported on R4 as well, so this is not related to the R6 hardware change.
Title: Re: Ultra low power listening mode for battery nodes
Post by: blebson on March 15, 2018, 03:32:29 PM
The extra cap was added to the DTR/reset circuit and should not have anything to do or impact ListenMode.
Reports of freezing/not waking from ListenMode have been reported on R4 as well, so this is not related to the R6 hardware change.

Gotcha, I totally misunderstood. Well, then even in my successful implementation of the Listening Mode, I had 3-4 boards that stopped waking up and only was able to complete the project by cycling in new boards that ended up working. Just adding to the mystery I suppose.