Welcome to the Parallax Discussion Forums, sign-up to participate.

# Current at only 330uA with battery pack supply?

Posts: 29
edited 2020-01-07 - 20:47:02
Hello,

I used my oscilloscope to measure the voltage across my circuit in a few spots, and found a maximum current of 550uA and a near constant current of 330uA. With a battery pack of four AA's this comes out to almost 10 months of battery life using this battery life calculator! https://digikey.com/en/resources/conversion-calculators/conversion-calculator-battery-life

This seems absurdly long, and I honestly don't believe it at all so I'm guessing I'm measuring something wrong with my oscilloscope.

I'm using the generic circuit on the example for the CM2302 sensor attached below, the resistor is 10k ohms.

I know the pause() function uses waitcnt and helps to save power, but this seems too good to be true, and thusly I am prone to think I'm wrong. Below is the section of the code concerned with waiting to take the next weather sample.
```for(time_wait_cnt ; time_wait_cnt < 60; time_wait_cnt ++)  //Clock shenanigans
{
print("%d", time_wait_cnt);
pause(30000);  //wait 30 mins for next data cycle

}
print("\n");
time_wait_cnt = 0;  //reset counters
Count = 0;
```

I can't believe nearly ten months of battery life is possible with this simple design, and I'm wondering if I'm just probing this wrong.

• Posts: 564
edited 2020-01-07 - 21:43:46
Three questions for ya:

1). WHAT processor/board configuration are you talking about?
2). WHERE did you measure this current?
3). WHY (and how) are you using an o-scope to measure current?

Vagueness is not your friend, and this post is pretty vague. But given the answer to these three questions, we can start to formulate some good answers.
• Posts: 29
edited 2020-01-07 - 22:07:37
JRoark wrote: »
Three questions for ya:

1). WHAT processor/board configuration are you talking about?
2). WHERE did you measure this current?
3). WHY (and how) are you using an o-scope to measure current?

Vagueness is not your friend, and this post is pretty vague. But given the answer to these three questions, we can start to formulate some good answers.

1. I'm using the prop activity board, code is compiled in SimpleIDE and written to EEPROM.
2. I measured the voltage across the 10k resistor and across the whole circuit. Both measurements gave me a 330uA reading during pause and a 560 uA reading during sensor measurement.
3. I'm using the Analog Discovery O-scope, and I used I = V/R to extrapolate the current. (assuming the resistance of the CM2302 sensor was negligible.) Assuming the load from the sensor is negligible, I'm pretty sure the circuit I attached is just a voltage source with a resistor in parallel. Analysis using KVL seems to confirm measurements.

A very crude and probably unnecessary drawing is pictured below.

• Posts: 11,731
But what current is the Activity Board drawing, (at its power source)?
• Posts: 29
edited 2020-01-07 - 22:05:31
Publison wrote: »
But what current is the Activity Board drawing, (at its power source)?

Measuring the voltage from the battery terminals to ground and dividing by the 10 k resistor gave the higher value, ~550uA. Constantly regardless of board activity. Which makes sense with a 6 V battery supply I suppose.

I'm right to be in disbelief of such long battery life figures aren't I?
• Posts: 564
edited 2020-01-07 - 22:11:33
If you are measuring across that 10k resistor, you’re mostly measuring source/sink for Pin 5. This completely misses:

1). The current into the CM2302, and
2). The current to run the Prop

Do this: break the positive battery lead and measure current with a proper meter. Even a cheapie will be fine.

Edited to add: yep, you’re right to be suspicious of your figures. I’d expect the current number to be about 1-1/2 orders of magnitude (ish) higher than what you are seeing.
• Posts: 29
JRoark wrote: »
If you are measuring across that 10k resistor, you’re mostly measuring source/sink for Pin 5. This completely misses:

1). The current into the CM2302, and
2). The current to run the Prop

Do this: break the positive battery lead and measure current with a proper meter. Even a cheapie will be fine.

Edited to add: yep, you’re right to be suspicious of your figures. I’d expect the current number to be about 1-1/2 orders of magnitude (ish) higher than what you are seeing.

Don't have one and don't have a car to get anywhere right now.

Base clock is 5MHz, assuming 6V constant supply from batteries, running a single cog in pause + whatever base consumption the propeller uses = ??

If you're right about it being an order and a half of magnitude higher, I still get ~12.5 days out of the pack.

More than good enough.
• Posts: 29

Picture I found from @Tracy Allen

Though perhaps there is also, @JRoark, the consideration of the current going into the sensor to worry about. I don't think the sensor is drawing current unless it is taking a measurement...
• Posts: 564
A quote from the P1 manual might be helpful here.

The manual says the P1 will consume “500 μA per MIPS (MIPS = Freq in MHz / 4 * Number of Active Cogs)”.

I’d take that number with a grain of salt actually (my designs always seem to take more, and sometimes LOTS more when you add-in support chips and pull-ups, etc). Remember those mhz ratings are for the actual cog freq.... not the freq of the oscillator or crystal being applied to XI/XO. If you have a 5 mhz xtal but are using a x16 multiplier on it internally, then those cogs are clocking along at 80 mhz (ie, 10 mA each).

Food for thought...
• Posts: 564
edited 2020-01-07 - 23:08:33
Ha! Our posts crossed. Sick minds think alike. What freq are you driving the cogs and how many cogs are there running?

Edit: if you want to really stretch your battery life, use the internal 20khz oscillator and put the chip to sleep between runs. At 20khz that chip can be powered by next to nuthin for current.
• Posts: 29
edited 2020-01-07 - 23:17:21
JRoark wrote: »
Ha! Our posts crossed. Sick minds think alike. What freq are you driving the cogs and how many cogs are there running?

Edit: if you want to really stretch your battery life, use the internal 20khz oscillator and put the chip to sleep between runs. At 20khz that chip can be powered by next to nuthin for current.
I just created a custom board in the prop gcc loader
```# custom.cfg
clkfreq: 20000
clkmode: XTAL1+PLL16X
baudrate: 115200
rxpin: 31
txpin: 30
tvpin: 12   # only used if TV_DEBUG is defined
```

I think that should do the trick!

EDIT: XTAL stand for crystal...PLL stands for???
• Posts: 564
edited 2020-01-07 - 23:25:22
I’m doing this on a phone browser, so apologies for bevity:

That header doesnt look right. I’m guessing you have a 5 mhz xtal, so adding that 16x in the PLL gives you 80 mhz. You need to change “XTAL1+PLL16x” to something else. From memory it is RCSLOW. Check the docs however... my mind is feeble and old.
• Posts: 29
edited 2020-01-07 - 23:50:00
JRoark wrote: »
I’m doing this on a phone browser, so apologies for bevity:

That header doesnt look right. I’m guessing you have a 5 mhz xtal, so adding that 16x in the PLL gives you 80 mhz. You need to change “XTAL1+PLL16x” to something else. From memory it is RCSLOW. Check the docs however... my mind is feeble and old.
```# custom.cfg
clkfreq: 20000
clkmode: RCSLOW
baudrate: 115200
rxpin: 31
txpin: 30
tvpin: 12   # only used if TV_DEBUG is defined
```
Done, but I thought PLL stood for the clkfreq. I can't find out the acronym is for. Which would have given my 5MHz + 20k*16 = 5.32 MHz clock. At any rate, I recompiled with RCSLOW and it works great so it is obviously enough!

EDIT: PLL stands for phase-locked loop...the lack of parenthesis threw me off since I thought PLL was multiplied by 16 and added with the XTAL.. instead we have the ever dubious implied parenthesis...also didn't help that I didn't know what PLL stands for, I guess it's to keep the clocks from going out of sync.
• Posts: 29
edited 2020-01-07 - 23:52:09
This officially concludes the SimpleIDE programming/hardware part.

