Faster Sync Triggering?

hokiespurs

9

Re: Faster Sync Triggering?

« Reply #10 on: 03 / February / 2015, 11:46:54 »

Advertisements

Quote from: reyalp on 02 / February / 2015, 16:04:46

FWIW, you could do the second one with the shutter script hook and polling USB from script, but it would introduce several tens of ms variability.

Thanks, can you explain why this would introduce what the 10s of ms of variability would be from? Would that be variability in the dt between frames or in the sync between cameras?

Quote from: waterwingz on 02 / February / 2015, 19:34:22

I'm not completely sure of the best way to do this with the standard "pushbutton" USB remote circuit we use. Here are some options :

From a user standpoint it seems like any of those options would work, but I dont know enough about the development to help suggest which would be easiest to implement.

Thanks!

Logged

waterwingz

12139

Re: Faster Sync Triggering?

« Reply #11 on: 03 / February / 2015, 14:35:04 »

Quote from: hokiespurs on 03 / February / 2015, 11:46:54

Thanks, can you explain why this would introduce what the 10s of ms of variability would be from? Would that be variability in the dt between frames or in the sync between cameras?

The existing sync code sits in a very tight loop down at the task level waiting for the 5V signal on the USB port to go to ground. Polling the same signal from a script can result in a longer delay before that transition is recognized due mostly to the script "yielding" periodically between instruction executions. This will produce variability both between cameras (i.e. sync error) and in the shot cycle rate, although in this case only the variability between cameras is really an issue.

Quote from: waterwingz on 02 / February / 2015, 19:34:22

From a user standpoint it seems like any of those options would work, but I dont know enough about the development to help suggest which would be easiest to implement.

Thanks - I'll likely play with this a bit before deciding on the "best" implementation. Meanwhile, I can post the other patch that will allow you to do what you need in a script.

« Last Edit: 03 / February / 2015, 14:38:32 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14082

Re: Faster Sync Triggering?

« Reply #12 on: 03 / February / 2015, 16:33:09 »

Quote from: waterwingz on 03 / February / 2015, 14:35:04

Polling the same signal from a script can result in a longer delay before that transition is recognized due mostly to the script "yielding" periodically between instruction executions.

To elaborate slightly:

When a hook is waiting, the hooked task (capt_seq in this case) sits in a loop, polling a flag set by .continue() and then yielding the task for 10ms. This is because OS sleep function only works in ~10ms increments, and if it didn't yield, then script wouldn't execute (probably, depends on task priorities and scheduler details). This part of the uncertainty could actually be removed now that we have the functions to access things like semaphores and eventflags on all cameras. Switching the hooks to use these is on my TODO list.

In script you would you have an equivalent loop waiting for the USB signal like
repeat sleep(10) until get_usb_power(...) = ...
You might be able to get away with a tight non-yielding loop in some cases, but I'm not sure.

The above means that in the current code total time between the USB signal changing and the hook continuing could be anywhere from ~0 to >20ms, depending how the scheduling works out. This variation would be different on each camera.

Logged

Don't forget what the H stands for.

waterwingz

12139

Re: Faster Sync Triggering?

« Reply #13 on: 05 / February / 2015, 22:19:02 »

Quote from: waterwingz on 01 / February / 2015, 16:56:36

Sorry - just rechecked the USB remote source as something was bothering me. Sure enough, this is not going to work the way I had hoped as the sync function is not enabled when shots are taken via a script (or the shutter button).

Darn - looks like I almost got it wrong that this would not work. There is code in action_stack.c that uses sync on a shoot() if it's via a KEY_SHOOT_FULL.

Code: [Select]

// Process a button press action from the stack
static int action_stack_AS_PRESS()
{
    extern int usb_sync_wait;
    long skey = action_pop_func(1); // Key parameter returned
    if ((skey == KEY_SHOOT_FULL) && conf.remote_enable && conf.synch_enable) usb_sync_wait = 1;
    kbd_key_press(skey);
    return 1;
}

So if USB remote and USB sync are both enabled, then a "SHOOT_FULL" from the script will make the shot pause when it gets to the wait_until_remote_button_is_released() function if the +5V is still there.

