Power consumption: a590 measurements and waveforms.

[peabody]

Did we have values for using an AV plug in record/active mode?  So, in intervalometer, using manual focus, how much do you benefit from putting a plug in the AV port versus leaving the display visible?

[bugsplatter]

Did we have values for using an AV plug in record/active mode?  So, in intervalometer, using manual focus, how much do you benefit from putting a plug in the AV port versus leaving the display visible?

We do now


Camera mode, operation                          V      mA      mW
--------------------------------------------  ----    ----    ----
Record active, MF mode                         2.5     584    1460
Record active, MF mode with AV lead in          "      530    1339
Record active, MF mode, backlight off           "      502    1255
Record active, AF mode                          "      504    1260
Record active, AF mode with AV lead in          "      448    1120
Record active, AF mode, backlight off           "      420    1050

Record idle, MF mode, camera idle              2.5     148     371
Record idle, AF mode, camera idle               "      147     366
Record idle, AF mode, script idle               "      138     345

Play mode, lens extended (AF or MF mode)       2.5     236     590
Play mode, lens retracted                       "      184     461

USB sense current, 5V to USB power via 200R            400uA

Note: Record Idle measurement is quite noisy and takes some time to settle, I imagine this is due to thermal effects as the CCD is off and camera innards are cooling down.  I'm inclined to average this group of measurements and take them as being the same, as the differences here are very near or within the measurement noise.  I need to perform a much longer term measurement sequence to reflect real world power use.  Now if only a590 had LED control...

Updated measurements on 2009-07-09

[bugsplatter]

Another annoying effect I've noticed is that the camera uses more power after it warms up  Just switching on cam now and repeating some tests, plus new ones, the values for modes I'd measured before were 3% lower, for example 1056mW for active record lcd_backlight off vs 1090mW yesterday, a 3% drop.

I'd noticed this variation earlier but not paid much attention, other than to mentally mark the measurements as having 2 or 3% uncertainty -- which I think is okay, but should be kept in mind since it's winter here down under and summer for those of you up the other hemisphere

The new effect I noticed is that scripting lcd_backlight off saves about 5.4% (MF mode), or 6.8% (AF mode) power compared to stuffing in an AV (dummy) plug, with the benefit you can still read the screen under a strong light.

I also adjusted the test script to have an @param control for dwell, these latest measurements taken with a 5s dwell instead of the 2s used yesterday.  Maybe a new all-warmed-up measurement sequence later.  

[Microfunguy]

my test script's two second cycle time was a little fast for the DPO measurement.  

Hmmm  .... and that is a very expensive 'scope.

Can you recommend any less expensive digital or USB 'scopes ?

[bugsplatter]

my test script's two second cycle time was a little fast for the DPO measurement. 

Hmmm  .... and that is a very expensive 'scope.

Can you recommend any less expensive digital or USB 'scopes ?

Was easier to get an accurate reading on a five second cycle, I could have use the cursors to define a point or small range and measure -- funny, the DPO is geared to taking far more complex measurements (all sorts of phase, overshoot, undershoot, even an FFT module), the simple measurements are not covered that well -- but I've not read the user's manual yet -- 'cos big boys don't read the manual until they're really stuck .

I've looked at USB connected 'scope frontends and they're quite expensive even for dismal performance, plus there's a premium for the PC 'scope software.  I'm lucky to be able to borrow this instrument. 

For me it would possibly be a USB connected thingy like the Arduino boards -- cheap but configurable and free access to design info and software.  Or buy a serial connected DVM?  They're relatively cheap too.  Depends so much on budget and requirements.

[fudgey]

Other thing is I'm including mW because you do, but battery life is a tad more complex as batteries are rated in AH, not WH.  And AH depends on load (SLAs rated at their 20 hour rate, for example), temp and stuff. 

Power is handy in conversation rather than voltage+current (of which voltage is way too often forgotten, leaving measurements with a tolerance of tens of percents), mostly because it allows direct and accurate comparison between supply choices and camera models (CHDK supported cameras are being powered from 2 or 4 alkaline, NiMH or lithium AA cells, lithium packs and various external power supplies (for example I use a 12 V -> 3 V converter to run my camera from external power, meaning input current matters even when on external power)... all these have different voltage ranges.

It's true that most (but not all...) batteries are rated in Ah instead of Wh, but since efficiency vs. input voltage is known to be nearly independent of input voltage at least on dual AA cell cameras, a single input power figure for each operating mode pretty much suffices for use with any Ah rated battery configuration.

a) CHDK Batt mV displayed value seems to have a constant slope integrating filter the takes about 10 seconds to reach a step-changed battery value.  Dunno if that filter is in CHDK or the cam, but I noticed the camera operates on actual battery voltage for low-going event triggers (for example on the last picture of second measurement set when camera activated lens park and power down as soon as Batt V went below 2.0V ), not the displayed mV value.

