Great stuff mphx - this
will be better than last !
Edit:
PS: i can link you the footage from yesterday's live if you like people , but its a greek tv show and i don't know if you will understand anything 
Please do (i'd love to see it at least:
"Leonidas (the return, value)" 
- maybe reyalp, WW (if they started to charge) & you could buy the Hellenic Republic shortly, or Santorini
https://www.youtube.com/watch?v=hVkA7G33EGk at least (that'd do)!!).
OtherUntil today I had been thinking that programmatic ptp synch is now the way to go (and maybe it is based on mphx's latest post) - especially if tight synch is not an absolute requirement because of shooting in a black room using flash. However, it just struck me that multicam.lua (or the logic of parts of it) has been developed to a state which means the following quote may no longer be such a big deal - with respect to loss of ptp comms at a point in a
usbremote enabled process which I describe, or perhaps re-describe, in more detail below:
If you want to use CHDK's USB remote "sync" feature, you need to be able to disconnect the 5V "red" wire to all 80 cameras at exactly the same time. If you don't want to lose USB communications, then you can't simply turn off the power to all the hubs (even supposing that causes the individual cameras to all see the power go off at exactly the same time).
If you can make reyalp's calibrated sync shooting mode in multicam.lua work acceptably then you are spared the pain of trying to switch the hubs. Note that your earlier tests on two cameras don't tell you what will happen with 80 cameras - the sync error is not 80x(two camera sync error). It might actually be okay for your application.
...i.e. maybe it no longer necessarily matters to workflow if ptp comms is lost at a point in the following sequence of steps:
USBREMOTE processi.e with
- Remote Enabled / OnePush / Synch Enabled
the kbd.c hack in place incorrect, the kbd.c hack is not needed as continuous ptp comms is unimportant the kbd.c hack in place- a full usb powered hub network in place (between workstation and cameras)
then:
in the morning, when power is first applied via a single (mains power) switch to the hubs (&all Camera 5V USB line), wait for the 10 (or 20 seconds?) Remote Onepush timeout to occur - no shot.
then:
START:for cameras with full "M"anual control (SX150IS - Mode Dial set to "M"), run some multicam type code to:
(i) capmode change to AUTO Mode (ii) set zoom & (iii) autofcus & then (iv) capmode change to Manual Mode and Manual Focus (v) & finally stop any long running chdkptp initiated camera script
then:
if necessary, physically tweak focus on cameras.
then:
run some multicam type code to:
set Canon (i) shutter period (ii) aperture for correct
upcoming blackroom/flash shoot exposure (iii) & finally stop any long running chdkptp initiated camera script
then:
physically disconnect the usb network connection between workstation & first powered hub -->
PTP comms lost here – but no script running on camera anyway
turn off single mains switch power to hub network --> (but no impact to camera settings – correct? since cameras in Manual mode & MF & the prior One Push remote timed out)
then:
turn on single mains switch power to hub network (
shoot-half) --> but cameras have zero focus/exposure work to do(or, at least, very little work to do?)
then:
within 10 (or 20 secs?) - but preferably near instantly so not to annoy subject pose - turn off single mains switch power to hub network (
shoot-full)...also interface from the usb mains power switch the switch to turn-off room lighting / setup flash at this point (can tweek USB remote delay to fit in with this)
then:
physically connect the final usb network connection between workstation & first powered hub, turn on single mains switch power to hub network, wait 10 (or 20 seconds?) for OnePush timeout period to expire
then:
run multicam type script in order to download last image / cleanup
then goto
STARTApologies for the slightly long winded description - does the flow seem, 5V decay voltage uncertainties aside, like a possible way round "last leg" 5V switch building / programmatic ptp uncertainties ?
If this approach is feasible, perhaps "Hardware-Hackers" hacked hubs could ease the voltage decay issue?
Or perhaps it is just a lot more hassle than switching out the last leg of the 5V with relays or programmatic ptp shooting
All that aside,
I just downloaded a 1.3 chdk from
http://mighty-hoernsche.de/trunk/ (sx150is-100a-1.3.0-3721-full) and used the multicam code in this present thread to upgrade my old, locally built, chdk i.e no kbd.c hack (SD card reader in laptop died
).
Problem is, with Remote Enabled / OnePush / Synch Enabled the camera acts exactly like this:
There is one thing I don't get:
"If the Enable Sync option is set in CHDK then each camera will wait for the final transition of the USB signal ( 5V to 0V )."
It seems just to be the opposite, with Sync enabled my camera takes a shot immediately when it gets 5V on the usb port and as reslult the camera's are not in sync. (elph300hs, one push, normal control mode)
With sync disabled** it works as I would like it takes the shot as soon as the 5v is switched off, just like the inverted remote script.
**Tested in M/ AUTO /P - even when 5V turned off after 60 secs
Any chance a kind guru could comment on or, even better, fix the "capt_seq.c", e.g.
http://chdk.setepontos.com/index.php?topic=8810.msg92334#msg92334, if that is the problem ?PS: if everything was sitting waiting for the shot, as described, in M mode
(having got there through capmode) and in MF should the OnePush period (after reaching 5V) to attain "lock" be practically zero (since, in my mind, the camera doesn't need do much of anything) ?
