Current at only 330uA with battery pack supply?

mundaneeffort

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.

JRoark

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.

mundaneeffort

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.

Sorry about the vagueness.

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.

Publison

But what current is the Activity Board drawing, (at its power source)?

mundaneeffort

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?

JRoark

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.

mundaneeffort

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.

mundaneeffort

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...

JRoark

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...

JRoark

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.

mundaneeffort

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???

JRoark

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.

mundaneeffort

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!

Thanks for your help btw!


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.

mundaneeffort

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) 
  {
    int n = dht22_read(5);
    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;
}

JRoark

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.

mundaneeffort

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.

JRoark

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...

mundaneeffort

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.

JRoark

With a few small solar cells and a carefully selected battery, you might be right!

mundaneeffort

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!

Oh well, it's already running outside, glad I noticed that though.

AJL

mundaneeffort 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.

mundaneeffort wrote: »

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!

Oh well, it's already running outside, glad I noticed that though.

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.

mundaneeffort

AJL wrote: »

mundaneeffort 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.

mundaneeffort wrote: »

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!

Oh well, it's already running outside, glad I noticed that though.

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.

JRoark

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.

mundaneeffort

> @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.

Peter Jakacki

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.

JRoark

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.

SaucySoliton

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) 

mundaneeffort

SaucySoliton wrote: »

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.

SaucySoliton

mundaneeffort wrote: »

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.

mundaneeffort

@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.