Selective Intervalometer (days, days of week, hours/min, intervals min/sec) - page 6 - Completed and Working Scripts - CHDK Forum supplierdeeply

Selective Intervalometer (days, days of week, hours/min, intervals min/sec)

  • 88 Replies
Hey guys, me again  :D

I think I have everything I want for the construction project but would like to find hyperfocal distance and lock the camera to that so it doesn't refocus each time.  I understand enough that I would want to add the  set_aflock 1 command to the script, or probably more properly the set_focus(f) but are there some basic steps in finding the hyperfocal distance value to plug in?  and where exactly should it be placed into the script? 

It's funny, I work in IT support but am completely lacking in anything that requires scripting of any kind.  Sorry for the rookie question  :(

I need a little help. Most of the TL that I do is done in the immediate - i.e. I set a script to run and go out and set up the camera and just turn it on and it runs! I do a lot of RCAP (aerial photography from a remote control aircraft) and consequently when I buy a camera (ebay) the LCD is NOT a primary concern for me as I will NOT be looking at it when the camera is mounted on a plane and 2500 feet away!! LOL!! SO. Most cameras I have do not have working LCD's. Works great for any script that can be PRE set and just "runs" when the camera comes on.

But if I want to use this script - and do NOT have a way to "look" at or respond to function input requests - can the script be automated for NO input?

What would be really nice from my end (I know - there's always someone wanting something else!! SORRY!! LOL!!) would be a way to set everything in the script - like instead of having to choose days of the week (DOW's) how about a simple string of "dates" from 1 to 31. The camera IS already set to it's date and time so it already KNOWS them - so it would be nice if I could just input into the script to "SHOOT" on  4,5,6,7,8,11,12,13,14,15. Those numbers representing DAYS of the current month. The time routines are fine as I already have figured out how to mod them in script (NOT in camera with the script running - but on the PC before the script is loaded which makes my changes be "DEFAULT" numbers)

So what I am asking for I guess is that the DOW routine be altered to a DOM (date of month) routine that would require NO visual inputs AFTER the CDHK initiates and the script is running!
 This change would be good as it would allow really long term use. I apologize in advance if I am asking you guys for something that is impossibly hard to implement as I do know the hard work you are already doing - AND I APPRECIATE IT!! This script AS WRITTEN is excellent and has given me a lot of ways to go that I never would have had otherwise.

Thanks a lot just for reading this!! LOL!!


Hillbille, it looks like you're looking at the wrong script for your time lapse.  The whole point of this one is to be able to walk away from the camera, knowing it will begin shooting at exactly 11:20 a.m. next Thursday, for instance.  For RCAP is seems to me you'd just want one to start 3 minutes after you push the button, or however much time you expect to get to altitude.
A time lapse script that waits a certain time before starting, then shoots at a certain, fixed rate would be one of the simplest scripts to write, I'd think.  I haven't written a TL script, but I'd start with one of the simplest ones for CHDK and strip away ALL the input parameters and replace them with constants.  For instance, where the existing script might say:

@param a First shot Delay minutes
@default a 1

It would cause your scripting menu to show:

First shot delay minutes    [  1]

And wait for you to override that number with the one you want.  But if you always expect to start 3 minutes after you push the button, replace those input parameter lines with:

a = 3

(Later in the code that will be converted to milliseconds like this:

d = a * 60 * 1000

where d is a name I made up to mean delay.)

You could start with a very simple script and strip it down to fixed timings with no input at all, if you want.   Or have only two input parameters: First shot delay and Interval.
If your camera has a TV output, you can hook it up at home to use the TV as a display while you set the delays you want, then disconnect it and take it out to your airfield to start it blind.  You would only need to press the shutter to have it start taking pictures after that initial delay, and keep running until it lands and you press the shutter again to stop it.

Look through the simplest TL scripts here, find one that you think you understand, and strip it.  Or start from scratch.  You don't need much more than a Title, a beginning delay:

sleep d

and a shooting loop:

  sleep i
until 2 = 3

In the uBASIC example above "i" is the name I made up for Interval.  "sleep" always works in milliseconds, so you'll do the same kind of calculation we did above to convert from minutes (or seconds, or a combination) to milliseconds.
Every step between "do" and "until" will repeat until the statement after "until" becomes true, which in this case is forever, since 2 will never equal 3.  I put the "end" command in there, just because I thought I ought to.  The script will end when you walk up to your plane and press the shutter again.
Have fun.  Show us some pics.
If you really do need something more complex that a starting delay and an interval, please accept my apologies.  Still, look at the existing scripts and strip & customize one for yourself.  For the application I'm imagining, the few lines above are almost the entire script.
S3 IS with LensMate filter/hood adapter

kidtree - Yes I know pretty well what RCAP involves as I have been doing it for 5 years. I have had and used CDHK scripts for cameras a lot in that time. But that was NOT the point of the post. I ALSO do Time Lapse photography in OTHER situations and settings at other events and locations.

The portion of my post explaining about the RCAP was to explain that MOST of the P & S cameras (all Canon) I have do NOT have functioning LCD's.

Without the means to SEE a LCD and respond to queries it is IMPOSSIBLE to make correct inputs to a script ASKING for inputs.

Since I am a photographer - AND since I DO use my cameras for other events and in other (than RCAP) situations - AND since I do like THIS SCRIPT and want to be able to run it on the cameras I OWN - I asked the questions.

I felt that a little background information might help others to understand WHY I was wanting the changes.

Of course I WILL use the script as it is - or modify it (if I can without making it NOT run) to suit. I simply thought that the DOW (Day Of Week) might become a moot issue if a DOM (Date Of Month) were used. That may NOT work (and that being said) so I asked if there might be a way to "SET" the DOW's in the script ON a PC - so that it would then become a "default" setting and the DOW querie routine might be REM'ed out and then when the script is saved to the card it is "SET" with specific times for shooting ON specific days.

My thinking was that simple DATE(s) - 1 - 31 might be substituted in a "string" fashion for the DOW and hence the camera then literally WOULD be set for long term shooting as in shooting on the DATES specified at the times set.

The camera(s) already keep track of DATES and TIMES internally - so long as the correct date and time are set by the user.

This script WILL work - but it is just nearly impossible to run on one of my normal CDHK cameras that does NOT have a working LCD as when I power up the camera in the field ther is no way to read and input responses. I - like everyone else would like to have my cake and eat it too. I would like the script to allow me to "SET" all the variables and set all dates and times before I save it to the card so that when the script is RUN it merely follows "DEFAULT" data and waits and shoots WHEN it is scheduled. LOL!!


I think I just stuck my foot in it, hillbille.  I reread your message and realized you do want some of the complexities offered by this script, but want it to activate according to the day of the month, not day of week.  It's still a matter of simplifying what's here.  This script calculates the DOW based on the year, month and date.
Search the script for the subroutine

It's first line is D=get_time 3

That's the day of the month you're looking for.  The rest of the subroutine collects the year and month to calculate the DOW and calls it w.  If I understand, you just want to match D and the time, not w.

-- I started to post this & found you'd already replied.  Sorry. --
How about a select/case routine to be modified on the computer as needed:
select D
 case 4; gosub "do_stuff"
 case 5; gosub "do_stuff"
 case 6; gosub "do_stuff"
 case 7; gosub "do_stuff"
 case 8; gosub "do_stuff"
 case 11; gosub "do_stuff"
 case 12; gosub "do_stuff"
 case 13; gosub "do_stuff"
 case 14; gosub "do_stuff"
 case 15; gosub "do_stuff"
S3 IS with LensMate filter/hood adapter

Something like that might work,

I'll have to spend some time just fooling around with this no matter what I do so...

