I couldn't understand the Y-End green setup as the PD was turned off and the sign of the servo was flipped. Once they are fixed, I could lock the cavity with the green beams.
[EricQ, Jenne, brains of other people]
Get green spots co-located with IR spots on ETMs, ITMs, check path of leakage through the arms, make sure both greens get out to PSL table
I had turned the green refl PD off on Tuesday while we were doing the IPANG alignment, since the beam was not so bright, and the LED on top of the PD was very annoyingly bright. I forgot to turn it back on. The sign flip on the servo, I can't explain.
After lots of trial and error, and a little inspiration from Koji, I have written a new script that will run when you select "update snapshot" in the yellow ! button on any MEDM screen.
Right now, it's only live for the OAF_OVERVIEW screen. View snapshot and view prev snapshot also work.
Next on the list is to make a script that will create the yellow buttons for each screen, so I don't have to type millions of things in by hand.
The script lives in: /cvs/cds/rtcds/caltech/c1/scripts/MEDMsnapshots, and it's called....wait for it....... "updatesnap".
Currently the update snapshot script looks at the 3 letters after "C1" to determine what folder to put the snapshots in. (It can also handle the case when there is no C1, ex. OAF_OVERVIEW.adl still goes to the c1oaf folder). If the 3 letters after C1 are SYS, then it puts the snapshot into /opt/rtcds/caltech/c1/medm/c1sys/snap/MEDM_SCREEN_NAME.adl
Mostly this is totally okay, but a few subsystems seem to have incongruous names. For example, there are screens called "C1ALS...." in the c1gcv folder. Is it okay if these snapshots go into a /c1als/snap folder, or do I need to figure out how to put them in the exact same folder they currently exist in? Or, perhaps, why aren't they just in a c1als folder to begin with? It seems like we just weren't careful when organizing these screens.
Another problem one is the C1_FE_STATUS.adl screen. Can I create a c1gds folder, and rename that screen to C1GDS_FE_STATUS.adl? Objections?
In the previous elog we've compared Matlab and Foton SOS representations using low-order filter. Now we move on to high order filters and see that Foton is pretty bad here.
We consider Chebyshev filter of the first type with cuf off frequency 12 Hz and ripple 1 dB. In the table below we summarize the GAINS obtained by Matlab and Foton for different digital filter orders.
We can see that for high orders the gains are completely different (ORDER of 2!!!). Interesting that besides of very bad GAIN, SOS-MATRIX Foton calculates pretty well. I checked up to 5 digit - full coincidence. Only GAIN is very bad.
The filter considered is cheby1("LowPass",6,1,12) and is a part of the bad Cheby filter where we loose coherence and see some other strange things.
We investigated some more the discrepancy between Matlab and Foton numbers. The comparison of cheby1(k, 1, 2*12/16384) was done between versions implemented in Matlab, R and Octave. Filters created by R and Octave agree with Foton.
Also, we found that Matlab has gross precision errors for cutoff frequencies just smaller than used in our fitler, for example cheby1(6, 2*3/16384) fails miserably.
It would be useful to see some plots so we could figure out exactly what magnitude and phase error correspond to "gross" and "miserable".
I'd like to re-measure the transfer function from driving MC2 position to the MC_L_DQ channel (for feedforward purposes). Swept sine would be one option, but I can't get the "Envelope" feature of DTT to work, the excitation amplitude isn't getting scaled as specified in the envelope, and so I'm unable to make the measurement near 1 Hz (which is where the FF is effective). I see some scattered mentions of such an issue in past elogs but no mention of a fix (I also feel like I have gotten the envelope function to work for some other loop measurement templates). So then I thought I'd try broadband noise injection, since that seems to have been the approach followed in the past. Again, the noise injection needs to be shaped around ~1 Hz to avoid knocking the IMC out of lock, but I can't get Foton to do shaped noise injections because it doesn't inherit the sample rate when launched from inside DTT/awggui - this is not a new issue, does anyone know the fix?
Note that we are using the gds2.15 install of foton, but the pre-packaged foton that comes with the SL7 installation doesn't work either.
The envelope feature for swept-sine wasn't working because i specified the frequency grid in the wrong order apparently. Eric von Reis has been notified to include a sorting algorithm in future DTT so that this can be in arbitrary order. fixing that allows me to run a swept sine with enveloped excitation amplitude and hence get the TF I want, but still no shaped noise injections via foton 😢
do you really mean awggui cannot make shaped noise injections via its foton text box ? That has always worked for me in the past.
If this is broken I'm suspicious there's been some package installs to the shared dirs by someone.
The problem is that foton does not inherit the model sample rate when launched from DTT/awggui. This is likely some shared/linked/dynamic library issue, the binaries we are running are precompiled presumably for some other OS. I've never gotten this to work since we changed to SL7 (but I did use it successfully in 2017 with the Ubuntu12 install).
While we looking using dtt and going over the basics of its operation, we discovered that the filter sample rates for the suspensions were still set to 2048 Hz, rather than 16384 Hz which is the new front end. This caused the filters loaded into the front ends to not behave as expected.
After correcting the sample rate, the transfer functions obtained from dtt are now looking like the bode plots from foton.
We fixed the C1SUS.txt and C1MCS.txt files in the /opt/rtcds/caltech/c1/chans/ directory, by changing the SAMPLING lines to have 16384 rather than 2048.
I found the current bias output channels, C1:SUS-<OPTIC>_<DOF>BiasAdj, were all pointed at C1:SUS-<OPTIC>_ULBiasSet for every degree of freedom. This same issue appeared in all eight database files (one per optic), so it looks like a copy-and-paste error. I fixed them to all reference the correct degree of freedom.
X green beat note found!
1. Near-field and far-field alignment on the PSL table. The near-field alignment checked by looking at the camera and the far-field alignment checked by allowing the beams to propagate by removing the DC PD.
2. Check laser temperature and get a sense of how the offset translates to the actual laser temperature.
3. Get an idea of the expected temperature of laser using the plot in elog.
PSL laser temperature = 31.45 deg C
X end laser temperature = 39.24 deg C
C1-ALS-X_SLOW_SEERVO2_OFFSET = 4810
Amplitude of beat note = -40dBm
I do not understand why
1. The amplitude of beatnote falls linearly with frequency (peak traced using 'hold' option of the spectrum analyzer).
2. I found the beat note at the RF output of the PD. Earlier, while I was trying to search for the beatnote from the RFmon output of the betabox, there was a strong peak at 29.6MHz that existed even when the green shutters were closed. It's source has to be traced.
Solve beatbox puzzle and lock arm using ALS.
It was unlocked since ~4:30am. No idea why. It's relocked so I can try round N of measuring the PRC length.
We found the beat at 1064nm. T(PSL)=26.59deg, T(X-end)=31.15deg.
The X-end laser was moved to the PSL table.
The beating setup was quickly constructed with mode matching based on beam profile measurements by the IR cards.
We used the 1GHz BW PD, Newfocus #1611-FS-AC.
As soon as we swept the Xtal temp of the X-end laser, we found the strong beating.
The beating setup was quickly constructed with mode matching based on beam profile measurements by the IR cards.
We used the 1GHz BW PD, Newfocus #1611-FS-AC.
[Koji / Suresh]
We worked on the 1064 beating a bit more.
- First of all, FSS and FSS SLOW servo were disabled not to have variating Xtal temp for the PSL.
- The PSL Xtal temp (T_PSL) was scanned from 22deg-45deg while we search the Xtal temp (T_Xend) for the Xend laser to have the beat freq well low (f<30MHz).
The pumping current for each laser was I_PSL = 2.101 [A] and I_Xend = 2.000 [A]
For a certain T_PSL, we found multiple T_Xend because the freq of the laser is not a monotonic function of the Xtal temperature. (see the innolight manual).
T_Xend to give us the beating was categorized in the three sets as shown in the figure. The set on "curve2" is the steadiest one. (Use this!)
The trends were quite linear but the slope was slightly off from the unity.
- T_PSL was scanned to see the trend of the PMC output.
The PMC was sometimes locked to the mode with lower transmission (V_PMCT ~ 3.0V).
When T_PSL ~ 31deg we consistently locked the PMC at higer transmission (V_PMCT ~ 5.3V).
At the moment we decided the operating point of T_PSL = 32.25 deg, V_PMCT = 5.34, where we found the beat at T_Xend=38.28deg.
- We cleaned up the PSL table more than how it was. Returned the tools to their original places.
The X-end laser was shut down and was left on the PSL table.
Kiwamu can move the X-end laser to the Xend and realign it.
Then we should be able to see the green beating quite easily.
Thesedays we were continuously annoyed by unELOGGED activities of the interferometer.
MC2 LOCKIN was left on and has continuously injected frequency noise and beam pointing modulation
during all of the comissioning / vent preparation.
C1:SUS-MC2_LOCKIN2_OSC_FREQ was 0.075
C1:SUS-MC2_LOCKIN2_OSC_CLKGAIN was 99
For more than a week ago we noticed that the curve of the MC WFS stripchart suddenly got THICKER.
MC WFS, arm transmission, beam pointing... everything was modulated.
It was not WFS instability, and it was not the cavity mirrors.
Today I made the investigation and finally tracked down the cause of this issue to be on MC2 suspension.
Then it was found that this LOCKIN was ON.
There is no direct record of this lockin in the frame files.
From the recorded channel "C1:IOO-WFS2-YAW_OUT16" (which is the trace on the StripTool chart on the wall)
It was turned on at July 10th, 2:00UTC (July 9th, 7PM PDT)
Yes, this was not ELOG'd by me, unfortunately. This was the MC tickler which I described to some people in the control room when I turned it on.
As Koji points out, with the MCL path turned off this injects frequency noise and pointing fluctuations into the MC. With the MCL path back on it would have very small effect. After the pumpdown we can turn it back on and have it disabled after lock is acquired. Unfortunately, our LOCKIN modules don't have a ramp available for the excitation and so this will produce some transients (or perhaps we can ezcastep it for now). Eventually, we will modify this CDS part so that we can ramp the sine wave.
I've written a new TICKLE script using the newly found 'cavget' and 'cavput' programs. They are in the standard epics distribution as extension binaries. They allow multichannel read/write as well as ramping, delays, incremental steps, etc. http://www.aps.anl.gov/epics/tech-talk/2012/msg01465.php.
Running from the command line, they seem to work fine, but I've left it OFF for now. I'll switch it into the MC autolocker at some point soon.
I found the PSL laser has been off for four hours. Nobody seemed to know why.
I just turned it on and it is now providing about 10% lower power compared with one before the shutdown.
Let's keep the eyes on the power if it can recover as the housing gets warm.
Frame builder is down. PRM has tripped its watch dogs. I have reset the watch dog on PRM and turned on the OPLEV. It has damped down. Unable to check what happened since FB is not responding.
There was an minor earthquake yesterday morning which people could feel a few blocks away. It could have caused the the PRM to unlock.
Jamie,Rolf, is it okay or us to restart the FB?
If it's down it's alway ok to restart it. If it doesn't respond or immediately crashes again after restart then it might require some investigation, but it should always be ok to restart it.
I tried restarting the fb in two different ways. Neither of them re-established the connection to dtt or epics.
1) I restarted the fb from the control room console with the 'shutdown' command. No change.
2) I halted the machine with 'shutdown -h now' and restarted it with the hardware reset button on its front-panel. No change.
The console connected to the fb showed that the network file systems did not load. Could this have resulted in failure to start several services since it could not find the files which are stored on the network file system?
The fb is otherwise healthy since I am able to ssh into it and browse the directory structure.
The fb is okay. Rana found that it works on Pianosa, but not on Allegra or Rossa. It also works on Rosalba, on which Jamie recently installed Ubuntu.
The white fields on the medm 'Status' screen for fb are an unrelated problem.
Please be conscious of what components are doing what. The problem you were experiencing was not "frame builder down". It was "dtt not able to connect to frame builder". Those are potentially completely different things. If the front end status screens show that the frame builder is fine, then it's probably not the frame builder.
Also "epics" has nothing whatsoever to do with any of this. That's a completely different set of stuff, unrelated to DTT or the frame builder.
I think the daqd process isn't running on the frame builder.
I tried telnetting' to fb's port 8087 (telnet fb 8087) and typing "shutdown", but so far that is hanging and hasn't returned a prompt to me in the last few minutes. Also, if I do a "ps -ef | grep daqd" in another terminal, it hangs.
I wasn't sure if this was an ntp problem (although that has been indicated in the past by 1 red block, not 2 red blocks and a white one), so I did "sudo /etc/init.d/ntp-client restart", but that didn't make any change. I also did an mxstream restart just in case, but that didn't help either.
I can ssh to the frame builder, but I can't do another telnet (the first one is still hung). I get an error "telnet: Unable to connect to remote host: Invalid argument"
Thoughts and suggestions are welcome!
CPU load seems extremely high. You need to reboot it, I think
controls@fb /proc 0$ cat loadavg
36.85 30.52 22.66 1/163 19295
This CPU load may have been me deleting some old frame files, to see if that would allow daqd to come back to life.
Daqd was segfaulting, and behaving in a manner similar to what is described here: (stack exchange link). However, I couldn't kill or revive daqd, so I rebooted the FB.
Things seem ok for now...
[Joe, Jamie, Alex]
I asked Alex which cron to use (dcron? frcron?). He promptly did the following:
rc-update add dcron default
Copied the wiper.pl script from LLO to /opt/rtcds/caltech/c1/target/fb/
At that point, I modified wiper.pl script to reduce to 95% instead of 99.7%.
I added controls to the cron group on fb:
sudo gpasswd -a controls cron
I then added the wiper.pl to the crontab as the following line using crontab -e.
0 6 * * * /opt/rtcds/caltech/c1/target/fb/wiper.pl --delete &> /opt/rtcds/caltech/c1/target/fb/wiper.log
Note, placing backups on the /frames raid array will break this script, because it compares the amount in the /frames/full/, /frames/trends/minutes, and /frames/trends/seconds to the total capacity.
Apparently, we had backups from September 27th, 2010 and March 22nd, 2011. These would have broken the script in any case.
We are currently removing these backups, as they are redundant data, and we have rsync'd backups of the frames and trends. We should now have approximately twice the lookback of full frames.
Since Leo was trying to demo his LIGO Data Listener code, he noticed that there was and NDS2 issue. The NDS2 guy (JZ) noticed that the FrameBuilder had an issue.
We investigated. At 4PM on Dec 31, the GPS timestamp of the frame file names started to be recorded wrong. In fact, it started to give it a file name matching the correct time from 1 year in the past.
So that's our version of the Y2011 bug. Here's the 'ls' of /frames/full:
drwxr-xr-x 2 controls controls 252K Dec 26 03:59 9773
drwxr-xr-x 2 controls controls 260K Dec 27 07:46 9774
drwxr-xr-x 2 controls controls 256K Dec 28 11:33 9775
drwxr-xr-x 2 controls controls 252K Dec 29 15:19 9776
drwxr-xr-x 2 controls controls 244K Dec 30 19:06 9777
drwxr-xr-x 2 controls controls 188K Dec 31 16:00 9778
drwxr-xr-x 2 controls controls 148K Jan 1 08:53 9463
drwxr-xr-x 2 controls controls 260K Jan 2 12:39 9464
drwxr-xr-x 2 controls controls 252K Jan 3 16:26 9465
drwxr-xr-x 2 controls controls 248K Jan 4 20:13 9466
drwxr-xr-x 2 controls controls 36K Jan 5 00:22 9467
controls@fb /frames/full $
The culprit is the directory who's name starts out as 9463 whereas it should be 9779.
Email from Alex:
Turned out to be the lack of current year information in the IRIG-B signal
received by the Symmetricom GPS card in the frame builder machine caused
this. I have added a constant in daqdrc to bring the seconds forward:
controls@fb /opt/rtcds/caltech/c1/target/fb $ grep symm daqdrc
Hopefully we will be upgrading to the newer timing system at the 40M this
year, so this will not happen again next year.
Doing an 'ls -lrt' in /frames/full/ now shows that the names are correct:
drwxr-xr-x 2 controls controls 249856 Dec 30 19:06 9777
drwxr-xr-x 2 controls controls 192512 Dec 31 16:00 9778
drwxr-xr-x 2 controls controls 151552 Jan 1 08:53 9463
drwxr-xr-x 2 controls controls 266240 Jan 2 12:39 9464
drwxr-xr-x 2 controls controls 258048 Jan 3 16:26 9465
drwxr-xr-x 2 controls controls 253952 Jan 4 20:13 9466
drwxr-xr-x 2 controls controls 151552 Jan 5 13:54 9467
drwxr-xr-x 2 controls controls 12288 Jan 5 15:57 9783
Just a proof that the DAQ is working - ran DTT on nodus from 3 hours ago.
We looked into the /frames situation a bit tonight. Here is a summary:
Plan of action:
BTW - the last chiara (shared drive) backup was October 16 6 am. dmesg showed a bunch of errors, Koji is now running fsck in a tmux session on chiara, let's see if that repairs the errors. We missed the opportunity to swap in the 4TB backup disk, so we will do this at the next opportunity.
DTT stopped working for recent data. An 'ls' in the frames/full/ directory reveals:
drwxr-xr-x 2 controls controls 258048 Feb 3 12:26 9807
drwxr-xr-x 2 controls controls 258048 Feb 4 16:13 9808
drwxr-xr-x 2 controls controls 262144 Feb 5 19:59 9809
drwxr-xr-x 2 controls controls 258048 Feb 6 23:46 9810
drwxr-xr-x 2 controls controls 258048 Feb 8 03:33 9811
drwxr-xr-x 2 controls controls 262144 Feb 9 07:19 9812
drwxr-xr-x 2 controls controls 253952 Feb 10 11:06 9813
drwxr-xr-x 2 controls controls 266240 Feb 11 14:53 9814
drwxr-xr-x 2 controls controls 266240 Feb 12 18:39 9815
drwxr-xr-x 2 controls controls 266240 Feb 13 22:26 9816
drwxr-xr-x 2 controls controls 262144 Feb 15 02:13 9817
drwxr-xr-x 2 controls controls 253952 Feb 16 05:59 9818
drwxr-xr-x 2 controls controls 241664 Feb 17 09:46 9819
drwxr-xr-x 2 controls controls 28672 Feb 17 12:22 9820
drwxr-xr-x 2 controls controls 32768 Feb 17 15:06 6663
drwxr-xr-x 2 controls controls 73728 Feb 17 23:39 6664
controls@fb /frames/full $ date
Thu Feb 17 23:39:27 PST 2011
There are at least 5 free DAC channels (4 if you discount the one channel from these that I am hijacking) available in the 1Y2 electronics rack.
Jamie's nice wiring diagram shows the topology - the actual DAC card sits in 1Y3 inside the c1lsc expansion chassis (while the c1lsc frontend itself is in 1X4). The output of the DAC goes via SCSI to an interface box (D080303) and then to some dewhitening/AI boards (D000316). There are a total of 16 DAC channels available, out of which 8 are used for the TTs, 2 are used for the DAFI model, and one is labeleld "From c1ioo 1X2" (I don't know what this one is for). So I'm going to use some of these channels for measuring the coupling of oscillator noise and intensity noise to MICH in the DRMI lock.
The de-whitening/AI board seems to be old - it has 2x 800Hz Butterworth LPFs and no notch for the clock frequency, but maybe this doesn't matter for the tests I have in mind. The AI board available on 1X2 is more modern but routing the DAC channels from 1Y2 to it is going to be some work.
I'm going to add my testpoint to c1daf given that it seems to be the least critical model on c1lsc.
EDIT: testpoints added to c1daf don't show up in the list of available channels - there was some issue with this model while we were getting the new RTCDS going. So I'm moving my temporary testpoint to c1cal instead.
its an acquired taste, but its a must since we're sending an interferometer to India
Free swing of ITMY started at
Tue Sep 6 17:41:43 PDT 2011
I think Kiwamu accidentally restarted this kick at 17:48:02 PDT.
The free swinging spectra of ITMs, ETMs, BS, PRM and SRM were measured last night in order to make sure that nothing wrong have happened by the wiping.
I think there are nothing wrong with ITMs, ETMs, BS, PRM and SRM successfully.
For the comparison, Yoichi's figure in his elog entry of Aug.7 2008 is good, but in his figure somehow PRM spectrum doesn't look correct.
Anyway, compared with his past data, there are no significant changes in the spectra. For PRM which has no counterpart to compare with, its shape of spectra looks similar to any other spectra. So I think PRM is also OK. The measured spectra are attached below.
Motivated by the strange pitch/yaw coupling behavior we ran into while doing diagonalization, we looked at the oplev pitch and yaw free swing spectra for all 4 test masses (see attachment 1). We saw the same behavior there: At the peak frequencies for the angular degress of freedom, the oplevs saw significant contributions from both pitch and yaw. We also examined the phase between pitch and yaw at these peaks and found that consistently, pitch and yaw were in phase at one of the resonance frequencies and out of phase at the other (ignoring the pos and side peaks).
This corresponds physically to angular motion about some axis that is diagonal, ie not perfectly vertical or horizontal. If we trust the oplev calibration, and Eric says that we do, then the angle of this axis of rotation with the horizontal (pitch axis) is
Where Y and P are yaw and pitch ASD values. This will always give an angle between 0 and 90 degrees; which quadrant the axis of rotation occupies can be dermined by looking at the phase between pitch and yaw at the same frequencies. 0 phase means that the axis of rotation lies somewhere less than 90 degrees counterclockwise from the horizontal as viewed from the AR face of the optic, and a phase of 180 degrees means the axis is clockwise from horizontal (see attachment 2). Qualitatively, these features show up the same way for segments of data taken at different times. In order to get some quantitative sense of the error in these angles, we found them using spectrogram values with a bandwidth of 0.02 Hz averaged over 4000 seconds.
Results (all numbers in degrees unless otherwise specified):
peak 1 ( 0.692 Hz):
ptich/yaw phase: -179.181
peak 2 ( 0.736 Hz):
pitch/yaw phase: 0.0123677
peak 1 ( 0.502 Hz):
ptich/yaw phase: -179.471
peak 2 ( 0.688 Hz):
pitch/yaw phase: -0.43991
peak 1 ( 0.73 Hz):
ptich/yaw phase: -0.227034
peak 2 ( 0.85 Hz):
pitch/yaw phase: -179.856
peak 1 ( 0.724 Hz):
ptich/yaw phase: 6.03312
peak 2 ( 0.844 Hz):
pitch/yaw phase: -176.838
ETMY and ITMX both show a more significant (~4x) contribution from pitch on one peak, and from yaw on the other. This is reflected in the fact that they each have one angle somewhat close to 0 (below 30 degrees) and one close to 90 (above 60 degrees). The other two test masses don't follow this rule, meaning that the 2 angular frequency peaks do not correspond to pitch and yaw straightforwardly.
Also, besides ITMX, the axes of rotation are at least several degrees away from being perpendicular to each other.
I have the DRMI free swinging right now, since it's not really locking. Looking at these time series in the attached pdf, particularly around time=1.15, it would be super handy to trigger the SRCL degree of freedom on AS110 after the PRMI is triggered on POP22.
In this night, I checked the free swinging spectra of ETMX to make sure nothing wrong with ETMX by the wiping.
Compared with the past (Aug.6 2008), the spectra of ETMX doesn't show significant change.
Successfully the wiping activity didn't change its configuration so much and didn't bring bad situations.
(bad situation means for example, the suspended components hit some others).
The spectra of ETMX by DTT are attached. Also you can see the past spectra in Yoichi's entry.
Yoichi's data was taken during the air-pressure condition, so it's good for comparing.
Actually I compared those data by my eyes, because I could not get the past raw data somehow.
The resonant frequencies and their typical height changed a little bit, but I think those are not significant.
NOTE: In the figure, pitch and yaw modes (~0.57Hz and ~0.58Hz) look like having a smaller Q-factor than the past.
To take the free swinging Michelson measurements for the interferometer calibration Jamie aligned the beam splitter with ITMX and ITMY. I recorded the GPS time (1027827100 and for several hundred seconds later) when the Michelson was aligned in order to look at the correct data. I then copied the python script nds-test.py from Jamie, and modified it to take and plot data from C1:LSC-AS55_Q_ERR_DQ offline. I used dataviewer to verify that C1:LSC-AS55_Q_ERR_DQ and C1:LSC-AS55_Q_ERR were recording the same signal, and to check that I was taking the correct data with NDS. Taking data online worked as well, but it was easier to use a time when the Michelson was known to be free-swinging and take data offline. Attached is some sample data while free-swinging, with time in GPS time.
I ran "freeswing all" at Fri Aug 19 01:09:28 PDT 2011 (997776583) and "opticshutdown" as well.
I noticed that Chiara's backup HD (which has a capacity of 1.8TB, vs the main drives 2TB) was near to getting full, meaning that we would soon be without a local backup.
I freed up ~200GB of space by compressing the autoburt snapshots from 2012, 2013, 2014. Nothing is deleted, I've just compressed text files into archives, so we can still dig out the data whenever we want.
I just started a freeswing all, as a final check before we pump:
Wed Sep 7 00:43:21 PDT 2011
Wed Sep 7 00:43:32 PDT 2011
WATCHDOGS WILL BE RESET 5 HOURS AFTER THIS TIME
sleeping for 5 hours...
Jamie: Please do a quickie analysis (at least for the ITMs) before helping Steve with the heavy doors.
I closed the PSL shutter.
Both ITM chambers were checked for tools, so there should be nothing left to do but put the heavy doors on, and begin pumping.
I modified the script freeSwing.py to use damping loop output switches to free the optic instead of watchdog or coil output filters. This ensures that the free swing test is being done at the nominal position of the optic. I started tests for LO1, LO2, As2, As4, PR2, PR3, and SR2 in a tmux session names freeSwing on rossa.
Note: LO2 face OSEMs are hardly sensitive to any motion right now due to excessive pitch offset required for LO beam. We should relieve this offset to LO1 and rerun this test later.
This work is now complete. The box was characterized and re-installed in 1X2. I am able to (briefly) lock the IMC and see PDH fringes in POX and POY so the lowest order checks pass.
Even though I did not deliberately change anything in the 29.5 MHz path, and I confirmed that the level at the output is the expected 13 dBm, I had to lower then IN1 gain of the IMC servo by 2dB to have a stable lock - should confirm if this is indeed due to higher optical gain at the IMC error point, or some electrical funkiness. I'm not delving into a detailed loop characterization today - but since my work involved all elements in the RF modulation chain, some detailed characterization of all the locking loops should be done - I will do this in the coming week.
After tweaking the servo gains for the POX/POY loops, I am able to realize the single arm locks as well (though I haven't dont the characterization of the loops yet).
I'm leaving the PSL shutter open, and allowing the IMC autolocker to run. The WFS loops remain disabled for now until I have a chance to check the RF path as well.
Unrelated to this work: Koji's swapping back of the backplane cards seems to have fixed the WFS2 issue - I now see the expected DC readbacks. I didn't check the RF readbacks tonight.
Update 7 Dec 2020 1 pm: A ZHL-2 with heat sink attached and a 11.06 MHz Wenzel source were removed from the box as part of this work (the former was no longer required and the latter wasn't being used at all). They have been stored in the RF electronics cabinet along the east arm.