R. Millan-Gabet

============================================
Report & Comments from CfA run on IOTA/FLUOR
============================================

Observers:      Wes Traub, John D. Monnier, Rafael Millan-Gabet

NICMOS3 Camera

A new problem with the NICMOS3 camera has appeared. When the Q_READ software runs, the quadrant display shows a fluctuating pattern noise. It is fluctuating in the sense that it comes and goes from frame to frame (although it is present in most frames), and it is patterned in the sense that when present it is very regular, as in digital noise or interference or pick-up from a well defined frequency. When imaging 64x64
pixels of the quadrant the minimum frame time is about 0.2 secs (which gives an idea of the time scale in the fluctuation); and when present the pattern appears in almost perfectly vertical stripes. I count about 7 periods in the 64x64 image, or 9 pixels/period. At an [access + read time] of about 21.25 usec per pixel  that corresponds to a period of 0.19 msec or a frequency of 5 KHz. When the background is high or there is a strong light signal on the array the interference pattern dissapears, and therefore seems to be a constant additive source of noise.

As of yet, I haven't had a chance to extensively test the system to characterize this problem more quantitatively, try to isolate it, or fix it.

The last time the camera was used before this run was by Jesse Bregman and Sebastien Morel in June 1999, and Sebastien tells me that this behaviour was not present then.

In fringe acquisition mode (fringes5 or fringes7) I see some regular spikes in the G3 display (Check Signals) at low light levels and in the fastest readout mode (1 read, 1 loop) that are perhaps consistent with barely sampling a 5kHz signal (it does look like a peak inmediately followed by a minimum, rather than spikes). I have recorded some scan data with our usual Quadra software in order to be able to diagnose this in Cambridge.

The rms of scan data with no light on the pixels looks normal (a few adu), and if comfirmed, the frequency of this extra signal falls outside of our fringe frequencies. Therefore for the moment we have been operating as is, with the additional annoyance of having to look at this pattern when we adjust the injection of the fiber outputs onto the 4 target pixels using the Q_READ program.

Future observers are encouraged to keep an eye on this problem and report to me any useful observations you might make.

PENTIUM/NICMOS Code

1) The original Pentium hard disk died in the Summer 99. Sebastien restored Windows  3.1, and all the NICMOS code that I had backed up in a ZIP disk. However the code for FLUOR that Damien worked on was lost. He sent us a copy of it a few days ago. I have made a directory in the Pentium called "FLUOR" where I put the programs to be used when using the NICMOS camera with FLUOR, and this should also be the directory for further development of these programs. I also made a directory called "Damien"
containing the backup of his code, in case you want to continue working on it. I note that Damien's version of Q_READ (which displays position and signal of 4 pixels instead of 2) doesn't seem to quite do the right thing (based on very quick inspection, I may be wrong on this), so for the moment we have continued using the original Q_READ program which only displays information about 2 pixels, and optimized the position and focus of the fiber outputs judging from the color coding.  I have put a copy of my Q_READ executable in the FLUOR directory, in case you want to use it too. In case further disasters occur with hard disks, there are backups of all the code in  ZIP disks in the big black steel cabinet.

2) A bug was found in the version of the NICMOS readout program (running in the Pentium) that was modified by Damien in order to accomodate readout of 4 pixels instead of 2, and by Sebastien in order to accomodate data transfers and commands to/from the G3 (currently called FRINGES7). The problem was that the new code accidentally switched the rows and columns in the coordinates of the target pixels. As
a result, the software was not sampling the pixels where the light from the 4 fiber outputs was being placed (using Q_READ). I fixed the code and commented it in a way I think should avoid this type of confusion in the future.  The config file from which FRINGES7 reads the target pixels coordinates (fringes7.cfg) is also free of ambiguities.

LabView Observing Software and FLUOR Control

 1) A bug was found in the combination of LabView FLUOR Observing Software and FLUOR Interface Box having to do with the logic of the PCI-MIO-16 bit DIO5.  Given the digital logic in the interface box, DIO5=1 addresses the SD limits and pulses, and  DIO5=0 addresses the LD limits and pulses. In the LabView software the logic was inverted and the program refused to start because it detected the wrong limits condition. The problem was solved by Sebastien inverting the logic of the DIO5 bit in the LabView software.

2) The G3 software does not start if it detects that the SD line is at a limit, which is a common occurence. But this makes it impossible to move the SD line out of the limit, since the SD is under G3 control. We could only get out of this situation by momentarily reconnecting the SD pulses input (DE9) and limits output from the IOTA "black box" (DB25) to the rate cards (as in "classical" IOTA operation), starting the
Quadra DelayLine software and moving the SD out of the limit. Then reconnecting the pulses and limits to the FLUOR interface box and restarting the G3 software.

By the way, Sebastien and I made long 9 pin (SD pulses) and 25 pin (limits) cables that reach from the FLUOR interface box to the rate cards area, with appropriate labels at each end.

