supplierdeeply

limiting factors of CHDK for extended time-lapse

  • 79 Replies
  • 2376 Views
Re: limiting factors of CHDK for extended time-lapse
« Reply #50 on: 05 / August / 2018, 23:06:12 »
Advertisements
here's a picture showing my basic rig set up, this is the Raspberry Pi version
Awesome pic! Thanks so much for posting that - helps a lot with my understanding.

Converting 9V to 5V and then converting again from 5V to 3.7V for the camera probably costs you something vs converting 9V directly to 3.7V FWIW.

Quote
It was only when I downloaded the DCIM folder later that I found it had only taken 25 shots, instead of 60.
Lot's of things might have cause that unfortunately - including a script that was never intended to be used that way.

But what I'm really interested in is a measurement of the power consumed by a simple intervalometer that keeps the camera powered up in "Playback" mode  with the LCD off  - except when shooting.  Pretty much the lowest power solution FWIW.

Then compare that to your Arduino "power up, shoot, power off" method.

That should help you judge if the wear & tear on the mechanicss is worth the power saving. It kind of depends on your budget - if replacing cameras periodically is less important than running out of power then you have your decision made for you.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline Sdack

  • ***
  • 166
Re: limiting factors of CHDK for extended time-lapse
« Reply #51 on: 05 / August / 2018, 23:13:53 »
Quote
Awesome pic! Thanks so much for posting that - helps a lot with my understanding.
No worries.
Quote
Converting 9V to 5V and then converting again from 5V to 3.7V for the camera probably costs you something vs converting 9V directly to 3.7V FWIW.
In that case I might reroute that camera buck converter direct to the 12V line.

Quote
But what I'm really interested in is a measurement of the power consumed by a simple intervalometer that keeps the camera powered up in "Playback" mode  with the LCD off  - except when shooting.  Pretty much the lowest power solution FWIW.

Then compare that to your Arduino "power up, shoot, power off" method.
Can you suggest the best settings and script for the non Arduino test?  Or did I already pick the best options with the KAP script?

I've managed to cobble together a way to measure the draw of both devices now, so I'm happy to run some tests today

Sdack

Re: limiting factors of CHDK for extended time-lapse
« Reply #52 on: 05 / August / 2018, 23:20:29 »
Can you suggest the best settings and script for the non Arduino test?  Or did I already pick the best options with the KAP script?

Might be better if I just modified my battery miser script so that we can configure the best options  (and play with others if it makes sense).

Did a little work on that today - might take me a day or two for testing.  Life keeps happening but if that works for you I'd be very interested in the results.

Quote
If my AliExpress wired meter turns up in the post, I'll be able to measure the 12V line easily.
Which one did you purchase? 

And I assume the 12V you mention is the 9V on your diagram?
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline Sdack

  • ***
  • 166
Re: limiting factors of CHDK for extended time-lapse
« Reply #53 on: 05 / August / 2018, 23:37:57 »
That would be great, thanks again.

No huge rush at my end.

The AliExpress wattmeter is this one



https://www.aliexpress.com/item/DC-100A-Digital-LED-Power-Meter-Monitor-Power-Energy-Voltmeter-Ammeter-shunt-free-shipping/32420786424.html?spm=a2g0s.9042311.0.0.569d4c4d90DmHO

I don't yet understand the use of 'shunts' but I guess I'll figure it out.

By the way, my first purchased IXUS160, that I had running for nearly 6 months straight, reports 61,234 shutter activations.


*

Offline Sdack

  • ***
  • 166
Re: limiting factors of CHDK for extended time-lapse
« Reply #54 on: 06 / August / 2018, 00:04:14 »
and yes.. when I said 9V I meant 12V... D'oh!

Sorry

*

Offline Sdack

  • ***
  • 166
Re: limiting factors of CHDK for extended time-lapse
« Reply #55 on: 06 / August / 2018, 04:25:28 »
I did a couple of test runs, measuring whole power draw, which features

Arduino and IXUS160, with the fast one shot script 1 hour of usage = 0.2 Wh

A whole, Rasberry Pi controlled, wifi connected rig (which is uploading each image immediately on capture) 1 hour of usage = 2Wh

