Author Topic: Using RTC for power savings  (Read 4403 times)

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Using RTC for power savings
« on: April 29, 2016, 04:14:44 PM »

WhiteHare is correct that you can achieve significant savings using an RTC instead of the radio's listen mode. That majority of that comes from the 1.1uA of idle current the radio no longer draws.

Roughly how much current would the RTC crystal be likely to draw? I've looked at a number of crystal datasheet where, frustratingly, operating current isn't even mentioned.  The AM1815 RTC without the crystal may draw 35na, but what is the current draw likely to be when a crystal is attached?  I'm sure it will be less than 1.1ua, but I'm just wondering how much the net savings is likely to be when it's all said and done.  Even if it were a wash wrt current (which, as I say, I'm sure it won't be), we'd still be gaining accuracy in the bargain, because apparently the RFM69 relies on a lower accuracy resonator, not a crystal, to provide the timing for RFM69's Listen-Mode.

A moment ago I was looking at Silicon Lab's "Mighty Gecko," where the receiver can employ a notionally similar strategy of measuring RSSI as a possible signal of intent to transmit.  What's different in its case, though, is that it has a dedicated circuit (which they have named RFSENSE) which their datasheet claims costs only 51na to run.  It appears to somehow operate independent of the radio, so that the radio can be sleeping while RFSENSE is running.  One limitation, though, is that RFSENSE does seem to require a rather high RSSI to trigger it.  Anyhow, I thought it was interesting enough to be worth mentioning.
« Last Edit: April 29, 2016, 04:28:45 PM by WhiteHare »

OSBSS

  • NewMember
  • *
  • Posts: 29
  • Country: us
    • OSBSS - Open Source Building Science Sensors
Re: Using RTC for power savings
« Reply #1 on: April 29, 2016, 04:28:03 PM »
Roughly how much current would the RTC crystal be likely to draw?

The RTC that I'm using, the DS3234, draws 1.5uA in time-keeping mode. It's I2C brother, the DS3231 draws 1uA. This excludes the spike in current to about 500uA for 100ms when the crystal is doing temperature compensation to maintain accurate time, which happens once every 64 seconds and that interval can be changed up to 512 seconds. Still gives a low average draw of under 2uA. There are RTCs that maintain time in the nA range even with a crystal, with some sacrifice in accuracy. But generally, you can assume 1uA for RTCs.
« Last Edit: April 29, 2016, 04:30:15 PM by OSBSS »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Using RTC for power savings
« Reply #2 on: April 29, 2016, 05:01:47 PM »
That's good info.  Thanks.

Well, in light of that, I guess it's presumptive of me to assume that the AM1815 would be paired with a crystal.  Perhaps the play is to use its internal resonator (something like 20na IIRC) with the objective of saving as much current as possible straight off the bat.  In the big picture, it seems likely that greater accuracy might also indirectly render some current savings, so  I'm unsure which strategy might yield the most current savings overall.  From what Joe is saying, though, it sounds like maybe it is the sustained current which is most likely to dominate.
« Last Edit: April 29, 2016, 05:14:21 PM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Using RTC for power savings
« Reply #3 on: April 30, 2016, 01:09:57 AM »
The am1815 has three modes: crystal only, rc only or regularly crystal calibrated rc. When I experimented with it I used the crystal mode since it has a much finer resolution. That also only costs smth like 55nA.

In my new listen mode scheme non rtc nodes and rtc nodes can both fully participate. For both the server will no longer need to send a full 3s burst to wake up a node. It will still send a shorter burst to account for any timing uncertainties when it reaches out to a node.

The rtc clients will keep better time so they will need shorter bursts, allowing more nodes to coexist in the same environment.  But otherwise it won't matter beyond the base sleep current consumption. So if you don't run 1000s of nodes the rc oscillator will give you the best savings.

A nice side effect will be that even a node running on a tpl5010 should be able to fully participate if that timer is stable enough. Which would allow for building very simple, ultra low power nodes. Another side effect of the new scheme is that it's now possible to talk to a specific node without waking the others, allowing much more nuanced use cases than the broadcasting burst drum we've been using.

