From rmillan Thu Jul 27 12:38:14 2000
To: brewer@fcrao1.astro.umass.edu
Subject: Re: Test Results
From: rmillan@cfa.harvard.edu
Cc: smorel@cfa.harvard.edu, wtraub@cfa.harvard.edu, schloerb@astro.umass.edu, 
jmonnier@cfa.harvard.edu
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-MD5: IrQ3YOtRtxl/Suyri4VkxA==

Hi Mike,

Thanks very much for the test results.

Here is what I extract from it:

1) DIO speed:

The DIO times you give (did you measure them with a scope or something?) imply 
that we can clock through the array rows and columns (outputting bytes) at a 
rate of:

1/(3x0.428 us) = 779 KHz

This is 779/300 = 2.6 times faster than with the current system, and is 
therefore good news.

It is also inconsistent with Sebastien's earlier report that he
measured a 300 KHz square wave when he tried this at Mt
Hopkins. Perhaps a comment on this from him would be worthwhile.

2) Determinism of sample times:

From your code and the DIO timings I calculate that the expected sample time 
should be: 96.9 +- 0.1 us, where the error comes from the resolution of the 
AuxClk. 

In practice, most of the time you get 96 us, which is very close to
the nominal.  In any case the actual precise value doesn't matter,
only that it always stays the same.

In all cases you got better than 93% of hits in the 96 us bin. This seems good.

A lower priority seems to result in a longer tail of longer sample times, but 
with very low hits and no spectacular effect on the mean.

Having the tracking tasks running produced an even longer tail of long sample 
times, but again with little overall effect.

Does tracking tasks refer both to telescopes (3) and SD (2)?

In the worst case (Tracking programs running, priority 160) I
calculate that the mean sample time is 96.3 us and the sigma is 7.4
us. So each sample time measurement would have a statistical error of
7.4 us, or 7.4/96.3 = 7.7% for the mean value. Synchronization would
probably reduce this spread, right?

What is Axis_Proc?

Conclusion
==========

It seems to me that the vx works system has passed this test, and can
be superior in speed to the current system (faster scanning on bright
sources will be possible).

I would propose then that we continue assuming that this is how the PICNIC 
camera will be controlled. 

From the hardware point of view I guess we had already decided that
the current DIO board has enough free lines, or should we purchase
another one? a better one? Also, a new cable will be needed from the
output of this DIO to the camera interface box. We need to make sure
that the camera interface box is electronically compatible with the
DIO card input/output. I can work on that.

-- R.