I have also thought of just REM'ing out the inquery routines and "setting" the calls. Much like the variables a - e - f - p - q - r and s are set now.

I have an event off in the future - October to be exact - that I will want this script working for. I am sure I can get what I want by then.

I have discovered that by just setting the times - and then saving it to my card - AND - letting it run, that if when the camera is started I can simply press "RIGHT" and "SET" blindly and it does work. The routines run fairly quickly so my timing must be just right to use this method - but it does work.  Only bad thing is that this "sets" it to run EVERY day at the times specified. Just a few extra shots that I can deal with.

Like I said it IS working and I can get it to work for me. What I need is to be able to "SET" the variables for the DOW's and I will just REM out the queries.

Calendar dates would be optimal for my purposes but at least it is workable. Like I said I just need to fiddle with it some.

kidtree - Thanks for the help! I do appreciate it. My "basic" language skills are about 40 years behind as I haven't played with any basic routines since the '70's and the days of Atari's and tape drives!! LOL!! Little rusty! That's another reason I hate "query" routines is that my eyesight ain't what it once was and I have a difficult time SEEing those tiny little screens even when they DO work!! LOL!!


I have now got MORE questions than answers!! LOL!!

I find that the last rendition of this script - will work just fine for me - as all that I need do is two inputs after start up and it runs and does exactly as intended.

So - it works and I WILL use it like it is.

NOW. My brain is such that I just cannot "let go" or shut off the thinking process for my idea. I am not smart enough to do what I can think though so I do need help still.

In this script there are lines that make "calls" to Get_Time.  Then runs a comparison of the camera time against the input start time and - follows the instruction.

Is there a string - line - routine that will/can go get and "print" the DATE in the camera?

If there is such a routine - then wouldn't a routine similar to the initial time input routine WORK to input a DATE and then a comparison to ensure the input is => than the internal date work?

Then - could separate routines for say at least 2 of these input dates with times be made. Then as the script runs it "looks" at routine 1 - and if the dates work - then it executes the times requested and shoots. If the dates do NOT work then it jumps to routine 2 and looks for the same - dates that work and if found then it executes the times for THOSE dates. The cycle through the dates section ends when there are NO dates AFTER the current date (in camera) and the script ends.

This would allow the camera to be "set" to shoot on ANY given DATE ahead of the date current in the camera. It would also allow for at least TWO separate shooting schedules as any DATE can be placed with different TIME sets for shooting.

I am just asking some questions - mostly COULD questions. If I had any knowledge I would know the answers myself but I don't. It just struck me that we CAN get the camera to tell it's current TIME easily enough - so - why not get the camera to tell us it's DATE too?


One limitation of UBasic is that the size of the script appears to determine the maximum number of input parameters the script can display - small scripts can have more than larger scripts. Due to the size of this script, only 8 parameters could be used.
Something does not seem correct here.  There is nothing in the code that "adjusts" the number of input parameters allowed AFAIK.   However, maybe its possible your overall script  is too large and uses too much memory ?  Reducing the declaration and use of those variables lowers the overall size ?
Ported :   A1200    SD940   G10    Powershot N    G16

(I decided to move the update on my construction time lapse to the appropriate thread) remaining quesiton is below.

I'm currently using manual focus mode so that shouldn't be a problem.  (some scripts have it so that it auto-focuses, then changes to MF and locks it to that value, which could be handy) Not really a question but something that might be cool to add. 

Question:  Is there a command I can add into the script to turn off the screen once the script has begun, and turn the screen back on once the script is interrupted?  I'd really like this thing to just be as "off" as possible, except just snapping a photo every 5 mins (might change it to 3 mins, still thinking about that) Just for the fact of less wear and tear on everything. 

Question:  Is there a command I can add into the script to turn off the screen once the script has begun, and turn the screen back on once the script is interrupted?
Ported :   A1200    SD940   G10    Powershot N    G16


Related Topics