I'm gonna put it in the crappy box I made from cardboard and stick it outside for a couple of days. Hopefully I can get the Matlab program written in the meantime.
```#include "simpletools.h"
#include "dht22.h"

int DO = 22, CLK = 23, DI = 24, CS = 25;      // SD card pins on Propeller BOE
int Count = 0;                             //Multiple sample count for averaging data taken from sensor
int DatCount = 0;                          //Total average samples to be taken.  (At 30 mins per sample, 48 samples = 1 day)
int time_wait_cnt = 0;                     //pause function counter for long waits

// ------ Main Program ------
int main()
{
int n;
int array1[3];
int array2[3];
float AveT, AveH;

sd_mount(DO, CLK, DI, CS);                  // Mount SD card
//pause(2000);

while(1)
{

while(Count < 3)
{
array1[Count] = ((float) dht22_getTemp(FAHRENHEIT));    //store temps values
array2[Count] = ((float) dht22_getHumidity());          //store humidity values
//print("%s%03.2f%s\r", "The temperature is ", ((float) dht22_getTemp(FAHRENHEIT)) / 10.0, " degrees F");
//print("%s%03.2f%s\r", "Humidity is ", ((float) dht22_getHumidity()) / 10.0, "%");
pause(2000);
Count = Count + 1;
}
AveT = (array1[0]+array1[1]+array1[2])/30.00;  //average temp samples
AveH = (array2[0]+array2[1]+array2[2])/30.00;  //average humidity samples
print("\nThe average value over three samples is %.2f degress F.\n",AveT);
//print("\nThe average humidty over three samples is %.2f%\n",AveH);

FILE* fp = fopen("THData.txt", "a");  //Open --> write data to SD card --> Close

fprintf(fp, "%.2f %.2f \n", AveT, AveH);
fflush(fp);

fclose(fp);

DatCount = DatCount + 1;   //Increment total averaged data sample count
if(DatCount == 48)        //48= 1 day, 96 = 2 days, 144 = 3 days, ...
{
break;
}

print("\nHi\n\n");
for(time_wait_cnt ; time_wait_cnt < 60; time_wait_cnt ++)  //Clock shenanigans
{
//print("%d", time_wait_cnt);
pause(30000);  //wait 30 mins for next data cycle

}

time_wait_cnt = 0;  //reset counters
Count = 0;
}
return 0;
}
```
• Posts: 564
edited 2020-01-08 - 00:17:26
XTAL: = crystal.
PLL: = phase locked loop. Basically the PLL multiplies the clock freq by some value. In the case of “PLL16X”, this multiplies whatever is coming into the XIn pin by 16. So a 5 mhz xtal times a 16x PLL gives you an 80 mhz system clock.

Note that you can shift clock speeds “on-the-fly”. For example, you may “downshift” to RCSLOW mode just before you do a WAITCNT to save (lots of) power. And then when the time comes to do something again, you can “kick it up” to 80 mhz, do your processing, and then turn the wick way down again.

Something that I learned too: the Prop 1 is stable with NO CLOCK. None. It is entirely possible to disconnect the clock entirely and the P1 “freezes”. It can stay “frozen” indefinitely. When the clock returns, it just picks-up happily where it left off. If you have a hardware-based switch on the clock line, this can save even more power... but the solution must be autonomous from the Prop, because obviously the Prop cant initiate the turn-on since... wait for it... it isnt running.
• Posts: 29
JRoark wrote: »
XTAL: = crystal.
PLL: = phase locked loop. Basically the PLL multiplies the clock freq by some value. In the case of “PLL16X”, this multiplies whatever is coming into the XIn pin by 16. So a 5 mhz xtal gives you an 80 mhz system clock.

Note that you can shift clock speeds “on-the-fly”. For example, you may “downshift” to RCSLOW mode just before you do a WAITCNT to save (lots of) power. And then when the time comes to do something again, you can “kick it up” to 80 mhz, do your processing, and then turn the wick way down again.

Something that I learned too: the Prop 1 is stable with NO CLOCK. None. It is entirely possible to disconnect the clock entirely and the P1 “freezes”. It can stay “frozen” indefinitely. When the clock returns, it just picks-up happily where it left off. If you have a hardware-based switch on the clock line, this can save even more power... but the solution must be autonomous from the Prop, because obviously the Prop cant initiate the turn-on since... wait for it... it isnt running.
Gdamn... the rabbit hole of power efficiency one could go down. Interesting stuff! I think this clock slow down will give me weeks of power if need be.

I'm gonna do a two day test for proof of concept outside, then I'll set it up in my room and let it run till the wheels fall off for science.
• Posts: 564
edited 2020-01-08 - 00:16:46
I just looked at the CM2302 specs. Interesting that this critter will also run from 3.3 volts. And the worst-case current draw is 500 uA. Which rather suggests you could power this sensor *from* a P1 pin. In other words, in addition to playing with the P1’s clock speed, you could also turn the sensor itself on and off to save power. You state that the CM2302 seems to be drawing 300-ish uA idle. If true, this value would drop to zero with the sensor off. If you were looking for major increases in battery life, that would be just the ticket.

