Observers:      John Monnier, Rafael Millan-Gabet, Irene Porro, Wes Traub

(0) Results

In short, this has been a very productive run. Here's a summary in the form of an annotated schedule:

Jan. 23 - Jan. 30, 00:
=====================
     * Setup & first fringes
 

Jan. 31 - Feb. 06, 00:
=====================
     * Observations on S15N15 baseline.
     * We had 3 nights of bad weather/seeing and
       4 very good nights.
     * Very good quality data obtained on: IK Tau, VY Cma, HD62623, R Crt,
       V Hya, Alp Ori, R Leo, RT Vir, R Hya, W Hya and RS Vir.
     * We also took diagnostic data in order to study any possible effects on the calibration of:
        IR flux, fringe speed, star tracker flux, star tracker frequency and alignment of fiber input on
        parabola star image.
 

Feb. 07 - Feb. 09, 00:
=====================
     * Observations on S15N25 baseline (chosen to provide optimum continuity
       with Keck coverage for the target sources).
     * In general the weather/seeing degraded for these last three nights.
     * Got good/decent data on: IK Tau, VY CMa, HD62623, V Hya, R Crt,
       R Hya and RS Vir.
     * Recorded data for diagnostic of NICMOS cam noise that appeared in
       Nov 99, with and without ADC input shorted to ground, and at
       different readout speeds (see 2 below).

(1) IOTA General
 

Nat Carleton and Wes Traub re-installed the re-silvered and re-coated dihedral mirrors, so we should all measure better throughputs.  Let's all try to document some photometric comparisons with previous runs in order to characterize the expected throughput improvement.

One of the fixed beam dihedrals was put back at a somewhat different position, so that the delay in that arm is now 1-1.5 cm shorter. See below for new magic constant values found.

An interferometer that can be installed at the domes was designed and built by Wes that can be used to align the telescopes without going through all the flat mirrors in the system.  The light source is the
laser shot from the lab, and fringes are imaged (for now) on a paper card. We used this new gizmo to improve focus on both telescopes and fix a tilt problem with the secondary in the south telescope that was
noticed in December 1999. Ultimately it would be nice to image the fringes on a TV camera, and control the secondary actuators via the picomotors (we did it by hand, which is not very sensitive).

However, later in the run, by looking at stars through the aligment telescope in the lab, the star focus didn't look so good, particularly in the south telescope. In both telescopes the best focus looks
comatic. So it seems like things have drifted and the telescope alignment needs to be improved again.

On Feb 01,00 John ran a telescope pointing model, while we were at the S15,N15 configuration. We now get better than 30" pointing (down from 4' in the north telescope).

When we moved to the S15N25 configuration though (on the night of Feb 06,00), using that same pointing model gave us back few arcmin offsets, at least in some parts of the sky.

(2) NICMOS Camera
 

No progress on fixing the new noise that appeared in November 1999.  I recommend taking fringe data with at least 4 reads 1 loop whenever possible, which appears to average it out quite effectively. I  apologize that this problem is still here.

I only had the opportunity to determine that shorting the ADC input to ground (eliminate the dewar from the signal chain) makes the problem go away completely. Therefore the problem lies somewhere inside the
dewar, in the pre-amp or detector card, or perhaps in the driving waveforms.

The dewar was nicely baked and pumped at the beginning of our run, and has consistently been holding the pressure at 5 uTorr.

(3) WLF Position
 

The values of the approx. FLUOR magic constant we found are as follows:

(baseline: S15,N15)

Autocol: MC=3.094 m
Sky:     MC=3.132 m

(baseline: S15,N25)

Sky:     MC=6.886 m

We warn non-fluor experts that in autocol, the G3 Observing Software filters out the actual fringe frequency in the QuickLook signal.  So, when searching autocol fringes, one must keep all the scans and look at them in I1 or I2 in the Obs. Block Viewer. Alternatively, one can change the lambda selection in the G3 OS to have a bandpass that is centered on 2.2 um but wider in order to include errors of factors of
2 in either direction (say, 0.83 um to 4.71 um).

(4) Long Delay
 

Marc updated the user and su passwords on the long delay server. Since this document will be e-mailed, ask Marc, Sebastien or Rafael  for the new passwords.

We now have a script, ldelay.star, that contains the sequence of commands to initialize and run the long delay server. The corresponding script to unload the modules and stop the server is ldelay.stop. Both scripts still need to be run by su. Petar is working  on versions of the scripts which can be run by normal users.