Now all I have to do is implement the concept  :)

Joe
« Last Edit: April 30, 2016, 01:13:17 AM by joelucid »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Using RTC for power savings
« Reply #4 on: May 01, 2016, 04:54:06 PM »
Roughly how much current would the RTC crystal be likely to draw?

The RTC that I'm using, the DS3234, draws 1.5uA in time-keeping mode. It's I2C brother, the DS3231 draws 1uA. This excludes the spike in current to about 500uA for 100ms when the crystal is doing temperature compensation to maintain accurate time, which happens once every 64 seconds and that interval can be changed up to 512 seconds. Still gives a low average draw of under 2uA. There are RTCs that maintain time in the nA range even with a crystal, with some sacrifice in accuracy. But generally, you can assume 1uA for RTCs.

What's interesting about those numbers is that the RFM69 (according to its datasheet) draws 1.2uA in idle mode (using its rc as the clock), so that part is largely the same (a little better or a little worse for the current drawn in timekeeping mode depending on whichever DS323x you pick).  Also, unless I'm mistaken, the mah drawn by the RFM69 to do a time sync with the gateway will probably (?) be less than what the DS323x draws (500uA for 100ms) to do its temperature compensation.  Anyhow, if it bears out, it's a somewhat interesting result.

Do we have any info as to the ppm's of the RFM69's rc oscillator?  According to the datasheet, its frequency is 62.5kHz "after calibration."  According to section 4.3.5, the user can force an rc oscillator calibration (I guess to account for changes in temperature), but for starters I wonder how accurate it is even just assuming a constant temperature.

It looks as though it is possible to configure ClkOut to be the RC clock by setting bits 2-0 in RegDioMapping2, and so it should be possible to directly measure the RC frequency on, for instance, an osciliscope.  Unfortunately, it doesn't look as though it can be mapped to DIO0, but there are other RFM69 pins that it can be mapped to.  Hypothetically, I suppose wiring it as an external clock into Timer1 would be a fairly good fit  (16 bits being 65536 counts) for doing a time sync calibration with the gateway, especially if comparing against highly accurate 1PPS GPS time....  Besides, the atmega328p would only have to wake up roughly once a second to count the overflows, which is manageable, and so it would seem possible to get very high resolution time measurements out of that setup by counting literally every clock tick output by the RFM69 RC.  Anyhow, I'm a bit hazy on some of the details, but it sounds promising! 
« Last Edit: May 01, 2016, 06:08:05 PM by WhiteHare »

emjay

  • Full Member
  • ***
  • Posts: 119
  • Country: nl
Re: Using RTC for power savings
« Reply #5 on: May 01, 2016, 08:29:47 PM »
@WhiteHare,

I expect turning on the driver to present ClkOut on a DIO pin will take a substantial bite out of your power budget.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Using RTC for power savings
« Reply #6 on: May 02, 2016, 02:41:45 AM »
Quote
I expect turning on the driver to present ClkOut on a DIO pin will take a substantial bite out of your power budget.

Definitely true for the crystal powered ClkOut settings. For the RC oscillator it would be worth a test.

Quote
Do we have any info as to the ppm's of the RFM69's rc oscillator?  According to the datasheet, its frequency is 62.5kHz "after calibration."  According to section 4.3.5, the user can force an rc oscillator calibration (I guess to account for changes in temperature), but for starters I wonder how accurate it is even just assuming a constant temperature.

I've done tests with it. I couldn't make the rc calibration do anything at all. Whether I put the mote in the freezer or put a lighter under the sx1231h, rc calibration does exactly nothing.

There's quite a bit of temp drift. Something like 20ppm per celsius if I recall correctly. At the same temp the rc oscillator is fairly stable.

Quote
Hypothetically, I suppose wiring it as an external clock into Timer1 would be a fairly good fit  (16 bits being 65536 counts) for doing a time sync calibration with the gateway, especially if comparing against highly accurate 1PPS GPS time....

