We found the MC reflection was distorted . And WFC beam went to upward of QPD
We recentered WFC beam and these problems were fixed
Good settings for acquisition:
MC INPUT GAIN = 6 dB
FAST polarity MINUS
VCO Gain -3 dB
MC LIMITER Disable
FSS TEST1 TEST
FSS CG -3 dB
FSS FG 13 dB
SUS-MC1_SENSOR_SIDE and SUS-MC2_SENSOR_UL are glitching
Yesterday's 4.8mag earthquake at Salton Sea is shown on Channel 1
C1:IOO-MC_BOOST1 0 (You can turn it on if you want, but turn it off for locking)
C1:IOO-MC_POL 1 (Minus)
C1:IOO-MC_LIMITER 1 (Disable)
C1:PSL-FSS_SW1 0 (Test1 ON)
C1:PSL-FSS_FASTGAIN 14 (Do not increase it, at least while locking. Otherwise the phase lag from the PZT loop gets significant and the MC loop will be conditionally stable).
When all things fail (netgpibdata.py is giving me weird data. When I plot the data it has saved from the 4395A, it's some wierd other universe's version of my transfer function. I don't really know what's up. I'm pretty sure I'm getting the 'correct' data, since each TF looks vaguely like it should, but with some crazy humps. I'll talk to Yoichi in the morning about it maybe.) (also, we're low on emergeny floppy discs), you can always take a picture of the Agilent 4395's screen, as shown below.
* Mode cleaner and PMC are both relocked after my shenanigans, and I'll try again in the morning (I assume locking is going on tonight) to get real TF's with real data, as opposed to the photo method.
Note to self: post the data of the TFs in the elog along with the plots, for posterity.
These TFs are of the Mode Cleaner servo board, exciting IN1 (or the 3.7MHz notch pomona box which is connected to IN1), and measuring at the SERVO out of the board.
One with the box, one without the box, and one of just the box for good measure.
netgpibdata.py is giving me weird data. When I plot the data it has saved from the 4395A, it's some wierd other universe's version of my transfer function. I don't really know what's up.
Yoichi, in all his infinite wisdom, reminded me that the netgpibdata script saves the data as the REAL and IMAGINARY parts, not the Mag and Phase. Brilliant. Using that nugget of information, here are the TFs that I measured earlier:
The last attachment is the .dat and .par files which contain the data and measurement parameters for the 3 TFs in the plots.
We ran cable from the suspension rack to the IOO rack to record the signals with DAQ channels.
The test channels:
UL coil C1:IOO-MC_DRUM1 (Caryn was using, we will replace when we are done)
UL input C1:IOO-MC_TMP1 (Caryn was using, we will replace when we are done)
LR coil C1:PEM-OSA_SPTEMP
LR input C1:PEM-OSA_APTEMP
We will leave these overnight; we intend to remove them tomorrow or Monday.
We closed the PSL shutter and killed the MC autolocker.
Earthquake mag 4.0 at Lennox, Ca trips MC2 watchdogs http://quake.usgs.gov/recenteqs/Quakes/ci10411545.html
See 40m accelerometers as they see it.
While Clara was working on her Wiener filtering and optimizing the locations of the accelerometers, she discovered that MC_L and MC_L_256 are totally flatlined. I looked at them, and it looks like they've been dead since ~9:30pm-ish on Sunday night. Bootfest-type activities shall commence shortly.
Under Alberto's tutalage, I rebooted the whole vme set (iovme, sosvme, susvme1, susvme2), and after that MC_L was all good again.
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.
I'm impressed by Rana's simple way to align the MC. IFO arms are locked or flashing. 20 days trend attached.
Q. When should we use plano-convex lenses, and when should we use bi-convex?
As I had the same question from Jenne and Dmass in a month,
I just like to introduce a good summary about it.
Lens selection guide (Newport)
At a first order, they have the same function.
Abberation (= non-ideal behavior of the lens) is the matter.
I tilted the periscope beam and aligned the MC. Now the spot at the Faraday entrance is near the center of the aperture in up/down space. The arm powers are only going up to ~0.8, though. Maybe we should try a little bit of left/right.
I looked at the IP POS spot with a viewer card, and it looked round, so no obvious egregious clipping in the Faraday. Someone might take a picture with one of the GigE camera and get us a beam profile there.
We no longer have an MC1 and MC3 camera view.
I can see a bright scatterer that can be seen from the east viewport of the BSC, but I can't tell what it is. It could be a ghost beam.
It would be nice to get an image looking into the north viewport of the IOO chamber. I can't see in there because the BS oplev table is in the way.
I am (was) able to get the mode cleaner mostly locked, but because WFS2 wasn't centered, the MC would drift, then lose lock. I recentered both the WFS (after unlocking the MC and the MZ), and am now about to commence relocking both of those.
Note to self: WFS get centered based on the direct reflection from MC1. Once the MC is close enough, the WFS are enabled, and they twiddle all 3 MC mirrors to minimize their error signal. Moral of the story: make sure the WFS are centered.
The mode cleaner seems to be locking again. I've manually unlocked it a few times in the past 20min, and most of the time it catches lock again (maybe about 80% of the time). Other times, it starts to lock in a bad mode, and can't fix itself, so I unlock it, and let it restart and it usually does fine the second time around.
I'd like it to be a little more robust, but I'm having a bit of trouble zeroing in on the optimal alignment for quickest, most durable lock aquisition of the MC. Right now I'm going to leave it for a little while to make sure it doesn't fall apart.
Jenne, Koji, Rana
After fixing up the Mode Cleaner a bit more (fiddling more with the MC_align sliders to get the alignment before locking, making sure that it is able to lock), we noticed that the MC Trans path could use some help. To align the MC, we put MC1 and MC3 back into the position where Rob left it on Thursday and then maximized the transmission with MC2. Then we went back and maximized with MC1/3 keeping in mind the Faraday. We got a good transmission and the X-arm had a transmission of 0.8 without us touching its alignment.
Upon looking at the AP table portion of the MC_trans path, we decided that it was all pretty bad. The light travels around the edge of the AP table, then out the corner of the table toward the PSL table. A periscope brings it down to the level of the PSL table, and then it travels through a few optics to the MC_trans QPD.
The light was clipping on the way through the periscope, and so the MC_trans QPD was totally unreliable as a method of fine-tuning the alignment of the Mode Cleaner. Ideally we'd like to be able to maximize MC_trans, and say that that's a good MC alignment, but that doesn't work when the beam is clipped.
1. The first turning mirror on the AP table after the beam comes out of the vacuum was changed from a 1" optic to a 2" optic, because the spot size is ~4-6mm. We were careful to avoid clipping the OMCT beam, by using a nifty U200 mount (C-shaped instead of ring-shaped).
2. We placed a lens with a RoC of 1m (focal length for 1064nm is ~2m), a 2" optic, between the first two mirrors, to help keep the beam small-ish when it gets to the periscope, to help avoid clipping.
3. Rana adjusted the angle of the upper periscope mirror, because even when the beam was centered on the steering mirror directly in front of the periscope and the spot was centered on the first periscope mirror, the beam wouldn't hit the bottom periscope mirror.
4. We noticed that the bottom periscope mirror was mounted much too low. It was mounted as if the optics after it were 3" high, which is true for all of the input optics on the PSL table. However, for the MC_trans stuff, all the optics are 4". We moved the periscope up one hole, which made it the correct height.
5. We removed the skinny beam tube which guided/protected the beam coming off the periscope after a steering mirror since it (a) wasn't necessary and (b) was clipping the beam. We cannot use such skinny tubes anymore Steve.
6. There was a lens just before the 2nd steering mirror on the PSL table portion, which we removed since we had placed the other lens earlier in the path. 2 lenses made the beam too skinny at the QPD.
7. After this 2nd steering mirror, there had been a pickoff, to send a bit of beam at a crazy angle over to the RFAM mon, which we removed. This results in a much brighter beam at the MC_trans QPD, and at the camera. The QPDs readouts are now a factor of ~3.5 higher than they used to be. These (especially the camera) could use some ND-filtering action.
8. The steering optic directly in front of the MC_trans QPD is a beamsplitter, and instead of dumping the light which doesn't go to the MC_trans QPD, we used this to go over to the RFAM mon (instead of the pickoff which we had removed).
9. Koji fixed up the optics directly in front of the RFAM mon, accomodating the new position of the input light (now at a much more reasonable angle, and about 15cm farther back from the PD). Note the beam dump which is preventing the cables from the FSS board from entering the beam path. This included removing an ND filter wheel, so the RFAM mon values will all be higher now. Koji also has the beam going to the PD going at a slight angle, so that the beam isn't directly reflected on itself, so that it can be dumped.
10. We aligned the beam onto the MC_trans QPD using the first steering mirror on the PSL table.
11. We also removed the giant wall of beam dumps separating the squeezing section of the table from the rest of the table.
Alberto will elog things about the RFAM mon, including different values of the PD output, etc.
Still on the to-do list:
A. Replace the second steering mirror on the AP table after the MC_trans light leaves the vacuum with a 2" optic, since the lens we placed isn't tight enough to make the spot small there yet. Us a U200A mount if possible, because they are really nice mounts.
B. Put an ND filter in front of the MC_trans camera, because the image is too bright.
C. Normalize the MC_trans QPD - the horz and vert are pretty much direct voltage readouts, with no normalization. They should be divided by the DC value. This lack of normalization results in higher sensitivity to input pointing.
D. Long term, next time someone wants to optimize the MC_trans path, move all the optics, including the MC_trans QPD and the camera closer to the periscope on the PSL table. There's no reason for the beam to be traveling nearly the full width of the PSL table when we're not manuvering around squeezing stuff.
E. Never, ever purchase these horrible U100 or U200 mounts with the full ring and the little plastic clips. They are the "AC28" version. Bad, bad, bad.
Image 1: The new setup of the AP table, Mc_trans portion.
Image 2: New setup of the MC_trans part of the PSL table.
The MC_trans QPD Pitch and Yaw readout on the Lock_MC screen are now normalized by the trans_sum. I used the method described in my entry elog 1488.
/caltech/target/c1iool0/ioo.db now includes:
field(SCAN, ".1 second")
field(SCAN, ".1 second")
The Lock_MC screen was changed to show these new P and Y channels.
So that I can collect a bit of free-swinging Mode Cleaner data, I started a script to wait 14400 seconds (4 hours), then unlock the mode cleaner. It should unlock the MC around 4am. As soon as someone gets in in the morning, you can relock it. I should have plenty of data by then.
When Rob and I were getting started on locking for the evening, Mode Cleaner lost lock a few times, but every time it lost lock, it took forever to reaquire, and was pretty insistent on locking in the TEM10 mode. I proposed that the alignment might be sketchy. I've been fiddling with the MC alignment sliders for the last hour and a half or so, but I think I'm not 100% in tune with the 3 mirror parameter space. The mode cleaner now locks, but I'm not in love with its' alignment. The WFS are definitely catywhompus. Before doing hardware things like recentering the WFS, I'm going to wait until tomorrow to consult with an alignment expert.
In case this is helpful for tomorrow, before I touched any of the sliders:
Optic, Pitch, Yaw
MC1, 3.1459, -0.7200
MC3, -0.8168, -3.0700
MC2, 3.6360, -1.0576
Now that mode cleaner locks, although not in a great alignment:
MC1, 3.1089, -0.7320
MC3, -0.7508, -3.0770
MC2, 3.6610, -1.0786
If I knew how to kill my script to unlock the mode cleaner, I would. But I sourced it, and Rob didn't know earlier this evening how to kill something which is started with 'source' since it doesn't seem to get a process number like when you './' to run a script. So the Mode Cleaner will probably be unlocked in the morning, and it may be persnickity to get it relocked, especially if the tree people are doing tree things with giant trucks again in the morning.
The MC WFS have apparently been bad for a few days, causing the MC alignment to drift away at DC. We tried a few things to fix it, including jiggling some EPICS settings in the WFS head & demod screens. This seemed to work for WFS1 but not WFS2. Confused, we decided to go stare at the rack 1Y2. While doing that, we noticed that the top two Sorensens in 1Y1 (these are directly below the Guralp box) were at different voltages from nominal. The 5V had dropped to 4.2V and the 24V was at 24.6V. We adjusted the knobs until these were set correctly. After this, the MC WFS appear to work again.
When working in a rack, you must be as careful about accidentally touching things as when working on an optical table.
If Rob/Yoichi say the alignment is now good, the we absolutely must center the IOO QPDs and IP POS and IP ANG and MC TRANS today so that we have good references.
IOO_QPD_POS, IOO_QPD_ANG, MC_TRANS, IP_POS, IP_ANG have all been centered.
Also, the MCWFS have been centered.
I'm now working on making sure beam is hitting all of the RF PDs around.
I measured the mode cleaner open loop gain with the HP3563A.
The UGF is 64kHz, phase margin is 28 deg.
we set the offsets for the MCWFS DC and for the MCWFS demod outputs and then turned off the lights put the MZ at half fringe and then centered the spots on the MCWFS heads.
The MCREFL beam looks symmetric again and the MC REFL power is low.
I drove MC2 in POS and used the resulting response in MC_F to calibrate the IOO-MC_L channel.
Yoichi did an excellent job of calibrating MC_F last year. I have used his calibration of MC_F (220 Hz/count @ DC) to get the MC_L calibration at DC as well as at high frequencies. The hardware dewhitening was OFF for all these measurements.
1. For the DC measurement I excited C1:SUS-MC2_MCL_EXC at 0.0731 Hz. At these frequencies, the MC_L path has much more gain than the MC_F path. So this excitation at the error point makes the length path to drive itself to cancel the digital excitation. Since the overall MC servo gain is huge, this causes the MC_F path to compensate the residual MC_L motion. One can simply take the ratio of MC_L/MC_F to get the calibration of MC_L in Hz.
2. For the AC measurement, I engaged FM9 of the MC2_MCL filter bank. This guy is an elliptic LP with a notch at 660.38 Hz. I then drove MC2_LSC at 660.38 Hz with a sine wave of 500 counts amplitude. The notch makes the gain of the MC_L feedback zero at that frequency. So MC_F has to do all the work. We can simply measure the ratio of MC2_LSC/MC_F to get the AC calibration of MC2_MCL_OUT (aka IOO-MC_L) and MC2_LSC_OUT (aka LSC-MC_L).
MCF/MCL @ 0.0731 Hz = 569.4. So the MC_L calibration at DC is 220 x 569.4 = 125 kHz/count or 6.02 nm/count.
From this we would expect the AC calibration to be (6 nm/count)*(660.38/f_pend)^2 = 13.0 x10^-15 m/count.
The AC measurement gave 1445 counts_peak** of MC_F for the 500 counts (peak) excitation in MC2_LSC. From Yoichi's entry we get that the high frequency calibration of MC_F should be 0.089 Hz/count. So the MC_L calibration at 660 Hz is 0.089*1445/500 = 0.25 Hz / count or 12.3 x 10^-15 m/count. So the AC/DC ratio is close to 1.
Splitting the difference, the new official MC_L calibration is 5.87 nm/counts @ DC with a complex pole pair at 0.972 Hz.
** note: To convert from the peak height observed in DTT with a 50% Overlap Hanning window you must use the following intuitive formula: counts_peak = (counts / rHz) * sqrt(2 * BW). In this case, BW is the number that DTT reports as BW on the screen, NOT the BW that you asked for on the measurement tab.
*** note: when measuring peak heights in a DTT FFT, make sure to unclick the box for 'Bin' under the config tab. Bin suppresses peaks in a plot with a lot of points and is ON by default.
**** note: I have updated the MCF reference in the Templates directory with the Yoichi calibration - spectrum attached. This is probably the most accurate MCF spectrum we have ever put in the elog in the history of the 40m. The implication is that the VCO phase noise is ~5 mHz/rHz. Not bad.
***** note: with the OAF off, I drove a 1.55 Hz sine wave into MC1 and measured the ratio of MC1_MCL_OUT/IOO-MC_L. This gives the DC calibration of MC1_MCL_OUT = 7.98 nm/count.
I used the XARM as a reference to measure the frequency noise after the MC. It's huge around 4kHz--hundreds of times larger than the frequency noise the MC servo is actually squashing. This presents a real problem for our noise performance.
An elog search reveals that this noise has been present (although not calibrated till now) for years. We're not sure what's causing it, but suspicion falls on the piezojena input PZTs.
I didn't bother too much about it before because we previously had enough common mode servo oomph to squash it below other DARM noises, and I didn't worry too much about stuff at 4kHz.. Now that we have a weaker FSS and thus much weaker CM servo, we can't squash it, and the most interesting feature of our IFO is at 4kHz.
I'll measure the actual voltage noise going to the PZTs. I remember doing this before and concluding it was ok, but can't find an elog entry. So this time maybe I'll do it right.
Last night while noise hunting, Rana found that the MC2 trans beam has been left for an unknown length of time just hitting the side of the black enclosure box. Today I put a brand-spankin'-new razor dump on the MC2 table, to dump the beam.
Pointing stability of 4 days. Initial pointing does not go through suspended optics. It is launched right after the Piezo Jena steering mirrors in the BS chamber.
IP-ANG on epics screen is C1:ASC-IBQPD_X and Y in dataviewer were recentered. This beam is clipping a bit in ETMX chamber pick off mirror.
IP-POS pick off is in the BS chamber and it's qpd on the BS_ISCT This beam is also clipping just a little bit. This is easy to fix. We'll have to remove an iris from the BS optical levers table.
note: arms were not locked when I recentered
the mode cleaner was having trouble locking in a 00 mode, needing several tries. I changed the MC2 coil biases, and it seems better for now.
Initial pointing beam is clearly clipping on 2" pick off mirror in ETMX vacuum chamber.
Atm. 1 The pick off mirror is just north west of the ETMX test mass
Atm. 2 The camera is looking in from the north view port of ETMX chamber. The back side of pick off mirror is visible now with the face view of the "IP-ANG-OUT" mirror.
IP-ANG clipping can be traced back to our last vent of Aug. 18, 2008 See elog entry #845
This was an after earth quake - sus repair vent
I measured the mode cleaner open loop gain. It's around 60kHz with 29 degs of phase margin.
The beam to PMC aligned. The beam to MC WFS cameras aligned.
PMC Trans increased from 2.73 to 2.75 (+1%).
MC Trans increased from 7.80 to 7.87 (+1%).
This level of frequency noise has not changed, but we now have increased common mode servo gain and so it's not as huge of a deal, although we should still probably do something about it.
Attached is a plot of the piezojena noise measurement, estimated into Hz, along with another measurement of frequency noise as described above.
To get the piezojena voltage noise into Hz, I estimated the PZTs within have a flat 2 micron/V response (based on a rough knowledge of their geometry and assuming a 10 milliradian / 150V steering range). This is the voltage noise with the PZTs operating in closed loop mode, which is how we normally run them. This plot also ignores the transfer function of the Pomona box, as we are mainly looking at noise in the kHz band. I think this plot shows that these PZTs are a good candidate for creating this frequency noise, especially near their mechanical resonances (the manual says the unloaded resonances are in the 3-4kHz range).
I've been operating one DOF of the piezojenas in open loop mode for a couple of weeks now, and the feared drift has not been a problem at all. If we plan to keep using these after the upgrade, we should definitely put some big resistors in series at the outputs and operate them in open loop mode.
Also attached is a plot of RF DARM noise, with a frequency noise spectrum. That spectrum is a REFL 2I spectrum put into DARM units using a measured TF (driving MC_L and measuring REFL 2I and DARM_ERR), and then put into meters using the same DARM calibration as used for the DARM curve.
This afternoon, while I was trying to add the StochMon channels to the frames, I rebooted the c1ioovme and c1iool0.
I had to do it twice because of a mispelling in the C1IOO.INI file that the first time prevented the computer to restart properly.
Eventually I restored the old .ini file, as it was before the changes.
After rebooting I also burtrestored.
During the process the mode cleaner got unlocked. Later on the autoclokcer couldn't engage. I had to run the MC_down and MC_up scripts.