This is a circuit I was hoping I would not need to build. Guess I have to :-(
I am putting approx 60-70 cameras in series - http://chdk.setepontos.com/index.php?topic=4103.0
For a film - www.mishra.tv
To film some gymnasts.

The camera is running CHDK firmware and is triggered with a 5V pulse. I want each camera to have a 10ms delay over the previous one.
So, if C1, C2 ... Cn are cameras
and D1, D2, ... Dn are delay circuits
and Pulse denotes the ON trigger pulse (just a simple switch I will turn on and off)

The circuit is
Pulse --- D1-C1---D2-C2--...--Dn-Cn

I looked at a simple RC circuit with a relay on the end. However, I am not sure about the relay driving another RC-Relay circuit.
Then I thought of a 555 circuit - then I figured out that the size of the circuit would mean lots of soldering (when you consider 60-70 circuits).

Is there an IC available that is preprogrammed for a 10ms delay ? Easy enough to solder it to a really small board, solder inputs, solder outputs and on we go.


Just hoping for ideas!

EDIT:- My earlier thought was to do it in software. But I would need to program each camera with a different delay. And the setup would cause problems if I rearrange cameras or add new cameras.

 

Just some thoughts;

- Using the Canon point and shoot models in my opinion is a huge waste in quality compared to the effort.
- Software control would give you infinite flexibility opposed to fixed hardware components.
- you would be much further ahead to transport an HD movie capable camera along the targets pathway.

 

70 old Canon P&S cost me about 3K off ebay.
For that price I would get maybe 1 HD camera that can be tethered (max 2).

The P&S cams are my cheapest option. The only one.

 

I had opened a thread over 2 years ago. This is the one. http://forum.allaboutcircuits.com/showthread.php?t=19665

To reply to the last questions :-
How precise does your delay have to be?
10ms precision

How wide is the pulse?
100ms per camera. Input can be held high as needed.

Does the pulse repeat?
Nope. 1 pulse activates C1, which propagates to C2 then to C3.

If so, what is the frequency (repetition rate)?
No repetition. The delay circuits D1..Dn are initially open and then stay closed to allow the voltage to trigger to the next one.

 

A 50Hz clock to cascaded 4017 (See Page 6) decade counters could be used, each output would go high for 20mS, then go to the next one. You'd need to chain several together, but it may be a working idea if you understand what the datasheet says.

 

Thatoneguy's suggestion is the simplest I can think of, except you would need a 100Hz clock for 10mS delay, and if you truly need each camera's pulse to be 100mS wide, you would also need a oneshot before each camera. In that case, it might be just as simple to use a 556 (dual 555) and do the delay and the oneshot at each camara, and daisy-chain them, which is, I think, your idea from ypur first post.

What is the physical spacing of the cameras?

 

after reviewing some of your links I see what your doing. Personally, I'd be researching hard to find a software timing solution. Possibly a common trigger with programmed delay within the cameras, or multi triggers. I'm just thinking that the extra work up front would make it the results so much more rewarding.

If you were thinking of daisy chaining hardware, maybe comparators set at step intervals, or counters decoding each successive pulse, or something that gives you external control on timing.

 

Wow. Great to have such responses.

@GetDeviceInfo I am also looking at using Arduino or a similar PIC with a shift register in front of it. Its a matter of comparison in the end. I used it once by hardcoding each camera with a n*10ms delay. I guess I could still do this, except you need to remember the location of each camera and number it properly. Its a pain but easy to do. Who knows - I might just do it the old way in the end.

@Ron Each camera will be on an individual tripod. So I'd say about 50 cm spacing per camera. Also, the pulse needs to be a min of 100ms. Does not need to be precise - just the same width for each camera. I'm going to google 556 oneshot circuits.

@thatoneguy I looked at the spec. The output is approx 1 pulse width wide. For a 100 Hz clock, I get 10ms output per pin. I would need something else to increase it to 100ms.

 

I will have to research the 556 solution as I need a voltage stabilizer before EACH camera for the power anyway.
Just a simple job to have a slightly larger pcb and wire the remote cable to it too.

 

I would use the microcontroller and a string of 74HC595 serial-in parallel-out 8-bit shift registers. You will need 9 of these shift registers in the string, as 70/8 = 8.75 shift registers.

Use RC networks on the appropriate inputs to clear the shift registers and hold the outputs disabled momentarily on power-up to initialize the '595 shift registers to known states to prevent inadvertent camera firing. 10k resistors and 0.1uF caps should be OK.

To start the sequence, hold the data input to the 1st shift register high, and issue 10 clocks, 10mS apart, then hold the data input low and issue 69 more clocks, 10mS apart. Each camera will see a 5v input pulse that is 100mS wide, and the pulses will be shifted by 10mS, just as you stated you need. This solution makes it pretty simple to pre-program the exact delay(s) you wish into the microcontroller.

All of the clock inputs are tied together.

QH of the 1st '595 is daisy-chained to the serial in of the 2nd '595, and so fourth.

Note that each IC requires a 0.1uF bypass cap across its' Vdd/GND pins.

 

I'm guessing that your 'trigger' pulse needs to be a minimum 100ms, but can be any duration beyond that?

 

I'm guessing that your 'trigger' pulse needs to be a minimum 100ms, but can be any duration beyond that?

I have Canon cameras, and anything under about 1/2 second only takes a single photo. If you hold it down longer, it will take more photos, but that can be disabled.

Short answer: Yes, if all the cameras are configured for single shot.

Thinking of SCRs?

 

I would use the microcontroller and a string of 74HC595 serial-in parallel-out 8-bit shift registers. You will need 9 of these shift registers in the string, as 70/8 = 8.75 shift registers.

Use RC networks on the appropriate inputs to clear the shift registers and hold the outputs disabled momentarily on power-up to initialize the '595 shift registers to known states to prevent inadvertent camera firing. 10k resistors and 0.1uF caps should be OK.

To start the sequence, hold the data input to the 1st shift register high, and issue 10 clocks, 10mS apart, then hold the data input low and issue 69 more clocks, 10mS apart. Each camera will see a 5v input pulse that is 100mS wide, and the pulses will be shifted by 10mS, just as you stated you need. This solution makes it pretty simple to pre-program the exact delay(s) you wish into the microcontroller.

All of the clock inputs are tied together.

QH of the 1st '595 is daisy-chained to the serial in of the 2nd '595, and so fourth.

Note that each IC requires a 0.1uF bypass cap across its' Vdd/GND pins.

I really like this idea. The main shortcoming, as I see it, is the amount of cable required. At 50 cm spacing, and with the cameras in a straight line, the line will be 35 meters long. If you put all the electronics at the midpoint of the string, you would need over 600 meters of cable.
I guess you could distribute the shift registers, spacing them about 4 meters apart, but it would probably make clocking difficult, and would still require a lot of cable.
A modification would be to put one shift register stage (a D FF) at each camera, with the clock daisy-chained and buffered by Schmitt trigger transmitters and receivers. The signals and power could be carried between modules on flexible ground plane cable.
See schematic below.

If this is a dumb idea, my excuse is it's late.

 

Excellent point about the cable lengths, Ron - I'd completely overlooked that.

But, it would be quite an expense/chore building 70 of the circuits you propose, and reliability would be dubious at best, even if built by pros. I'm afraid that the MTBF (mean time between failures) would not be acceptable.

Perhaps the '595 idea could be used on 9 separate boards as you mentioned, using line drivers/receivers over twisted pair for the clock and data signals; our OP might use Cat-5 cables for interconnecting the boards; as they would minimize the chance for glitches to occur. That would also leave two pairs for Vcc/ground connections.

 

The flat cable I proposed has a built-in ground plane.
There are no signal currents that have to travel down the daisy chain. With buffered signals, the maximum signal path length is 50cm. CD40106 transition times are slow enough to not cause reflections at this line length.
For future applications, the system is modular at the single-camera level.
I don't see any problem with MTBF. As you said, the need to build 70 circuits and 70 flat cables is a negative.

 

Any idea what the MTBF is for 4000 series CMOS? I tried some quick searches but didn't come up with much.

Anyway, just roughly:
since the flip-flop/inverter concept has two CMOS IC's on one board, and if we just assume that such IC's might have a MTBF of 100,000 hours (~11.4 years) after burn-in, and the board depends on both ICs being functional, then the MTBF would be 1/(1/100,000*2) hours, or 50,000 hours.

For the entire system to work, you'd have to have all of the boards functioning, so then you wind up with 1/(1/50,000*70) = ~714 hours. That's actually not as bad as I originally thought, but then again, I don't know what kind of MTBF those IC's are actually rated for; I haven't looked for that kind of info in awhile.
[eta]
Found some info on TI's site in the quality section - they seem to think that since they tested 4,016 CD40106BM's for 1,000 hours with no failures, that the MTBF is 3.68 x 10E8. Why is it that I have a hard time believing that? I mean, 408,396.1 years?

 

Sarge,

I found this on the net and it has the MTBF of some components ... it might be useful for a rough idea of the various devices.

The other pdf talks about metastability.

OnSemi has a reliability calculator for their products ... you can look up each part number and choose from 60% to 99% and get the MTBF ... visit http://www.onsemi.com/PowerSolutions/reliability.do

 

Found some info on TI's site in the quality section - they seem to think that since they tested 4,016 CD40106BM's for 1,000 hours with no failures, that the MTBF is 3.68 x 10E8. Why is it that I have a hard time believing that? I mean, 408,396.1 years?

Mr Schmitt's fame will outlive the entire human race!
Actually, I suspect that the least reliable parts of the system I described are the interconnects between the boards and the cables. I'd still be willing to consider it, though, if it were my project.

 

Thanks, Joe - but even then, OnSemi's 99% data for an MC14013Bx gave me around 25.4k years for 99% reliability for the die. We'd have a long wait to find out if that's accurate.

 

A bigger issue might be the MTBF of 70 used cameras. If one dies, sure, you can replace it easier than you could one of the circuit boards, but that presupposes that the same type of camera is still available.
This brings up another question in my mind. How many times will this system be used? If it will only used a few times, MTBF is moot.
I also have a couple of other questions:
I wonder if 70 used cameras will all have the same color balance, etc. (I am not a camera expert). I suppose you could correct them with software, if necessary.
I am wondering if the cameras are really in a straight line. If they are intended to track a moving object, it would be moving at 50m/sec. To us hicks here in the USofA, that's about 112mph. I guess I don't understand what the goal is here.