For testing maybe. If you wanted to deploy using this approach you'd have to use Timer2 since that's the only one that can do async counting in powerSave mode < 1uA. You'd have to use the maximum pre-scaler setting (1024 I believe). This would give you an irq around every 4s if I recall correctly. For more precise times you'd have to switch the pre-scaler to a much lower setting on wake and hope not to lose too many cycles in between. It's all a bit tricky.

All this led me to the conclusion that it you want to use rc oscillator to time communication with the gw, the best approach is to use listen mode to keep the time while sleeping (either using noise wakeup with RSSITHRESH 255, or for real), and switch to millis() and the internal RC oscillator when awake. Wake periods will be short so the inaccuracy of the internal osc shouldn't matter much.

Longer periods in listen mode can only be set with a resolution of ~4ms, so with this approach the gw needs to calibrate to each client, not the other way around.

Joe

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Using RTC for power savings
« Reply #7 on: May 02, 2016, 05:23:58 PM »
Quote
I expect turning on the driver to present ClkOut on a DIO pin will take a substantial bite out of your power budget.

Definitely true for the crystal powered ClkOut settings. For the RC oscillator it would be worth a test.

Quote
Do we have any info as to the ppm's of the RFM69's rc oscillator?  According to the datasheet, its frequency is 62.5kHz "after calibration."  According to section 4.3.5, the user can force an rc oscillator calibration (I guess to account for changes in temperature), but for starters I wonder how accurate it is even just assuming a constant temperature.

I've done tests with it. I couldn't make the rc calibration do anything at all. Whether I put the mote in the freezer or put a lighter under the sx1231h, rc calibration does exactly nothing.

There's quite a bit of temp drift. Something like 20ppm per celsius if I recall correctly. At the same temp the rc oscillator is fairly stable.

Quote
Hypothetically, I suppose wiring it as an external clock into Timer1 would be a fairly good fit  (16 bits being 65536 counts) for doing a time sync calibration with the gateway, especially if comparing against highly accurate 1PPS GPS time....

For testing maybe. If you wanted to deploy using this approach you'd have to use Timer2 since that's the only one that can do async counting in powerSave mode < 1uA. You'd have to use the maximum pre-scaler setting (1024 I believe). This would give you an irq around every 4s if I recall correctly. For more precise times you'd have to switch the pre-scaler to a much lower setting on wake and hope not to lose too many cycles in between. It's all a bit tricky.

All this led me to the conclusion that it you want to use rc oscillator to time communication with the gw, the best approach is to use listen mode to keep the time while sleeping (either using noise wakeup with RSSITHRESH 255, or for real), and switch to millis() and the internal RC oscillator when awake. Wake periods will be short so the inaccuracy of the internal osc shouldn't matter much.

Longer periods in listen mode can only be set with a resolution of ~4ms, so with this approach the gw needs to calibrate to each client, not the other way around.

Joe

Thanks!  That clears some of the haze away.

Too bad about the async counter being 8-bit timer2.
« Last Edit: May 04, 2016, 10:25:39 AM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Using RTC for power savings
« Reply #8 on: May 04, 2016, 12:54:27 PM »
For portability reasons, I've decided not to pursue the idea of using the RFM69's rc.  In case anyone else wants to explore it (and hopefully report their findings),  there's a convenient arduino library for a frequency counter using a GPS 1PPS as an accurate time reference:  https://github.com/JChristensen/gpsFreq
« Last Edit: May 04, 2016, 01:37:57 PM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Using RTC for power savings
« Reply #9 on: May 04, 2016, 01:53:35 PM »
Quote
For portability reasons, I've decided not to pursue the idea of using the RFM69's rc.  In case anyone else wants to explore it (and hopefully report their findings),  there's a convenient arduino library for a frequency counter using a GPS 1PPS as an accurate time reference:  https://github.com/JChristensen/gpsFreq

I still think there's something magical about the simplicity of a 328p + rfm69w with one 0.1uF decoupling cap thrown in. My solution needs to work with that - if only because I have so many of those. I think it will work with just listen mode and the internal oscillator. No rewiring of clkout necessary.