Just a thought...
• Posts: 29
JRoark wrote: »
I just looked at the CM2302 specs. Interesting that this critter will also run from 3.3 volts. And the worst-case current draw is 500 uA. Which rather suggests you could power this sensor *from* a P1 pin. In other words, in addition to playing with the P1’s clock speed, you could also turn the sensor itself on and off to save power. You state that the CM2302 seems to be drawing 300-ish uA idle. If true, this value would drop to zero with the sensor off. If you were looking for major increases in battery life, that would be just the ticket.

Just a thought...
I'll pass my little weather station taking temp and humidity dat on to my grandchildren using the same batteries I bought 40 years ago.

Disney will make a movie about my life one day lol.
• Posts: 564
With a few small solar cells and a carefully selected battery, you might be right!
• Posts: 29
edited 2020-01-08 - 01:46:44
Just realized my clock will shift 6 seconds every sampling, which over the course of near 100 samples (over two days at one sample per 30 mins) will shift the clock away from it's wanted time by almost 10 minutes!

I need to add another condition to the time_wait_cnt loop to do only 59 counts every 5th time incrementing the DatCount counter. This will cause a 30 second drift from the true time by the 5th count, but would reset it on the 6th. Not as if +-30 seconds is a huge difference maker when it comes to taking a temperature reading, but I don't want all my data to shift 30 minutes into the future every 6 days!

• Posts: 347
edited 2020-01-08 - 02:46:31
JRoark wrote: »
Ha! Our posts crossed. Sick minds think alike. What freq are you driving the cogs and how many cogs are there running?

Edit: if you want to really stretch your battery life, use the internal 20khz oscillator and put the chip to sleep between runs. At 20khz that chip can be powered by next to nuthin for current.
I just created a custom board in the prop gcc loader
```# custom.cfg
clkfreq: 20000
clkmode: XTAL1+PLL16X
baudrate: 115200
rxpin: 31
txpin: 30
tvpin: 12   # only used if TV_DEBUG is defined
```

I think that should do the trick!

EDIT: XTAL stand for crystal...PLL stands for???

Phase-Locked Loop
This is a pretty good discussion of what they are for.
Just realized my clock will shift 6 seconds every sampling, which over the course of near 100 samples (over two days at one sample per 30 mins) will shift the clock away from it's wanted time by almost 10 minutes!

I need to add another condition to the time_wait_cnt loop to do only 59 counts every 5th time incrementing the DatCount counter. This will cause a 30 second drift from the true time by the 5th count, but would reset it on the 6th. Not as if +-30 seconds is a huge difference maker when it comes to taking a temperature reading, but I don't want all my data to shift 30 minutes into the future every 6 days!

You also aren't taking into account the time taken to perform the processing. This probably isn't particularly significant over the course of a week, but over months can push your timing out of alignment even with your proposed fix.

There are a few options, depending on the accuracy you are looking for:
A real-time clock chip,
A software PLL driven from an external stable time reference e.g. GPS PPS (pulse per second),
A periodic manual adjustment e.g. a simple push button that zaps the timing reference to a predefined time of day (or count), or others that I'm not thinking of right now.

The first two will likely draw more power, while the third relies on you operating the control at a particular time on the day you wish to realign timing.
• Posts: 29
AJL wrote: »
JRoark wrote: »
Ha! Our posts crossed. Sick minds think alike. What freq are you driving the cogs and how many cogs are there running?

Edit: if you want to really stretch your battery life, use the internal 20khz oscillator and put the chip to sleep between runs. At 20khz that chip can be powered by next to nuthin for current.
I just created a custom board in the prop gcc loader
```# custom.cfg
clkfreq: 20000
clkmode: XTAL1+PLL16X
baudrate: 115200
rxpin: 31
txpin: 30
tvpin: 12   # only used if TV_DEBUG is defined
```

I think that should do the trick!

EDIT: XTAL stand for crystal...PLL stands for???

Phase-Locked Loop
This is a pretty good discussion of what they are for.
Just realized my clock will shift 6 seconds every sampling, which over the course of near 100 samples (over two days at one sample per 30 mins) will shift the clock away from it's wanted time by almost 10 minutes!

