limiting factors of CHDK for extended time-lapse

Sdack

195

« on: 01 / August / 2018, 21:56:19 »

Advertisements

Hi folks,

Well it's been about a year now since I first discovered CHDK and started building time-lapse rigs, using IXUS160s.

I've been helped a lot in my journey by the fine people on this forum and I've had some great results but now I'm starting to think I need a more robust solution to proceed in a commercial direction with my time-lapse rigs and the reason boils down to power consumption and temperature (I'm in Australia).

My most preferred interval for images is 60 seconds, so my cameras and Raspberry Pi controlled, Internet connected (wifi or more recently 3/4G mobile data) rigs run constantly during the day with an average power draw of 8W (measured with a cheap, consumer AC Watt meter).

I use weatherproof outdoor enclosures, with sun shields but when they're in the full Sun, I've been encountering camera shutdowns, with logs showing a sensor temperature of 80 degrees C. It seems the camera sensor (not the LCD display, the actual picture sensor) remains on the entire time the camera is powered and the heat just builds up.

I've discovered some reasonably low power DC Peltier cooling systems with the upside that the system only needs cooling when the Sun is out and therefore well suited for Solar Panel supply but it's a slippery slope, the more electrical components I add, the bigger the panels and battery I need, the cost goes up and the mounting gets harder and the complexity goes on and on.

So recently I've started looking at how the bigger, long running professional players in the market manage this and they seem to do it without cooling. Using a micro processor control for camera control, then, if Internet connectivity is required, using a linux board to handle networking and uploads with much less frequency.

Digital SLR cameras seem to be dumber than the Canon CHDK cameras and I've been told their sensors turn off in between shots. Either that, or one can power up an SLR very briefly, take the shot using an electronic shutter release and then power down again to achieve the same thing. With my IXUS, the lens extension is a big, albeit brief, power draw, which might negate the saving of turning the camera off.

I write in the hope that someone could either suggest a way to shut off the IXUS160 sensor, inbetween shots, or perhaps an alternative, microprocessor-based variant of CHDK that I can use. I did look briefly at STM32 controllers but found the initial learning curve a bit too steep. The connections for programming, unfamiliar programming language and firmware updating rather stumped me.

However there seem to be a whole new breed of Internet of Things devices with built in network connectivity that look very promising. One can be found here https://core-electronics.com.au/pycom-gpy.html. It has a built in real time clock and SD card, and runs MicroPython, which is a bit more familiar and easy to implement.

I fear my leaning towards DSLR's could be seen as a betrayal of the whole idea of CHDK. Super high quality images from affordable consumer cameras but that's not my intention. My experience has been so positive up to now, I'm deeply indebted to CHDK for the journey. I just don't know if this bus can get me all the way to where I am now inspired to go.

I'm hoping I might have missed a development along the way that might solve my issue. It's easy to do in a forum so large.

Any suggestions?

Cheers
Sdack

Logged

reyalp

14080

Re: limiting factors of CHDK for extended time-lapse

« Reply #1 on: 02 / August / 2018, 00:53:09 »

Quote from: Sdack on 01 / August / 2018, 21:56:19

My most preferred interval for images is 60 seconds, so my cameras and Raspberry Pi controlled, Internet connected (wifi or more recently 3/4G mobile data) rigs run constantly during the day with an average power draw of 8W (measured with a cheap, consumer AC Watt meter).

I use weatherproof outdoor enclosures, with sun shields but when they're in the full Sun, I've been encountering camera shutdowns, with logs showing a sensor temperature of 80 degrees C. It seems the camera sensor (not the LCD display, the actual picture sensor) remains on the entire time the camera is powered and the heat just builds up.

You should be able to use the Canon power saving options to have the sensor turn off after 10 seconds of idle. AFAIK the escursionisticivatesi.it multilapse cams use this technique.

I feel like this was discussed in one of the other threads, but briefly
In the Canon power saving menu, set
Auto power down: off
Display off: 10 sec

In CHDK settings, set
Disable LCD off: never

Your camera should now turn off the display and sensor after 10 seconds of inactivity. The first key press from a script will wake it up.

Note if you have the power button held down for external power control, you also need to to do
post_levent_to_ui"UnpressPowerButton"
after startup for the display off function to work. The multilapse script already does this.

You can also turn off the sensor by switching to playback mode, but if you interval is longer than the lens retract time, you'll put a lot of wear and tear on the mechanism and the switch back to record will be slow.

Old canon cameras with an optical viewfinder (and a few others) allow you to switch the display + sensor directly.

edit:
Previous discussion https://chdk.setepontos.com/index.php?topic=13340.msg136488#msg136488

« Last Edit: 02 / August / 2018, 01:03:26 by reyalp »

Logged

Don't forget what the H stands for.

Sdack

195

Re: limiting factors of CHDK for extended time-lapse

« Reply #2 on: 02 / August / 2018, 01:11:18 »

Hi Reyalp,

Thanks for your informative reply and for not taking offence at my doubts at CHDK's robustness.

I followed your instructions, which you have actually offered in the past and it seems you are correct or at least the LCD goes black.

