USBremote - sync test issue

  • 21 Replies
  • 1290 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

*

Online reyalp

  • ******
  • 11583
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.

 

Related Topics