Obviously the file handling and upload are still missing from the Arduino set up but it's a massive saving, only using a tenth the energy.  So all the remote powering can be much smaller scale... panels batteries etc. not to mention the ease of installation of such items way up a pole.

What next?


Re: limiting factors of CHDK for extended time-lapse
« Reply #56 on: 07 / August / 2018, 07:51:35 »
I did a couple of test runs, measuring whole power draw, which features
Arduino and IXUS160, with the fast one shot script 1 hour of usage = 0.2 Wh
I would be very interested to know how much power your camera would use without the Arduino controlling it but with CHDK configured to "idle in playback mode" with the LCD disabled via the set_lcd_display( ) function.

Quote
A whole, Rasberry Pi controlled, wifi connected rig (which is uploading each image immediately on capture) 1 hour of usage = 2Wh
So the next trick is to power cycle the Pi so it only starts a few times a day maybe?  Be careful to allow it to power down itself via software prior to actually cutting power.

Quote
What next?
If you are handy enough to mod the camera internals, you could use the Arduino relay to briefly short out the camera's power switch in order to turn it on (rather than switch the battery).  That way the power drain disappears the moment the CHDK script halts the camera.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline Sdack

  • ***
  • 166
Re: limiting factors of CHDK for extended time-lapse
« Reply #57 on: 07 / August / 2018, 19:41:57 »
Quote
I would be very interested to know how much power your camera would use without the Arduino controlling it but with CHDK configured to "idle in playback mode" with the LCD disabled via the set_lcd_display( ) function.
No problem.  I will see if I can figure out and give it a whirl today.
This method is attractive because it eliminates the lens actuator wear and tear.
If the camera draw is low enough, it might work well as a slight variation on the optional workflow that I outline below
Quote
So the next trick is to power cycle the Pi so it only starts a few times a day maybe?  Be careful to allow it to power down itself via software prior to actually cutting power.
That part is easy, scheduling a shutdown is a simple 'cron' task, or can be added as a line at the end of a task in a bash script.
Quote
If you are handy enough to mod the camera internals..
Fraid not!  These cameras are a miracle of compact design.  I might hazard a tear down once I have a dead one.. or if I see one on Gumtree selling for parts only

Yesterday I found an interesting add on device for the Raspberry Pi (or HAT as they're known in Pi world).

It's called a Sleepy Pi and seems to offer most of what I'm looking for in an affordable and nicely integrated manner

https://spellfoundry.com/product/sleepy-pi-2/

Optional workflow
I woke up this morning wondering if this might work...

  • Following the scheduled daily, image interval (say every 60 seconds) the Arduino powers up the camera
  • The camera autoruns a script which then awaits a pulse signal at the USB port
  • During normal shooting, the Arduino initiates a pulse (on the 5V lines) which tells the camera to fire up the OneShot script
  • The script causes the camera to shoot one shot and shuts down (or, idles in playback mode perhaps)
  • The Arduino shuts the power off to the camera (saving that small draw due to the power button being constantly down)
  • Once an hour, or whatever, the Arduino powers up the Raspberry Pi and the camera
  • The camera autoruns the listening script
  • The Arduino initiates a different pulse, telling the camera to go into PTP mode
  • The Raspberry Pi connects with CHDKPTP and does it's business file transferring then shuts both itself and the camera down




Re: limiting factors of CHDK for extended time-lapse
« Reply #58 on: 08 / August / 2018, 00:23:17 »
One small refinement that might simplify this a bit?

Have the camera script check the USB plug +5V pin state each time it runs.

If it sees +5v there it  knows the Pi is active and it should wait for PTP transfers.  The script can power the camera off when the +5V goes away (Pi powered off).

Otherwise the script just takes one shot and powers off.



Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline Sdack

  • ***
  • 166
Re: limiting factors of CHDK for extended time-lapse
« Reply #59 on: 08 / August / 2018, 01:14:41 »
Quote
One small refinement that might simplify this a bit?

Have the camera script check the USB plug +5V pin state each time it runs.

If it sees +5v there it  knows the Pi is active and it should wait for PTP transfers.  The script can power the camera off when the +5V goes away (Pi powered off).

Otherwise the script just takes one shot and powers off.
Yup, that's cleaner by far.  Thanks for that.

 

Related Topics