Open source K3 intervelometer project

[Michael Collier]

I have a few months before my next film project, so I figured I would waste some time and build something easily buyable online. A k3 intervelometer (it will probably work with other cameras as well)

 

I figured I would start this thread early just to give others a chance to refine this products feature set and comment on the design as I get the damn thing working.

 

This is all about building a cheap intervelometer for my K3. To keep parts down I am using as much over the counter stuff as possible, and keeping the parts count down on my design.

 

Quickly to review the concept. Timer keeps track of the last frame exposed and how long until the next frame. Once the next frame is set to expose, some kind of accuator triggers the shutter release. There needs to be some sort of keypad to enter the time duration between frames. Unfortunatley there is no way to make the K3 expose for more than 1/30 of a second, so all that needs to be determined is the time between exposures.

 

For accuracy, timing will be accomplished with a 20mhz crystal, though pretty much any speed x-stal could work, I just found 20mhz surplus on the cheap. A microcontroler will control both the timing and display unit, as well as trigger the shutter release.

 

(proto board, working on display circuit/program)

 

for an actuator I bought a cheap surplus door lock actuator for cars. It seems to have a bit of power to it. I have only ran it at 5v so far and it has some kick, though I have no way to measure its output.

 

its rated to 12v so I assume it will be enough to trigger the shutter release. I am getting a cable release from my friend soon, so I can test it out at 12v. Also needed will be some sort of amplifier, since the microcontroller certainly cannot drive the actuator directly. Weather this will be a MOSFET, Relay or similar method, I cannot say yet. I lean towards mosfet to keep noise down (not critical, but the sound will be anoying enough)

 

(actuator)

 

Any other features you guys can think of that would be useful? I have been contemplating some kind of motion control to make pans/tilt moves over long periods possible (maybe even dolly/jib action?) Would it be of any use to have a footage counter to show the number of exposed frames during run?

 

Also one thing of concern to me, I read somewhere there is a slight light leak in the K3s shutter. Not enough to matter at most speeds, but past 1 frame every two or 3 minutes its enough to become visible. Is this true and if so should I make provisions to control a secondary shutter to cap the body between exposures? Any help would be great....especially in electronics or programing...hal I am looking at you.

 

Assumed parts list:

 

PIC 16F871 (might change, testing now with a PIC 16F84)

74LS47 BCD to LED driver

12 button keypad

2 PC mount buttons (run/set)

2 22pf capacitors

1 1K PC mount trimmer pot (display brightness)

1 20mhz crystal

3 common annode LED displays

battery?? 5 and 12 v required.

 

(pretty sparse list, I hope this will be cheap when its done. I think the cost of all those parts above is less than 20-30 bucks)

 

This will be the first of several open source projects and perhaps a few non-open source (if its a good enough idea, I might try and make money off of it) projects planned for the future:

 

K3 crystal motor

Remote/Motion Control crane head

D-mag for uncompressed SDI/HD-SDI capture in the feild

complete LED lighting solution (to replace HMI lights) along with digital set management controler

complimentary control units to integrate tungsten/HMI units into the DSMC.

[Nick Mulder]

Use an LCD and save on the BCD drivers and the segment displays ? Would work out about the same in terms of $$$

 

with a 16x4 you have heaps of room to display things like perhaps different modes and system feedback - ("I'm sorry Dave, but I cant do that" kinda stuff) - you could have ramps so the delay inbetween exposures (period-1/30 sec) could be multiplied by a percentage each frame for instance ... Have a sequencer of sorts so you can say go this speed for this many frames (or time, whichever you choose to work with) and then this many frames at this speed then this speed for this long etc...

 

Use a 4x4 keypad and you get the full 16 keys in the matrix instead of the 3x4 - ABC&D can be used for modes or 'go' 'stop' instead of the others you have there (yes, no?)

 

Mosfets are good as are SCR's - whichever is cheaper :lol:

 

Unless you are going for a complete PID closed loop servo system in which the intervalometer chip would just provide the step/dir I'd go with a stepper for pan, you can make your uP provide the wave steps pretty easy and drive it via a darlington array or similar (steppers that pull less than an amp at up to 35v or so) - tilt would need a grunty one unless you can rotate around the centre of mass, then dedicated stepper/servo drivers are the go...

Edited April 24, 2007 by Nick Mulder

[Luke Prendergast]

I know you're having fun, but if it's just doing a countdown then click, why not just use a $15 countdown timer, as used in the kitchen and for exercise routines? Some have a looping function. And it will be more chronometrically accurate than an off-the-shelf untrimmed crystal-driven PIC clock. And you don't have to build the thing. And it comes in a nice case. Photocoupler on the beep out...

 

