Blinking (back)lights... for very long time delays on battery power.

  • 8 Replies
  • 1379 Views
*

Offline ahull

  • *****
  • 634
Advertisements
A quick question for the developers... how much control do we have over the backlight (or indeed any of the other LEDs, but the backlight is going to be easiest to use in this scenario)?

My thinking is this...

If I want to sleep for many hours (or indeed days), in order to capture a particular event or sequence of events, as we have seen, there is a problem, I need a very large battery, or I need to keep swapping the battery.

An alternative approach is to switch on the camera only when needed. To do this,  I can switch the camera on and off with a microcontroller.

The controller of choice these days seems to be an Atmel (arduino and clones), but a PIC would be equally valid in this scenario.

These guys can sleep for extended periods and use next to no power, but they have a downside, no real time clock. You can add one, but that adds to the complexity.

Furthermore, if you run them in very low power mode, typically they run from their internal R/C oscillator. This means that they keep very bad time, typically the oscillator is only good for +/- 3% accuracy, which works out about  +/- 43.2 minutes per day.

So, my thinking was this.. Let the microcontroller sleep for "about the right time" less 4%, then wakeup and ask the camera what time it is (The camera has a pretty accurate real time clock in it).
 
As I said, the camera up till this point has been powered off.  The microcontroller switches on the camera with a FET or relay or whatever is appropriate. Once it knows the exact time, it switches off the camera again to preserve battery life, then it too sleeps for the remaining time less 4%  and so forth until the error is insignificant.

The trouble is... how to let the micro-controller know what time the camera has. I want this to be an easy hack. Something anybody with an arduino clone can copy, so I cant split the camera open and solder on to the uart, 'cos this is not something your average joe would even consider doing.

Most people can however fire a relay or mosfet and a photo transistor and a resistor on to a couple of I/O pins on an arduino clone (powered from the same source as the camera for ease of construction).

With the right software tweaks on both ends, the camera can blink the data from the RTC and the microcontroller can listen.

So my remaining questions are, would anybody be interested in this if it could be done, how easy would it be to do, and can anybody think of a better way to do this?

(OK I lied about it being a quick question  :D )

Re: Blinking (back)lights... for very long time delays on battery power.
« Reply #1 on: 24 / January / 2014, 15:18:58 »
Blinking the focus lamp from a Lua script would be trivial and a simple phototransistor circuit could be used to read the blinks into the microcontroller.

There is a commercial device that does much of this :  http://www.gentles.ltd.uk/clickpan/sdm.htm  that is supported in SDM right now.  Interfacing from CHDK with a Lua script seems possible but adding a function in C that supports this makes some sense too.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline srsa_4c

  • ******
  • 3628
Re: Blinking (back)lights... for very long time delays on battery power.
« Reply #2 on: 24 / January / 2014, 15:19:51 »
The problem with the backlight is that it is already blinking (pwm). It's probably possible to find its on/off control GPIO port, but you'll need to handle those unwanted impulses too.
If you want a better output method, you could use the AF 'lamp'.
RTC addons for arduino seem to be available for less than $2 on the usual marketplace, btw.  ;)

And from the software side:
Since various timer functions of the camera's OS are now available, it should be possible to create bitstream transmitter and receiver routines with their help (and forget about the 10ms resolution that is available now).
« Last Edit: 24 / January / 2014, 15:24:58 by srsa_4c »

*

Offline ahull

  • *****
  • 634
Re: Blinking (back)lights... for very long time delays on battery power.
« Reply #3 on: 24 / January / 2014, 15:33:28 »
The problem with the backlight is that it is already blinking (pwm). It's probably possible to find its on/off control GPIO port, but you'll need to handle those unwanted impulses too.
If you want a better output method, you could use the AF 'lamp'.
Good point
Quote
RTC addons for arduino seem to be available for less than $2 on the usual marketplace, btw.  ;)

I know, I've got one somewhere, however if we can send the time, we can also send how long the next sleep is....
so now our dumb microcontroller can sleep till the next sunset, or the next pass of the ISS... or the next time the moon rises... or 20 minutes after sunset when the interesting animals come out of their den or the next whatever other list of events we have already loaded on the camera SD card or calculated on the camera.

You don't have to limit yourself to just the time, you could send servo position too, so alignment of astronomy "barn door" or X-Y  could be sent. Sleep till meteor shower is due, look at meteor shower..

The code on the microcontroller would be set once, and thereafter it would perform the same task, sleep, task, sleep and so forth. All of the microcontroller data would be coming from the camera and SD card. The microcontroller would be fit and forget.

