Faster Sync Triggering? - page 7 - General Help and Assistance on using CHDK stable releases - CHDK Forum
« previous next »
Pages: 1 2 3 4 5 6 [7]   Go Down

Faster Sync Triggering?

  • 68 Replies
  • 34857 Views
*

Offline cdordoni

  • *
  • 19
Re: Faster Sync Triggering?
« Reply #60 on: 27 / September / 2017, 11:55:48 »
Advertisements
I'm curious if there might be a way to reduce the time by breaking down a large number of cameras in smaller groups. Of course one would have to work out a method to sync the groups so perhaps its not possible ... ?
Logged
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: Faster Sync Triggering?
« Reply #61 on: 27 / September / 2017, 12:53:57 »
To the best of my understanding (it was without confidence) at the time, I tried to explain the relevant round trip transmission period in the 2nd part of this post:
https://chdk.setepontos.com/index.php?topic=11490.msg124541#msg124541

I don't know anything much to know if multithreading could help but have a picture that the usb network could still then only send/receive to/from one camera in sequence.
Logged
*

Offline reyalp

  • ******
  • 14139
Re: Faster Sync Triggering?
« Reply #62 on: 27 / September / 2017, 12:58:57 »
Quote from: andrew.stephens.754365 on 27 / September / 2017, 11:16:48
From this, the minimum prefocus period was 680ms, the maximum 770ms and the subsequent period until the hook_shoot was ready was constant at 140ms on all 8 cameras.
Thanks for posting those results. 140 is slightly longer than I would have guessed, but not a huge surprise.

Quote
Quote from: reyalp on 22 / September / 2017, 17:31:16
and there's some hand-off time between the usb code and the script seeing it (~10s of ms).

Is there another way of saying the same thing - I can't quite picture the context.
Multicam commands are sent using the script message interface (PTP_CHDK_WriteScriptMsg / lua read_usb_msg)

When the host PC sends PTP_CHDK_WriteScriptMsg, the message is received by CHDK code that runs in the Canon firmware PTP task (core/ptp.c). The PTP task puts the message into a queue.
Script runs in kbd_task, which runs every 10ms or so. If a script is waiting in read_usb_msg, it will only see the message the next time the script task runs.

The hand-off time I referred to is the time the message spends sitting in the queue.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14139
Re: Faster Sync Triggering?
« Reply #63 on: 27 / September / 2017, 13:00:11 »
Quote from: cdordoni on 27 / September / 2017, 11:55:48
I'm curious if there might be a way to reduce the time by breaking down a large number of cameras in smaller groups. Of course one would have to work out a method to sync the groups so perhaps its not possible ... ?
Can you clarify which time you are trying to reduce?
Logged
Don't forget what the H stands for.
*

Offline cdordoni

  • *
  • 19
Re: Faster Sync Triggering?
« Reply #64 on: 27 / September / 2017, 13:24:29 »
I meant if the sync time becomes too great with a large number of cameras, would it be possible to parallel process with smaller groups simultaneously, so a higher process would determine when all the groups were sync'd?

Your comment is what inspired my thought ...
>>FWIW, you can adjust the polling interval in the options sent to mc:cmdwait (opts are passed to mc:wait_status_msg) However, cameras are polled >>sequentially and a USB transaction takes several milliseconds, so on large rigs the minimum achievable value could be significant.
« Last Edit: 27 / September / 2017, 13:28:26 by cdordoni »
Logged
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: Faster Sync Triggering?
« Reply #65 on: 27 / September / 2017, 13:35:51 »
Quote from: reyalp on 27 / September / 2017, 12:58:57
The hand-off time I referred to is the time the message spends sitting in the queue.

Useful, as usual, thanks.

Current observation, as you suggested, is that - getting as near the end with closed loop ( i.e. satus via cmdwait) [edit: and 10ms poll period, rather than 250ms?] followed by a "relatively deterministic?" 20ms until switch release open loop seems optimal.
« Last Edit: 27 / September / 2017, 13:41:04 by andrew.stephens.754365 »
Logged
*

Offline reyalp

  • ******
  • 14139
Re: Faster Sync Triggering?
« Reply #66 on: 27 / September / 2017, 17:07:10 »
Quote from: cdordoni on 27 / September / 2017, 13:24:29
I meant if the sync time becomes too great with a large number of cameras, would it be possible to parallel process with smaller groups simultaneously, so a higher process would determine when all the groups were sync'd?
In theory, yeah. If you had multiple, separate systems running multicam which you could command simultaneously, then the amount of time required to send commands to or receive responses from them would reduced proportional to the number of cameras connected to a single system. I suspect implementation would be complicated though.