Note that current practice is to shut off power to the LD motor and laser (a single switch in a labelled power strip at the hut) at the end of the night.  Therefore, although in principle there is no reason
to ever stop the server, turning off laser power seems to confuse it so that even after turning the power back on, the laser voltage is never detected. The only solution is to kill the server and restart it
after turning the power back on. To kill the server one can use the ldelay.stop script described above, or, in order to avoid unnecessary unloading of the modules and at6400 OS, simply type "ps -ax" to get
the server process number and then type "kill process_number".

Also (a corollary of the above), if the laser signal happens to not be detected even just once, for example because of slight misalignment of the laser beam (the Quadra will pop up a window advertising this
fact), Delay.Line2.0.3 needs to be quit, then the server needs to be killed and restarted, and then Delay.Line.2.0.3 needs to be restarted.

Recall that the Quadra software does not restart remembering the last LD position, so it is best to write down the LD position before quitting the program.

Desired code upgrades/fixes?: (a) server recognizes the lack of laser signal as a valid condition and reacts to it when it is restored, without having to restart it; (b) client saves the last LD position and re-starts with it as a default; (c) one time we didn't know where the LD was, and in the process of trying to guess we commanded it past home, and it hit the microswitch. Therefore the part of the software that was supposed to detect the limit prior to the microswitch and stop the LD doesn't seem to have worked.

(5) G3 Observing Software (OS)
 

The current version provided by Vincent and installed on Jan 25,00 is MUCH improved compared to Nov 99. It basically all works very well. On Feb 03,00 Vincent provided and we installed yet another version which includes an "Ascii Data Dumper", so that groups can take home data that can be read by any program. Thanks Vincent!

Here is our list of friendly comments:

5.a - There is still something fishy about the part of the G3 OS that has to do with the SD control. We have had many instances of the following two bugs: (1) The "Current carriage position" displayed by
the G3 OS suddenly jumps by many meters (usually advertises that the position is +- 22m!)  ... this must be purely software of course, but it forces one to re-home to recover normal SD positions displayed, or
drives the SD into a limit. (2) The SD truly losses its position. We just realize this because we suddenly lose the fringe, and after much searching we decide to re-home, and find that the SD position was off
by anywhere from several mm to tens of cm.

In addition to a drift in MC that is expected from a non-perfect baseline solution, we tend to have a +- few mm variations in MC; which may be related to problem (2) above.

5.b - Pulses are sent out to the SD by the G3 MIO card even after quitting the OS. The solution is to turn off the pulses switch on the FLUOR interface box. This is a problem particularly in two scenarios:
(1) When switching back and forth between G3 and Quadra control of the SD, for debugging purposes. If the G3 continues to send pulses, then the SD will take off as soon as you re-connect the SD pulses cable to the FLUOR interface box, invalidating whatever test of the SD position you were trying to make. (2) Sometimes we get G3 crashes or errors in the OS (see below) that cause it to stop running. Any SD pulses sent out are then not counted, and the SD position is lost. This is really only confusing in the "soft re-start" mode, which doesn't begin by homing the SD.

5.c - One error that is pretty destructive is the "You have requested a number of data points greater then the number of useful frames"; the OS then stops, but not the pulses, causing the loss of SD position
mentioned above (5.b).

5.d - Frequent G3 crashes ... I suspect having to do with communication with the Pentium. This happens 2-3 times per night, although on one ocasion we had 5 crashes in 2 hours!

5.e - Sometimes, we get an error message that says "you have requested a scan length above 180 um"; when that is in fact not true.

5.f - Mistery error, this one we have no clue what it is about: "Error in Arbitrary VI Filter: the filtering function does not have the same size size as the one-sided spectrum of the signal".

5.g - See (3) above on digital filtering of QuickLook signal in autocol.

(6) Alignment
 

In this run (we didn't notice this in Nov 99) we always had to re-adjust the XY position of the fibers (via the piezo controls) between sources, including between source and calibrator, by many 10s of volts. Does anyone have a theory on why this might be the case? The previous theory went that the star trackers define the direction of the incoming beams, and that any star that is tracked should end up focused at the same place on the FLUOR, or any, table. The only thing we can think of is that color differences between target and cal cause slightly different centroid tracking; and in fact it seems like when the sources have very different colors this adjustment becomes more important, and is unnecessary when the target/cal pair have similar colors.

We've had some confusion with our usual process of LD yaw correction: sometimes we have found the reference used for yaw adjustment off *vertically*, and this always coincides with some loss of flux on the
CCDs from the delayed beam. We don't have an explanation, and whenever the flux loss was significant we simply peaked it up empirically by aiming the beam using the star tracker mirrors. Interestingly, at the
end of this procedure we would always recover the correct reference vertically.  Although we haven't really monitored/documented this carefully, it seems pretty clear that this vertical angular offset
increases with distance traveled along the LD track, and becomes noticeable past about 8-9 m.