(a) because no trap is encountered it is the variability between cameras subsequently getting focus / exposure that causes the loss of "synch enabled" levels of synch between them ?
(b) with a missing "wait_untill_remote_button_released" hook should both OnePush with either:Synch enabled orSynch disabled act in exactly the same fashion ?
(c) if the cameras had native Canon Manual Mode / Manual focus, and were in those modes, should the focus/exposure "period" of all cameras be approximately zero and thereby effectively re-instating "synch enabled" levels of synch (even in absence of the hook) ?
or is there other "stuff", e.g in "shooting.c", i'm not thinking about yet ?
I'm currently interested to identify a work around to the apparent lack of "OnePush/Synch enabled" on the SX150IS first reported here http://chdk.setepontos.com/index.php?topic=11667.msg118374#msg118374 Fmi, a further description: http://chdk.setepontos.com/index.php?topic=7127.msg112154#msg112154
Quote from: andrew.stephens.754365 on 18 / November / 2014, 10:59:43or is there other "stuff", e.g in "shooting.c", i'm not thinking about yet ? Yes there is other stuff. But it's not in shooting.c - it's just the normal overhead in the camera shooting sequence
The script I posted above will not do "precision" sync as written. Enabling the USB remote sync menu option makes no difference in this case. Variations between cameras of as much as 100 mSec are quite possible.
Okay - it looks like the scripting shoot() command is treated exactly the same was as a real shutter button press (i.e. the sync delay code does nothing).
Quote from: andrew.stephens.754365 on 18 / November / 2014, 10:59:43I'm currently interested to identify a work around to the apparent lack of "OnePush/Synch enabled" on the SX150IS first reported here http://chdk.setepontos.com/index.php?topic=11667.msg118374#msg118374 When I get a minute, I'll take another look at that.
I'm currently interested to identify a work around to the apparent lack of "OnePush/Synch enabled" on the SX150IS first reported here http://chdk.setepontos.com/index.php?topic=11667.msg118374#msg118374
PS: I'm really just trying to use this as an example to see how much of this I really (sort of) understand. For info, I think SX150IS has a mechanical shutter but not 100% sure and don't know if that may be significant w.r.t variability anyhow.
Quote from: waterwingz on 18 / November / 2014, 14:05:33Quote from: andrew.stephens.754365 on 18 / November / 2014, 10:59:43I'm currently interested to identify a work around to the apparent lack of "OnePush/Synch enabled" on the SX150IS first reported here http://chdk.setepontos.com/index.php?topic=11667.msg118374#msg118374 When I get a minute, I'll take another look at that.Thanks.
" BL wait_until_remote_button_is_released\n" // Added (not tested) -------->
Okay then, I will make one last try to explain this.
Bear in mind as you read this that really good sync for 3D stuff requires less than 1 mSec difference between cameras.
When you use a CHDK USB remote with sync enabled to take a shot, the camera goes almost all the way through its shooting sequence - way past where it checks focus and exposure setting - until right before it releases the shutter. And then CHDK stops it there are holds, waiting for the USB voltage to go away. If two or more cameras all wait at the same point, then they will all tend to release their shutters within 1 mSec of each other once the 5V is removed. If they are not waiting at the same exact place when the trigger signal occurs, then even with focus and exposure locked, they will be off doing something else and will not releases their shutters within 100 mSec of each other (on average).
However, even that sync is not guaranteed as an interrupt could occur after the final sequence is released, causing one or more cameras to be delayed in releasing their shutter. On many recent cameras, this occasional delay can be over 50 mSec and happens more often than not. So some additional code (precision sync) is available on some cameras that attempts to work around any interrupt and give better sync.
Sorry, you seem to want to keep quoting me and rephrasing my words to convince yourself that you will somehow get good sync without the sync (or precision sync) code working.
Go ahead then - try it.
Just because you read that DSLR's can lock their shutter and focus and get 10 mSec sync does meant that Canon P&S cameras can also do that.
Feel free to hookup an oscilloscope or other test instrument and test for yourself. You asked the question and I answered it as best I can.
I assume you actually have this camera and can test an update file?
So my conclusion from all of this is as follows. If you pound away at get_usb_power() in a tight loop in Lua, it's possible to add so much processor load that the underlying code in the kbd.c task does not actually monitor the USB power status every 10 mSec. Different cameras seem to run scripts at different speeds so the magnitude of the error will change.
If the loop actually yields every iteration (I haven't traced through Andre's code to make sure) then there's really no chance that the Lua script is causing too much load.
I assume that get_usb_power() does not explicitly yield.
Edit: related to earlier conversation-Quote from: waterwingz on 28 / January / 2014, 19:47:09So my conclusion from all of this is as follows. If you pound away at get_usb_power() in a tight loop in Lua, it's possible to add so much processor load that the underlying code in the kbd.c task does not actually monitor the USB power status every 10 mSec. Different cameras seem to run scripts at different speeds so the magnitude of the error will change.---Quote from: reyalp on 28 / January / 2014, 23:52:44If the loop actually yields every iteration (I haven't traced through Andre's code to make sure) then there's really no chance that the Lua script is causing too much load.---Quote from: waterwingz on 29 / January / 2014, 00:12:51I assume that get_usb_power() does not explicitly yield.
Taken somewhat out of context ( i.e. there turned out to be more to this story)
The resolution of all these questions & mysteries about accuracy of USB pulse width measurements turned out to be the difference between measuring in shooting mode vs measuring in playback mode. I had done my detailed testing in playback mode and the jitter and variation in pulse width measurement proved to be minimal. Once I finally realized that camera CPU loading goes through the roof in shooting mode, it was clear that the CHDK hooked tasks do not reliably run at 10 mSec intervals in shooting mode - it is frequently much longer. Which explained why the pulse width measurement accuracy on some cameras was so bad (in shooting mode).
And incidentally, it also explains why there is no hope of getting under 10 mSec sync without USB sync enabled, regardless of what the processors on Canon DSLR's are purported to do.
For all situations, other than what follows, both ptp synch and usb remote (synch not available) would probably be sufficient.
Quote from: t.beauchant on 03 / August / 2014, 17:50:06I'm not sure what you are refering to when mentionning the 'shoot hooks', could you point me to some documentation?http://chdk.wikia.com/wiki/Script_Shooting_HooksBasically a way to have a script start a shooting sequence and then halt it just before the actual shutter opens while it waits for some event ( like a PTP "complete the shoot" command).
I'm not sure what you are refering to when mentionning the 'shoot hooks', could you point me to some documentation?
Quote from: t.beauchant on 03 / August / 2014, 17:50:06I'm not sure what you are refering to when mentionning the 'shoot hooks', could you point me to some documentation?See the link waterwingz posted. Not that just using the message system to trigger a shoot_full should be within a few tens of ms of physically clicking the shutter, shoot hooks would only be required if you need to do better than that.The rsint command and multicam modules in chdkptp both have examples of using shoot hooks and the message system.Using the CLI shoot command or sending shoot() is much slower, since it does the whole focus / preshoot process. If you start and connect a chdkptp process for each shot that adds further delay.
Quote from: andrew.stephens.754365 on 18 / November / 2014, 10:59:43(a) because no trap is encountered it is the variability between cameras subsequently getting focus / exposure that causes the loss of "synch enabled" levels of synch between them ?YesQuote(b) with a missing "wait_untill_remote_button_released" hook should both OnePush with either:Synch enabled orSynch disabled act in exactly the same fashion ?Yes
Started by OralDouglas Hello, I'm a NEWBIE - HELP!! (Newbies assistance, User Guides and thank you notes)
Started by jls3512 Hello, I'm a NEWBIE - HELP!! (Newbies assistance, User Guides and thank you notes)
Started by Blooper « 1 2 » Creative Uses of CHDK
Started by Alarik « 1 2 ... 12 13 » General Discussion and Assistance
Started by cameraman Creative Uses of CHDK