From core/gui_batt.c get_batt_average() it would appear that it's CHDK's doing. You may want to modify that for your experiments (either define VOLTS_N smaller I suppose, or make it return direct battery voltage result or modify the gui function that calls it to use that get_stat_bat func instead). And now that you made me look (no, I didn't know it was CHDK doing this...) I think I'll be doing that for myself too...

Keep up the good work! 

[bugsplatter]

It's true that most (but not all...) batteries are rated in Ah instead of Wh, but since efficiency vs. input voltage is known to be nearly independent of input voltage at least on dual AA cell cameras, a single input power figure for each operating mode pretty much suffices for use with any Ah rated battery configuration.

Okay, that sounds like a good reason to keep mW  I may add percentage savings as that might be useful to people deciding on best power savings method -- lcd_backlight off is a little better than the easy AV matchstick option.  

But camera idle is best for long intervals between shots.  Trouble I do have with idle at the moment is for AF mode there seems no camera status value that tells if cam is asleep.  Can tell for MF mode requested idle as the cam wakes up in AF mode.  How tell for AF mode idle?

From core/gui_batt.c get_batt_average() it would appear that it's CHDK's doing. You may want to modify that for your experiments (either define VOLTS_N smaller I suppose, or make it return direct battery voltage result or modify the gui function that calls it to use that get_stat_bat func instead). And now that you made me look (no, I didn't know it was CHDK doing this...) I think I'll be doing that for myself too...

So I wasn't imagining that?  Good!  But every time I go look at the source I want to scream and fix the very creative white-space so it's easier for me to read.  My background is assembler (sorry, 8bit 6805, 8048, 8080, z80, not Arm) programming and thus I find free-form C very hard to read.

From: http://bugsplatter.id.au/chdk/a590-power-2.html
Here's the table again with percentage savings:

Camera mode, operation (a590 1.01b)           V      mA      mW    save%
------------------------------------------  ----    ----    ----   -----
Record active, MF mode                       2.5     584    1460     n/a
Record active, MF mode with AV lead in        "      530    1339     8.3
Record active, MF mode, backlight off         "      502    1255    14.0
Record active, AF mode                        "      504    1260     n/a
Record active, AF mode with AV lead in        "      448    1120    11.1
Record active, AF mode, backlight off         "      420    1050    16.7

Record idle, MF mode, camera idle [1,2]      2.5     148     371      76
Record idle, MF mode, script idle [2]         "       -       -        -
Record idle, AF mode, camera idle [1]         "      147     366      70
Record idle, AF mode, script idle [1]         "      138     345      73

Play mode, lens extended (AF or MF mode)     2.5     236     590
Play mode, lens retracted                     "      184     461

[1] Record Idle measurement is quite noisy and takes some time to
settle, I imagine this is due to thermal effects as the CCD is off
and camera innards are cooling down.
[2] Camera switches back to AF mode on idle.

[bugsplatter]

Interval-o-meter power requirements.

The test: daylapse script, 60s interval, Af refocus, AF lock focus and MF modes compared.  Cam set to display idle in 10s. Note that daylapse actually wakes up the cam for a preparation time before shoot, prepares then waits for shoot time, then shoot -- other interval scripts usually wakeup, prepare and shoot as soon as possible.  So these results may be considered a little high.

I think I've done the math right for energy cost in mWH per shot:
  
  cam_active_s * mean_active_mW / 3600 to get total shot_energy mWH, then subtract:
  cam_active_s * idle_mW / 3600 to get net shot_energy mWH
which could have been:
  cam_active_s * (mean_active_mW - idle_mW) / 3600
if I'd thought of that sooner

Results:
  AF mode refocus: 353mW plus 4.96mWH / shot
  AF lock focus: 358mW plus 3.88mWH / shot
  MF mode: 359mW plus 7.52mWH / shot

Also on bottom of http://bugsplatter.id.au/chdk/a590-power-2.html page if you want to see the pictures and check how the measurements were taken between the cursors.

Notes:
MF mode takes more energy because the cam needs time to restore MF mode after waking up, as well as the increased power while active.

AF refocus also takes extra time to refocus, test was done in a dim room, it's a cloudy day today.  Bright light focusing would be quicker.

Both AF refocus and MF modes turned on the AF assist LED.

The daylapse script uses 'shoot_half' to wake cam from idle, and is not yet fully optimised for lowest power consumption.  I'm happy to test other scripts if they're easy to use and work on a590-101b or a470-101b -- even a580-101b if you have a chdk port requires testing .


View from the cam.

[PEU]

Is there a way to disable the native battery sensor on the A590? Im running it out of an external power supply (self made provides 3.6v) and it always blinks in battery low mode while CHDK says battery is 100% full

It would be great to be able to disable this sensor via CHDK. Thanks!

[fudgey]

Is there a way to disable the native battery sensor on the A590? Im running it out of an external power supply (self made provides 3.6v) and it always blinks in battery low mode while CHDK says battery is 100% full

It would be great to be able to disable this sensor via CHDK. Thanks!

The reason you get battery warning blink is most likely that either your power supply is too weak for the camera or you have too high cable and/or connector resistance (camera detects a severe voltage dip at its DC input when it works its lens motors and thinks that's due to a weak battery).

Once it has started to blink, it can probably be disabled using events, see http://chdk.setepontos.com/index.php?topic=4037.0

[PEU]

you think that a bigger section cable should solve this? since the connector is not easy to find here I used one from a cellphone supply purchased on the street, the wire is really thin.

[fudgey]

you think that a bigger section cable should solve this? since the connector is not easy to find here I used one from a cellphone supply purchased on the street, the wire is really thin.

If cable is the problem, then yes...1 ohm/m isn't unheard of and really is a lot at e.g. 3V 1A peaks. But if voltage dips at the PSU end of the cable as well, then no.