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

joelucid

  • Hero Member
  • *****
  • Posts: 869
    • View Profile
Re: Ultra low power listening mode for battery nodes
« Reply #195 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

TomWS

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1688
    • View Profile
Re: Ultra low power listening mode for battery nodes
« Reply #196 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

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
    • View Profile
Re: Ultra low power listening mode for battery nodes
« Reply #197 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.

craigburden

  • Newbie
  • *
  • Posts: 13
    • View Profile
Re: Ultra low power listening mode for battery nodes
« Reply #198 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!

craigburden

  • Newbie
  • *
  • Posts: 13
    • View Profile
Re: Ultra low power listening mode for battery nodes
« Reply #199 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?

snorp

  • Jr. Member
  • **
  • Posts: 62
  • Country: us
    • View Profile
Re: Ultra low power listening mode for battery nodes
« Reply #200 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....

zingbat

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: Ultra low power listening mode for battery nodes
« Reply #201 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

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5160
  • Country: us
    • View Profile
    • LowPowerLab
Re: Ultra low power listening mode for battery nodes
« Reply #202 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. Specs and details in his shop.

zingbat

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: Ultra low power listening mode for battery nodes
« Reply #203 on: February 16, 2018, 03:10:52 AM »
Ah, great to know it can work reliably. Thanks!

brolly759

  • Jr. Member
  • **
  • Posts: 58
  • Country: us
    • View Profile
Re: Ultra low power listening mode for battery nodes
« Reply #204 on: February 27, 2018, 11:58:27 PM »
Any news on changes, average current over time or any libraries recommended ?

blebson

  • Newbie
  • *
  • Posts: 23
  • Country: us
    • View Profile
Re: Ultra low power listening mode for battery nodes
« Reply #205 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. Specs and details in his shop.

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.

LukaQ

  • Sr. Member
  • ****
  • Posts: 250
  • Country: si
    • View Profile
Re: Ultra low power listening mode for battery nodes
« Reply #206 on: March 15, 2018, 12:54:53 AM »
in the R5 and R6 with the extra cap.
what extra cap?

ChemE

  • Sr. Member
  • ****
  • Posts: 385
  • Country: us
    • View Profile
Re: Ultra low power listening mode for battery nodes
« Reply #207 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.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5160
  • Country: us
    • View Profile
    • LowPowerLab
Re: Ultra low power listening mode for battery nodes
« Reply #208 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.

blebson

  • Newbie
  • *
  • Posts: 23
  • Country: us
    • View Profile
Re: Ultra low power listening mode for battery nodes
« Reply #209 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.