CHDK PTP multiple instances - page 13 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 8 9 10 11 12 [13] 14 15 16 17 18 19   Go Down

CHDK PTP multiple instances

  • 180 Replies
  • 57139 Views
*

Offline reyalp

  • ******
  • 13833
Re: CHDK PTP multiple instances
« Reply #120 on: 15 / December / 2013, 18:26:13 »
Advertisements
Quote from: Karmaschinken on 15 / December / 2013, 16:50:35
Hmmm. Okay, although the 10ms might not be a barrier, as long as the "right" 10ms are triggered?
The point is that there are multiple steps which are variable or uncertain by tens of ms. If you can accept sync within something like 50-100ms, there's a good chance multicam.lua would work. For example, it should be fine if you use relatively long exposure time in a dark studio and do your sync with flash.

I did some testing here http://chdk.setepontos.com/index.php?topic=6231.msg81330#msg81330
Logged
Don't forget what the H stands for.
*

Offline ahull

  • *****
  • 634
Re: CHDK PTP multiple instances
« Reply #121 on: 16 / December / 2013, 02:07:47 »
Quote from: Karmaschinken on 15 / December / 2013, 14:47:41
Hmmm... How should that be done? There is always the USB between me and the camera clock making it virtually impossible to sync the cameras. I suppose the USB-ports are very inconsistent when sending and receiving this and that. However it will be okay for me to build the remote func solution.

A good question. Let me have a play with this... meanwhile here is  a quick brain dump.

If I send a command from the host to the camera telling it to compare its  time to the host time, then ask the camera what time it is, and compare with the host time, I should see a difference of two delays, the delay for the send, plus the delay for the receive (both no doubt different). If I repeat this n times, then I can calculate the average delay over n repetitions, and I can use this as a base line for further refining of the time.

NTP  (Network Time Protocol) uses a feedback loop to narrow down this offset and any subsequent drift considerably,  as follows...

"A typical NTP client will regularly poll three or more servers on diverse networks."

In our case we only want all our cameras to agree with the chdkptp host with a high degree of certainty, so we are only polling one host. It makes little sense to have the cameras poll each other.

"To synchronize its clock with a remote server, the client must compute the round-trip delay time and the offset. The round-trip delay δ is computed as\delta = (t_3 - t_0 ) - ( t_2- t_1 )wheret0 is the client's timestamp of the request packet transmission,t1 is the server's timestamp of the request packet reception,t2 is the server's timestamp of the response packet transmission andt3 is the client's timestamp of the response packet reception."

My previously mentioned scenario equates loosely to this step.

"Thereforet3 − t0 is the time elapsed on the client side between the emission of the request packet and the reception of the response packet andt2 − t1 is the time the server waited before sending the answer.The offset θ is given by[8]\theta = {(t_1 - t_0) + (t_2 - t_3 ) \over 2}"

Once we have an initial offset we are able to refine our accuracy as follows.

"The calculated δ and θ are passed through filters and subjected to statistical analysis. Outliers are discarded and an estimate of time offset is derived from the best three remaining candidates. The clock frequency is then adjusted to steadily reduce the offset, creating a feedback loop.[1]:20"

The "filters" in our case don't need to be particularly complex, but we could base them on code for existing NTP implementations (since Linux, BSD and other open source projects will give us good working examples).

I suspect the "clock frequency is adjusted" line is a little off the mark in our case, as we are simply attempting to sync the camera hardware clocks, so we would write the new time to the hardware clock, rather than have any mechanism to try to make the underlying OS adjust its "ticks" every so often, as is the case in NTP implementations on systems like Linux and BSD.   

"The synchronization is correct when both the incoming and outgoing routes between the client and the server have symmetrical nominal delay. If the routes do not have a common nominal delay, the synchronization has a systematic bias of half the difference between the forward and backward travel times.[9]"

If I get a chance I'll see if I can script up something simple, but this might require some changes to the chdkptp code to get the kind of accuracy we are looking for. Also bear in mind that as I stated previously the real time clock on these cameras are not particularly accurate, as the crystal frequency is a mere 32KHz, as compared to the processor clock, which is several orders of magnitude more accurate, since it runs at several MHz, however if we can trigger all of the cameras within  a few 1/32768 of a second I suspect that will do for the purposes of this exercise.  ;)

Of course once we have all of the camera hardware clocks synchronised we still have the problem of ensuring that the canon hardware triggers at exactly the same moment, so this is only one piece of the puzzle.

With accurately synchronised clocks we would be able to say all cameras should trigger at a particular time, for example 10:00:00000 AM precisely, or trigger at "now_time on the chdkptp host+500ms", or start shooting every 3 seconds, starting at time X,  but the exact moment the camera chooses to fire is still dependant on other factors as previously mentioned in this and other threads.
« Last Edit: 16 / December / 2013, 05:09:26 by ahull »
Logged
*

Offline ahull

  • *****
  • 634
Re: CHDK PTP multiple instances
« Reply #122 on: 16 / December / 2013, 05:33:01 »
I did a little more digging. From the camera schematics for the Ixus 60, it seems this uses an Epson RX-4575 LC real time clock chip. The way Canon have wired it up, the alarm(/AIRQ) and timer(/TIRQ) pins are not connected up for alarm or timer interrupts, so we are out of luck there.

From a quick reading of the online documentation this particular chip is capable of a slightly disappointing resolution of 1/4096th of a second, although it is running from a 32.768 kHz crystal.

Whether we can get millisecond levels of accuracy, without talking to the hardware directly,  rather depends on what the camera OS will provide. I suspect that the OS does not maintain a separate OS or software clock, and that any call to the OS time functions will simply read the hardware clock.


EDIT: While the chip may be capable of 1/4096 second resolution, we are probably limited to one second accuracy by the OS and also lua.

We may be able to get millisecond accuracy in lua by combining the RTC time with the  time reported by os.clock() assuming the chdk version of lua implements this particular function. 

EDIT: It seems from the Wiki Lua pages that os.clock() is not implemented.
 
This is what the Wiki has to say on the subject.

Missing features
 
  • os.clock: not implemented. Note this relates to CPU time used by a process, not time of day (which is handled by os.time and os.date)
Time for a little more head scratching I think..  ::)

Clearly these cameras are capable of some very accurate timing, otherwise they wouldn't be able to produce such spectacular results, so now I think I need to figure out how they do it.  Ideally it would be good to be able to combine some kind of free running hardware timer with the RTC time to give us the kind of accuracy we need.Time to start looking at the Digic hardware for our millisecond timings I think...
« Last Edit: 16 / December / 2013, 07:47:51 by ahull »
Logged
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: CHDK PTP multiple instances
« Reply #123 on: 16 / December / 2013, 08:58:57 »
Quote from: Karmaschinken on 15 / December / 2013, 16:50:35

...but I won't use a script waiting for the 5v drop but the remote function. I think it is much more accurate than a loop in a script. I had no problem changing the keyb.c as suggested by waterwingz. I tested that with one camera, at the moment I try to use the multicam.lua to adjust all the cameras from a single PC, works with three cameras now. Next week I will be ready to try with some mosfets (which will actually disconnect the usb-bus, as you suggested).



say you forget about the script loop.

Instead:

(i) Enable remote / Enable Synch on all cams [manually]

any chance [with complete hub network in place change to kbd.c implemented] you [via chdkptp]

(ii) start [on all cams] a script to
 
set / lock manual overrides (if desired) then
end script

(iii) once the script has ended, disconnect connection [edit: power&data] between pc and usb hub network

then

(iv) turn usb hub network power off [to capture image to sd]

then

(v) reconnect hub network [edit: power&data]to PC

then

(vi) turn usb hub network power on

then

(vii) via chdkptp script, connect to all cams and download images   

PS any chance - what 13 port hub did you decide on ?
« Last Edit: 16 / December / 2013, 10:41:10 by andrew.stephens.754365 »
Logged
*

Offline waterwingz

  • ******
  • 12128
    • Waterwingz
Re: CHDK PTP multiple instances
« Reply #124 on: 16 / December / 2013, 09:00:01 »
Quote from: ahull on 16 / December / 2013, 05:33:01
Clearly these cameras are capable of some very accurate timing, otherwise they wouldn't be able to produce such spectacular results, so now I think I need to figure out how they do it.  Ideally it would be good to be able to combine some kind of free running hardware timer with the RTC time to give us the kind of accuracy we need.Time to start looking at the Digic hardware for our millisecond timings I think...
Most real time O/S's that I have worked with use an interrupt driven internal clock to maintain system timing (usually at a sub-millisecond level). If there is a separate RTC chip, its mostly used just for battery backup of time & date information - not O/S timing.   

The point here being that while the O/S time might be initialized from the RTC chip at start-up,  the actual time is driven by the system "tic" clock from then on.  Which should give you a lot more resolution for creating the synchronization you are hoping for.
« Last Edit: 16 / December / 2013, 09:01:42 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline ahull

  • *****
  • 634
Re: CHDK PTP multiple instances
« Reply #125 on: 16 / December / 2013, 09:03:23 »
More brain-dump, one possibility might be to use the built in timers to keep our ticks in order...

There is some mention of Head Timers, on the magic lantern wikia.. there seem to be a number of these, probably the number depends on the variant of Digic we are dealing with.

The SD430 strings only mention two

Code: [Select]
HeadInterrupt1
HeadInterrupt2
... but the Ixus140  mentions four.

Code: [Select]
HeadInterrupt1
HeadInterrupt2
HeadInterrupt3
HeadInterrupt4

... it could of course be the case that others exist on the SD430, but are not used (and thus have no interrupt handler) on this particular model.

These may, or may not be the source of O/S timings and or "tic" time.

There are some other intriguing strings in the SD430 and SD600 (and presumably other VxWorks) firmware relating to "ticks"

Code: [Select]
  seconds    nanosecs  freq (hz)  resolution
---------- ----------- ---------- ----------
  base ticks          base secs  base nsecs
--------------------  ---------- ----------
 %8.8ld   %9.9ld   %8.8d   %8.8d
.. these strings are not present on the Ixus140

EDIT: I am also looking at some of the possible ARM modules that might relate to the timers...
First candidate.. http://infocenter.arm.com/help/topic/com.arm.doc.ddi0271d/DDI0271.pdf
« Last Edit: 16 / December / 2013, 09:48:50 by ahull »
Logged
*

Offline waterwingz

  • ******
  • 12128
    • Waterwingz
Re: CHDK PTP multiple instances
« Reply #126 on: 16 / December / 2013, 09:05:11 »
Quote from: andrew.stephens.754365 on 16 / December / 2013, 08:58:57
<snip>
(ii) start [on all cams] a script to
 
set / lock manual overrides (if desired) then
end script

(iii) once the script has ended, disconnect connection between pc and usb hub network

then

(iv) turn usb hub network power off [to capture image to sd]

then
</snip>
I think what you describe is what we have been discussing all along, with the additional note that at the end of step (ii) above,  you need to initiate the shot somehow so that the cameras all get to the point in the shooting sequence where they wait for USB power to go away in step (iv).
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: CHDK PTP multiple instances
« Reply #127 on: 16 / December / 2013, 09:31:19 »
Quote from: waterwingz on 16 / December / 2013, 09:05:11
I think what you describe is what we have been discussing all along,

sort of - but breaking complete connection [data / power] between usbhost / hubs is a little different.

Quote from: waterwingz on 16 / December / 2013, 09:05:11
with the additional note that at the end of step (ii) above,  you need to initiate the shot somehow so that the cameras all get to the point in the shooting sequence where they wait for USB power to go away in step (iv).

can that initiator be the last "command" in the script [just before it ends] ? what is it ?  ::)
« Last Edit: 16 / December / 2013, 09:42:12 by andrew.stephens.754365 »
Logged
*

Offline reyalp

  • ******
  • 13833
Re: CHDK PTP multiple instances
« Reply #128 on: 16 / December / 2013, 16:02:19 »
Quote from: ahull on 16 / December / 2013, 05:33:01
Missing features
 
  • os.clock: not implemented. Note this relates to CPU time used by a process, not time of day (which is handled by os.time and os.date)
Time for a little more head scratching I think..  ::)
The highest resolution clock available to CHDK lua is get_tick_count, which has a precision (but not necessarily accuracy) of 10 ms. os.time only gives you seconds.

As I posted earlier, the multicam.lua chdkptp module attempts to do something a bit like what you described in  http://chdk.setepontos.com/index.php?topic=8769.msg107985#msg107985 using get_tick_count and wait loops in lua.

If a higher precision clock were available, you'd probably want to make a script command that let you schedule a shot to begin at a certain precise time using the remote hook, rather than doing the wait in Lua. The stuff in this thread http://chdk.setepontos.com/index.php?topic=8312.100 might be helpful. I suspect that even if you get the high precision clock, synchronizing it with a similar level of precision of USB would still be tricky.
Logged
Don't forget what the H stands for.
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: CHDK PTP multiple instances
« Reply #129 on: 17 / December / 2013, 05:46:18 »
For my record [and future testing] - here's an attempt to document a response to my own query:

Quote from: andrew.stephens.754365 on 16 / December / 2013, 09:31:19
can that initiator be the last "command" in the script [just before it ends] ? what is it ?  ::)

then basing my conclusion [largely] on:

Quote from: waterwingz on 17 / September / 2013, 20:01:30
...
Using this setup and the switch closed,   I was able to connect to my camera with CHDKPTP,  go into shooting mode and issue a "shoot" command.  With USB Remote enabled and sync enabled,  this caused the picture shooting process to start but then wait on the USB 5V signal.  I opened the switch and the picture taking process completed immediately.  I was able to continue issuing commands to the camera - all I had to do next was make sure I closed the switch before the next shot.
Using your pictured setup,  you would have to make a ptp connection to each camera and issue shoot commands to each over ptp.   If your microcontroller then opened the 5V line,  all cameras would shoot at exactly the same time.   Which I believe is exactly what you are looking for!
...

[my] Conclusion:

since, in my newly stated [zero arduino / zero FET switch] scenario http://chdk.setepontos.com/index.php?topic=8769.msg107988#msg107988 at point (iii) the usb hostcontoller data connection [and power connection] has been removed then [obviously] a chdkptp "shoot" command cannot be sent to [any] camera to:

Quote from: waterwingz on 16 / December / 2013, 09:05:11
you need to initiate the shot somehow so that the cameras all get to the point in the shooting sequence where they wait for USB power to go away in step (iv).

Therefore, for testing, I will assume [currently without confidence unless informed otherwise] that a "shoot" command [as the last code line in the chdkptp initiated script, running on all cameras (before script termination) will:

"initiate the shot somehow so that the cameras all get to the point in the shooting sequence where they wait for USB power to go away in step (iv)"

[step (iv) being the point when the mains electricity to the powered usb hub network is switched off]

 
« Last Edit: 17 / December / 2013, 08:18:03 by andrew.stephens.754365 »
Logged
Pages: 1 ... 8 9 10 11 12 [13] 14 15 16 17 18 19   Go Up
« previous next »
 

Related Topics