TRIGGERING A PAIR OF  NIKON COOLPIX 5000's

Prof. John Hart

Program in Atmospheric and Oceanic Sciences

University of Colorado

Boulder, CO 80302

November 2001

hart@tack.colorado.edu

nimbus.colorado.edu/hart/science.htm

www.crystalcanyons.net

In our laboratory at the University of Colorado we have tested parallel  triggering a pair of 5 megapixel Nikon Coolpix 5000 digital cameras.  The scientific application is two-camera 3D imaging of rapidly moving turbulent flows where flash freezing of the motion is critical.  Tests were done to see how well digital cameras can be synchronized.

The CP5000 camera is fired by a serial-protocol remote controller,  the Digisnap 2200, using a StereoSnap cable splitter.  For applications in fluid dynamics, of viewing turbulent flows at different angles, or in 3D, it is important that the cameras fire simultaneously.  In these tests two cameras are attached to the same controller (see the Twin-Cams page).  They then shoot images of a rapidly rotating wheel (going at 4 Hz.)  The images are read to get the interval between pictures taken by the two cameras.  In all these tests the cameras are first commanded to go into a preset mode, where all the focusing and exposure controls are locked.  Then they are fired (i.e. the command is sent for them to fire).  There was not very significant differences when using aperture priority vs. fully manual modes of operation.  The report here is for aperture (A) priority.

Figure 1.  Closeup of the DigiSnap 2200 with splitout box (StereoSnap) from Harbortronics.

Figure 2.  The Digisnap and the "twinned"  CP5000's.

Figure 3.  The Spin-Test setup.  The wheel rotates at 4Hz, leading to a 1/80'th second interval in which  the stripes on the wheel pass one unit on the scale.  Cameras are triggered, then the LCD panels are read to get differences in the stripes' positions.  Ideally the stripes will lie exactly on the same ruling.

Figure 4.  A typical result frame, side-by-side.  Here the left (the Master) lags the right (the Slave camera - in Digisnap lingo) by 0.2 units or about 1/400 sec.

Figure 5.  Results.  When the cameras are first turned on, there is a lag of 0.02 seconds where the Master camera fires later then the Slave camera.  This lag slowly decreases, becomes a lead, jumps back to a lag, and repeats.

This is an interesting plot.  There are times when the synchronization is very good (e.g. around 40 and 115 minutes).  When the errors are bad (around 85 minutes, say) they can be bad either way, lead or lag!!  When the errors are good (around 50 minutes), very occasionally one gets a badly synced shot.

Figure 6.  Another run.  Here, when the cameras were turned on, there was a lag of only .005 (1/200) seconds.  Over a period of about 75 minutes the system cycles from good (in sync) to bad (with errors of plus or minus 1/30 second or so).  Again, when bad, a lead or lag is about equally probably.  When good (i.e. at 5 minutes), very rarely one gets a bad shot.

Figure 7.  Here are a set of closely spaced samples (15 seconds apart) during a period where the cameras sync up well (as in around minute 16 of figure 6).  THIS SHOWS THAT, IN PRINCIPLE, THE ELECTROMECHANICAL ABILITY OF THE CAMERA TO SYNC IS OF ORDER 1/500'th SECOND.

We assert below that the larger errors found during certain periods in figures 5 and 6 are due to software issues.

Before describing a model that explains these data, let's look at flash.  One wants to use flash on one camera (only), and have the second camera's shutter be open when the flash goes off.  Is this possible?

Figure 8.  Flash can work, but it depends where you are in the cycles of figure 5 and 6.  Here is a plot of the probability for success, depending on what the lag is.  If the lag is positive, using the Slave as a flash works OK.  If the lag is small or not too negative, using the Master for the flash works pretty well.  It is necessary to let both cameras actually flash (i.e. they must be set up identically), however light from the camera whose strobe is not actually to be used is screened out via a card placed a few inches in front of the flash head (DO NOT tape over the flash, heat will built up inside and burn it up).  Using both cameras to flash generally does not work.  One picture will likely be over exposed (gets both flashes) and there will be motion errors (i.e you'll never take advantage of short flash pulses for freezing action if you let both shine on the scene).

A THEORY

Here is a model that explains the data.

1. When you turn the cameras on, the CPU's in each polls the respective serial input port.  When the poll indicates new data (a command to fire has arrived), the shutter is released.  These polls apparently happen about every 1/30 of a second.  When you turn the cameras on, the phase of the polling is arbitrary.
2. As the oscillators in the two cameras are slightly different (inevitably), the phase of the polling will drift with time.  For a while the polling will be in  phase (leading to good sync), then after a time the polling will be out of phase (leading to the largest errors).  From the data (figure 5), we conclude that, for our test pair of cameras, the oscillators differ by about .03 seconds/80 minutes = 1 part in 160,000.   This is about what one might expect based on typical electronic components.  The drift will probably vary from camera pair to camera pair, with temperature, etc.
3. Since the triggers from the Digisnap (i.e. you, the human operator) can come at random, the phase differences in the port polling between the two cameras can lead to weird (but exactly as observed) sync errors.  When the sync generally looks good, on rare occasions it will be awful.  When the sync is bad (e.g. at time ~ 50 minutes in figure 6) it can more or less equally be a bad lead or a bad lag.

In cartoon form this model looks like:

Figure 9.  Here is the timeline for two cameras (M = "master", S = "slave") that happen to come on with the polling of the serial port command register in phase.  A trigger at A leads to a response at (a).  These are close together (roughly within the 1/500'th electromechanical stability).  Later on the polling phases have drifted apart and a trigger at B leads to triggering at (b), which in the above sketch has S lagging M by about 0.02 seconds.

Figure 10.  We can quantify this a little.  Here p is the polling period (about 1/30 in reality, or as noted (a little off) in the figure ~40 milliseconds).  x is the phase lag in the input port polling of M behind S. 

A trigger at A ( in the X window) leads to a response (a) that is a lead (of M) by the large amount  (p - x).

A trigger at B (in the  p - x window) leads to a response (b) that is a lag (of M) by the small amount  x .

Similarly, when the polling is out of phase, triggers at C or D lead to lags or leads by roughly the same large amount p/2 .

So,

The probability of  error ( p - x )  is  x /p.  The probability of error  x  is  (p - x)/p .

The total error (lags + leads) should be  p . 

For example, if X = p/10, 9/10 of the time the sync error will be p/10 or about .003 seconds (for p = .03sec).  However about 1/10 of the time the sync error will be 9p/10 or about .027 seconds.

Figure 5 shows that the sum of lags + leads everywhere on the plot is about 0.033, hence the polling cycle p for the Nikon CP5000 is about 0.033 seconds (or 1/30'th)!  Hey, this is pretty good science!  

The Situation Cannot Be Saved By Lagging the Commands

Figure 11.  Lagging the commands only resolves the lead/lag ambiguity.  As shown here, triggers C and D now lead to firing at (c) and (d), i.e. always a lead (of M) by the still large amount ~ p/2 .

Fixes??

These cameras are quick (capable of 1/500'th sync), they are sweet (small size, high res, good color....).  Can they be made to work????

One possibility is an external hardware reset that forces the clocks of both to go into the state on the left of figure 9.  We will have to open the cameras up......   Not good.  In any case, even if you could do this, there is still a small probability of getting a bad sync once in while.  This will inevitably occur on your best picture.  You will have to do the external reset every few minutes as the cameras drift apart.   Rejected.

A better way is simply to reduce the polling interval  p .   Make it 0.004seconds and you are good to 1/250'th.  Why is it so long?  The cameras are preset and waiting to go.... 

The polling interval is close to 1/30'th of a second (indirectly inferred from our timing measurements).  NTSC Video frame rate is ~1/30'th of a second.  Curious.  Now, these CP5000's output NTSC video in real time even in the preset, ready-to-fire, mode.  If you turn the camera, the video output follows, even though exposure and focus are fixed and locked in.  The video cannot be disabled (via the CP5000 menus).   This (and other cameras like the Dimage 7) apparently have a master cycle based on the the video frame rate.  This cycle is interrupt driven.  This is why no matter what you do with the camera (framing, erasing memory, etc.) the synchronization drift continues unabated (figure 5).  The interrupt clock is drifting.    

Therefore, it's what gets done during the interrupt master cycle that counts!  Apparently, the serial input register is only polled once.  Other things like acquiring and sending out the video frame are done too.  

Thus in order to make these cameras work simultaneously (up to their electromechanical limit of about 1/500'th), all that is needed is a firmware update that will read the serial input port (and respond appropriately) continuously during the interrupt master routine.  When the camera is preset, most other services can be skipped, including sending out the video frame.

Is there hope?    Either Nikon can be convinced to do change the firmware to disable video and increase serial register polling rates, or perhaps they will release enough information so that the firmware can be hacked......   We'll see.

Home