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
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]
"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.