Nick, an SCR doesn't turn off until the load current is interrupted, so would be no use here.

[Michael Collier]

Nick....I have a ton of LCDs around, and will probably be using some before this project is done...I just want to make things simple at first and build it up. I also had a bunch of 7447s around. As for the 16keypad...interesting idea. I will look into it. I just happend to have that keypad around (its not even matrixed. it has 13 active pins, so I need to multiplex it before running it to the PIC, or waste 12 IO lines) I figure it takes 5 minutes to set up and 5 hours to expose, so its more important to give ALL information easily rather than be easy to adjust.

 

I like the idea of ramping. The only problem I find with it is finding an easy way of defining ramps (having the chip read a LUT of delays is simple, but making a program to define those ramps, either in the box or in a computer thats later downloaded to EEPROm or Flash will take some thought.) I will get working on it.

 

Luke....yeah its all for fun. I have been out of the electronics game for so long, I forgot I needed to compile my assembly into hex before programing the PIC. I have ideas for some really revolutionary set products, but I need to get back into the hobby of electronics before designing anything serious. For so long photography took over my hobby time (basicly from when I was 13 or 14 until now) now photography and cinematography is a profession, and I need a hobby, so I figure go back to a good one that gets me thinking, and could be useful on set (see the in production for stormlife for an example of how its already helped)

 

The crystals should be plenty accurate. The ones I have are for some kind of high accuracy device (they are surplus) but they are +-10 PPM accurate, and the PIC crystal drive circut seems to be pretty reliable as long as you attach two capacitors of higher value than recomended (15pf is recomended at 20mhz, I am using 22pf. The oscilator takes a little longer to stabalize, but I have the power on timer set so should stabalize within 2-3 ms before the program starts running...i have that sort of time to wait.)

 

So yeah, its overkill, there are easier ways to do it, but hey, its all in fun. Im the sort of guy who would actualy design the machine that goes 'BING!' just for the hell of it.....hey come to think of it....

[Patrick Cooper]

Good luck on your endeavour on building an intervalometer for your K3. I admire your resourcefulness and your plan to keep things 'on the cheap.' However, the prototype does look like a bomb! You may have to be careful when using it for time lapse shoots near major buildings....!

[Nick Mulder]

I've read that about SCR's but for whatever reason that I've declined to follow up on so far I've managed to use them interchangeably with MOSFETs in all the cct's I've done so far - hence the mention... I'm not saying your wrong, just that I have a few of them lying around and have never had a problem with them for whatever reason (I'll keep it mind for the day it doesn't work though)...

 

Xtals should be accurate considering the application - whats a few mS this way or that when we are talking K3 intervalometer ....

 

I assumed it was a 3x4 matrix keypad ... 13 pins huh - sheesh! I have a 3x4 and a 4x4 here - the 3x4 outs are all screwy so you cant simply add a factor to the output and get the correct ASCII numbers like the 4x4 - hopefully if you go that way yours will be in the right order also - really useful for input and LCD feedback ...

 

I use the OOPIC (this flavor specifically)- its super easy to set up as it has pre-defined objects for LCD's and keypads etc... made the UI part of my intervalometer project much easier as I could concentrate on defining how the user would enter values and how they would be interpreted as the parameters to drive the outputs (it ran both SCR's and servos for both the Bolex EL and a hacked SB) - As the SB could run in 'T' mode the user could set period and exposure - it would flash at them if they entered void times (exposure>period for instance) and could be paused etc... I sorted ramping out for my own applications but never got round to making a UI for it as I started work on a stepper drive that will have much much more capabilities, turns out steppers are noisy little buggers so I've started playing with proper servo drives...

 

I really want to get into AVR's as this OOPIC business I feel is making me regress in terms of learning - and I am somewhat jealous of your naked PIC capability there, mine is all dressed up in fancy-pants stuff that dumbs it down a little... At the mo' I'm starting to learn LabView and have a USB-logic output card that works with it - I can make my own puder based intervalometer hopefully working alongside some sort of pre-vis software...

 

Also using video cameras to trigger film snaps via Max/MSP/Jitter is a plan - that way real world objects can trigger the action - I think even the OOPIC can be taught to read security cameras via some sort of farmed-out chip marketed for those maze bot competition types - need to research that

 

anyways, excuse the blabber! good luck with your project - I'll watch and see what happens and poke my beak in and chirp if I have any ideas, but as for the UI code its all in oopic language so it wont be any good for whatever compiler you are using ...