I'm not sure how much sending in parallel from a single host would help, it might depend on USB hardware. With the current architecture of chdkptp, you'd need to run multiple instances of multicam which would be ugly.

If you use the hardware remote for triggering, all of this latency applies only to setting up the shot (AF, AE etc), the actual triggering is nearly instant and not dependent on the number of cameras. However, the current implementation of usb_sync_wait ends up with a hard coded 10 second timeout in the remote hook, so you can't set up a shot and then wait indefinitely. This is something that could probably be improved.
Logged
Don't forget what the H stands for.
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: Faster Sync Triggering?
« Reply #67 on: 28 / September / 2017, 06:41:49 »
Quote from: reyalp on 27 / September / 2017, 17:07:10
In theory, yeah. If you had multiple, separate systems running multicam which you could command simultaneously, then the amount of time required to send commands to or receive responses from them would reduced proportional to the number of cameras connected to a single system. I suspect implementation would be complicated though.

Primarily for faster image download - I have an AutoIt based tcp/ip gui master client that can control unlimited AutoIt tcp/ip servers. Of interest, it actually reminds me a little of chdkptp itself insofar as it uses psexec to initially copy the remote AutoIt script from the client machine to the server machine and start its execution there.

Each server controls a chdkptp cli by passing keystrokes to it. On each server, chdkptp status is returned to file. Each file is processed remotely to provide an overall status prior to simple message return to the master client.

Of course, the tcp/ip command from the master client to each server is sequential and the time for each server to write to its related chdkptp cli is, probably, different and the client has to poll each server to understand when its satus file is ready before, sequentially, reading it's status back before the next command can be issued.

While the command time on each chdkptp instance is faster by a factor of the number of servers, all in all, other than for image download, a single instance would, probably, be much faster.       

Perhaps this could all be done within lua and udp to make something that really is faster (edit) and udp transmission delay modelled so appropriate wait could be included for the earlier servers in the chain in order that all chdkptp commands start at, nearly, the same time.

Edit2:
in a similar vein, I can currently vary the ptp sync based parameter syncat for each chdkptp instance with aim to account for tcp/ip transmission delay between each.
« Last Edit: 28 / September / 2017, 09:54:43 by andrew.stephens.754365 »
Logged
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: Faster Sync Triggering?
« Reply #68 on: 30 / January / 2018, 16:44:44 »
Quote from: waterwingz on 08 / April / 2017, 10:20:53
FWIW, the USB remote code includes a function called kbd_calibrate_synch_delay( ). That function must be used during CHDK development to calibrate an internal constant named synch_delay_tick .  The default value if no calibration is done is just a wild guess of an appropriate starting value, and the actual delay that occurs will change with ARM CPU model and clock speed.

AFAIK, the calibration function has never been used and every camera defaults to the same calibration value. In fact, as built today, the value is in part of the CHDK source code that is common to every camera.  There is no way to set it up on a per camera basis. :-[

So you options are to enable the function in source and calibrate yourself for your personal build.  Or, just experiment with the Synch Delay [  ] value.  Set it to 5000 and measure the delay created from shutter release.  Adjust the value until you get five seconds.  Calculate the multiplier necessary to calibrate the value.  Then multiply your 420 value by that factor.  Done.
 

Using SX150IS 4755, stereo pairs and the crt tester http://www.3dtv.at/knowhow/Synctest_en.aspx:

both cameras Remote menu -> two push / normal / Enable Sync [enabled]

physical left camera "sync delay 1ms" disabled
physical right camera "sync delay 1ms" enabled

With physical right remote menu at 500 by 0.1ms steps, 9 pair results are:
Average actual crt delay 36.11ms
Max Var 4.77ms (34.32ms->39.09ms)

 
On that basis, I expected (50/36.11)*500 = 692 steps to provide a crt delay of (approx) 50ms, so with menu set to 692 by 0.1ms steps, 9 pair results are:
Average actual crt delay 14.45ms
Max Var 9.69ms (10.31ms->20ms)


At the very least I had expected the measured crt delay to increase with increasing menu steps.


Excel spreadsheet results attached.


Any method or comment to help address the challenge would be appreciated.


Edit: perhaps I overstepped the difference limits of the crt tester...
Edit 1: reliable only up to somewhere between 2&3 vertical bar separation
 i.e. at 59Hz then 2*16.95ms = 33.9ms & *16.95ms = 50.85ms.
« Last Edit: 31 / January / 2018, 08:51:20 by andrew.stephens.754365 »
Logged
Pages: 1 2 3 4 5 6 [7]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal