USBremote - sync test issue - page 3 - General Help and Assistance on using CHDK stable releases - CHDK Forum  

USBremote - sync test issue

  • 26 Replies
  • 9905 Views
Re: USBremote - sync test issue
« Reply #20 on: 01 / December / 2018, 15:14:43 »
Advertisements
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
I'm not sure that will buy you anything. 

The USB remote triggered precision sync code kicks in with a physical event while both cameras are waiting in a tight loop for the USB remote +5V signal to go to zero.  Both cameras essentially start forward from there exactly the same moment. And vnd's hack just helps to avoid the situation where one camera gets more interrupts than the other after that prior to actually opening the shutters.

AFAIk, triggering from a ptp command does not give you that exact same starting point.  So trying to add a precision adjustment to avoid interrupts won't do much for you if the two cameras are already tens of milliseconds apart when they start interpretting the ptp continue message.

But by all means, implement and test it.  I'd be interested to hear what you learn.

Quote
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) {}
You could certainly give that a try too. I'd be curious to hear if it makes any difference in real world testing.

Frankly, after I implemented vnd's hack, tested it, and submitted it to the svn, I lost interest in doing any more work on it.  And nobody has since asked for it to be added to their camera's port.  So the A1200 is the only camera where it is implemented.

I suspect that any serious stereo enthusiasts stick with SDM. So that just leaves the few brave souls trying for a ptp enabled multicamera setup,  And they have enough additional challenges that sync falls by the wayside once what they get is "good enough".
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 14080
Re: USBremote - sync test issue
« Reply #21 on: 01 / December / 2018, 17:55:14 »
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
I'm not sure that will buy you anything. 
I agree. Given multiple points that add +/- 10ms uncertainty, executing the precision sync code would just add latency.

Quote
AFAIk, triggering from a ptp command does not give you that exact same starting point.  So trying to add a precision adjustment to avoid interrupts won't do much for you if the two cameras are already tens of milliseconds apart when they start interpretting the ptp continue message.
multicam waits for a pre-calculated tick time rather than using the actual message, but both the clock offset calculation and the actual schedule time are subject to ~10ms or more uncertainty, so the effect is the same. This is one of the reasons I haven't bothered trying to optimize the hook hand-off.

I think to really improve PTP sync precision, the best approach would be to use HP timers to implement a sub 10ms clock, and then add the ability to schedule the hook to continue at a specific HP timer time. After that, perhaps precision sync would provide some benefit, though getting precise enough clock sync over PTP to make it worthwhile might still be challenging.
Don't forget what the H stands for.

Re: USBremote - sync test issue
« Reply #22 on: 19 / December / 2018, 06:26:11 »
AFAIk, triggering from a ptp command does not give you that exact same starting point.  So trying to add a precision adjustment to avoid interrupts won't do much for you if the two cameras are already tens of milliseconds apart when they start interpretting the ptp continue message.

But by all means, implement and test it.  I'd be interested to hear what you learn.

Yes, I plan to do a large camera count trial sometime in the new year and will provide feedback. I first need to make sure I more fully understand the various +/- 10ms uncertainty points and maybe a little more at the low-level USB frame level. Collapsing variability by using the combination of ptp based trigger and precision sync is potentially of interest in one use case so I want to investigate that more fully before continuing down the more complicated usb trigger wiring / ucontroller route.

So the A1200 is the only camera where it is implemented.

Not sure what you mean - vnd's precision sync code is in https://app.assembla.com/spaces/chdk/subversion/source/HEAD/trunk/core/usb_sync.c. I've very little compiler experience and ages since I done that, is there an option to include it somewhere?


For usb wired trigger, I still can't fathom your A1200 (red) normal sync test results of Dec 2013. 

A theory for normal sync:
  • Assuming a normal standard period of 32ms
  • Assuming exposure (nearly always to the same ms) starts at the end of the current standard period if usb switch release is prior to the "criitcal value"
  • Assuming exposure (nearly always to the same ms) starts at the end of the subsequent standard period if usb switch release is after the "critical value"

(these 2nd two assumptions based in nearly total 1ms precision sync test result here https://chdk.setepontos.com/index.php?topic=13363.msg136349#msg136349 and that non precision sync shooting is very nearly as far advanced, when waiting on release, as that with precision sync)

Then, to ever record 62ms delay (between usb release and exposure start) the critical value count must be incredibly early and equate to around 2 ms.

In other words - the current count must be after 2ms (i.e. after the critical count) but prior to 3ms in which case:

time from switch release until end of current period = 32 - 2 = 30
time from end of current period to end of following standard period = 32ms

i.e. Total time from switch release = 30 + 32 = 62ms.

However, we should then also expect some current counts, at switch release, very close to the end of the standard period and therefore delay between switch release and exposure (at end of subsequent standard period) of just over 1x standard period i.e. 32ms ... but we don't see that (although your sample is small).

But it seems, to me, rather incredible that the critical value could be so early in the count & therefore that my theory could be based in reality is unlikely.

Do you have a theory to explain the observed results or know  the A1200 critical value?

Edit:
the sync test diagram referred to above was here https://chdk.setepontos.com/index.php?topic=8312.msg107601#msg107601 but I can't currently view that.
« Last Edit: 19 / December / 2018, 08:58:59 by andrew.stephens.754365 »

Re: USBremote - sync test issue
« Reply #23 on: 19 / December / 2018, 19:14:42 »
So the A1200 is the only camera where it is implemented.
Not sure what you mean - vnd's precision sync code is in https://app.assembla.com/spaces/chdk/subversion/source/HEAD/trunk/core/usb_sync.c. I've very little compiler experience and ages since I done that, is there an option to include it somewhere?
The precision sync code only gets built into a port if
Code: [Select]
#define CAM_REMOTE_USES_PRECISION_SYNC   1    // USB remote precision sync patch works with this camerais included in the camera's platform_camera.h file.  So far, only the A1200 has it included.

Quote
For usb wired trigger, I still can't fathom your A1200 (red) normal sync test results of Dec 2013. 
....
Do you have a theory to explain the observed results or know  the A1200 critical value?
To be candid, I don't remember what I resolved when I tried to puzzle out how the precision sync code works.  But I seem to recall it's just an inprecise hack that tries to make sure both cameras are clear of the timer tic interrupt most of the time when they finally release the shutter.

Quote
Edit:
the sync test diagram referred to above was here https://chdk.setepontos.com/index.php?topic=8312.msg107601#msg107601 but I can't currently view that.
Yes - I see the chart I had posted there is now gone.  There used to be a big problem on this forum with attachments disappearing after a while - read any of the threads from ten years ago for example.  Now it appears other stuff is going missing.  Not good - I may have the original image file tucked away on my PC somewhere.
Ported :   A1200    SD940   G10    Powershot N    G16


Re: USBremote - sync test issue
« Reply #24 on: 20 / December / 2018, 05:13:54 »
The precision sync code only gets built into a port if
Code: [Select]
#define CAM_REMOTE_USES_PRECISION_SYNC   1    // USB remote precision sync patch works with this camerais included in the camera's platform_camera.h file.  So far, only the A1200 has it included.

Ah - thanks.

To be candid, I don't remember what I resolved when I tried to puzzle out how the precision sync code works.  But I seem to recall it's just an inprecise hack that tries to make sure both cameras are clear of the timer tic interrupt most of the time when they finally release the shutter.

With Phil's change it does not seem to be imprecise.

It:

measures current count at switch release

then
extends subsequent count in such a way that that finishes at the same time on all cameras
&
ensures canon only inspects the value of the count (in this extended period) at a value greater than the "critical" one.

The result (in a single 1000 stereo pair test on SX150IS, with continuous lighting) is that Canon always starts exposure at the end of the standard period following the extended period. That point is now  the same time (nearly always to the same ms) on all cameras. The added "latency" cf normal sync maximum (between release & exposure start) is probably (with the change I suggested) a single standard period (approx 32 ms)... but I can imagine why that is probably not very interesting for most :xmas (although I can also never imagine how SDM could provide superior synch to that).

Not good - I may have the original image file tucked away on my PC somewhere.
Understood. If you ever post it back here as an attachment i'll make sure to download.

Re: USBremote - sync test issue
« Reply #25 on: 17 / January / 2019, 13:23:56 »
In multicam.lua 841 https://app.assembla.com/spaces/chdkptp/subversion/source/HEAD/trunk/lua/multicam.lua#ln543
Code: [Select]
function mc:init_sync_single_send(i,lcon,lt0,rt0,ticks,sends)
    local tsend = ustime.new()
    local diff = ustime.diffms(lt0)
    lcon:write_msg('tick')
    sends[i] = ustime.diffms(tsend)

i'm trying to imagine what is happening between tsend and sends.

Does lcon:write_msg('tick') block until the the ACK handshake packet of the USB bulk transfer is received back from the camera?

*

Offline reyalp

  • ******
  • 14080
Re: USBremote - sync test issue
« Reply #26 on: 18 / January / 2019, 00:18:09 »
Does lcon:write_msg('tick') block until the the ACK handshake packet of the USB bulk transfer is received back from the camera?
Yes. It blocks until the transaction is completed. chdkptp is single threaded, and does not return to Lua while a transaction is in progress.
Don't forget what the H stands for.

 

Related Topics