I've already toyed with alarm clock modules, but they are somewhat limiting.. once per day doesn't really cut the mustard for most applications.

Quote
And from the software side:
Since various timer functions of the camera's OS are now available, it should be possible to create bitstream transmitter and receiver routines with their help (and forget about the 10ms resolution that is available now).

..any LED would do, I went for the backlight because its easy to align a photo sensor with, but the power LED might be better, or perhaps the Print LED, we might after all be using the focus assist lamp.. for... focus assist... 
« Last Edit: 24 / January / 2014, 15:49:07 by ahull »


Re: Blinking (back)lights... for very long time delays on battery power.
« Reply #4 on: 24 / January / 2014, 16:00:30 »
If I want to sleep for many hours (or indeed days), in order to capture a particular event or sequence of events, as we have seen, there is a problem, I need a very large battery, or I need to keep swapping the battery.

Last year I took many month-long timelapses, I only had to change the battery weekly.
The battery was not physically large.
I was also able to check the equipment  and unknown unknowns.
One timelapse lasted nine months.

I will do the same this year, I have akready started charging the many batteries.
« Last Edit: 24 / January / 2014, 16:05:47 by Microfunguy »

*

Offline ahull

  • *****
  • 634
Re: Blinking (back)lights... for very long time delays on battery power.
« Reply #5 on: 24 / January / 2014, 16:47:43 »
@microfunguy, I'm not detecting a lot of enthusiasm for this idea...  :D
« Last Edit: 24 / January / 2014, 18:56:29 by ahull »

*

Offline srsa_4c

  • ******
  • 3628
Re: Blinking (back)lights... for very long time delays on battery power.
« Reply #6 on: 24 / January / 2014, 18:13:49 »
I'm not detecting a lot of enthusiasm for this idea...  :D
?
The problem with the backlight is that it is already blinking (pwm).
If you're lucky, the pwm controller can do 100% duty cycle.
You could do some experimenting on some of your cameras:
'DispDev_EnableEventProc' should register 'LcdCon_SetLcdBackLightBrightness' and 'DispCon_SetMaxBackLightBrightness'. They don't exist on some of the oldest DIGICII models (ixus30/40/50/700, s2), but they do on anything newer. They don't appear to do anything on the a470 (this cam lacks user backlight control).
If you have access to an oscilloscope (and a photodiode), you can try to determine whether the backlight's duty cycle can reach 100%.
You also haven't specified the blinking protocol.

*

Offline ahull

  • *****
  • 634
Re: Blinking (back)lights... for very long time delays on battery power.
« Reply #7 on: 24 / January / 2014, 18:52:40 »
Blinking the focus lamp from a Lua script would be trivial and a simple phototransistor circuit could be used to read the blinks into the microcontroller.

That's what I thought.

Quote
There is a commercial device that does much of this :  http://www.gentles.ltd.uk/clickpan/sdm.htm  that is supported in SDM right now.

Interesting... very similar concept...

Quote
Interfacing from CHDK with a Lua script seems possible but adding a function in C that supports this makes some sense too.

Thanks for that, it seems this should be possible then. Time to start playing with one of my arduino pro mini clones and a photodiode. Hopefully I'll get a chance to make a start next week.
« Last Edit: 24 / January / 2014, 18:54:57 by ahull »


*

Offline ahull

  • *****
  • 634
Re: Blinking (back)lights... for very long time delays on battery power.
« Reply #8 on: 24 / January / 2014, 19:06:41 »
I'm not detecting a lot of enthusiasm for this idea...  :D
?
Just kidding.
Quote
The problem with the backlight is that it is already blinking (pwm).
If you're lucky, the pwm controller can do 100% duty cycle.
You could do some experimenting on some of your cameras:
'DispDev_EnableEventProc' should register 'LcdCon_SetLcdBackLightBrightness' and 'DispCon_SetMaxBackLightBrightness'. They don't exist on some of the oldest DIGICII models (ixus30/40/50/700, s2), but they do on anything newer. They don't appear to do anything on the a470 (this cam lacks user backlight control).
If you have access to an oscilloscope (and a photodiode), you can try to determine whether the backlight's duty cycle can reach 100%.
I'll hook up the scope probably on Monday.
Quote

You also haven't specified the blinking protocol.
I suspect I'll reuse some existing library on the arduino end, perhaps adapt one of the existing IR remote control protocols.

 

Related Topics