ID |
Date |
Author |
Type |
Category |
Subject |
1561
|
Fri May 8 02:39:02 2009 |
pete, rana | Update | Locking | crossover |
attached plot shows MC_IN1/MC_IN2. needs work.
This is supposed to be a measurement of the relative gain of the MCL and AO paths in the CM servo. We expect there to
be a more steep slope (ideally 1/f). Somehow the magnitude is very shallow and so the crossover is not stable. Possible
causes? Saturations in the measurement, broken whitening filters, extremely bad delay in the digital system? needs work.
|
Attachment 1: crossover.pdf
|
|
Attachment 2: photo.jpg
|
|
1565
|
Fri May 8 15:40:44 2009 |
pete | Update | Locking | progressively weaker locks |
the align script was run after the third lock here. it would have been interesting to see the arm powers in a 4th lock |
Attachment 1: powers_3lock.pdf
|
|
1585
|
Thu May 14 02:36:05 2009 |
pete | Update | Locking | unstable IFO |
It seems that the MC3 problem is intermittent (one-day trend attached). I tried to take advantage of a "clean MC3" night, but the watch script would usually fail at the transition to DC CARM and DARM. It got past this twice and then failed later, during powering up. I need to check the handoff.
|
Attachment 1: mc3.jpg
|
|
1611
|
Wed May 20 01:53:48 2009 |
rob, pete | Update | Locking | violin mode filters in drstep_bang |
Recently the watch script was having difficulty grabbing a lock for more than a few seconds. Rob discovered that the violin notch filters which were activated in the script were causing the instability. We're not sure why yet. The script seems significantly more stable with that step commented out. |
1641
|
Tue Jun 2 02:28:58 2009 |
pete | Update | Locking | DD handoff work |
alberto, pete
We worked on tuning the DD handoff tonight. We checked the DD PD alignments and they looked fine. First I tuned the 3 demod phases to minimize offsets. Then I noticed that the post-handoff MICH xfer function needed an increase in gain to look like the pre-handoff xfer function (which has a UGF of about 25 Hz). I increased the MICH PD9_Q gain from 2 to 7 in the input matrix. But, the handoff to PRC still failed, so tomorrow we will try to find out why.
In the plot, ref0 is before MICH handoff, and ref1 is after MICH handoff. There is also a PRC trace (before PRC handooff).
|
Attachment 1: mich_dd.pdf
|
|
1645
|
Wed Jun 3 03:22:16 2009 |
pete | Update | Locking | DD handoff |
Rana, Alberto, Pete
We have the DD handoff nominally working. Sometimes, increasing the SRC gain at the end makes MICH get unstable. This could be due to a non-diagonal term in the matrix, or possibly because the DRM locks in a funky mode sometimes.
To get the DD handoff working, first we tuned demod phases in order to zero the offsets in the PD signals handed-off-to. Based on transer function measurements, I set the PRC PD6_I element to 0.1, and set the PD8_I signal to 0, since it didn't seem to be contributing much. We also commented out the MICH gain increase at the end of the DD_handoff script.
It could still be more stable, but it seems to work most of the time.
|
1652
|
Thu Jun 4 16:54:19 2009 |
pete | Update | Locking | daytime DD handoff |
I played with the DD handoff during the day. The DRM dark port was flickering like a candle flame in Dracula's castle. The demod offsets for the handoff signals looked fine. After MICH handoff, the MICH_CTRL started to get unstable at some low frequency, maybe 3 Hz (I didn't measure). So I increased the MICH gain from 0.1 to 0.17 and it settled down. PRC and SRC went fine. Then the DD_handoff script raised the MICH gain to 0.7, and an instability started to grow in MICH_CTRL (at some higher frequency). I decreased the MICH gain from 0.7 to 0.5, and it settled down and stayed stable. |
1654
|
Fri Jun 5 01:10:13 2009 |
rob, pete | Update | Locking | undermined |
We were stymied early in the evening by a surreptitiously placed, verbo-visually obfuscated command in the drstep script. |
1655
|
Fri Jun 5 02:59:03 2009 |
pete, alberto | Update | Locking | tdsavg failure in cm_step script |
the command
tdsavg 5 C1:LSC-PD4_DC_IN1
was causing grievous woe in the cm_step script. It turned out to fail intermittently at the command line, as did other LSC channels. (But non-LSC channels seem to be OK.) So we power cycled c1lsc (we couldn't ssh).
Then we noticed that computers were out of sync again (several timing fields said 16383 in the C0DAQ_RFMNETWORK screen). We restarted c1iscey, c1iscex, c1lsc, c1susvme1, and c1susvme2. The timing fields went back to 0. But the tdsavg command still intermittently said "ERROR: LDAQ - SendRequest - bad NDS status: 13".
The channel C1:LSC-SRM_OUT16 seems to work with tdsavg every time.
Let us know if you know how to fix this.
|
1656
|
Fri Jun 5 13:51:49 2009 |
rob | Update | Locking | tdsavg failure in cm_step script |
Quote: |
the command
tdsavg 5 C1:LSC-PD4_DC_IN1
was causing grievous woe in the cm_step script. It turned out to fail intermittently at the command line, as did other LSC channels. (But non-LSC channels seem to be OK.) So we power cycled c1lsc (we couldn't ssh).
Then we noticed that computers were out of sync again (several timing fields said 16383 in the C0DAQ_RFMNETWORK screen). We restarted c1iscey, c1iscex, c1lsc, c1susvme1, and c1susvme2. The timing fields went back to 0. But the tdsavg command still intermittently said "ERROR: LDAQ - SendRequest - bad NDS status: 13".
The channel C1:LSC-SRM_OUT16 seems to work with tdsavg every time.
Let us know if you know how to fix this.
|
Did you try restarting the framebuilder?
What you type is in bold:
op440m> telnet fb40m 8087
daqd> shutdown
|
1658
|
Fri Jun 5 17:22:55 2009 |
pete | Update | Locking | daytime locking |
After fixing the tp problem, I tried locking again. Grabbing and DD handoff, no problem. Died earlier than last night, handing off CARM to REFL_DC, around arm power of 4 or so. Seems to happen after turning off the moving zero, Rob says it might be touchy in daytime. |
1659
|
Sat Jun 6 01:44:53 2009 |
rob | Update | Locking | ? |
Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.
Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board. We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.
The problem is occurring after this transition, which works reliably. However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost. DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra. But lock is always lost right about the same offset.
Saturation somewhere? |
1660
|
Sun Jun 7 04:57:39 2009 |
Yoichi | Update | Locking | ? |
Quote: |
Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.
Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board. We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.
The problem is occurring after this transition, which works reliably. However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost. DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra. But lock is always lost right about the same offset.
Saturation somewhere?
|
I've seen this before. At that time, the problem was gone spontaneously the next day.
You could stop just before the offset reaches zero and then try to slowly reduce the offset manually to see where is the threshold.
|
1663
|
Tue Jun 9 23:25:24 2009 |
rob | Update | Locking | ? |
Quote: |
Quote: |
Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.
Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board. We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.
The problem is occurring after this transition, which works reliably. However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost. DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra. But lock is always lost right about the same offset.
Saturation somewhere?
|
I've seen this before. At that time, the problem was gone spontaneously the next day.
You could stop just before the offset reaches zero and then try to slowly reduce the offset manually to see where is the threshold.
|
Well, it hasn't gone away yet. It happened Sat, Mon, and Tues afternoon, as well as Friday. The threshold varies slightly, but is always around ~200-300 cnts. I've tried reducing the offset with the signal coming from the CM board and the signal not going through the CM board, I've also tried jumping the signal to zero (rather than a gradual reduction).
Tonight we'll measure the MC length and set the modulation frequencies, and maybe try some MZ tweaking to do RFAMMon minimization. |
1675
|
Tue Jun 16 02:09:31 2009 |
rob | Update | Locking | DD handoff finally working |
I had trouble getting the SRC handoff from SD to DD to work. I tried different gains, flipping the PD7 & 8 demod phases by 180 degrees, and messing with the output matrix to reduce cross-couplings in the state with MICH & PRC on DD and SRC on SD. Eventually I decided to try to make the DRM matrix diagonalization work.
It does, mostly. The handoff is now stable, and the loops all have UGFs around 100Hz. So, tonight anyways, it's possible to run senseDRM and then loadDRMImatrixData.m and run the resulting tdswrite command, and have a working handoff. I had to eliminate a few PDs (PD5 & PD10) to get it to work properly.
It would be nice if this script would measure all the PDs and allow individual setting of loop UGFs and measurement frequencies.
|
1676
|
Tue Jun 16 03:43:04 2009 |
rob | Update | Locking | same troubles |
Lock is still being lost, right at the end of the process when trying to reduce the CARM offset to zero. |
1678
|
Tue Jun 16 14:02:16 2009 |
rob | Update | Locking | locked |
The IFO is locked, at the operating point (zero CARM offset). The problem with reducing the residual CARM offset in the last stage appears to have been because the common mode gain was getting too high, and so the loop was going unstable at high frequencies.
The cm_step script is currently a confusing mess, with all the debugging statements. I'll clean it up this afternoon and check that it still works. |
1679
|
Tue Jun 16 16:10:01 2009 |
pete | Update | Locking | input matrix experiments |
Last night Rob ran senseDRM and loadDRMImatrixData and came up with the following for the input matrix:
tdswrite C1:LSC-ITMTRX_b2 0.065778 \
C1:LSC-ITMTRX_d2 2.2709 \
C1:LSC-ITMTRX_f2 2.9361 \
C1:LSC-ITMTRX_122 0.42826 \
C1:LSC-ITMTRX_b3 -0.064839 \
C1:LSC-ITMTRX_d3 -0.016913 \
C1:LSC-ITMTRX_f3 -0.021576 \
C1:LSC-ITMTRX_123 -0.0025243 \
C1:LSC-ITMTRX_b5 0.3719 \
C1:LSC-ITMTRX_d5 1.3109 \
C1:LSC-ITMTRX_f5 -0.16412 \
C1:LSC-ITMTRX_125 0.39574 \
C1:LSC-ITMTRX_33 0 \
C1:LSC-ITMTRX_42 0 \
C1:LSC-ITMTRX_155 0
Today, I reran these and got the following, and DD_handoff remained happy:
tdswrite C1:LSC-ITMTRX_b2 -0.10329 \
C1:LSC-ITMTRX_d2 2.0344 \
C1:LSC-ITMTRX_f2 3.2804 \
C1:LSC-ITMTRX_122 0.22516 \
C1:LSC-ITMTRX_b3 -0.076292 \
C1:LSC-ITMTRX_d3 -0.014603 \
C1:LSC-ITMTRX_f3 -0.12101 \
C1:LSC-ITMTRX_123 0.0054128 \
C1:LSC-ITMTRX_b5 0.33521 \
C1:LSC-ITMTRX_d5 1.1425 \
C1:LSC-ITMTRX_f5 -0.32759 \
C1:LSC-ITMTRX_125 0.25877 \
C1:LSC-ITMTRX_33 0 \
C1:LSC-ITMTRX_42 0 \
C1:LSC-ITMTRX_155 0
I wanted to remeasure with the canonical output matrix (-0.7 from MICH to PRM and 0.7 from MICH to SRM), but the DRM freaked out when MICH to PRM went below -0.3. |
1680
|
Tue Jun 16 17:38:35 2009 |
rob | Update | Locking | DeWhites ON |
With the common mode servo bandwidth above 30kHz and the BOOST on (1), I was able to switch on the test mass dewhitening. Finally. |
1684
|
Thu Jun 18 23:08:46 2009 |
rob | Update | Locking | spectrum |
Here's a noise spectrum of the RSE interferometer, in anti-spring mode, with RF readout. I'd say the calibration is "loose."
I used the Buonanno & Chen modification of the KLMTV IFO transfer functions to model the DARM opto-mechanical response. I just guessed at the quadrature, and normalized the optical gain at the frequency of the calibration line used (927Hz, not visible on the plot). |
Attachment 1: DARMnoise_929352240.png
|
|
Attachment 2: DARMnoise_929352240.pdf
|
|
1709
|
Tue Jun 30 23:09:40 2009 |
Alberto | Update | Locking | chronicles of some locking attempts |
Tonight I tried to lock the interferometer. At the first attempts the arm power didn't go above about 4. The mode cleaner seemed to be not well aligned and it lost lock or got stuck on a wrong mode. I had to run the MC_UP and MC_DOWN scripts to lock it again.
After that the locking proceed more smoothly; at least till a power level in the arms of about 60. Then again the mode cleaner lost lock and I had to run the scripts again. Without the MCWFS servo off the MC reflected power is still rather high (about 1.7); also even when the WFS servo is engaged the reflected power is about 0.5, versus 0.3 that it should be.
Those are both signs of a not very good alignment. Tomorrow I'll have to work on the injection periscope on the PSL table to try to fix that. |
1742
|
Tue Jul 14 00:57:11 2009 |
Alberto | Update | Locking | photodiode alignment check |
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. |
1747
|
Wed Jul 15 11:38:31 2009 |
rob | Update | Locking | MC_F channel dead |
It's railed. This is what halted locking progess on Monday night, as this channel is used for the offloadMCF script, which slowly feeds back a CARM signal to the ETMs to prevent the VCO from saturating.
Attached is a 5 day trend, which shows that the channel went dead a few days ago. All the channels shown are being collected from the same ICS110B (I think), but only some are dead. It looks like they went dead around the time of the "All computers down" from Sunday. |
Attachment 1: mcfdead.png
|
|
1749
|
Wed Jul 15 12:14:08 2009 |
Alberto | Update | Locking | photodiode alignment check |
Quote: |
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.
|
Attachment 1: 2009-07-15_PD9spectrumPDF.pdf
|
|
1755
|
Thu Jul 16 01:00:56 2009 |
Alberto | Update | Locking | PD9 aligned |
Quote: |
Quote: |
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.
p.s.
Ants, theyre everywhere, even inside the AS table. They're taking over the lab, save yourself! |
Attachment 1: 2009-07-15_PD9spectrumPDF02.pdf
|
|
1758
|
Thu Jul 16 14:41:38 2009 |
rob | Update | Locking | MC_F channel dead |
Quote: |
It's railed. This is what halted locking progess on Monday night, as this channel is used for the offloadMCF script, which slowly feeds back a CARM signal to the ETMs to prevent the VCO from saturating.
Attached is a 5 day trend, which shows that the channel went dead a few days ago. All the channels shown are being collected from the same ICS110B (I think), but only some are dead. It looks like they went dead around the time of the "All computers down" from Sunday.
|
Attached are the channels being recorded from the ICS110B in 1Y2 (the IOO rack). Channels 12, 13, 16, 17, 22, 24, 25 appear to have gone dead after the computer problems on Sunday. |
Attachment 1: IOO_ICS_0_15.png
|
|
Attachment 2: IOO_ICS_15_32.png
|
|
1759
|
Thu Jul 16 14:54:05 2009 |
rob | Update | Locking | MC_F channel dead |
Quote: |
Quote: |
It's railed. This is what halted locking progess on Monday night, as this channel is used for the offloadMCF script, which slowly feeds back a CARM signal to the ETMs to prevent the VCO from saturating.
Attached is a 5 day trend, which shows that the channel went dead a few days ago. All the channels shown are being collected from the same ICS110B (I think), but only some are dead. It looks like they went dead around the time of the "All computers down" from Sunday.
|
Attached are the channels being recorded from the ICS110B in 1Y2 (the IOO rack). Channels 12, 13, 16, 17, 22, 24, 25 appear to have gone dead after the computer problems on Sunday.
|
This has been fixed by one of the two most powerful & useful IFO debugging techniques: rebooting. I keyed the crate in 1Y2. |
1764
|
Mon Jul 20 12:35:21 2009 |
rob | Configuration | Locking | alignment biases funny |
I found the alignment biases for the PRM and the SRM in a funny state. It seemed like they had been "saved" in badly misaligned position, so the restore scripts on the IFO configure screen were not working. I've manually put them into a better alignment. |
1830
|
Tue Aug 4 23:03:56 2009 |
alberto | Update | Locking | IFO Alignment |
After the mini boot fest that Jenne did today, I checked whether that fixed the overflow issues we yesterday prevented the alignemnt of the arms.
I ran the alignment script for the arms getting 0.85 for TRX and 0.75 for TRY: low values.
After I ran the script ,C1SUSVME1 and C1SUSVME2 started having problems with the FE SYNC (counter at 16378). I rebooted those two and fix the sync problem but the transmitted powers didn't improve.
Are we still having problem due to MC misalignment? |
1833
|
Wed Aug 5 09:48:05 2009 |
alberto | Update | Locking | IFO Alignment |
Quote: |
After the mini boot fest that Jenne did today, I checked whether that fixed the overflow issues we yesterday prevented the alignemnt of the arms.
I ran the alignment script for the arms getting 0.85 for TRX and 0.75 for TRY: low values.
After I ran the script ,C1SUSVME1 and C1SUSVME2 started having problems with the FE SYNC (counter at 16378). I rebooted those two and fix the sync problem but the transmitted powers didn't improve.
Are we still having problem due to MC misalignment?
|
I also noticed that the FSS transmitted power has been constantly decaying for the last 6 months. Only in the last month tt dropped by 15%. The laser power hasn't decayed as much, so it's probably not the cause.
Maybe this is one reason why lately of less power going to the IFO.
We call it FSS Transmission, but I guess we mean power transmitted TO the IFO, that is it measures the power reflected from reference cavity, right?
Still on the front of the FSS, the reflected power has dropped from -0.5 to -1.2. Here I also wonder about the reason of negative values for that.
See attachments |
Attachment 1: 2009-08-09_FSStransPD.png
|
|
Attachment 2: 2009-08-09_FSreflPD.png
|
|
1842
|
Thu Aug 6 09:33:08 2009 |
alberto | Update | Locking | FSS Transmitted and Reflected Power Trends |
I've now also trended the MOPA output power for the last 200 days to check a possible correlation with the FSS reflected power. See attachment.
The trend shows that the laser power has decayed but it seems that the FSS reflected power has done it even faster: 30% drop in the FSS vs 7% for the MOPA in the last 60 days (attachment n.2). |
Attachment 1: 2009-08-06_PSL_trends200days.png
|
|
Attachment 2: 2009-08-06_PSL_trends.png
|
|
1843
|
Thu Aug 6 10:32:45 2009 |
alberto, rob | Update | Locking | More PSL trends: NPRO, MOPA, FSS, PMC and MZ |
Here we trended also the PMC and the MZ. The drop in the PMC happens at the same rate as the MOPA's.
That let us think that the FSS transmitteed power has gone down because of the reference cavity progressive misalignment to the laser beam.
We need to adjust that alignment sometime.
The drop in the NPRO output power (upper row, 3rd plot: Ch10 C1:PSL_126MOPA_126MON) accompained an increase of "fuzziness" in PMCTRANSPD and both coincided in time with the day we tempoarirly removed the flap from the laser chiller's chiller (July 14 2009). |
Attachment 1: 2009-08-06_PSLtrends.png
|
|
1889
|
Wed Aug 12 02:00:32 2009 |
rob | Update | Locking | report |
Spent a lot of time aligning tonight. The BS is not staying put--sometimes after a lock loss it gets badly mis-aligned.
DD handoff is working, after putting beam on REFL diodes and running senseDRM script. |
1909
|
Sat Aug 15 05:08:55 2009 |
Yoichi | Update | Locking | Friday night locking |
Summary: DD hand off fails for DRFPMI.
Tonight, I did a lot of house keeping work.
(1) I noticed that the reference cavity (RC) was locked to TEM10.
This was probably the reason why we had to increase the FSS common gain.
I re-locked the RC to TEM00. Now the common gain value is back to the original.
(2) The MC WFS did not engage. I found that c1dcuepics had the /cvs/cds mounting problem.
I rebooted it. Then MC WFS started working.
(3) After checking that the MC WFS QPDs are centered for direct reflection (the MZ half fringe method),
I locked the MC and tweaked the mirror alignment (mainly MC3) to offload the WFS feedback signals.
Now the MC locks to TEM00 robustly.
(4) Since the MC mirror alignment is touchy recently, I did not like the idea of mis-aligning MC2
when you do the LSC PD offset adjustment. So I modified the LSCoffset script so that it will close
the PSL shutter instead of mis-aligning MC2.
(5) I changed the PD11_Q criteria for success in the alignment scripts because PD11_Q is now lower
than before due to the lower laser power.
(6) Since today's bootfest, some epics values were not properly restored. Some of the PD gains were
unmatched between I and Q. I corrected these with the help of conlog.
(7) By checking the open loop TFs, I found that the short DOFs have significantly lower UGFs than before,
probably due to the lower laser power. I increased the gains of MICH, PRCL and SRCL by a factor of 2 for
the full configuration.
For the DRM configuration the changes I made were:
PRC -0.15 -> -0.3
SRC 0.2 -> 0.6
MICH 0.5 -> 0.5
(8) I locked the DRFPMI with arm offsets, then adjusted the demodulation phases of PD6,PD7,PD8 and PD9 (DD PDs)
to minimize the offsets in the error signal, while locked with the single demodulation signals.
Change log:
PD6_PHASE 201 -> 270
PD7_PHASE 120 -> 105
PD8_PHASE 131 -> 145
PD9_PHASE -45 -> -65
(9) I ran senseDRM to get the sensing Matrix for the short DOFs using DD signals in DRM configuration.
(10) Still the DD hand off fails for DRFPMI. It succeeds for DRM. |
1913
|
Sat Aug 15 22:50:18 2009 |
Clara | Update | Locking | Mode Cleaner is out of lock again |
It was fine when I came in earlier today, but I just got back from dinner, and it's not good. I looked in dataviewer, and it seems to have been sliding out for the past couple of hours... Here is a picture:

I swear I am not responsible this time... all I've been doing is working in the control room. |
1914
|
Sun Aug 16 04:33:11 2009 |
Clara | Update | Locking | Mode Cleaner is out of lock again |
Quote:
|
It was fine when I came in earlier today, but I just got back from dinner, and it's not good. I looked in dataviewer, and it seems to have been sliding out for the past couple of hours... Here is a picture:

I swear I am not responsible this time... all I've been doing is working in the control room.
|
Mode cleaner bounced back on its own about 2 hours ago. |
1930
|
Wed Aug 19 23:57:35 2009 |
rob | Update | Locking | report |
locking work proceeding apace tonight.
diagonalized DRM with setDDphases & senseDRM.
initial locks are fairly quick, aqstep script succeeds reliably.
first part of cm_step (handoff CARM-> MCL) usually works.
tuning up later parts of cm_step (presumably due to optical gain changes resulting from MOPA decline).
got to arm powers ~60. |
1955
|
Thu Aug 27 12:34:48 2009 |
Yoichi | Update | Locking | up to arm power 70 |
Last night, I tried to run locking scripts.
The power went up to 70 a couple of times .
Then it failed to switch to RF CARM.
I was too tired at that time to figure out what is the problem with the switching.
But it seemed to me that the problem could be solved by some gain tweaking.
Looks like the IFO is back to a good state. |
1959
|
Fri Aug 28 12:56:17 2009 |
Yoichi | Update | Locking | RF CARM hand off problem |
Last night, the lock script proceeded to the RF CARM hand-off about half of the time.
However, the hand off was still unsuccessful.
It failed instantly when you turn on the REFL1 input of the CM board, even
when the REFL1 input gain was very low, like -28dB.
I went to the LSC rack and checked the cabling.
The output from the PD11_I (REFL_2) demodulation board is split
into two paths. One goes directly to the ADC and the other one goes
to an SR560. This SR560 is used just as an inverter. Then
the signal goes to the REFL1 input of the CM board.
I found that the SR560 was set to the A-B mode, but B input was open.
This made the signal very noisy. So I changed it to A only mode.
There was also a 1/4 attenuator between the PD11_I output and the SR560.
I took it out and reduced the gain of SR560 from 10 to 2.
These changes allowed me to increase the REFL1 gain to -22dB or so.
But it is still not enough.
I wanted to check the CM open loop TF before the hand-off, but I could
not do that because the lock was lost instantly as soon as I enabled the
test input B of the CM board.
Something is wrong with the board ?
Using the PD11_I signal going into the ADC, I measured the transfer functions
from the CM excitation (digital one) to the REFL_DC (DC CARM signal) and PD11_I.
The TF shapes matched. So the PD11_I signal itself should be fine.
We should try:
* See if flipping the sign of PD11_I signal going to REFL1 input solve the problem.
* Try to measure the CM analog TF again.
* If the noise from the servo analyzer is a problem, try to increase the input gains
of the CM board and reduce the output gain accordingly, so that the signal flowing
inside the CM board is larger. |
1960
|
Fri Aug 28 13:49:07 2009 |
rob | Update | Locking | RF CARM hand off problem |
Quote: | Last night, the lock script proceeded to the RF CARM hand-off about half of the time.
However, the hand off was still unsuccessful.
It failed instantly when you turn on the REFL1 input of the CM board, even
when the REFL1 input gain was very low, like -28dB.
I went to the LSC rack and checked the cabling.
The output from the PD11_I (REFL_2) demodulation board is split
into two paths. One goes directly to the ADC and the other one goes
to an SR560. This SR560 is used just as an inverter. Then
the signal goes to the REFL1 input of the CM board.
I found that the SR560 was set to the A-B mode, but B input was open.
This made the signal very noisy. So I changed it to A only mode.
There was also a 1/4 attenuator between the PD11_I output and the SR560.
I took it out and reduced the gain of SR560 from 10 to 2.
These changes allowed me to increase the REFL1 gain to -22dB or so.
But it is still not enough.
I wanted to check the CM open loop TF before the hand-off, but I could
not do that because the lock was lost instantly as soon as I enabled the
test input B of the CM board.
Something is wrong with the board ?
Using the PD11_I signal going into the ADC, I measured the transfer functions
from the CM excitation (digital one) to the REFL_DC (DC CARM signal) and PD11_I.
The TF shapes matched. So the PD11_I signal itself should be fine.
We should try:
* See if flipping the sign of PD11_I signal going to REFL1 input solve the problem.
* Try to measure the CM analog TF again.
* If the noise from the servo analyzer is a problem, try to increase the input gains
of the CM board and reduce the output gain accordingly, so that the signal flowing
inside the CM board is larger. |
I'd bet it's in a really twitchy state by the time the script gets to the RF CARM handoff, as the script is not really validated up to that point. It's just the old script with a few haphazard mods, so it needs to be adjusted to accomodate the 15% power drop we've experienced since the last time it was locked.
The CM servo gain needs to be tweaked earlier in the script--you should be able to measure the AO path TF with the arm powers at 30 or so. I was able to do this with the current SR785 setup earlier this week without any trouble.
The 1/4 attenuator is there to prevent saturations on the input to the SR560 when there's still a CARM offset.
Not sure if flipping the sign of PD11 is right, but it's possible we compensated the digital gains and forgot about it. This signal is used for SRCL in the initial acquisition, so we'd have noticed a sign flip. |
1969
|
Mon Sep 7 23:18:01 2009 |
Alberto | Update | Locking | Some locking attempts |
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. |
2011
|
Mon Sep 28 02:24:05 2009 |
rana | Update | Locking | MC1/3 Dewhitening found OFF: Turned back ON |
While trying to make the OAF work, I found that the XYCOM switches for MC1/3 have been set in the bad way for awhile. This means that the hardware filters were bypassed and that MC1 & MC3 were moving around too much at high frequency and possibly causing trouble with the locking. I have put them back into the default position.
On Friday, Jenne and I were playing around with turning the dewhitening off/on to see if it efffected the OAF stability. At the time, I didn't pay too much attention to what the state was. Looks like it was in the wrong state (hardware bypassed) when we found it. For the OAF work, we generally want it in that bypassed state, but its bad because it makes noise in the interferometer. The bits in question are bits 16-23 on the XYCOM screen.
I have updated the snapshot and set the screen in the appropriate settings. I used a swept sine measurement to verify the filter state. In the attached plot, green corresponds to XYCOM green and red corresponds to red. |
Attachment 1: C1SUS_SRM_XYCOM1.png
|
|
Attachment 2: Untitled.png
|
|
2027
|
Wed Sep 30 02:01:28 2009 |
rob | Update | Locking | week |
It's been a miserable week for lock acquisition, with each night worst than the last. The nadir was around Sunday night, when I couldn't even get a PRM to lock stably, which meant that the auto-alignment scripts could not finish successfully. It now appears that was due to some XYCOM mis-settings.
We've also been having problems with timing for c1susvme2. Attached is a one-hour plot of timing data for this cpu, known as SRM. Each spike is an instance of lateness, and a potential cause of lock loss. This has been going on for a quite a while.
Tonight we also encountered a large peak in the frequency noise around 485 Hz. Changing the MZ lock point (the spot in the PZT range) solved this.
|
Attachment 1: srmcpu.png
|
|
2030
|
Thu Oct 1 03:12:56 2009 |
rob | Update | Locking | some progress |
Good progress in IFO locking tonight, with the arm powers reaching about half the full resonant maximum.
Still to do is check out some weirdness with the OMC DAC, fix the wireless network, and look at c1susvme2 timing. |
2037
|
Thu Oct 1 15:42:55 2009 |
rob | Update | Locking | c1susvme2 timing problems update |
Quote: |
We've also been having problems with timing for c1susvme2. Attached is a one-hour plot of timing data for this cpu, known as SRM. Each spike is an instance of lateness, and a potential cause of lock loss. This has been going on for a quite a while.
|
Attached is a 3 day trend of SRM CPU timing info. It clearly gets better (though still problematic) at some point, but I don't know why as it doesn't correspond with any work done. I've labeled a reboot, which was done to try to clear out the timing issues. It can also be seen that it gets worse during locking work, but maybe that's a coincidence. |
Attachment 1: srmcpu2.png
|
|
2040
|
Fri Oct 2 02:55:07 2009 |
rob | Update | Locking | more progress |
More progress with locking tonight, with initial acquisition and power ramps working. The final handoff to RF CARM still needs work.
I found the wireless router was unplugged from the network--just plugging in the cable solved the problem. For some reason that RJ45 connector doesn't actually latch, so the cable is prone to slipping out of the jack.
|
2047
|
Sat Oct 3 14:53:24 2009 |
rob | Update | Locking | more progress |
Late last night after the ETMY settled down from the quake I made some more progress in locking, with the handoff to RF CARM succeeding once. The final reduction of the CARM offset to zero didn't work, however. |
2048
|
Mon Oct 5 02:51:08 2009 |
rob | Update | Locking | almost there |
Working well tonight: the handoff of CARM to RF (REFL2I), successful reduction of CARM offset to zero, and transition control of MCL path to the OUT1 from the common mode board. All that's left in lock acquisition is to try and get the common mode bandwidth up and the boost on. |
2056
|
Tue Oct 6 01:41:20 2009 |
rob | Update | Locking | DC Readout |
Lock acquisition working well tonight. Was able to engage CM boost (not superboost) with bandwidth of ~10kHz. Also succeeded once in handing off DARM to DC readout. |
2081
|
Mon Oct 12 17:14:39 2009 |
rob | Update | Locking | stability |
Last night, 2+ hour lock, probably broken by me driving too hard (DARM_EXC). |
Attachment 1: transpow.png
|
|