Too bad that it won't currently work with SHOOT_FULL_ONLY.

Still working on cleaning this up but it looks like I had this almost right when the patch went in several years ago.

Update : this might actually still work via a script. You can do a SHOOT_HALF to lock focus and exposure. Then a SHOOT_FULL (with sync enabled). If you release via a SHOOT_FULL_ONLY then you can do the next shot via a SHOOT_FULL and get sync on the second shot. At least I think that would work.

« Last Edit: 05 / February / 2015, 22:36:50 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

andrew.stephens.754365

461

Re: Faster Sync Triggering?

« Reply #14 on: 06 / February / 2015, 18:21:49 »

This is an interesting thread and i'm not sure this is a good place to post the following.

I don't understand this:

Quote from: waterwingz on 07 / December / 2014, 11:00:42

In non-sync situations, "one press" does a shutter half-press on 0->5 and shutter full-press on 5-0. Thus, in sync mode, there is nowhere to put the half-press and it is sacrificed to allow the two necessary action for sync.

w.r.t this description:

Testing with chdktptp and SX150IS 1.4.0 3976 (and kbd.c usb/ptp hack in build), camera connected to hub with per-port 5v switch. With onepush/normal/sync then on 0->5 the AF assist led comes on prior to the lcd going black.

I was under the impression that no focus/exposure ops would be attempted with this setup . Does the outcome meake sense or is it likely a bug?

Logged

waterwingz

12139

Re: Faster Sync Triggering?

« Reply #15 on: 06 / February / 2015, 18:34:19 »

Quote from: andrew.stephens.754365 on 06 / February / 2015, 18:21:49

I was under the impression that no focus/exposure ops would be attempted with this setup . Does the outcome meake sense or is it likely a bug?

When using one press & sync, the code does the focus & exposure adjustment and then a "full press" to shoot on the rising edge of the USB pulse ( 0V to 5V). So yes, there is focus & exposure setting done - it's just that the shot immediately starts after that rather than waiting for the USB 5V to be released. The big difference here is that the display will go dark in this mode when 5V is applied. When sync is not enabled the display stays active until the 5V is released.

Logged

Ported : A1200 SD940 G10 Powershot N G16

waterwingz

12139

Re: Faster Sync Triggering?

« Reply #16 on: 06 / February / 2015, 20:33:04 »

@hokiespurs : I have your script setup so it works now with a sync'd shot rate of 1.75 seconds per shot (on my A1200 - an elcheapo Powershot) ! And no special builds or changes to CHDK were needed.

The script turns on an LED each time it is ready to shoot and turns it off when the shot starts. By watching the LED and manually toggling my USB remote switch each time it lit up, I took 34 shots in 60 seconds. I would think that your uController has better reaction time than I do so you might even be able to go faster. Or you could simply set the uController to fire every 1.8 seconds with no feedback from the LED.

Each shot is "sync'd" to the falling edge of the USB pulse so if you had multiple cameras, they would have all been within a few milliseconds of each other.

Code: [Select]

--[[
@title USB Sync
 @chdk_version 1.3
 @param   l LED?
 @default l 1
 @range   l 0 7
--]]

function restore()
    set_config_value(cnf.remote_enable,0) -- disable USB remote
    set_config_value(cnf.synch_enable, 0) -- disable sync
end

-- setup
    AF_led = l 
    cnf=require("gen/cnf_core")
    set_console_layout(10, 0, 40, 14)
    print("USB Sync test started...")
    set_config_value(cnf.remote_enable,1) -- enable USB remote
    set_config_value(cnf.synch_enable, 1) -- enable sync

-- switch to shooting mode
    if ( get_mode() == false ) then
        set_record(1)
        while ( get_mode() == false ) do sleep(100) end
    end

-- set focus & exposure and lock them in
    press("shoot_half")
    repeat
        sleep(50)
    until get_shooting() == true

-- fire away as fast as possible
    repeat
        ecnt=get_exp_count()
        set_led(AF_led,1)
        repeat sleep(20) until get_usb_power(1) == 1
        press("shoot_full")
        set_led(AF_led,0)
        tic = get_tick_count()
        repeat sleep(20) until get_usb_power(1) == 0 
        pwidth = get_tick_count() - tic         
        i=0
        repeat
          sleep(20)
          i=i+1 
        until( get_exp_count()~=ecnt ) or ( i>100 )
        release("shoot_full_only")                     
    until ( pwidth > 2000)
    
-- done
    release("shoot_half")
    restore()
    print("done")

Edit : forgot to mention that the script will stop if you give it a pulse of more than 2 seconds. Otherwise it will shoot forever.

usb_sync.lua (1.36 kB - downloaded 27 times.)

« Last Edit: 06 / February / 2015, 21:41:27 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

andrew.stephens.754365

461

Re: Faster Sync Triggering?

« Reply #17 on: 07 / February / 2015, 09:04:03 »

Quote from: waterwingz on 06 / February / 2015, 18:34:19

Quote from: andrew.stephens.754365 on 06 / February / 2015, 18:21:49
I was under the impression that no focus/exposure ops would be attempted with this setup . Does the outcome meake sense or is it likely a bug?
When using one press & sync, the code does the focus & exposure adjustment and then a "full press" to shoot on the rising edge of the USB pulse ( 0V to 5V). So yes, there is focus & exposure setting done - it's just that the shot immediately starts after that rather than waiting for the USB 5V to be released. The big difference here is that the display will go dark in this mode when 5V is applied. When sync is not enabled the display stays active until the 5V is released.

Thanks. I'm still confused. I hope i'm not quoting out of context when you originally said (my memory is, wrt onepush/normal/sync):

"Thus, in sync mode, there is nowhere to put the half-press and it is sacrificed to allow the two necessary action for sync."

So, if the half-press is sacrificied that infers the autofocus/exposure operations related to that process no longer occur - correct?
If that is true (and since testing proves that these ops are occuring) then what process has replaced the half-press to enable autofocus/exposure ops?

In summary, you said:
"the code does the focus & exposure adjustment" - how and at what point?
"and then a "full press" to shoot on the rising edge of the USB pulse ( 0V to 5V)" - is this "full press" functionally equivalent to (i) "shoot_full" or (ii) "shoot_full_only" (as per the wiki notes below)?

Neither do I understand why shooting would occur on the rising edge (the first edge) of a onepush - surely the synch loop is waiting for the falling edge (the second edge)?

Finally, for the moment, i've only been testing, so far, with either a simple, stereo, 5v switch (on the 5v line) or with chdkptp through a single hub with per-port switch (and the usbremote/ptp hack) "throwing" single lines of ,mostly levent, code at one or two cameras. I'm nearly ready to start bcam &/or multicam.lua testing (saving the best for last

).

I haven't yet studied either of these in great detail yet but it struck me to enquire at this stage - is there a particular reason why, with bcam, you wished to start the shooting process with a ptp initiated shoot() & the usb line at 5v while waiting for a synch capture at 5v->0v transistion?
The same said differently: is there a particular reason why you didn't want to initiate the shooting process from the rising edge of a onepush?

For my own reference http://chdk.wikia.com/wiki/CHDK_scripting#shoot

Shoot - This command is similar to the click "shoot_full" command (see below), but it waits for the camera to perform some normally automatic actions, such as auto-focusing, charging the flash, etc"
click/press/release "shoot_full" - Actuates the shutter-release button completely, regardless if the camera has finished charging the flash or other normally automatic camera operations.
click/press/release "shoot_half" - Actuates the shutter-release in the half-press position. This is often used to lock focus, exposure, or other camera settings.
click/press/release "shoot_full_only" - Actuates only the shutter-release button "full press" internal switch. This is mostly useful where a click "shoot half" has been previously used and you wish to hold the focus and exposure locked.

Logged

waterwingz

12139

Re: Faster Sync Triggering?

« Reply #18 on: 07 / February / 2015, 11:31:05 »

Quote from: andrew.stephens.754365 on 07 / February / 2015, 09:04:03

So, if the half-press is sacrificied that infers the autofocus/exposure operations related to that process no longer occur - correct?

Not correct. The normal things that have to happen when shooting if you are going to get the correct exposure and focus all happen. I was not implying that they do not. My description and choice of words describe what changes in the timing of when things happen relative to the transitions created by the USB remote switch.

As the risk of repeating myself again, with one push/normal/no sync, the sequence is :

CHDK detects the 0V - 5V transistion on the USB power pin
CHDK sets the bit the makes the camera think that the shutter button has been pressed half way.
CHDK waits for the USB 5V line to change back to 0V
CHDK detects the 5V - 0V transistion on the USB power pin
CHDK sets the bit the makes the camera think that the shutter button has been pressed fully.
CHDK pauses briefly
CHDK clear sets the bits that makes the camera think that the shutter button has been half & fully pressed.

In this process, the actual shot is released at step 5 and occurs as quickly as the Canon firmware can do so.

But with one push/normal/sync, the sequence is :

CHDK detects the 0V - 5V transistion on the USB power pin
CHDK sets the bit the makes the camera think that the shutter button has been pressed half way.
CHDK waits for the camera to indicate the focus & exposure have been set.
CHDK sets the bit the makes the camera think that the shutter button has been pressed fully.
CHDK waits for the USB 5V line to change back to 0V
CHDK detects the 5V - 0V transistion on the USB power pin
CHDK clear sets the bits that makes the camera think that the shutter button has been half & fully pressed.

In this process, the actual shot is released at step 4 but pauses waiting for the USB 5V to go to 0V. It then occurs as quickly as the Canon firmware can do so.

So in the one push/normal/sync, there is no "half press" state that you can hold & maintain - CHDK goes from nothing to half press to full press as quickly as it can. AND IT FOCUSES AND SETS EXPOSURE DURING THE HALF PRESS JUST LIKE YOU OBSERVED.

The reason I even mention all of this is that you, as the photographer, will see something very different as a result. In the one push/normal/sync case, the display will go blank when you set the USB pin to 5v. In the one push/normal/no sync case it does not. So there is no chance to reframe your shot or waiting for the "perfect moment" by watching the LCD if you are using sync.

Quote

is there a particular reason why you didn't want to initiate the shooting process from the rising edge of a onepush?

None : six of one, half a dozen of the other. It will work either way

However, remember that the USB remote and PTP communications are sharing the USB port. So at some point before you remove 5V from the USB power pin for the first time, you need to call the usb_force_active() function. Prior to that, you need 5V connected to the USB power pin at all times to maintain communications.

As you need to design your work flow sequence to accommodate this, one method might work better than the other for you.

Logged

Ported : A1200 SD940 G10 Powershot N G16

andrew.stephens.754365

461

Re: Faster Sync Triggering?

« Reply #19 on: 07 / February / 2015, 13:17:22 »

Quote from: waterwingz on 07 / February / 2015, 11:31:05

As the risk of repeating myself again

You are joking - right? do you think i'd have asked the questions if I already understood the answers? If you can point me to one (or even a few) threads that summarise this as succinctly I might believe that you do not jest - we are not all software / hardware eng camera fanatics. Please bear that in mind.

Quote from: waterwingz on 07 / February / 2015, 11:31:05

The reason I even mention all of this is that you, as the photographer, will see something very different as a result. In the one push/normal/sync case, the display will go blank when you set the USB pin to 5v. In the one push/normal/no sync case it does not. So there is no chance to reframe your shot or waiting for the "perfect moment" by watching the LCD if you are using sync.

I have practically no interest in photography (a mobile phone suffices for that) - I plan to use it for capturing 3D point-cloud information but I do understand your point.

Quote from: waterwingz on 07 / February / 2015, 11:31:05

However, remember that the USB remote and PTP communications are sharing the USB port. So at some point before you remove 5V from the USB power pin for the first time, you need to call the usb_force_active() function. Prior to that, you need 5V connected to the USB power pin at all times to maintain communications.

As you need to design your work flow sequence to accommodate this, one method might work better than the other for you.

I've locally edited the kbd.c file to enable usbremote/ptp, is there a particular reason why you mention "usb_force_active" in my circumstances?

PS: Your reply is a fantastic summary in one place for future reference. Thanks.

« Last Edit: 07 / February / 2015, 15:23:05 by andrew.stephens.754365 »

Logged