supplierdeeply

USBremote - sync test issue

  • 21 Replies
  • 1319 Views
*

Offline reyalp

  • ******
  • 11592
Re: USBremote - sync test issue
« Reply #10 on: 23 / October / 2017, 13:08:09 »
Advertisements

just continues the shooting process, after
hook_shoot.continue(), never entering the tight loop which monitors the fall of the 5V->0V on the usb line ... seems obvious (since there's no 5V line involved) but I have to ask? ::)
The relevant code is:
https://app.assembla.com/spaces/chdk/subversion/source/4002/trunk/core/usb_sync.c#ln82

In every shot, the capt_seq task hits wait_until_remote_button_is_released at some point in the shooting processes, near where the exposure would start in Canon code.

wait_until_remote_button_is_released first checks if hook_shoot is set. If it is, capt_seq waits for continue to be called or for the timeout to be hit.

It then checks for hardware remote settings that would require it to wait for the remote. If they are set, it waits for the hardware remote with a 10 second timeout.

So you could use both, waiting for both the hook and hardware remote, but the situations where this would be useful are probably limited.

Quote
i.e. the time between the hook_shoot.continue and the start of exposure (over many repetitions) is likely to have much greater difference (between the lowest & greatest of those times) than the variability reported here (camera dependent), for the red "sync" case, between the fall of the usb line to 0V & exposure start:
The difference is due to the imprecision of the timing available from script (both get_tick_count() and sleep() only have ~10ms precision), and the time required to hand off from kbd_task where the script runs to capt_seq where shooting happens.

https://chdk.setepontos.com/index.php?topic=8312.msg107601#msg107601

Quote
In that experiment:
sync variability was, say 62-40 = 22ms
&
no sync variability was, say 106-78 = 28ms

Or, could the inclusion of the hook_shoot.continue be expected to improve upon (or worsen) the 28ms "no sync" variability?   
IMO, testing would be required to answer that question with any confidence. My expectation is that hook_shoot should provide better sync than without, but it's possible the overhead negates the benefits. This results are likely to be port specific.
Don't forget what the H stands for.

Re: USBremote - sync test issue
« Reply #11 on: 23 / October / 2017, 14:34:01 »
Thanks for all that - very thorough explanation.

So you could use both, waiting for both the hook and hardware remote, but the situations where this would be useful are probably limited.


For the record and anybody following along sometime, at one point that was considered a very possible use case:
https://chdk.setepontos.com/index.php?topic=12219.msg134721#msg134721

Re: USBremote - sync test issue
« Reply #12 on: 29 / November / 2018, 15:16:31 »
Edit: horizontal rules removed from comment

...[]...
IMO, testing would be required to answer that question with any confidence. My expectation is that hook_shoot should provide better sync than without, but it's possible the overhead negates the benefits. This results are likely to be port specific.

(Apologies for horizontal rules in what follows- found the format practically impossible to read without them and it's still a mess)

Having reviewed this thread yesterday I realise I probably still don't fully understand all that is involved here. The query is related to ptp trigger.

In attempt to pin it down some more:

If multicam.lua (currently 841) https://app.assembla.com/spaces/chdkptp/subversion/source/HEAD/trunk/lua/multicam.lua#ln1394
Code: [Select]
hook_shoot.continue() executed (somehow, by miracle) at exactly the same real world ms instant on a large number of A1200 could we then expect a (very) similar variation of shutter opening times (from hook_shoot.continue instant) as the red  hardware remote "sync" distribution (from usb 5V->0V) displayed in waterwingz test results here https://chdk.setepontos.com/index.php?topic=8312.msg107601#msg107601
?                           
(I think the red graph in that experiment simply waited for switch to be released but did not change timing period).

If not, since the circumstances of my description have nullified the effect of both get_tick_count() and sleep() re:
The difference is due to the imprecision of the timing available from script (both get_tick_count() and sleep() only have ~10ms precision), and the time required to hand off from kbd_task where the script runs to capt_seq where shooting happens.
is the remaining difference only because of the remaining hand-off time between kbd_task where the script runs to capt_seq?

If the only remaining discrepancy above is due to the kbd_task / capt_seq[/size] handoff, please ignore that in this follow-up...

If that is true (i.e. red graph equivalence) then in a second experiment in which hook_shoot.continue again (miraculously) occurred at the same real world ms instant on all cameras but instead now (somehow) immediately continue by executing vnd's precision sync code (i.e. reconfigure code so that there is no remote wait) beginning sync.c 5062 at line 112 https://app.assembla.com/spaces/chdk/subversion/source/HEAD/trunk/core/usb_sync.c#ln112 ) would we then expect the resultant sync distribution to be (very) similar to that displayed in waterwingz test diagram "Precision sync" green distribution
?

There's at most ~10ms between hook_shoot.continue() and the camera being in the hardware remote loop
Is this due to the kbd_task / capt_seq handoff?
« Last Edit: 01 / December / 2018, 16:33:28 by andrew.stephens.754365 »

*

Offline reyalp

  • ******
  • 11592
Re: USBremote - sync test issue
« Reply #13 on: 29 / November / 2018, 22:51:23 »
(Apologies for horizontal rules in what follows- found the format practically impossible to read without them and it's still a mess)   
Tip: Disable WYSIWYG editing in your forum profile under look and layout. The bbcode tags are quite easy to use.

Quote
Code: [Select]
hook_shoot.continue() executed (somehow, by miracle) at exactly the same real world ms instant on a large number of A1200 could we then expect a (very) similar variation of shutter opening times (from hook_shoot.continue instant) as the red  hardware remote "sync" distribution (from usb 5V->0V) displayed in waterwingz test results here https://chdk.setepontos.com/index.php?topic=8312.msg107601#msg107601
?
+/- the handoff overhead.
Quote
is the remaining difference only because of the remaining hand-off time between kbd_task where the script runs to capt_seq?
Pretty much. Your "miracle" removes the uncertainty due to clock sync and the fact that lua sleep and get_tick_count() only have 10ms precision, leaving the hand-off as the remaining difference between hardware remote and shoot hook.

Quote
If that is true (i.e. red graph equivalence) then in a second experiment in which hook_shoot.continue again (miraculously) occurred at the same real world ms instant on all cameras but instead now (somehow) immediately continue by executing vnd's precision sync code (i.e. reconfigure code so that there is no remote wait) beginning sync.c 5062 at line 112 https://app.assembla.com/spaces/chdk/subversion/source/HEAD/trunk/core/usb_sync.c#ln112 ) would we then expect the resultant sync distribution to be (very) similar to that displayed in waterwingz test diagram "Precision sync" green distribution
?
I don't understand precision sync code very well, but there shouldn't be a substantial difference between reaching that point of the code from hook_shoot.countinue() or the remote. hook_shoot.continue() causes that code to proceed from line 99.
Quote
There's at most ~10ms between hook_shoot.continue() and the camera being in the hardware remote loop
Is this due to the kbd_task / capt_seq handoff?
Yes, though the "at most" is probably not strictly correct. The Canon firmware could schedule another task that executes for more than 10ms while kbd and capt_seq are both sleeping.

The ~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.
Don't forget what the H stands for.


Re: USBremote - sync test issue
« Reply #14 on: 30 / November / 2018, 06:55:11 »
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#msg136349


The ~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.
« Last Edit: 30 / November / 2018, 16:37:13 by andrew.stephens.754365 »

*

Offline reyalp

  • ******
  • 11592
Re: USBremote - sync test issue
« Reply #15 on: 01 / December / 2018, 00:06:15 »
this is a total value of 4 x standard periods i.e. 132ms in our example.
So, ignoring all the details, it attempts to ensure there is exactly the same amount of real
time between when the code is entered and when it finishes. In that case, my earlier answer should apply, it won't care whether it entered from the hook_shoot being released or the physical remote (+/- a handful of instructions)
Quote
Interesting (although i'm not yet capable of attempting).
I may attempt to get rid of the 10ms sleep loops at some point, but the value is probably as long as the imprecision in the other script related parts remains.

Quote
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?
I'm not sure what you mean. If you don't want it to wait for the physical remote, don't enable usb_sync_wait.

Quote
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).
In the no-sync case, the remote triggers a shoot_full key press, which is far earlier in the code. So the gap between the remote signal being complete and the shot is significantly longer and more variable.
Don't forget what the H stands for.

Re: USBremote - sync test issue
« Reply #16 on: 01 / December / 2018, 01:14:51 »
Quote
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).
In the no-sync case, the remote triggers a shoot_full key press, which is far earlier in the code. So the gap between the remote signal being complete and the shot is significantly longer and more variable.
reyalp's explanation matches my understanding of what I reported.

For reference, I added vnd's code to the A1200 that I used for the Dec 2013 testing and submitted it as a patch that was added in Jan 2014.
Ported :   A1200    SD940   G10    Powershot N    G16

Re: USBremote - sync test issue
« Reply #17 on: 01 / December / 2018, 04:42:39 »
I'm not sure what you mean. If you don't want it to wait for the physical remote, don't enable usb_sync_wait.

My familiarity with chdk (&C) is not what it should be, but:

If operating with ptp sync (i.e. no 5V transistion available) and sync enabled then does usb_sync.c#ln110:

do { }  while( get_remote_state() &&  ((int)get_tick_count()-tick < DELAY_TIMEOUT))

not wait until DELAY_TIMEOUT has passed before executing vnd precision sync? is that 10 seconds?

reyalp's explanation matches my understanding of what I reported.

Thanks - makes sense now.

The precision sync code could probably be changed to count until the critical value is reached and then release to Canon code. The advantage would be to stop reliance on vaguery of msleep(40) and reduce the period between switch release and exposure to 3x std periods (edit: assuming critical count/camera availability).     
« Last Edit: 01 / December / 2018, 07:43:55 by andrew.stephens.754365 »


Re: USBremote - sync test issue
« Reply #18 on: 01 / December / 2018, 10:37:19 »
I'm not sure what you mean. If you don't want it to wait for the physical remote, don't enable usb_sync_wait.
My familiarity with chdk (&C) is not what it should be, but:
If operating with ptp sync (i.e. no 5V transistion available) and sync enabled then does usb_sync.c#ln110:
do { }  while( get_remote_state() &&  ((int)get_tick_count()-tick < DELAY_TIMEOUT))
not wait until DELAY_TIMEOUT has passed before executing vnd precision sync? is that 10 seconds?
Under the conditions you describe, the code will not wait when operating under ptp sync control.   The wait only occurs if the variable usb_sync_wait_flag equal one and that only occurs when the shot is actually triggered by the code monitoring the physical USB line for a transistion.

Quote
The precision sync code could probably be changed to count until the critical value is reached and then release to Canon code. The advantage would be to stop reliance on vaguery of msleep(40) and reduce the period between switch release and exposure to 3x std periods (edit: assuming critical count/camera availability).   
Count what?  Do you mean locked loop continuously? How would we know when "the critical value is reached" ?

From the comments in the code (based on vnd's notes IIRC) :

msleep(40) should get us there, the timing is not critical and with sleep we give the camera a chance
to run the delayed low prio tasks now


So I'm guessing he didn't think it was important?



Ported :   A1200    SD940   G10    Powershot N    G16

Re: USBremote - sync test issue
« Reply #19 on: 01 / December / 2018, 12:24:34 »
Under the conditions you describe, the code will not wait when operating under ptp sync control.   The wait only occurs if the variable usb_sync_wait_flag equal one and that only occurs when the shot is actually triggered by the code monitoring the physical USB line for a transistion.

In my last comment I had imagined that setting the remote menu option "Enable Sync" [.] is what set usb_sync_wait_flag equal to one (usb_sync.c#ln101).

Since that is not the case then vnd's precision sync code is not executed in what I wish for, which is:

if possible, following multicam.lua function cmds.shoot_hook_sync() hook_shoot.continue() the facility to immediately execute the precision sync code

Count what?

in usb_sync.c, change:

Code: [Select]
int sync_period = std_period * 2 + cur_cnt; (line 114)to
Code: [Select]
int sync_period = std_period * 1 + cur_cnt; (line 114)
replace msleep(40) with:
Code: [Select]
#define GPIO_TICKS_TO_INTERRUPT ??cam dependent??
x=EngDrvRead(GPIO_TICKS_TO_INTERRUPT) ;
while ((*(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff) <= x) {}
« Last Edit: 01 / December / 2018, 12:46:42 by andrew.stephens.754365 »

 

Related Topics