Hmmm. Okay, although the 10ms might not be a barrier, as long as the "right" 10ms are triggered?
Hmmm... How should that be done? There is always the USB between me and the camera clock making it virtually impossible to sync the cameras. I suppose the USB-ports are very inconsistent when sending and receiving this and that. However it will be okay for me to build the remote func solution.
...but I won't use a script waiting for the 5v drop but the remote function. I think it is much more accurate than a loop in a script. I had no problem changing the keyb.c as suggested by waterwingz. I tested that with one camera, at the moment I try to use the multicam.lua to adjust all the cameras from a single PC, works with three cameras now. Next week I will be ready to try with some mosfets (which will actually disconnect the usb-bus, as you suggested).
Clearly these cameras are capable of some very accurate timing, otherwise they wouldn't be able to produce such spectacular results, so now I think I need to figure out how they do it. Ideally it would be good to be able to combine some kind of free running hardware timer with the RTC time to give us the kind of accuracy we need.Time to start looking at the Digic hardware for our millisecond timings I think...
HeadInterrupt1HeadInterrupt2
HeadInterrupt1HeadInterrupt2HeadInterrupt3HeadInterrupt4
seconds nanosecs freq (hz) resolution---------- ----------- ---------- ---------- base ticks base secs base nsecs-------------------- ---------- ---------- %8.8ld %9.9ld %8.8d %8.8d
<snip>(ii) start [on all cams] a script to set / lock manual overrides (if desired) thenend script (iii) once the script has ended, disconnect connection between pc and usb hub networkthen(iv) turn usb hub network power off [to capture image to sd]then</snip>
I think what you describe is what we have been discussing all along,
with the additional note that at the end of step (ii) above, you need to initiate the shot somehow so that the cameras all get to the point in the shooting sequence where they wait for USB power to go away in step (iv).
Missing features os.clock: not implemented. Note this relates to CPU time used by a process, not time of day (which is handled by os.time and os.date) Time for a little more head scratching I think..
can that initiator be the last "command" in the script [just before it ends] ? what is it ?
...Using this setup and the switch closed, I was able to connect to my camera with CHDKPTP, go into shooting mode and issue a "shoot" command. With USB Remote enabled and sync enabled, this caused the picture shooting process to start but then wait on the USB 5V signal. I opened the switch and the picture taking process completed immediately. I was able to continue issuing commands to the camera - all I had to do next was make sure I closed the switch before the next shot.Using your pictured setup, you would have to make a ptp connection to each camera and issue shoot commands to each over ptp. If your microcontroller then opened the 5V line, all cameras would shoot at exactly the same time. Which I believe is exactly what you are looking for!...
you need to initiate the shot somehow so that the cameras all get to the point in the shooting sequence where they wait for USB power to go away in step (iv).
Started by mweerden « 1 2 ... 124 125 » General Discussion and Assistance
Started by jbaiter General Discussion and Assistance
Started by Peter Machtschuß General Discussion and Assistance
Started by andrew.stephens.754365 Hotwire! Hardware Mods, Accessories and Insights
Started by reyalp General Discussion and Assistance