Remote camcorder controller

On a sunny day (Mon, 02 Jul 2007 12:23:12 -0500) it happened George wrote in :

Long time ago I made a 'IR recorder', just used a par port pin of the PC, connected a photo transistor darlington circuit to it, wrote a small program for MSDOS, sampled the pin in a loop (written in C). Then recorded some key presses as files.

Playing back the files via an other pin and an IR LED did the same thing as pressing the remote keys. I used it to control my VCR from 'ceefax' (TV text service).

This will not work right with a multitasking system like Linux or Xp or Vista. But you could use a MicroCHIP P I C (NO I WILL NOT WRITE THE CODE FOR YOU), to replay the data into the LED. DOS in windows is also multitasking, remember, so you need a clean DOS to record, or do something with a micro with enough memory. IIRC sampling rate of some 100kHz for 1 second (save on / off as 8 bits in a byte) makes 12kB / second per button press, so 12 kB files for each button. I still have some C code under GPL somewhere if you must see it.

Thanks very much for the reply.

So, instead of trying to figure out the codes, you just recorded the raw output of the remote for the button in question, and then played it back as needed. Since my original post, I found one site that said the typical modulation frequency is 40K, and if that's true then the

100k capture rate should work just fine (as in 44.1k sampling to get 20kHz reproduction>.

Well as far as capturing the input is concerned, I could break out my trusty 286, and MS Assembler, and put something together. Or, even more strange, IIRC my old C64's CIA chip has a clocked serial shift register that would handle it, although I don't remember if it would be fast enough.

For output, I wonder if it could be done with a processor at all. If you store the 12k bytes in an eprom, you could use a counter chip and a clock signal and cycle through the needed address lines, then cycle through the data pins with another counter. Or better yet, just use a 128k CMOS eprom, and only use one bit of each byte for data instead of 8 - drive the output from d0. Does it sound like that would work?

Thanks again for your suggestions. I was making it more difficult than it needed to be. It reminds me of what a professional programmer told me when I was learning assembler - "Your mother need never know you used a lookup table."

You might want to take a look at this:

Thanks. I didn't know it was called that.

The problem is that there's no "shutter release" connector on the camera. At least not on the outside. I think all of the intervalometers are for cameras which have that feature.

On a sunny day (Mon, 02 Jul 2007 17:39:28 -0500) it happened George wrote in :

Yes, way to go :-)

I would consider rigging a kind of frame or mount or bracket that interfaces the intervalometer's shutter release to the button on the remote. There is a rod about 1/16" x 5/8" that pokes out of a little threaded pipe to release the shutter, then retracts into the pipe until next time. You can take a look at a remote shutter release or intervalometer at a camera shop to size up the job.

This saves you reinventing the intervalometer and reverse engineering the IR interface.

Even more simple:

The remote is powered by a 3V coin-shaped battery that slides in. If I can make a connector that looks like that, and drive the remote from an outside PS, then I can clamp the "Photo" button down, and just cycle the power supply.

Yep. That's gonna be the answer right there. :-)

(Don't tell Mom I used a lookpup table.)

Careful readers may recall that the original idea here was to get the camcorder to do time-lapse still photography, preferably by duplicating the function of the Photo button on the remote control at a set interval.

I wanted to report that the idea I described above in the last quoted section did not work. It appears the remote will not transmit anyting if a button is already depressed when it powers up. This was a surprise since I assumed there was no power to the circuit until a key was pressed - in other words, the key press not only identifies which function is wanted, but also provides power to the circuit. But I tested it several times, and if power is applied first, then the key pressed, it transmits normally, but if it's done in the opposite order, nothing happens until you release the button and then apply it again.

So, I ended up using an old solenoid from my junque box to rig up a button pusher for the remote. Not exactly an elegant solution, but it works ok.

I still like Jan Panteltje's idea of "recording" the remote's transmission by sampling it at 100k. That would be nifty because then you could do other things the remote does, like zoom, etc., in any desired programmed sequence. Maybe someday when I have more time, I'll come back to that idea.

Thanks for everyone's help.