I just cracked open the multilapse.lua script and found the following code, exactly as you proposed..

Code: [Select]

function camera_init()
	print('Unpressing power button')
	cli_cmd('=post_levent_to_ui"UnpressPowerButton"')

Perhaps it's just the frequency of my 60 second image taking plus the heat of the Sun that's causing my 80 degree sensor shutdowns? I didn't experience any shutdowns with my 6 month installation at the nearby school but that camera was on a shaded window ledge.

Thanks again

Sdack

Logged

reyalp

14080

Re: limiting factors of CHDK for extended time-lapse

« Reply #3 on: 02 / August / 2018, 02:27:01 »

Quote from: Sdack on 02 / August / 2018, 01:11:18

I followed your instructions, which you have actually offered in the past and it seems you are correct or at least the LCD goes black.

I'd suggest testing to confirm that the sensor is actually being turned off in your particular setup. Even if it eventually overheats, the difference between sensor on all the time vs off 5/6 of the time should be pretty clear.

My elph130 sensor temp went from 27c (~ambient) to 39c idling with the sensor on (lcd turned off via CHDK) and for ~5 minutes. A minute after canon power saving turned the screen off, it dropped to 35.

Leaving on for longer seemed to level off around 42c and drop back to 35 when turned off.

There did seem to be a smaller difference for LCD alone (maybe 1c)

Quote

Thanks for your informative reply and for not taking offence at my doubts at CHDK's robustness.

You should use whatever works for you. Older DSLRs can be had relatively cheaply, and will should keep the sensor off between shots unless in live view mode.

Quote

I write in the hope that someone could either suggest a way to shut off the IXUS160 sensor, inbetween shots,

It's possible a way could be found to turn off the sensor immediately rather than after 10 seconds, but if you are still hitting 80c with the sensor on for 10 seconds, that seems like it likely wouldn't be enough.

Quote

or perhaps an alternative, microprocessor-based variant of CHDK that I can use.

I'm not sure what you mean by this. CHDK only runs on canon cameras. If you mean using a microcontroller to do what you are doing with chdkptp now, that would most likely require a lot of work.

I think if I were doing this, I think I would focus would be on getting the heat out of the enclosure more efficiently (after verifying that the sensor off after 10s was actually working). But again, you should do whatever best matches your personal preference and resources.

Logged

Don't forget what the H stands for.

Sdack

195

Re: limiting factors of CHDK for extended time-lapse

« Reply #4 on: 02 / August / 2018, 02:43:19 »

Quote

or perhaps an alternative, microprocessor-based variant of CHDK that I can use.

Quote

I'm not sure what you mean by this. CHDK only runs on canon cameras. If you mean using a microcontroller to do what you are doing with chdkptp now, that would most likely require a lot of work.

Sorry, I didn't mean on another camera brand, I meant an Arduino implementation of CHDKPTP.. I've seen promising looking projects proposing such as this one
https://www.circuitsathome.com/mcu/controlling-canon-powershot-cameras-to-arduino/

I'm thinking that an ultra low power, low heat producing, real-time clock based Arduino intervalometer could handle the CHDKPTP time-lapse image taking, then on a separate schedule, the Arduiono could power up the Raspberry Pi which would extract the images from the camera (oops.. two devices trying to connect to the same USB port (but not at the same time at least - perhaps using a split USB cable?)

Quote

I think if I were doing this, I think I would focus would be on getting the heat out of the enclosure more efficiently (after verifying that the sensor off after 10s was actually working). But again, you should do whatever best matches your personal preference and resources.

Here in Australia the ambient temperature can exceed 45 degrees Centigrade, so my goal is more about preventing extra heat than it is about getting cool air into the case from outside, because there sometimes isn't any - cool air.

Thanks for your input though, appreciate it as always

Sdack

Logged

waterwingz

12138

Re: limiting factors of CHDK for extended time-lapse

« Reply #5 on: 02 / August / 2018, 23:17:12 »

Quote from: Sdack on 02 / August / 2018, 02:43:19

I'm thinking that an ultra low power, low heat producing, real-time clock based Arduino intervalometer could handle the CHDKPTP time-lapse image taking, then on a separate schedule, the Arduiono could power up the Raspberry Pi which would extract the images from the camera (oops.. two devices trying to connect to the same USB port (but not at the same time at least - perhaps using a split USB cable?)

If you just want an intervalometer, use a CHDK script. Or if you insist on using an Arduino, control the camera via CHDK's USB Remote functionality. That leaves the actual USB data connection for the requested download to the Raspberry Pi. The code for the Ultimate Intervalometer show how to mix USB remote functionality and CHDKPTP on the same USB port.

Quote

Here in Australia the ambient temperature can exceed 45 degrees Centigrade, so my goal is more about preventing extra heat than it is about getting cool air into the case from outside, because there sometimes isn't any - cool air.

After a short period of time, the temperature inside any sealed container will rise to the outside ambient temperature plus the heat gain from the components inside. Insulation only slows the rate of rise. The point of ventilation is to let as much of the heat generate inside as possible escape - minimizing the rise above ambient.

Logged

Ported : A1200 SD940 G10 Powershot N G16

Sdack

195

Re: limiting factors of CHDK for extended time-lapse

« Reply #6 on: 02 / August / 2018, 23:35:07 »

Quote

If you just want an intervalometer, use a CHDK script. Or if you insist on using an Arduino, control the camera via CHDK's USB Remote functionality. That leaves the actual USB data connection for the requested download to the Raspberry Pi. The code for the Ultimate Intervalometer show how to mix USB remote functionality and CHDKPTP on the same USB port.

Thanks for those insights WW, I think you've solved my two devices in the one connection issue. The flexibility of CHDK never ceases to amaze me.

Quote

After a short period of time, the temperature inside any sealed container will rise to the outside ambient temperature plus the heat gain from the components inside. Insulation only slows the rate of rise. The point of ventilation is to let as much of the heat generate inside as possible escape - minimizing the rise above ambient.

Moisture and condensation are also potential problems in my sub-tropical environment, so I'm leaning towards a sealed enclosure with a gel absorbtion pack rather than ventilation.

If I can't reduce my thermal build up, by utilising ultra low powered microcontrollers. I will try something like this which I've seen in use on this very high end professional systems

https://www.mktimelapse.com/technology/#MKV3

To which end I've ordered this cheap and cheerful test kit

https://www.aliexpress.com/item/1pc-Thermoelectric-Peltier-Refrigeration-Cooler-DC-12V-Semiconductor-Air-Conditioner-Cooling-System-DIY-Kit/32814753813.html?spm=a2g0s.9042311.0.0.9bf44c4dFJupPF

Thanks again
Sdack

Logged

waterwingz

12138

Re: limiting factors of CHDK for extended time-lapse

« Reply #7 on: 02 / August / 2018, 23:46:22 »

Quote from: Sdack on 02 / August / 2018, 23:35:07

Quote
To which end I've ordered this cheap and cheerful test kit
Peltier effect cells are fun to play with. But getting any significant amount of cooling takes a big set of cells with heat sinks and quite a bit of electrical power. Which kind of flys in the face of your original low power requirement.

Logged

Ported : A1200 SD940 G10 Powershot N G16

Sdack

195

Re: limiting factors of CHDK for extended time-lapse

« Reply #8 on: 03 / August / 2018, 04:53:13 »

http://chdk.wikia.com/wiki/USB_Remote which state the following:

Quote

Enabling USB Remote operation
To enable USB remote operation, go to the CHDK Remote parameters menu and select Enable Remote.
Note : When this option is selected, the USB port on the camera will no longer be available for uploading picture files or PTP operations.

I see in your Ultimage Intervalometer options there is both a Shoot on USB Pulse option AND a Pause when USB connected toggle. So I'm guessing and hoping that the camera can tell the difference due to the action on the two different sets of USB pins. As I understand it it's the power pins that are used for the Remote shutter and the two inner data pins for CHDKPTP.

Am I right?

However I was just about to dive in and see what happened when a second potential stumbling block arose in my mind..

The missing item in question is the initiation of a Camera Shutdown, to save power between shots ie.

A super low powered microcontroller (Arduino or similar) with a programmable timer, switches a relay to supply power to the camera which turns it on (because the physical button is constantly depressed)
The Arduino then initiates one or more image captures over USB Remote
The resulting image/s are saved locally onto the camera SD card
The camera powers down until the next Arduino initiated schedule
This continues until a second schedule initiates a relay to wake up of the linux box for file handling and network tasks such as moving images from the SD card to the Raspberry Pi storage and subsequent resizing and uploading of thumbnails images

Do you think it might be possible (for a novice like myself) to copy the camera shutdown segment of another script, like the KAP UAV script which features a setting to shut down once a user set number of images have been taken?

I suspect this would be easier to implement than a USB Remote function initiated by a set of pulses.

Cheers
Nigel[/list][/list][/list]

« Last Edit: 03 / August / 2018, 05:24:58 by Sdack »

Logged

blackhole

937
A590IS 101b

Re: limiting factors of CHDK for extended time-lapse

« Reply #9 on: 03 / August / 2018, 08:56:55 »

Quote from: Sdack on 02 / August / 2018, 23:35:07

Moisture and condensation are also potential problems in my sub-tropical environment, so I'm leaning towards a sealed enclosure with a gel absorbtion pack rather than ventilation.
To which end I've ordered this cheap and cheerful test kit

https://www.aliexpress.com/item/1pc-Thermoelectric-Peltier-Refrigeration-Cooler-DC-12V-Semiconductor-Air-Conditioner-Cooling-System-DIY-Kit/32814753813.html?spm=a2g0s.9042311.0.0.9bf44c4dFJupPF

With a Peltier cooler you need a sealed and vacuumed casing, otherwise there will be some big problems with condensation.Only the use of silica gel or something similar will not be enough.
In my experience the best solution is a casing filled with Argon gas.
You can use non-return valves which are used in window making.
As mentioned above, the power consumption of the Peltier cooler is significant.

Logged

http://astrofoto.pondi.hr