3) There is a bug in the control of the fixed and delayed shutters from the LabView software: they are reversed. We fixed it by swapping the BNC cables in the box above the FLUOR table.

4) We could never make sense of the feature which allows to select channel indices in the Observing Software and in Check Signals ... does that really work?

5) We found wrong settings for driving the SD (speed too fast). This caused overflow of error signal and therefore a lost SD position. Also, the train of pulses sent out to the SD contains gaps at regular intervals. Also the speed that the G3 software thinks it is driving the SD seems to be twice the actual value, as measured by displaying the pulses output by the FLUOR interface box on an oscilloscope.

Ultimately, it became obvious that we were not finding fringes in autocol or on the sky because the SD was not at the proper place due to the bugs in the SD control  described above. Therefore we decided to use our IOTA DelayLine Control (DelayLine2.0.3) software to control the SD, and use the G3 software only to control the PZT scanner and do the data acquisition. In order to do this, I put a female DB25
connector on the cable that connects the limit switches from the IOTA "black box" to the rate cards. The corresponding cable from the FLUOR interface box can then be plugged in there so that the G3 software receives the limit switches information and can start happily.

6) The algorithm that tracks the sidereal fringe position doesn't seem to converge very well. Often we had to encourage convergence by clicking on "Track zero OPD" every time the SD was near the target  position.

7) The G3 seems to be always off in date by one day before midnight.

8) The G3 and Pentium hang very often during data acquisition. We have noticed that the Pentium always displays "Transfer" when this happens, so it is possible that the data transfer code between the G3 and the Pentium is not completly bug-free yet.

Ideas about Labview Software GUI Improvements

1) Since you measure the frame time, it would be nice to see in Check Signals a value of the mean signal in adu/ms (instead of adu); since that is a measure of the photometric signal that is independent of the readout mode. By the way, the measured frame time seems to vary a lot (factors of 2 sometimes), so perhaps there is a glitch in that part of the fringes7 code still.

FLUOR Optics

Wes Traub and John Monnier worked on aligning IOTA & FLUOR, I refer you to them for comments on how that went and on improved procedures they found.

Here are some obvious items:

1) The beam splitter cubes seem to have a wedge in them, as manifested by the fact that alignment is not preserved when they are used to view from the alignment telescope and then removed for operation.

2) The nominal FLUOR setup seems to be such that the beams travel on the table at an angle (vertically), as opposed to parallel to it ...

3) We noticed that there seems to be leakage of light between the photometric channels (putting light into the "delayed" beam only results in some light appearing in the "fixed" photometric output, and viceversa, possibly due to reflections at the couplers). Is this a known effect? Isn't this hard to calibrate?

4) Most of the time we didn't have well balanced signals in in the two photometric outputs ... was that our fault, or is there a built-in unbalance?

Notes on the New Long Delay Control

Here are the steps to get the server-client software running for commanding the long delay.

0) Turn on power to LD motor and laser. Laser needs a few minutes to warm up before it reports accurate positions.

1) Use a free terminal to telnet to the ldelay linux box

2) Log in as username: ldelay / passwd: compumotor

3) Type the following to become root:

        su -
        passwd: xxx (ask Marc)

4) cd /home/ldelay

5) Now there are two possibilities, depending on whether or not the linux box has been rebooted  since the last time the server-client software was run (there is no need to reboot the linux box ever, this will only happen if someone has been working on the code, or if there was a need to turn off the machine for some special reason).

Type lsmod or /sbin/lsmod to list the modules that are loaded.

5-a) If you see an entry for the at6400 driver and one for the hp10885a driver then the linux box has not been rebooted. In that case the steps are:

cd /home/ldelay/at6400
./load_at6400 (wait until the at6400 OS gets loaded into the card)

cd /home/ldelay/udp
./server

Then you can start the client software in the IOTA Delay Line Control Mac (currently
DelayLine2.0.3).

5-b) If you don't see entries for the at6400 and hp10885a drivers in lsmod, then the
modules need to be reloaded:

cd /home/ldelay/at6400
./load_at6400
./1
cd /home/ldelay/hp10885a
./1
cd /home/ldelay/udp
./server

Then proceed as above to run the client software.

6) At the end of the night, turn off the power to the LD motor and laser (out in the hut). Those two are plugged into a single power strip that just needs to be turned off. Do not turn off anything else, particularly the linux box.

note:
=====

The server-client software is still rather flaky. Sometimes you will find that the client does not execute move commands, or that you get wrong Home or Limit switch information. We have found that simply restarting client helps. Believe it or not, a good indication that the software is going to run properly is getting a "Command Error" message when the client software starts. You will also get error messages
concerning drive 2, but that is normal since the second LD is not powered.

Conclusion
==========

We succesfully observed several sources in the last three nights. We obtained weak fringes in the star Ci Cam (a symbiotic system which was also observed last year with the classical system), which is K=4.9; and your magnitude limit measure was better than 5 in our last night.

It has been a pleasure (and a challenge) observing with FLUOR. We look forward to our next run on it!