ELOG 40m

PMC transmittance at high power

We received a new cable for the Scientech calorimeter. So I measured the transmittance of the PMC at higher power.

Summary:
Input power = 2.298W
Output power = 1.364W
Transmittance = 59%

Detail:
The input power to the PMC was measured between the two mode matching lenses by the calorimeter.
2.298W looks a bit too low. Actually, the calibrated monitor PD on the MEDM screen shows about 3W output from MOPA.
So we (me and Steve) measured the power right after the PBS after the periscope from MOPA with the HWP set to maximize the transmission of the PBS.
It was 2.77W. According to Steve's previous measurement, the first mirror of the periscope transmits about 200mW of the incoming light to the monitor PD. So the actual output of the MOPA is about 2.97W, which is consistent with the monitor PD reading.
The aperture of the EOM for the PMC control is glowing a lot. We suspect this is the main cause of the loss (from 2.77W to 2.298W).
We may want to re-align the EOM.

The output light from the PMC was picked off by a glass slide. The reflectance of the glass slide was measured first at a lower power (input 98mW, reflected power 1.58mW). Assuming that the reflectance is the same for the higher power, I turned up the input power to the PMC. This time, the picked off power was 22.45mW. This means the actual output power is 98/1.58*22.45=1364mW. The glass slide was kept at the same angle through out the measurement.
The measurement of the output power was done by the Ophir power meter. So calibration difference between the Ophir and the calorimeter may introduce some error.

535

Mon Jun 16 18:26:01 2008

Max Jones

Noise Budget Changes

In the directory cvs/cds/caltech/NB the following changes were made:

I created temporary files in ReferenceData for the C1 by copying and renaming the corresponding H1 files.
- C1_SRD_Disp.txt
- C1IFOparams.m
- C1_NoiseParams.m

In getmultichan.m I added a C1 case.

In NoiseBudget.m I added a C1 case with modified sources array to include only DARM and Seismic

I appreciate and suggestions. Max.

537

Wed Jun 18 00:19:29 2008

15 day trend of MOPA channels. The NPRO temperature fluctations are real, and causing the PMC to consistently run up against its rails. The cause of the temperature fluctations is unknown. This, combined with the MZ glitches and Miller kicking off DC power supplies is making locking rather tetchy tonight. Hopefully Yoichi will find the problem with the laser and fix it by tomorrow night.

Attachment 1: MOPAtrend.png

539

Wed Jun 18 16:37:54 2008

steve,rana

SAFETY

CO2 test in the east arm

The CO2 laser and table are in the east arm for characterization of the mechanics. We
will not be operating it until we have an SOP (which is being written). No worries.

Attachment 1: co2.png

540

Wed Jun 18 18:20:10 2008

Investigation on the NPRO temperature stabilization glitches

As Rob pointed out in http://dziban.ligo.caltech.edu:40/40m/537 the MOPA NPRO has been showing some glitchiness in the LTEC loop.
Following Rana's suggestion, Steve and I opened the MOPA and directed a heat gun for a minute to the NPRO hoping that we can see something in the LTEC loop.
The first attachment shows the behavior of LTMP and LTECH along with DTMP and DTECH at the time of the heat gun attack.
T=0 is the time when Steve directed the heat gun to the NPRO. There is no response neither in LTMP nor LTECH.
DTMP and DTECH look like responding.
Around the center, there is a dip in LTMP. This might be caused by removing the heat gun. But we are not sure. This kind of small glitches can be found in LTMP everywhere (see the attachment 2).
It looks like the LTMP sensor is not working, or the LTECH loop is actually working but the LTECH reading is broken.
However, the scan of the slow actuator (temperature) shows the LTECH loop is actually working. So it is a bit confusing.
More investigation is necessary.
See the next entry by me.

Attachment 1: LTEC-loop-HeatGun-Response.pdf

Attachment 2: LTMP-glitches.pdf

541

Wed Jun 18 18:26:19 2008

Finding the optimal operation temperature for the NPRO by the slow act scan

Being suspicious of the temperature stabilization of the NPRO crystal, I ran the slow scan script written by Rana to find the suitable operation temperature.
The procedure is the same as the one explained in the entry below:
http://www.ldas-sw.ligo.caltech.edu/ilog/pub/ilog.cgi?group=40m&task=view&date_to_view=09/04/2006&anchor_to_scroll_to=2006:09:04:22:23:56-rana
The attached plots show the results. By looking at C1:PSL-126MOPA_126MON, I set the slow slider voltage to 0.
This time, it looks like the temperature control of the NPRO crystal is working fine.
Obviously, PMC picks up many higher order modes. I will try to mode match/align the PMC later.

Attachment 1: FSS-slow-scan.pdf

542

Wed Jun 18 18:32:09 2008

Max Jones

NB Update

I am reconfiguring the the noisebudget code currently in use at the sights. To that end, I have done the following things (in addition to the elog I posted earlier)

In get_dtt_dataset.m - I added C1 specific cases for DARM_CTRL, SEIS, and ITMTRX changing the specific channels to make those in use at caltech

In LocalizeSite.m - I changed the NDS_PATH to match caltechs. I left NDS_HOST untouched.

Since I am trying to get SEIS and DARM to work initially I added C1 specific cases to both of these.

Better documentation may be found in /users/mjones/DailyProgressReport/06_18_08. Suggestions are appreciated. Max.

544

Wed Jun 18 18:50:09 2008

It can only be attributable to human error. (HAL - 2001)

Computers

There has been another one of "those" events and all of the front end machines are down.

We poked around and Rob determined that the FEs can't get the EPICS data from EPICS. The
dcuepics machine is hooked up and running and all of the epics binaries are running. We also
tried resetting its RFM switch as well as power cycling the box using the "poweroff" command.

Not a sausage.

Rob points out that although the Signal Detect lights are on on the cards, the 'Own Data' light
is not on on the dcuepics' card although it is on for some of the cards on the other boxes.

We have placed messages with the Russian. If anyone sees him, don't let him go without fixing things.
Also, make sure to follow him around with notepad and possibly a camera to record what it is that
he does. If he's muttering, maybe try to use a sensitive hidden sound recorder.

546

Thu Jun 19 20:22:03 2008

I called Rolf (@LLO) who called Alex (@MIT) who suggested that we power cycle every crate
with an RFM connection as we did before (twice in the past year).

Rob and I followed Yoichi around the lab as he turned off and on everything. There
was no special order; he started at the Y-end and worked his way into the corner and
finishing at the X-End. Along the way we also reset the 2 RFM switches around fb0.

This cured the EPICS problem; the FEs could now boot and received the EPICS data.

However, there are still some residual channel hopping-ish issues which Rob and Yoichi are
now working on.

547

Fri Jun 20 01:38:55 2008

Yoichi showed me that its possible to make PNG images from PS using GS:

gs -sDEVICE=png16m -sOutputFile=foo.png bar.ps

Attachment 1: test.png

548

Fri Jun 20 02:20:33 2008

PMC transmittance degradation

The PMC transmitted light power has been degrading constantly for last two weeks (see the attachment 1).
I went down to 2.55V.
The output of the MOPA is constant during this period. More strangely, the reflected power from the PMC is also constant.
One possible explanation is the contamination of the PMC mirrors. But I don't know why it started two weeks ago.

I tweaked the alignment of PMC and was able to recover the transmitted power to above 2.7V (attachment 2).
I will keep eye on this issue.

Attachment 1: pmc_trans_long_trend.pdf

Attachment 2: pmc_trans_improvement.pdf

549

Fri Jun 20 08:30:27 2008

stiv

Photos

40m summer line up 2008

atm1: John, Alberto, Yoichi, Koji, Masha, and Sharon

atm2: surf students Max of CIT, Sharon of MIT, Masha of Harvard, Eric of CIT not shown

Attachment 1: P1020559.png

Attachment 2: P1020560.png

550

Fri Jun 20 17:42:48 2008

steve

SS trap scattering compared to black glass trap

Circular SS304 trap was compared to wedged black glass trap.

The measurement set up of entry 529 was changed to define polarization.
CrystaLaser was remounted in horizontal position and half wave plate was placed after it.
These measurements were done in horizontal polarization.

atm1: the cSSt and wBGt was moved horizontally, ~90 degrees of the incident beam
atm2: traps were rotated around the incident beam, ~20 degrees each direction
atm3: set up
atm4: top view of traps
atm5: side view of trap

Attachment 1: cSSt_1.png

Attachment 2: cSSt_2.png

Attachment 3: scatset_61908.png

Attachment 4: cSSt&wBGt.png

Attachment 5: cSStbeam.png

553

Mon Jun 23 19:33:01 2008

We looked at the MC_F spectrum because Rob and Yoichi said that it had gone 'all crazy'. It
seemed fine as we looked at it (even with only one boost stage on) so we looked for things
that might be marginal and make it go nuts.

At the error point (Q mon on the demod board and TEST IN1) of the MC Servo board we saw the
old 3.7 MHz signal (comes from the 33 MHz RFAM getting demodulated by the 29.5 MHz MC LO)
and thought that this might cause some worries. So we installed Jenne's passive elliptic
low pass which has a 3.7 MHz zero.

This wiped out the 3.7 MHz noise but we were not able to re-create the extra frequency noise
so its unlikely to have fixed the main problem. However, we leave it in because its good. If
there is a need to revert it, we have left hanging on the side of the rack the old cable which
was a SMA->TNC making a direct, unfiltered connection between the MC Demod board and the MC
servo board.

More before and after results from Jenne tomorrow, but for now here is a calibrated MC_F spectrum
using the new MC_F-Reference.xml template file.

We also noticed that we could make some small effects on the MCF spec by adjusting the PMC gain so
there's probably more hay to be made there using a lead brick and a gain slider. More in Jenne's
entry.

Attachment 1: mcf.png

555

Mon Jun 23 21:51:19 2008

Alberto

Arm Cavity Length Measurement

We measured the arm cavity lengths sweeping the ETM mirror position and looking at the reflected demodulated output. We excited the mirror by a sine wave of 0.2 Hz and amplitude of 30000 counts. From the time series of the occurrences of the resonances of the sidebands and of the carrier we evaluated the free spectral range of the cavities and thus the lengths. The details of the procedure are explained in the attached document. As discussed in it, for each cavity we obtain two possible values of the length depending on which of the sideband resonances is that corresponding to the upper sideband and which corresponds to the lower one instead. The numbers are:
Lx=(38.30 +/- 0.08)m / (38.45 +/- 0.08)m
Ly=(38.16 +/- 0.08)m / (38.70 +/- 0.08)m

Since the difference between the two possibilities is quite large, we should be able to decide which one is correct by somehow measuring directly the cavity length. We want to try it tomorrow by a tape meter.

Alberto and Koji

Attachment 1: 40mLengthMeasure.pdf

556

Tue Jun 24 10:24:43 2008

Abs. Len. Meas. ~ Cavity Swing Measurement (2)

At the entry 555, Alberto reported the results of the cavity length measurement using cavity sweeping.
As expected, each result inevitably has an ambiguity depending on which resonance do we take as an upper sideband.

In order to exclude this ambiguity Steve and Koji performed a primitive non-optical measurement using a tape and photos:
This morning Steve and Koji did tape measurements to know the lengths between the ITM/ETM chambers.
Yesterday, Koji took photos of the optical tables in vacuum to know the actual positions of the suspensions.

The results are shown in the figures attached. From those non-optical measurements the lengths of the X/Y arm are known to be 38.48+-0.03 / 38.67+-/0.03 [m].

Then, we could exclude the shorter lengths of the values in the entry 555. i.e. The Y arm is longer than the X arm about 0.2 m.

These approximate lengths will be used in the further precise measurements which use precise scans of the FSR frequencies.

Attachment 1: armlength.png

Attachment 2: armlength2.png

559

Tue Jun 24 22:31:10 2008

Masha

my first step in fiber stabilization

Auxiliary locking

There is a new 1W INNOLIGHT NPRO laser at the Symmetric Port.

Set up an interferometer to measure difference in phase noise introduced by a fiber. Works as expected without the fiber! (balanced intensity, out of phase noise in the two outputs).

563

Wed Jun 25 09:46:45 2008

Sharon

Adaptive Filters

I have been learning about different methods for applying adaptive filters to improve the Mode Cleaner lock in specific, and other LIGO systems in general.
Finding the exact number of coeffs we would like to apply for our FIR adaptive filter is very important to the efficiency of the filter. Getting this number higher might improve the accuracy of the filter, but costs time we do not have. Another important number to find is the step size. The step size is the variable that controls how far back we want to look into our data for finding the new coeffs. To understand more about the step size it is necessary to learn about the standard deviation of our input and output signals. By getting the step size too big, we are considering long term behavior, but might be missing out on a short term one.
In the near future I will be learning about the meanings of these variables and their contribution to the over all accuracy of our filters.
Results will be posted.

564

Wed Jun 25 11:01:45 2008

For the first week, I have been learning about fiber noise cancellation, auxiliary locking techniques, and other relevant helpful topics in more detail. I am now working on a setup (more detail in previous entry) to measure phase noise introduced by 25m(?) fiber, and then will proceed to try to cancel the noise.

565

Wed Jun 25 11:36:14 2008

Max Jones

First Week Update

For the first week I have been modifying the noise budget script in caltech/NB to run with 40 m parameters and data. As per Rana's instructions, I have tried to run the script with only seismic and Darm sources. This involves identifying and changing channel names and altering paramter files (such as NB/ReferenceData/C1IFOparams.m). To supply the parameter files, I have copied the H1 files with (as yet only) slight modification. The channel name changes have been made to mirror the sites for the most part. Two figures are attached which show the current noise budget. The Day plot was taken 6/23/08 at ~10:30 am. The night plot was taken 6/22/08 at ~11:00 pm . Note that the SRD curve is for the sites and not for the 40 m (I hope to change that soon). Also in one of the plots the DARM noise signal is visible. Obviously this needs work. A list of current concerns is

1) I am using a seismic transfer function made by previous SURF student Ryan Kinney to operate with channels of the form C1:PEM_ACC-ETMY_Y (should I be using C1:DMF-IX_ACCY?) and the channels I am currently using are the acceleraometers for the mode cleaner with names of the form C1:PEM_ACC-MC1_X. Rana said that he thinks these may be the same but I need to be sure.

2) We don't have a DARM_CTRL channel but the code requires it, currently I am using DARM_ERR as a substitute which is probably partly responsible for the obvious error in DARM noise.

Any suggestions are appreciated. Max.

Attachment 1: C1_NoiseBudgetPlot_Day.eps

Attachment 2: C1_NoiseBudgetPlot_Night.eps

567

Wed Jun 25 13:38:22 2008

Abs. Len. Meas. ~ Placement of the 700mW NPRO on the AP table

This morning I have put the 700mW NPRO on the AP table for the abs length measurement.

The RF amplifier was moved (the cables were not changed). I cleaned up some cable arrangements. I was keen not to disturb any of the other optical path. Even so, please let me know if any suspicious behaviour is found on the AP table.

Attachment 1: NPRO700mW_placement.jpg

571

Thu Jun 26 01:10:18 2008

Alarm Handler indicates that dust level is high

PEM

In its first useful act, the Alarm Handler started beeping indicating that the dust particle
counts for particles of diameter less than 0.5 micron had exceeded 5000 /cu. ft. Here's the
80 day trend of particles, temperature and humidity:

Attachment 1: Untitled.png

572

Thu Jun 26 10:56:15 2008

I removed the Bartington Magnetometer on the x arm to one of the outside benches. I'll be trying to determine if and how it works today. It makes a horrible high pitched sound which is due to the fact that the battery is probably 16 yrs old. It still works with ac power though and I want to see if it is still operating correctly before I ask to buy a new battery. Sorry for the bother.

574

Thu Jun 26 14:06:00 2008

Masha

500mW INNOLIGHT NPRO info

Below is the placement of 500mW INNOLIGHT NPRO mephisto laser. It is set up on the Symmetric Port table.

575

Thu Jun 26 18:24:28 2008

FSS input ofset slider problem - fixed

I checked the FSS servo interface board and found that a LT1125CSW used to differentialize offset channel was broken (no virtual short).
So I replaced it. Now the slider is working.
The op-amp was hitting the rail. So it seems like we had been applying the maximum offset to the FSS input all the time.
The reason why the FSS loop still worked with the large offset is that the applied offset (~14V) is attenuated by a factor of 500 at the summing point.

576

Thu Jun 26 18:27:04 2008

No Dataviewer No Cry

Dataviewer was hanging. It would open the Grace window but then not plot anything. Since DTT was working
fine we diagnosed this as a DV only problem. It turned out that there was a boatload of messages in the
dataviewer queue. You can check for extra messaages using the command 'ipcs -q' and then use 'rmq' to remove them.

Dataviewer is working now.

Here's the screen dump from op440m:

op440m:~>ipcs -q
IPC status from <running system> as of Thu Jun 26 18:19:32 PDT 2008
T         ID      KEY        MODE        OWNER    GROUP
Message Queues:
q        400   0x1a51     -Rrw-rw-rw- controls    staff
q          1   0x501      -Rrw-rw-rw- controls    staff
q          2   0x512      -Rrw-rw-rw- controls    staff
q        103   0x553      -Rrw-rw-rw- controls    staff
q          4   0x574      -Rrw-rw-rw- controls    staff
q          5   0x18be     --rw-rw-rw- controls    staff
q         56   0x1d9f     -Rrw-rw-rw- controls    staff
q          7   0x1e56     -Rrw-rw-rw- controls    staff
q          8   0x1efd     -Rrw-rw-rw- controls    staff
q        109   0x2044     -Rrw-rw-rw- controls    staff
q         10   0x207a     -Rrw-rw-rw- controls    staff
q         11   0x24c4     -Rrw-rw-rw- controls    staff
q         12   0x24d7     -Rrw-rw-rw- controls    staff
q         13   0x251b     -Rrw-rw-rw- controls    staff
q         14   0x2fe8     -Rrw-rw-rw- controls    staff
q        115   0x3a65     -Rrw-rw-rw- controls    staff
q        116   0x967      -Rrw-rw-rw- controls    staff
q         17   0x98e      -Rrw-rw-rw- controls    staff
q        118   0x456c     -Rrw-rw-rw- controls    staff
q        669   0x194      -Rrw-rw-rw- controls    staff
q        620   0xe70      -Rrw-rw-rw- controls    staff
q         71   0x15d0     -Rrw-rw-rw- controls    staff
q        222   0x3586     -Rrw-rw-rw- controls    staff
q        173   0x5e37     -Rrw-rw-rw- controls    staff
q        624   0x5e4d     -Rrw-rw-rw- controls    staff
q        475   0x10d7     -Rrw-rw-rw- controls    staff
q        176   0x5ee3     -Rrw-rw-rw- controls    staff
q        277   0x4e22     -Rrw-rw-rw- controls    staff
q        428   0x25f3     -Rrw-rw-rw- controls    staff
q         29   0x3354     -Rrw-rw-rw- controls    staff
q        180   0x368f     -Rrw-rw-rw- controls    staff
q        131   0xb0f      -Rrw-rw-rw- controls    staff
q         82   0x47a5     --rw-rw-rw- controls    staff
q         83   0x4b83     -Rrw-rw-rw- controls    staff
q         34   0x4f6d     -Rrw-rw-rw- controls    staff
q         85   0x4539     -Rrw-rw-rw- controls    staff
q         86   0x67a1     --rw-rw-rw- controls    staff
q         37   0x4b7      -Rrw-rw-rw- controls    staff
q         38   0xd37      -Rrw-rw-rw- controls    staff
q         39   0x156c     -Rrw-rw-rw- controls    staff
q         40   0x2b62     -Rrw-rw-rw- controls    staff
op440m:~>rmq
---------------------------------------------------------------
Deleting message queues which are owned by user: controls ....
---------------------------------------------------------------
      Deleted message queue: 400
      Deleted message queue: 1
      Deleted message queue: 2
      Deleted message queue: 103
      Deleted message queue: 4
      Deleted message queue: 5
      Deleted message queue: 56
      Deleted message queue: 7
      Deleted message queue: 8
      Deleted message queue: 109
      Deleted message queue: 10
      Deleted message queue: 11
      Deleted message queue: 12
      Deleted message queue: 13
      Deleted message queue: 14
      Deleted message queue: 115
      Deleted message queue: 116
      Deleted message queue: 17
      Deleted message queue: 118
      Deleted message queue: 669
      Deleted message queue: 620
      Deleted message queue: 71
      Deleted message queue: 222
      Deleted message queue: 173
      Deleted message queue: 624
      Deleted message queue: 475
      Deleted message queue: 176
      Deleted message queue: 277
      Deleted message queue: 428
      Deleted message queue: 29
      Deleted message queue: 180
      Deleted message queue: 131
      Deleted message queue: 82
      Deleted message queue: 83
      Deleted message queue: 34
      Deleted message queue: 85
      Deleted message queue: 86
      Deleted message queue: 37
      Deleted message queue: 38
      Deleted message queue: 39
      Deleted message queue: 40
---------------------------------------------------------------
op440m:~>

577

Thu Jun 26 18:29:44 2008

MC Back online

Jenne, Rob, Yoichi

I was playing with the Mode Cleaner earlier today, working on measuring the effect of the new filter (see next post for loop gain measurements etc.), and bumped something which made it so the Mode Cleaner would not lock.

After much poking around by Rob and Yoichi, we found that the TNC-to-2 pin LEMO from Out1 of the MC Servo Board to Ch1 of the Pentek Generic board to the right of the MC Servo Board was bad. If we touched the cable, the MC would lock, but as soon as we let go, the MC would fall out of lock. The LEMO end of the cable was not heat shrink wrapped, so the 2 wires could have been touching. I replaced the cable, and the MC locked immediately after plugging it in, so I think that has fixed the problem.

578

Thu Jun 26 20:59:22 2008

Alarm Handler

Please do not turn off the Alarm Handler on op540m.

580

Thu Jun 26 22:08:33 2008

3.7MHz bandstop filter in MC Servo

The 3.7MHz elliptical bandstop filter that I made during my SURF summer is now installed in the MC servo loop to reduce the noise at 3.7MHz.

I have taken transfer functions with and without the filter between TP1A and TP2A, with EXCA at -20dBm, using the HP4195A Network Analyzer. I have also taken power spectra of TP1A with and without the filter, and time domain data with the filter of OUT2 on the MC Servo Board and Qmon on the Demod board just before the MC servo board. The filter is between Qmon and OUT2 in the loop.

The UGF and phase margin don't change noticeably with and without the filter, and the MC still locks nicely (after the minor fiasco this afternoon), so I think it's okay. The UGF is around 57kHz, with about 38 degrees phase margin.

1 July 2008: I redid the plots. Same info, but the traces with and without the filters are now on the same graph for easier readability.

Attachment 1: MCLoopGainBoth.png

Attachment 2: TP1ASpectrumBoth.png

Attachment 3: QmonWithFilt.png

Attachment 4: MCOut2WithFilt.png

584

Fri Jun 27 18:03:46 2008

Another bad cable in the MC servo

Eric was helping me to measure the response of the LO input on the MC's Demod board, and when we disconnected the end of the cable between the demod board and the delay line phase shifter for the 29.5MHz oscillator, we noticed that the phase shifter's end of the cable was loose, like the connector wasn't fully connected. When we checked it by wiggling the connector, the SMA end fell off. I made a new SMA end for the cable, and reinstalled the cable. The MC locked as soon as I plugged the cable in, so everything seems good again. I tried to not change the cable length when I remade the connector, but the cable is shorter than it was by a small amount, due to the way the end fell off.

585

Fri Jun 27 18:21:01 2008

Response of the LO input on the MC demod board

The alarm handler has been flipping out saying that the LO input of the MC's demod board is too low, so at Rana's suggestion, Eric and I measured the response of the LO input. We used an SR345 function generator at 29.485MHz and several different amplitudes to make a table. The demod board should see an input from the LO between 0-2dBm. When I measured what was going into the LO input from the 29.5MHz delay line phase shifter, the LO input was seeing 4dBm. I'm going to put a 3dB attenuator between the phase shifter and the demod board.

Also, now that we have this table of response values, I'm going to change the settings of the alarm handler to something more reasonable.

Amplitude of 29.485MHz input sine wave [dBm]    |        Value of channel C1:IOO-MC_DEMOD_LO
--------------------------------------------    |        -----------------------------------
-10                                             |        -0.000449867
-8                                              |        -0.000449867
-6                                              |        -0.000449867
-4                                              |        0.000384331
-2                                              |        0.00526733
0                                               |        0.0199163
2                                               |        0.0492143
4                                               |        0.0931613
6                                               |        0.161523
8                                               |        0.229885
10                                              |        0.293364

586

Fri Jun 27 19:59:44 2008

C1susvme2 and C1iovme crashed which sent the optics swinging and tripped the watchdogs.

Koji and I were able to restore c1susvme2 without any trouble.

We have been unable to revive c1iovme. We have tried telneting in and running startup.cmd,
the process runs for a while then hangs with "DAQ init failed -- exiting".

Resetting the board doesn't help. I didn't try keying the whole crate.

All optics are back to normal with damping restored.

587

Sat Jun 28 03:10:25 2008

Quote:

I tried keying the crate, then keying the DAQ controller & AWG, then powering down & restarting the framebuilder.
On coming up, the framebuild doesn't start a daqd process, and I can't get one to start by hand (it just prints "652", and then stops).
No error messages and daqd doesn't appear in the prstat.

I then tried keying the DAQ controller again (after the fb0 reboot), which blew the watchdogs on all the suspensions. So then I went around and keyed all the crates.

Now, the suspension controllers are back online. Still no c1iovme, and now the framebuilder/DAQ/AWG are also hosed. We can try keying all the crates again, in the order that Yoichi did last week.

After some more poking around, I found the daqd log file. It's now complaining about

Jun 28 03:00:39 fb daqd[546]: [ID 355684 user.info] Fatal error: channel `C1: PSL-FSS_MIXERM_F' is duplicated 126

This is the second error message like this. It first complained about C1: PSL-FSS_FAST_F, so I commented that out of C1IOOF.ini and rebooted the framebuilder (note this is an actual reboot of the full solaris machine). Eventually I discovered that C1IOOF.ini and C1IOO.ini are essentially identical. They presumably will keep getting these duplicate channel errors until one of them is completely removed.

C1IOO.ini has a modification time of seven PM on Friday night. Who did this and didn't elog it? I've now modified C1IOOF.ini, and I don't remember when it was last modified.

588

Sat Jun 28 14:56:44 2008

In short, I was editing the ini files yesterday evening, I didn't e-log it and after some investigation this afternoon it apears
that I am to blame for all the computer problems which followed.

I wanted to edit C0EDCU.ini and C1IOOF.ini to change C1: PSL-FSS_FAST to a fast channel as C1: PSL-FSS_FAST_F
was dead.

I opened these files and made backups. It appears this is where it all went awry. My backup for C1IOOF
is called C1IOO.ini.090627 i.e. missing the F.

Later c1susvme2 and c1iovme crashed. After failing to bring c1iovme back I wondered if my edits had
caused the problems so I restored the back up files. It appears that here I wrote over C1IOO with my backup of
C1IOOF (presumably because I had made a typo in the name).

To remedy the situation we could restore C1IOO from e.g. chans/archive/C1IOO_080618_160028.ini

No excuses for not e-logging this activity.

589

Sat Jun 28 23:23:50 2008

All of the computers are now showing green lights.

Remaining problems:

Alignment scripts are failing with "ERROR: LDS - NDS server error #13"
I think this is a server transmission error.

Dataviwer shows all channels as zero.

590

Sun Jun 29 02:33:28 2008

Abs. Len. Meas. ~ Optical setup (I)

I have constructed the beam injection optics for the abs length measurement.

The injection beam was coarsely aligned to the interferometer. The reflected beam from SRM was already seen at AS CCD.
I have attached the optical configration for this measurement and the optics layout at the AP table.

I am going to go to LHO for three weeks. During the absence Alberto tunes the mode matching and the alignment of the interferometer.

In the process of making this report, I noticed that one of the iris apertures is about disturbing the beam for OMCR CCD. I will check this before I go to Hanford. Also an RF spectrum analyzer is at the AP table. I try to return this near the PSL on Monday morning.

Attachment 1: Optical configuration for the abs length measurement.
1) One of the arms is locked to the PSL beam by the main control system (red).
2) A laser beam is injected from the AS port (blue). This laser essentially has different frequency from that of PSL.
3) The injected beam and the outgoing PSL beam appear at the output of the faraday in the injection system.
4) They beat each other at the frequency difference of those two lasers.
5) A PLL is used to lock the frequency difference to a local oscillator (LO).
6) The LO frequency is swept at around 3.87MHz, that is the approximate FSR frequency of the arm cavity.
7) If the LO frequency hits the FSR within the resonant width, the beating also appears at the transmitted light as the injected beam also becomes resonant to the arm cavity.
8) Amplitude of the beating at the transmitted light is measured by a RF spectrum analyzer as a function of the LO frequency. We get the FSR frequency (= the arm cavity length) from the top of the resonance.

Attachment 2: Optics at the AP table for the laser injection
700mW NPRO, laser source. vertically polarized.
Periscope, to raise the beam 1 inch to make the beam at the 4 inch elevation.
INJ_SM1/INJ_SM2, steering mirrors to align the injection beam to the IFO beam.
HWP1, half wave plate to make the beam to the farady horiz-polarized. nominal 42deg on the readout.
FI, Faraday isolator for protection of the NPRO from the returning light, for obtaining the returning light.
HWP2, to make the beam from the Faraday horiz-polarized. nominal 357deg on the readout.
MM_Lens, f=125mm to match the laser mode to the IFO beam.
SM1/SM2, steering mirrors to align the IFO beam to the Farady Isolator.
IRIS1/IRIS2, for the coarse alignment of the injection beam.
FLIP, flipper mount to turn on/off the injection optics.

Alignment procedure of the injection system
0) Ignite NPRO several hours before the experiment so that the laser frequency can be stable.
1) Turn up FLIP. Close the shutter of NPRO.
2) Adjust SM1/SM2 so that the ifo beam can appear at the output of FI.
3) Adjust height and position of IRIS1/IRIS2 with regard to the ifo beam so that the ifo beam goes through IRIS1/IRIS2 even when they are closed.
4) Turn down FLIP. Open the shutter of NPRO.
5) Adjust INJ_SM1/INJ_SM2 so that the injection beam can go through IRIS1/IRIS2 even when they are closed.
6) At this time, it is expected that the reflection of the injection beam from SRM appears at AS CCD, if SRM is aligned.
7) Adjust INJ_SM1/INJ_SM2 so that the injection beam at AS CCD can overlap to the IFO beam.
8) Confirm the beam at the output of the FI also overlaps.
---- We are here ----
9) Change the ifo configuration to the X or Y arm only.
10) Scan the crystal temperature of the 700mW NPRO in order to try to have the beating of the two beams at the PD. AS OSA may be useful to obtain the beating.
11) Once the beating is obtained, adjust INJ_SM1/INJ_SM2 such that the beating amplitude is maximized.

Attachment 1: optical_configuration.png

Attachment 2: optical_layout_ap_table2.png

Attachment 3: optical_layout_ap_table2.pdf

592

Sun Jun 29 14:53:02 2008

Quote:

Fixed. Just started the testpoint manager on fb40m.

su
/usr/controls/tpman &

597

Sun Jun 29 20:29:48 2008

Correlation of PSL SLOW control v. Room temperature

Attachment 1: slowtemp.png

598

Mon Jun 30 01:49:06 2008

I'm in the process of aligning the mode cleaner/ input beam.

I turned off the WFS and cleared their histories, adjusted the input periscope and re-aligned the mode-cleaner accordingly.
I then unlocked the cavity and centred the beams on the WFS.

MC transmission is ~3.3 and the REFL beam looks a little better.

However, turning the WFS on now lowers the transmission. More thought tomorrow.

I'm leaving the MC locked with WFS off.

599

Mon Jun 30 05:33:38 2008

Abs. Len. Meas. ~ Optical setup (II)

o The position of the iris was adjusted so as not to disturub the beam for OMCR CCD.

o The RF spectrum analyzer was returned to the place of the network analyzer.

Quote:

In the process of making this report, I noticed that one of the iris apertures is about disturbing the beam for OMCR CCD. I will check this before I go to Hanford. Also an RF spectrum analyzer is at the AP table. I try to return this near the PSL on Monday morning.

600

Mon Jun 30 08:59:23 2008

steve

IOO

IOO-MC_DEMOD_LO is low

The alarm handler is beeping relentlessly: asking for help in high partical count and low demod signal

Attachment 1: demlo.jpg_____

601

Mon Jun 30 09:46:15 2008

MC WFS are on. They seem to do some good during the day.

605

Mon Jun 30 15:56:22 2008

Fixing the LO demod signal

To make the alarm handler happy, at Rana and John's suggestion I replaced R14 of the MC's Demod board, changing it from 4.99 Ohms to 4.99 kOhms. This increased the gain of the LO portion of the demod board by a factor of 10. Sharon and I have remeasured the table of LO input to the demod board, and the output on the C1:IOO-MC_DEMOD_LO channel:

Input Amplitude to LO input on demod board [dBm]: | Value of channel C1:IOO-MC_DEMOD_LO
------------------------------------------------- | -----------------------------------
-10 | -0.00449867
-8 | 0.000384331
-6 | 0.0101503
-4 | 0.0296823
-2 | 0.0882783
0 | 0.2543
2 | 0.542397
4 | 0.962335
6 | 1.65572
8 | 2.34911
10 | 2.96925

607

Mon Jun 30 18:36:01 2008

John, Yoichi

We re-adjusted the MZ alignment. The reason behind this is to make sure that the MZ dark port is not falling at a strange fringe, where it is only dark at the dark port PD. It can happen when the two beams poorly overlap.
We tried both the minimization of the MZ dark PD and the maximization of the MZ transmission at the same time.
We also placed another PD in the MZ dark port at a different distance from the original dark PD and tried to minimize this too.
If the MZ dark port is at a strange fringe, one of the dark PD can be dark where the other one is still bright.
If both of the dark PD get dark, the overlap between the beams should be ok.
We tweaked only the two mirrors of the MZ after the EOMs (mainly the one with a PZT).

Right now, the MZ dark power is 0.432.
BTW, we should change the name of the MZ dark port on the medm screen (it is now MZ reflection, where it is not a reflection).
I will try to change it later.

We wanted to put the beam position on the IOO-QPD_POS_* back to the original (before John tweaked the MZ alignment earlier).
However, the trends of IOO-QPD_POS_* show a lot of fluctuation and jumps, of which we don't know the cause. So we could not find reasonable original values.
We suspect a circuit problem in IOO-QPD_POS, especially because the jumps are very strange.
We will do this investigation later too.

608

Tue Jul 1 09:26:33 2008

Tue Jul 1 10:15:22 2008

The laser recovered from a short temp rise. The MZ was aligned and realigned. The suspentions were kicked up accidentally.
Now the computers are down.

Attachment 1: 2d.jpg

610

Tue Jul 1 11:53:38 2008

I took a tour of the FE machines and power cycled all of them.
After executing the software restart procedures of those computers, the RFM network got back to the normal state.
For some reason, the computers requiring startup.cmd (like c1lsc) halt after running this command. Actually the computer is running ok, but the command freezes. Basically, what it does is simply to load a kernel module. I don't know what is wrong.
Anyway, I just closed the terminal after running startup.cmd and it seems fine for now.

614

Tue Jul 1 13:34:29 2008

Quote:

For some reason, the computers requiring startup.cmd (like c1lsc) halt after running this command. Actually the computer is running ok, but the command freezes. Basically, what it does is simply to load a kernel module. I don't know what is wrong.
Anyway, I just closed the terminal after running startup.cmd and it seems fine for now.

This is normal. On the linux RTFEs (Real-Time Front Ends), the real-time code totally hijacks the kernel, disallowing any interrupts. The system thus becomes totally unresponsive while the code is running, and communicates only through the RFM and the VME backplane.

618

Tue Jul 1 21:45:48 2008

John