I need to add another condition to the time_wait_cnt loop to do only 59 counts every 5th time incrementing the DatCount counter. This will cause a 30 second drift from the true time by the 5th count, but would reset it on the 6th. Not as if +-30 seconds is a huge difference maker when it comes to taking a temperature reading, but I don't want all my data to shift 30 minutes into the future every 6 days!

You also aren't taking into account the time taken to perform the processing. This probably isn't particularly significant over the course of a week, but over months can push your timing out of alignment even with your proposed fix.

There are a few options, depending on the accuracy you are looking for:
A real-time clock chip,
A software PLL driven from an external stable time reference e.g. GPS PPS (pulse per second),
A periodic manual adjustment e.g. a simple push button that zaps the timing reference to a predefined time of day (or count), or others that I'm not thinking of right now.

The first two will likely draw more power, while the third relies on you operating the control at a particular time on the day you wish to realign timing.

What about more and more complicated loops! If you figure out how it goes wrong,

```if(loop_count % 5 == 0)
count = a;
if(loop_count % 20 == 0)
count = b;
if(loop_count % 80 == 0)
count = c;

for(x=0, x<(count), x++)
pause(1000);
```

This would require some very precise knowledge of the timing of your program, a simulator could probably provide this for me though. No excess hardware required which is nice! This solution probably becomes less feasible as time goes on. For projects requiring < one year of execution it's probably pretty feasible with some simple analysis though.
• Posts: 564
An RTC chip like a DS3231 does basically everything you want. It is a very accurate time base, has a programmable 1 pulse per second output, has an alarm function, and runs on flea power. You would have the Prop program it, then put the prop to sleep, and wait for the RTC to wake the Prop by pulsing a pin. This could be once once per second (using the 1 pps output) or whatever time of day you want. If you are really going for a measurement every 30 minutes, have the Prop set the time of day alarm for 30 minutes down the road. When the DTC fires that pin, the Prop wakes up, snapshots the time/temp/humidity, saves this data to memory, and reprograms the RTC to alarm again in 30 minutes.

There is a side benefit to using the DS3231. It has a *highly* accurate temperature sensor built into the chip that you can use to calibrate the other temp sensor. it also has 200-something bytes of memory that you can use for storing general configuration or program data.
• Posts: 29
edited 2020-01-08 - 15:12:09
> @JRoark said:
> An RTC chip like a DS3231 does basically everything you want. It is a very accurate time base, has a programmable 1 pulse per second output, has an alarm function, and runs on flea power. You would have the Prop program it, then put the prop to sleep, and wait for the RTC to wake the Prop by pulsing a pin. This could be once once per second (using the 1 pps output) or whatever time of day you want. If you are really going for a measurement every 30 minutes, have the Prop set the time of day alarm for 30 minutes down the road. When the DTC fires that pin, the Prop wakes up, snapshots the time/temp/humidity, saves this data to memory, and reprograms the RTC to alarm again in 30 minutes.
>
> There is a side benefit to using the DS3231. It has a *highly* accurate temperature sensor built into the chip that you can use to calibrate the other temp sensor. it also has 200-something bytes of memory that you can use for storing general configuration or program data.

It's definitely something to look into in the future, I mainly didnt want to buy any additional hardware since I already had a prop ab and a battery supply from a microcontrollers class last semester.

There something to be said for making it work with what you got too!

Keep forgetting quote is broken on mobile.
• Posts: 9,714
Having used all kinds of RTC chips over the decades including the DS3231 I now favor the tiny and tiny RV-3028-C7 as it is completely self-contained, draws only a microscopic 45nA so a tiny chip cap is enough to power it and it is extremely accurate. What's more is that it has an event input to capture and timestamp changes as well as a periodic countdown timer which can wake up the P2 at predetermined intervals, rather than setting a new alarm each time. There are plenty of other pluses this chip has which is why it is integrated on my P2D2 module.

The ebay RTC modules that you buy for the DS3231 are fake chips that drift worse than a drunk on an icy road. Besides all those modules have huge primary cells and holder so what's the point of a tiny chip? The RV3028 plus chip cap takes up less room than an 8-pin SOIC.

I'm thinking of making up these RTCs on a thin pcb module with 4 pins/pads that I can breadboard and prototype with, but the module is really small and the 4 pins would dwarf the circuit normally unless it has the larger 7mm supercap installed.
• Posts: 564
That little RV-3028-C7 really is a gem. I can see why you like it. Looks like I need to get my hands dirty with that one.

FWIW, my luck with getting DS3231’s off Amazon (not eBay) has been really good. I have several attached to FLIP’s that have 4 months of runtime on them, and they only vary from GPS time by about 2-3 seconds. Thats pretty impressive, even if they may be of dubious origins.
• Posts: 341
Are you using an Activity Board or Activity Board WX?

I just measured my activity board:
Power switch 0: .25mA
Power switch 1: 23.5mA
Power switch 2: 36.1mA

Those bright green LEDs use 12mA each! On the Activity Board WX it is decreased to 6mA each. It will be even less at the battery due to the WX's more efficient switching regulators.

Vsup = 5v
Vled = 2v (measured)
Vsup = Vled + iR
R=240
iR=Vsup - Vled = 3
i=V/R = 3v/240 = .0126 A
```CON
_clkmode = rcslow

PUB main

repeat
waitcnt( cnt+clkfreq)
```
• Posts: 29
Are you using an Activity Board or Activity Board WX?

I just measured my activity board:
Power switch 0: .25mA
Power switch 1: 23.5mA
Power switch 2: 36.1mA

Those bright green LEDs use 12mA each! On the Activity Board WX it is decreased to 6mA each. It will be even less at the battery due to the WX's more efficient switching regulators.

Vsup = 5v
Vled = 2v (measured)
Vsup = Vled + iR
R=240
iR=Vsup - Vled = 3
i=V/R = 3v/240 = .0126 A
```CON
_clkmode = rcslow

PUB main

repeat
waitcnt( cnt+clkfreq)
```

I'm using a WX, so far I've used it about 5 days total, which was well within even the lowest estimates for battery life.

I'm having some location problems right now, I can't find a good spot to leave the sensor where it doesn't get direct sunlight or not enough airflow. I live in an apartment in the downtown area of a city and leaving it outside my gate somewhere means it probably gets stolen.

I think I've done enough for proof of concept, I might just let it run until the batteries die and see how long it lasts.

How did you measure the current? I'm getting a digital multimeter soon so hopefully it'll be a bit easier to figure out current flow then using my o-scope.
• Posts: 341
I'm using a WX, so far I've used it about 5 days total, which was well within even the lowest estimates for battery life.

I'm having some location problems right now, I can't find a good spot to leave the sensor where it doesn't get direct sunlight or not enough airflow. I live in an apartment in the downtown area of a city and leaving it outside my gate somewhere means it probably gets stolen.

I think I've done enough for proof of concept, I might just let it run until the batteries die and see how long it lasts.

How did you measure the current? I'm getting a digital multimeter soon so hopefully it'll be a bit easier to figure out current flow then using my o-scope.
Yes, I used a multimeter between the power supply and activity board. I would be interested to know the results. I estimate 16 days. (A 2000mAh battery / 5mA load)

The math you have done here calculates the current through the resistor. If points A and B go to the activity board, that current does not flow through the resistor. Usually, you need to break a circuit to measure current. That's what you do when measuring current with a multimeter. But internally, the multimeter measures voltage. To measure current, it actually measures voltage across a small valued resistor inside the meter. You could try measuring the current again with a 47 Ohm resistor inline with the activity board power.
The calculation would be like:
0.235 V / 47 Ohms = 0.005 A

For the estimated current used by an Activity Board WX, anything between 10 and 100 Ohms might work. That range results in a useful voltage that you should be able to measure with your oscilloscope, given the expected 5mA current. It's just a trade-off between having enough voltage to measure accurately and having the voltage low enough that voltage supplied to the load is not adversely affected.

The SD card might use quite a lot of current when it is accessed. So you might see a peak current that is a lot higher than 5mA.
• Posts: 29
edited 2020-01-17 - 17:42:31
@SaucySoliton

Battery pack only lasted about 7 days where it actually took data.

The board LEDs flashed on and off for an hour or so and I believe that was to signify that the power was too low to continue operation.

Any rate I left it for a few more days and came back to only a day and a half worth of data written on the SD card.

7 days might not be very accurate though since my initial test run of about 8 hours was run on a 80MHz clock using the sleep rather than pause function (which is an active wait rather than pause which shuts the core down to an idle. )

I imagine this took days off my readings.