Since lately the alignment of the input beam to the interferometer has changed, I went checking the alignment of the beam on the photodiodea. They were all fine except for pd9, that is AS DD 199. Here the DC is totally null. The beam seems to go right on the diode but the scope on the PD's DC output shows no power. This is really strange and bad.
After inspecting PD9 with the viewer and the cards, the beam looks like it is aligned to the photodiode althought there is no signal at the DC output of the photodetector. So I checked the spectrum for PD9_i and Q (see attachments) and it seems that those channels are actually seeing the beam. I'm going to check the alignemtn again and see the efefct on the spectra to make sure that the beam is really hitting the PD.
I aligned PD9. Here are the spectra confirming that.
All suspentions are kicked up. Sus dampings and oplev servos turned off.
c1iscey and c1lsc are down. c1asc and c1iovme are up-down
The computers and RFM network are up working again. A boot fest was necessary.Then I restored all the parameters with burtgooey.
The mode cleaner alignment is in a bad state. The autolocker can't get it locked. I don't know what caused it to move so far from the good state that it was till this afternoon. I went tuning the periscope but the cavity alignment is so bad that it's taking more time than expected. I'll continue working on that tomorrow morning.
I now suspect that after the reboot the MC mirrors didn't really go back to their original place even if the MC sliders were on the same positions as before.
Trying to track the MC positions back for a few days, it seems that the data hasn't been recorded properly for a while. Something happened yesterday after my boot fest and then the record got restored. Attached here are the readbacks showing the event for MC1.
Is anything wrong with the data record?
we diagnosed the problem. It was related with sticky sliders. After a reboot of C1:IOO the actual output of the DAC does not correspond anymore to the values read on the sliders. In order to update the actual output it is necessary to do a change of the values of the sliders, i.e. jiggling a bit with them.
Chronicles of periscope and MC alignment
Yesterday morning I started aligning the periscope but it turned out to be trickier than usual. With the ASC (Alignment Sensing Control) off and only the length controls on, the Mode Cleaner didn't lock easily, although I knew I wasn't very far from the sweet spot.
In the afternoon the struggle continued and the matching of the the beam to the MC cavity became just worse. At some point I noticed that the ASC inputs somehow had got on - although the ASC still looked disabled from the MClock MEDM main screen. So I was actually working against the Wave Front Sensors and further worsening the periscope alignment.
That hurled me to the weeds. After hours of rowing across the stormy waters of a four-dimensional universe I got to have occasional TEM00 flashes at the transmission but still, surprisingly, no MC locking. Confused, I kept tuning the periscope but that just kicked me off road again.
Then at about 7pm Koji came to my rescue and suggested a more clever and systematic way to solve the problems. He suggested to keep record of the MC mirrors alignment state and re-align the cavity to the periscope. Then we would gradually bring the cavity back to the original good position changing the periscope alignment at the same time.
That would have worked straight away, if we hadn't been fighting against a subtle and cruel enemy: the 40m computer network. But I (as John Connor), and Koji (as the Terminator) didn't pull back.
Here's a short list of the kinds of weapons that the computers threw to us:
We then proceeded with Koji's plan. In an iterative process, we aligned the MC cavity maximizing the transmission and tuned the periscope in order to match the Faraday input of the interferometer. The last thing we did it by looking at the camera pointing at the Faraday isolator.
We found that we didn't have to tune the periscope much. That means that all afternoon I didn't really go too far, but the autolocker wasn't working properly, or it wasn't working at all.
Then we ran the alignment script for the X arm but it didn't work before we aligned the steering mirrors.
Then we ran it three times but could not get more than 0.87 at TRX. That means that there we still have to work on the alignment to the Faraday. That's job for today in the trenches of the lab.
After yesterday's changes in the MC cavity state today it was necessary to optimize the alignment to the Faraday.
The way I did it was by tuning the PSL periscope in pitch and yaw trying to maximize TRX with the arm locked. After a small change in either one of the two directions I first maximized the MC transmitted power and then I ran the alignment script for the X arm.
I explored the space for both pitch and yaw and the max that I could get from TRX was 0.91. I'm not sure whether the increase in TRX is entirely due to a better alignment to the Farady rather than to a higher MC transmitted power.
Also I'm not sure I'm well interpreting the image from the camera pointing at the Farady. I guess I need someone more familiar with it to tell me if it shows any sign of clipping.
Anyway, last week, even before the MC got misaligned, TRX didn't go above 0.90. So now I wonder whether it's the MC's fault or something else's if we have that value..
This morning I found the elog down. I restarted it using the procedure in the wiki.
This afternoon I kept working on the alignment of the beam so that it matches at the same the PSL periscope, the Mode Cleaner and the Faraday isolator at the input of the IFO.
The camera looking at the Farady showed a beam quite low from the center of the Faraday's entrance. I wanted to move it up.
After working on the periscope alignment and on the MC mirrors, I think I managed to moved it up a bit. To know whether that was enough or not I wanted to evaluate the alignment to the X arm by checking the value of TRX.
In order for the MC to be finely matched to the input beam from the periscope, the WFS controls have to be on. Before turning them on, I centered the beam on their QPDs and run the WFS_zero_offset script.
When I turned them on, the control signal in Pitch from WFS2 started going up with no stop. It was like the integrator in the loop was fed with a DC bias. The effect of that was to misalign the MC cavity from the good state in which it was with the only length control on (that is, transmission ~2.7, reflection ~ 0.4).
I don't know why that is happening. To exclude that it was due to a computer problem I first burtrestored C1IOO to July the 18th, but since that did not help, I even restarted it. Also that didn't solve the problem.
Flashes at ETMX show at least that the beam is going through the Farady. How well, I can't tell untill the MC is under full control.
I have to leave the lab now, but I can be back tomorrow to keep working on that.
I set the MC back to its good alignment (June 21st) using this procedure. The trend of the OSEM values over the last 40 days and 40 nights is attached.
Then I aligned the periscope to that beam. This took some serious periscope knob action. Without WFS, the transmission went to 2.7 V and the reflection down to 0.6V.
Then I re-aligned the MC_REFL path as usual. The beam was far enough off that I had to also re-align onto the MC LSC PD as well as the MC REFL camera (~2 beam radii).
Beams are now close to their historical positions on Faraday and MC2. I then restored the PZT sliders to their April snapshot and the X-arm locked.
Steve - please recenter the iris which is on the periscope. It has been way off for a long time.
So it looks OK now. The main point here is that we can trust the MC OSEMs.
Afterwards I rebooted c1susvme1 and c1susvme2 because they were skewed.
It is really surprising that we now have again the data from the MC OSEMs since up to two days ago the record looked corrupted (see the attachments in my entry 1774).
The reason I ended up severely misaligning the the MC is exactly that there wasn't anymore a reference position that I could go back to and I had to use the camera looking a the Faraday.
This morning I found the Mode Cleaner unlocked.
I check the sliders for the mirrors bias and they have not changed. Also the OSEMs readbacks show no change in the optics positions.
I don't understand what's wrong because in the previous days, in this state of alignmanet, it could lock.
I tried to tweak a little bit the periscope to check whether it was a problem of beam matching but that didn't help the cavity to lock.
I don't want to change the periscpe alignment to much becasue I believe it is still good and I suspect that there is something else going on.
Friday afternoon the mode cleaner got unlocked. Then some adjustment of the MC1 bias sliders locked it again. The driftmon showed the excursion for pitch and yaw of MC1 becasue it wasn't updated after the change.
Tonight Rana found the MC unlocked and simply touched the sliders to bring the OSEMs back to the driftmon values.
MC1 Yaw remains different from the driftmon. If brught back to htat value, the MC would get unlocked.
More investigation is needed to understand why the MC lock hasn't been stable for the last few days.
The mode cleaner is still unlocked. I played with the cable at the MC2 satellite to enusre they were all plugged in.
Then I tweaked the the mirrors alignment by the sliders and eventually I could get it locked stably with 1.3 reflection. Then I rebooted C1IOO because the WFS wouldn't engage. After that the cavity wasn't locked anymore. Trying to adjust the mirrors around their position didn't restore the lock.
More work is necessary.
I'll be back on it in a while.
FB40m up and running again after restarting the DAQ.
I added a clock to the PMC medm screen.
I made a backup of the original file in the same directory and named it *.bk20090805
We can't read minute trends from either Dataviewer or loadLIGOData from before 11am this morning.
fb:/frames>du -skh minute-trend-frames/
So the frames are still on the disk. We just can't get them with our usual tools (NDS).
Trying to read 60 days of minute trends from C1:PSL-PMC_TRANSPD yields:
Connecting to NDS Server fb40m (TCP port 8088)
258.0 minutes of trend displayed
T0=09-06-06-22-34-02; Length=5184000 (s)
No data output.
Trying to read 3 seconds of full data works.
Second trends are readable after about 4am UTC this morning, which is about 9 pm last night.
Yesterday Alex started transferring the data records to the new storage unit. That prevented us from accessing the trends for a fe hours.
The process had been completed and now we can read the trends again.
For some reason a few minutes ago the FB DAQ crashed and I had to restarted.
With the high power meter I measured the reflected power when the PMC was unlocked and used that to obtain the calibration of the PMC-REFL PD: 1.12V/W.
P_in = 1.98W ; P_trans = 1.28W ; P_refl = 0.45W
From that I estimated that the losses account to 13% of the input power.
I checked both the new and the old elogs to see if such a measurement had ever been done but it doesn't seems so. I don't know if such a value for the visibility is "normal". It seems a little low. For instance, as a comparison, the MC visibility, is equal to a few percents.
Also Rana measured the transmitted power after locking the PMC on the TEM20-02: the photodiode on the MEDM screen read 0.325V. That means that a lot of power is going to that mode.
That makes us think that we're dealing with a mode matching problem with the PMC.
In the last hour or so the elog crashed. I have restarted it.
This morning I found that all the front end computers down. A failure of the RFM network drove all the computers down.
I was about to restart them all, but it wasn't necessary. After I power cycled and restarted C1SOSVME all the other computers and RFM network came back to their green status on the MEDM screen. After that I just had to reset and then restart C1SUSVME1/2.
I just found the elog down and I restarted it.
Is that the reason of the PSL craziness tonight? See attachment.
There's no elog entry about what work has gone on today, but it looks like Peter took apart the reference cavity temperature control around 2PM.
I touched the reference cavity by putting my finger up underneath its sweater and it was nearly too hot to keep my finger in there. I looked at the heater power supply front panel and it seems that it was railed at 30 V and 3 A. The nominal value according to the sticker on the front is 11.5 V and 1 A.
So I turned down the current on the front panel and then switched it off. Otherwise, it would take it a couple of days to cool down once we get the temperature box back in. So for tonight there will definitely be no locking. The original settings are in the attached photo. We should turn this back on with its 1A setting in the morning before Peter starts so that the RC is at a stable temp by the evening. Its important NOT to turn it back on and let it just rail. Use the current limit to set it to 1 A. After the temperature box is back in the current limit can be turned back up to 2A or so. We never need the range for 3A, don't know why anyone set it so high.
While Peter King is still working on the reference cavity temperature box, I turned the power supply for the reference cavity's heater back on. Rana turned it off last night since the ref cav temperature box had been removed.
I just switched it on and turned the current knob in the front panel until current and voltage got back to their values as in Rana's picture.
I plan to leave it like that for half an hour so that the the cavity starts warming up. After that, I'll turn the current back to the nominal value as indicated in the front panel.
It turned out that half an hour was too long. In less than that the reference cavity temperature passed the critical point when the temperature controller (located just below the ref cav power supply in the same rack) disables the input power to the reference cavity power supply.
The controller's display in the front shows two numbers. The first goes with the temperature of the reference cavity; the second is a threshold set for the first number. The power supply gets enabled only when the first number comes under the threshold value.
Now the cavity is cooling down and it will take about another hour for its temperature to be low enough and for the heater power supply to be powered.
Basically, in addition to the replacement of the resistors with metal film ones, Peter replaced the chip that provides a voltage reference.
The old one provided about 2.5 V, whereas the new one gets to about 7V. Such reference voltage somehow depends on the room temperature and it is used to generate an error signal for the temperature of the reference cavity.
Peter said that the new higher reference should work better.
Today I aligned the beam to PD3 (POX) since Steve had moved it.
The DC power read 1.3mV when the beam was on the PD.
Tried to lock the interferometer but arm power didn't get over 65.
Tonight, after the weekend, I resumed the work on locking.
When I started the Mode Cleaner was unlocked because the MZ was also unlocked.
I aligned the MZ and the transmitted power reached about 2.5
Initially the interferometer lost lock at arm power of about 3-4. It looked like the alignment wasn't good enough. So I ran the alignment scripts a few times, first the scripts for the single parts and in the end the one for the full IFO.
Then I also locked again the MZ and this time the transmitted power got to about 4.
In the following locking attempts the the arm power reached 65 but then the lock got lost during the handing of CARM to C1:LSC-PD11_I
I'll keep working on that tomorrow night.
I have replaced the temporary clamps that were connecting the RC heater to its power supply with a new permanent connection.
In the IY1 rack, I connected the control signal of the RC PID temperature servo - C1:PSL-FSS_TIDALSET - to the input of the RC heater's power supply.
The signal comes from a DAC in the same rack, through a pair of wires connected to the J9-4116*3-P3 cross-connector (FLKM). I joined the pair to the wires of the BNC cable coming from the power supply, by twisting and screwing them into two available clamps of the breakout FKLM in the IY1 rack - the same connected to the ribbon cable from RC Tmeperature box.
Instead of opening the BNC cable coming from the power supply, I thought it was a cleaner and more robust solution to use a BNC-to-crocodile clamp from which I had cut the clamps off.
During the transition process, I connected the power supply BNC input to a a voltage source that I set at the same voltage of the control signal before I disconnected it (~1.145V).
I monitored the temperature signals and it looked like the RC Temperature wasn't significantly affected by the operation.
Here's the gist of the requirements on the 5x frequency multiplier for the upgrade (see attachemnt - despite the preview down here in the elog, they're 3 pages).
An extended version is available on the wiki.
A more complete document is under work and will soon be available on the wiki as well.
While I was moving a cart near by the PSL table I pushed the red emergency button that turns off the PSL laser. We had to unlock the button and then power cycle the laser driver to turn the laser back on.
I relocked MZ, FSS, PMC and I'm now waiting for the power to finish ramping up back to the previous value.
In the revival of the experiement length measurement for the recycling cavities, I turned the auxiliary NPRO back on. The shutter is closed.
I also recollected all the equipment of the experiment after that during the summer it had been scattered around the lab to be used for other purposes (Joe and Zach's cameras and Stephanie and Koji's work with the new EOM).
Inspecting the AS table to make an inventory of the photodiodes in use around the interferometer, I found a mysterious photodetector hiding behind PD1 (AS166).
It turned out the detector was an old type of QPD from the Squeezing Experiment a few years ago.
We removed the box and the cable to which it was connected from the table. We stored it in the optics cabinet along the X arm.
I uploaded on the Wiki (here) the results of an inventory over our current PDs, a list of the new ones that we're going to need for the new control scheme.
On behalf of Steve and of the rest of the not-native-English community at the 40m willing to have their browser's spell checker working while editing the Elog, I fixed the Elog's feature that prevented Firefox' context menu (that one which pops up with a mouse right click) to work when using the HTML editing interface (FCKeditor).
That let also Firefox spell checker to get enabled.
To get the browser context menu just press CTRL right-clicking.
To make sure that the features works properly on your browser, you might have to fully clear the browser's cache.
Basically I modified the FCKeditor config file (/cvs/cds/caltech/elog/elog-2.7.5/scripts/fckeditor/fckconfig.js). I added this also to the elog section on our Wiki.
I'm going to work on the X arm to measure the arm cavity finesse.
The idea is to measure the cavity transfer function to estimate the frequency of its cavity pole. That should be a more accurate measurement than that based on the cavity decay time.
I'm starting now and I'm going to inject a swept sine excitation on the OMC_ISS_EXC input cable laying on the floor nearby the AP table (see pic).
In orderf to do that I disconnected the cable from the OMC breakout box laying on the floor. I'm going to plug the cable back in as soon as I'm done.
Since I need to measure the transfer function between TRX and MC_TRANS_DC I picked off the beam going to RFAM PD to send it to a PDA255 photodiode (cannibalized from the AbsL's PLL) which I installed on the PSL table.
I centerd the beam on the PD and I was able to see the injected signal.
I think I'm ready to measure the transfer function.
Except for the RFAM PD everything is as before.
I'm gonna go grab dinner and I should be back to keep working on that in about one hour.
Since I need to measure the transfer function between TRX and MC_TRANS_DC I picked off the beam going to RFAM PD to send it to a PDA255 photodiode (cannibalized from the AbsL's PLL) which I installed on the PSL table.
Back from dinner. Taking measurements.
I measured the transfer function between MC_TRANS and TRX and I'm attaching the result.
That looks quite strange. Something's wrong. I'll repeat it tomorrow.
for the night I'm putting everything back. I'm also reconnecting the OMC_ISS_EXC and opening again the test switch on the ISS screen.
The RFAM monitor remains disable
I would have guessed that you have to calibrate the detectors relative to each other before trying this. Its also going to be tricky if you use 2 different kinds of ADC for this (c.f. today's delay discussion in the group meeting).
I think Osamu used to look at fast transmission signals by making sure the PD at the end had a 50 Ohm output impedance and just drive the 40m long cable and terminate the receiving end with 50 Ohms. Then both PDs go into the SR785.
On Rana's suggestion I measured the trasfer function between the two photodiodes PDA255 that I'm using.
I took the one that I had on the end table and put it on the PSL table. I split the MC transmitted beam with a 50% beam splitter and sent the beams on the two diodes. (Rana's idea of picking off the beam and interposing the PDs before the ISS PDs was not doable: ISS PDs would be too close and there would be no room to install the PDA255 before them). See picture with the final setup.
The transfer function also includes the 40m long cable that I was using for the Arm Cavity measurement.
Here's what I got. It looks rather flat. Yesterday the calibration was probably not the problem in that measurement.
I'm now going to install the PD back on the end table and measure the TFs between the excitation and several points of the loop.
(Trivia. At first, the PDs were saturating so Koji attached attenuation filters on to them. Suddenly the measurement got much nicer)
It seems that just repeating the measurement was enough to get a good transfer function of the x arm cavity. Here's what I got.
I'm going to fit the data on matlab, but at first sight, the pole seems to be at about 1.7KHz (that is where the phase is 45deg): as expected.
Probably it was useful to realign the beam on the Transmission PD. (btw, I'm using the PDA255 that was still on the X end table since the AbsL experiemtn that measured the arm length)
As for the X Arm, this the transfer function I measured for the Y arm cavity.
This time I'm using a different photodiode than the PDA255 on the Y end table.
The diode I'm using is the PDA520 from where TRY comes from.
I'm going to repeat the measurement with PDA255.
The elog just crashed and I rebooted it
Measurement repeated with the PDA255 PD at the end but not big changes
I disconnected the setup for the arm cavity TF measurement. I opened the scitation switch on the ISS medm screen. I reconnected the OMC ISS EXC cable to the breakout box on the floor.
The photodiode on the Y end is stilll connected.
Also the RFAm (whish is not disbaled anymore) still has a 50% beam splitter before it.
I'm also running the Align Full IFO script.
This afternoon I re-enabled the ETMY coils after I found that the watchdogs for the mirror had tripped last night at 2:06am.
Tonight I aligned the IFO by running the scripts one by one.
SRC was far off and I had to align SRM by hand before the script could work. SPOB is still low when DRM is aligned.
I'm restoring the full IFO now that I'm taking off.
The MC2 watchdogs tripped. I just restored them.
I also had to relock the MZ and then the Mode Cleaner.
I'm working on the PSL table to set up the PLL setup for the AbsL experiment.