by Sébastien Morel
Dates: 9/14/2000 to 9/30/2000
Weather: still some thunderstorms, though summer should be over now. Globally, the night sky was never very clear. Only one night was overcast and prevented from observing. Many times, the sky was cloudy at the beginning of the night, then improved, allowing to observe.
Pumped for 13 h and cooled, after having not been used for more than 2 months. Pressure gauge on the ion pump read less than 1e-6 Torr. It seems that the ion pump needs a rest after about 5 days of duty (blinking gauge ? : Unplug it for a day, then replug. It will blink again then going back to low pressure after 1 hour). The correlated noise is unfortunately still present, but doesn't seem to be worse than before.
The hard-drive of the NICMOS PC has been damaged but not destroyed (like last year). It has been plagued with unreadable sectors, and the fringes7 program could not be executed. Hopefully, an archive on a zip-disk, dated 11/20/99 and containing all the NICMOS software for FLUOR exists in the lab.
The coupler (cleaned up at "Le Verre Fluoré" last summer) has been reinstalled. Room has been made on the FLUOR table for the future output pipe of the third telescope. The coupler box has been sealed with tape to stop dust infiltration. This is maybe useless. However, cracks on the box near the output connectors (due to holes that have been drilled larger than the connector size) are visible and are maybe a source of dirt. Maybe they should be filled with stuff like RTV.
A small CCD camera (former pointing camera) has been installed on the table, at 90 degrees from the alignment refractor telescope (ART). When the ART uses the right-angle eyepiece, it can be possible to rotate this eyepiece such that the CCD "looks" through it. The image is displayed on a TV monitor put on the IR table. This system enables alignment operations (rough "FLUOR on IOTA", pupil optimization) done by one operator. Also, a monitor put on the visible table (not the best place, actually) can be plugged into the star-tracker Mac for fine "FLUOR on IOTA" alignment.
Improvements of the transmission of pulses from the G3 to the Harvard Velocity Servo Board (HVSB) have been made last summer. Basically, a differential line driver has been added to the G3 interface, a shielded cable is used for carrying the signals, and impedance matching of the HVSB has been made. Oddly, the Anorad carriage moved by exactly twice the length that was requested by the G3. This was due to a kludge in the FLUOR piece of software that computes the delay-line position from the virtual encoder value: this value was somewhere divided by two to yield the position. This suggests that with the previous transmission system, one pulse out of two was actually received.
Also, some little things had to be fixed: - Blown-up line receiver on the HVSB. - FLUOR interface box: home flag didn't work. Since this box doesn't have to control the long delay-line anymore, simplification of the electronics was possible by replacing some chips with short-circuits or open-circuits.
With the second Anorad carriage installed by C. Papaliolios at the south of the existing one (used by FLUOR), the position of the home has been moved by 43.8 cm (see report from JDM and CP). The magic constants that gives fringes with FLUOR when the S15-N15 baseline is used are now:
- North beam delayed: between 2.242 m and 2.250 m - South beam delayed: between -2.019 m and -2.000 m
These intervals suggest a small error in the baseline vector, but the delay-line control is not flawless yet. Position error overflows ("plik !") were often heard, especially when fringes were searched for in a given direction (if this happens, use the other limit of the MC and change the direction. Experience proved that in south beam delayed, it's better to go in the positive direction). For searching the fringes, I suggest to use a 80-um increment step in 4-reads-4-loops and 4-reads-3-loops, 60 um in 4-reads-2-loops, and 40 um in 4-reads-1-loop (when the scan length is about 160 um).
Also, from what I saw in the FLUOR code (but I may be wrong), no more pulses are sent to the Anorad when the "Track Zero OPD" button has been released, though it should gently decelerate the carriage until zero velocity is reached.
Other little bug in the software: it's impossible to back-out the carriage from a limit if it has been hit. This should be possible because the software can have knowledge of which limit has been hit (south or north) and can therefore deduce the back-out direction for the carriage.
The travel of the delay-line has been set in the software at 1.95 cm. However, scanning on the 40-cm zone near the home is not recommended and may cause artifacts in the fringes.
First, retro-illuminate the fibers by using the maglite bulb. Check with the ART (focused at infinity) + beamsplitter cube (BSC) that the fibers show a well uniform disk (this should have not changed from the last time).
If the visible table has been previously aligned, a first "FLUOR on IOTA" alignment check can be done as following:
The two first nights, I could not get the star from the fixed beam on the CCD. I used this alignment procedure I like to do:
NEVER TOUCH ANY TELESCOPE POST FOR ANY REASON ! THEY MUST ALWAYS BE ON THE REFERENCE AXIS OF IOTA !!!
(to-do: check that all the posts are well aligned with the reference axis of IOTA -given by the post at the east end of the visible table-, tighten them and put labels reading it's forbidden to touch the post !)
Obviously, the first fringes of the run appeared shortly after this had been fixed...
Nothing special to say. The DC offset was wrong. In this case, just turn the knob on the amplifier until the OFL LED is always off. Double check the result by displaying the piezo command signal and the returned position on an oscilloscope in XY mode (I suggest to have the scope turned on like this for all the night).
First scans (took on a calibrator) indicated a very low and stable transfer function (15%). By moving a little the coupler to let one of the input fiber stretching itself, a higher transfer function was noticed. However, maybe this was due to another reason that occurred meanwhile. I am not a specialist of polarization, so I don't know exactly. Until the end of the run, transfer functions were around 80 to 90 %
Cleaning-up the coupler was not useless. In 4-reads-4-loops mode, the K' limit magnitude, reckoned by the FLUOR software reached 4.9 but was most of the time a little below. However, the transparency of the sky was never really good. Under a clear sky, 5.5 should be possible.
Tests of new coherencing methods were carried on. The complete NASA-Ames algorithm for finding center of a fringe packet was not available at the time of the run, so we used the classical FLUOR method (filtered fringes centroid) to estimate the OPD. However two things were tested: - OPD estimator based on an auto-regressive model computed by recursive least-squares algorithm. - Variable loop gain (from 0 to 1, 0.2 step).
Scans in open-loop (by setting the fringe detection threshold at 200!) were also recorded. Different scan rates have been used for these tests. All these results suggest that a noise in the OPD error signal is generated by the coherencing itself (likely due to delay-line control). After a few scans, the fringes jump (by about 60 um). This seems to be another delay-line problem. Also, sometimes the fringes totally disappear, and you have to paddle a little to find them again.
A thorough analysis of the data taken during the above tests will be necessary to find a way to optimize the coherencing (I have already some ideas about it).
OBSERVATIONS OF SYMBIOTIC STARS
Assuming that these objects are not perfectly spherical but may feature ejections of matter due to the gravity field generated by a small companion, visibility measurements were done super-synthesis (plotting visibility vs. hour angle to get a coverage of the (u,v) plane as large as possible). The following symbiotic stars have been observed this way: