Tip: Disable WYSIWYG editing in your forum profile under look and layout. The bbcode tags are quite easy to use.
Cheers.
I don't understand precision sync code very well
In essence (simplified) [edit: I think
] ,
vnd examines the current instant count (which is within a "normal" standard period count) at usb switch release and extends the subsequent period to:
2xstandard periods counts + count at switch release
At 40ms progression within this, subsequent, extended count, Canon code examines the instant count value and (so long as the count value is greater than a fixed "critical" number , please see detail below) the exposure always starts at the end of the "normal" standard period following the extended period (otherwise, exposure begins at end of this extended count).
As an example, if the standard period end count value is 100 and that equates to 33ms then the subsequent extended period count will be:
2 x 100 = 200 counts (+ count at switch release)
vnd assumes that:
(i) a standard period is always less than 40ms (but > 20ms).
(ii) the "critical count" is less than the maximum count of a standard period
Therefore, the critical count value is always surpassed at 40ms progression into the extended period count and the exposure always begins, from switch release, at:
counts remaining to end of standard period (in which switch release occurs)
+
count at switch release + 2xstandard period counts (i.e. this is the extended period)
+
1 x standard period count (i.e. this is the one following the extended period)
This is a total value of 4 x standard periods i.e. 132ms in our example.
However,
vnd's code, infrequently, produced early exposure "outliers" (by a value of a single standard period). Phil examined those early outliers and proposed a solution here:
https://chdk.setepontos.com/index.php?topic=13363.msg136293#msg136293 My own 1000 stereo pair test here, which included Phil's code change, seems to infer that precision sync (without the single standard period outliers) has been solved
https://chdk.setepontos.com/index.php?topic=13363.msg136349#msg136349The ~10ms hand-off part should actually be easy to fix now, by replacing the dumb 10ms wait loops to a proper synchronization object like an event flag. The necessary functions should all be in the sig finders now, which wasn't true when the feature was initially implemented. This would probably reduce the risk of other stuff being scheduled in the hand-off too.
Interesting (although i'm not yet capable of attempting).
Other:
Although i'm currently only investigating wired usb sync, could it sometime (for testing) be fairly straightforward, for ptp sync, to change multicam.lua/usb_sync.c (& anything else needed) to provide a choice between hook_shoot.continue only or for that followed by precision sync?
Also,
i'm scratching my head - could there be a straightforward reason why the blue (no sync) exposures occur
after the red sync exposures in waterwingz test of December 2013
https://chdk.setepontos.com/index.php?topic=8312.msg107601#msg107601 (vnd's precision sync seems to have been added in January 2014).
Thanks for all those other clarifications.
