I went to the Y-end and took more photos of the cable stand. These revealed that in-vac pin #13 is connected to the shield of the cable (P.2). This in-vac pin #13 corresponds to in-air pin #1. So in the end, we bunch the pins in the following order.
We need to check spot centering on PRM with camera tomorrow.
Suresh checked that we're not clipped by IP ANG/POS pickoff mirrors, but we haven't done any alignment of IP ANG/POS.
I think we should NOT do any adjustment of IP ANG/POS now. We should in fact try to recover them when doing the PRM spot centering
Tomorrow: Open ITMX door. Check with Watek that we're hitting center of PRM. Then look to see if we're hitting center of PR2. Then, continue through the chain of optics.
The motivation for removing the ITMX door was so that the scatter measurement team could check alignment of the new viewing mirror next to ETMX. After discussion today we decided that everything can be done at the X end. They can inject a probe beam into the ETMX chamber, bounce it off of ITMX and align the viewing mirror with the reflection. So we'll leave ITMX door on for now.
We should, however, inspect the situation ITMY and make sure we have good clearance in the Y arm part of the Michaelson. Koji previously expressed suspicion that we might have clipping on the southern edge of the POY steering mirror, so we need to check that out.
Koji and I discussed the situation for getting camera face views of BS and PRM. Koji said the original idea was to see if we could install something at the south-east view port of ITMX chamber. Steve also suggested utilizing the "ceiling" camera mounted on the top of the IOO chamber.
End X tasks:
1,PRM spot can be viewed directly from the window south-east of ITMX chamber. I can easy set up the mobile- Watek for this reason or you can just use an IR viewer.
Remember, we have 2 SOS centering targets ready to use , that Rana was suggesting.
2, PR2 spot centering can be viewed directly through window north-west of ITMX.
3, We should put back the BS view pick-up mirror for the vertical camera on the BS chamber and adjust its upper pick-up.
4, The BS centering can be viewed with the mobile-Watek placed inside the BS chamber immediately.
The question arose whether we can get good enough data to diagonize our OSEM sensing matrices in air.
I just took a look at the BS spectra over the last six hours (~10PM-4AM), and the SNR looks good. The BS diagonalization itself doesn't seem so great; the POS is hugely coupled into pitch and yaw, and the angular motions are themselves coupled to each other at around 10%.
NB: use a flat-top window when you really care about peak heights that don't fall exactly on an FFT bin.
I would've liked to check this for the PRM and SRM too, but one of the PRM sensors continues to be dark, and I just noticed that all of the SRM OSEM signals are dark. ughhhh
We were wondering yesterday if we can somehow test the ASS system in air. Though the arm cavity can be locked with the low power IMC transmission, I think the dither would render the POY lock unstable. But I wonder if we can use the green beam for a test. The steering PZTs installed by Yuki can serve the role of TT1/TT2 and we can dither the arm cavity mirrors while the green TEM00 mode is locked to the arm no problem. This would at least give us confidence that the actuation of ETMY/ITMY are okay (in addition to the other suspension tests). Then on the sensing side, after pumping down, the only thing we'd be foiled by is in-vacuum clipping or some major gunk on ETMY - everything else should be de-buggable even after pumping down?
I think most of the CDS infrastructure for this is already in place.
After much fussing, we got a picture of MMT1 with the beam.
Using the iris doesn't seem feasible. Since it has to be significantly separated from the optic, it is hard to judge whether it is centered, especially in yaw.
It took ~30 min to get this picture. Comments on whether this kind of picture is good enough are welcomed, since there are many more to be taken.
I've been taking more photos. Obviously, it gets quicker as I go along and get the hang of it. Also, I've been taking overhead pictures with the Nikon so we can see what kind of parallax there is for each snapshot.
However, I just took MMT2, and the beam is nearly falling off the side of the optic! It seemed fine last night when Rana and I were working on it. The MC spots haven't moved significantly (I had measured yesterday, and again a few hours ago). WTF?
This means that I need to move the knobs of MMT1, and then redo the whole alignment chain all over again. Lame.
EDIT: MC spot positions, last night at 12:33am, and this afternoon at 2:12pm:
year month day hour minute MC1pit MC2pit MC3pit MC1yaw MC2yaw MC3yaw
./data_spotMeasurements/MCdecenter201209140033.dat 1.749759 9.744013 1.025681 -0.791683 -1.338786 -1.779958
./data_spotMeasurements/MCdecenter201209141412.dat 1.702974 7.916438 0.986519 -0.888736 -0.170237 -1.771267
All the photos so far:
Tonight we noticed that there were significant improvements to be had in the predicted DARM Wiener filtering FF performance by using weighting filters and more taps in the FIR filter.
The plots below tell the story:
The first one shows the improvement in the residual (black & blue) by applying a weighting filter. The weight filter tilts the spectrum up at HF and applies and all real pole BP from 10-20 Hz.
The second plot shows the improvement gotten by using 3000 instead of 2000 taps for the Wiener filter. With the larger number of taps we not only get the big improvement at LF, but also some beefy reduction in the higher frequency stack modes and the LOS roll mode.
I'm not sure why we haven't run across this before; the weighting filter was arrived at today by just iterating by hand on the placement of poles and zeros until the trace looked nice.
Jenne is going to run this new filter on the S5-month that we have been using for stationarity testing.
* Some notes:
** this Wiener stuff is faster, by far, on rossa than either megatron or rosalba or my laptop. More than a factor of 3.
*** there is a bug with Macports/Matlab - if you get fftw3 with Macports, it sets itself as the right version to use. This confuses matlab in some cases.
if you get the error about libfftw3.dylib, whe trying fft in matlab after installing macports, then you can fix it by setting the Matlab lib/ path with the fftw libraries to be ahead of /opt/local/lib in the LD_LIBRARY_PATH in your .cshrc.
Rossa is a rather beefy machine. It effectively has 8 Intel i7 Cores (2.67 Ghz each) and 12 Gigs of ram. Megatron only has 8 Gigs of ram and just 8 Opterons (1 GHz each). Rosalba has 4 Quad Core2 (2.4 GHz) with only 4 Gigs of ram.
At Rob's request I've added the following features to the camera code.
The camera server, which can be started on Ottavia by just typing pserv1 (for camera 1) or pserv2 (for camera 2), now has the ability to save individual jpeg snap shots, as well as taking a jpeg image every X seconds, as defined by the user.
The first text box is for the file name (i.e. ./default.jpg will save the file to the local directory and call it default.jpg). If the camera is running (i.e. you've pressed start), prsessing "Take Snapshot to" will take an image immediately and save it. If the camera is not running, it will take an image as soon as you do start it.
If you press "Start image capture every X seconds", it will do exactly that. The file name is the same as for the first button, but it appends a time stamp to the end of the file.
There is also a viedo recording client now. This is access by typing "pcam1-mov" or "pcam2-mov". The text box is for setting the file name. It is currently using the open source Theora encoder and Ogg format (.ogm). Totem is capable of reading this format (and I also believe vlc). This can be run on any of the Linux machines.
The viewing client is still accessed by "pcam1" or "pcam2".
I'll try rolling out these updates to the sites on Monday.
The configuration files for camera 1 and camera 2 can be found by typing in camera (which is aliased to cd /cvs/cds/caltech/apps/linux64/python/pcamera) and are called pcam1.ini, pcam2.ini, etc.
I've reinstalled the beatbox in the 1X2 rack. This improved version has the X and Y arm channels stuffed, but just one of the DFD channels (fine) each.
I hooked up the beat PD signals for X and Y to the RF inputs, and used the following two delay lines:
The following channel --> c1ioo ADC --> c1gcv model connections were made:
The connections to the course inputs on the ALS block were grounded. I then recompiled, reinstalled, and restarted c1gcv. Functioning fine so far.
In my previous elog:11492, I stated that in order to improve the subtraction and reduce the injection of high frequency noise we want the filter's magnitude to have a 1/f rolloff.
I implemented this scheme on the filter SISO filter previously analyzed. The results are shown below.
The filters bode plot:
The nice 1/f rollof is the main change here. Everything else remained pretty much the same.
The predicted FIR and IIR subtractions:
Everything looks right but that hump at 8 Hz. I used 8 pairs of poles/zeros to get this subtraction.
The online MCL subtraction:
This looks better than I expected. One has to keep in mind that I ran this at 1 AM. I wonder how well this filter will do during the noisier hours of the day. The RMS at high frequencies doesn't look great, there will definitely be noise being injected into the YARM signal at high frequencies.
Measuring the YARM signal:
There is still noise being injected on YARM but it is definitely much better than the previous filter. I'm thinking about doing some IIR subtraction on the arms now to see if I can get rid of the noise that is being injected that way, but before I embark on that quest I will rething my prefiltering.
The plot below shows the ratio of the unfiltered versus filtered ASDs for the FIR and IIR subtraction predictions as well as for the measured online IIR subtraction. Positive dB means better subtraction.
This is an update on the results already presented earlier (refer to elog 13274 for more introductory details). I improved significantly the results with the following tricks:
An example of time domain reconstruction is visible below. It already looks better than the old results:
As before, to better evaluate the performance I plotted averaged values of the real signals as a function of the reconstructed MICH and PRCL positions. The results are compared with simulation below. They match quite well (left real data, right simualtion expectation)
One thing to better understand is that MICH seems to be somewhat compressed: most of the output values are between -100 and +100 nm, instead of the expected -lambda/4, lambda/4. The reason is still unclear to me. It might be a bug that I haven't been able to track down yet.
Attached are gain-variation measurements of the final, in situ AUX-to-PSL phase-locked loop (PLL).
Attachment 1: Figure of open-loop transfer function
Attachment 2: Raw network analyzer data
The figure shows the open-loop transfer function measured at several gain settings of the LB1005 PI servo controller. The shaded regions denote the 1-sigma sample variance inferred from 10 sweeps per gain setting. This analysis supercedes previous posts as it reflects the final loop architecture, which was slightly modified (now has a 90 dB low-frequency gain limit) as a workaround to make the LB1005 remotely operable. The measurements are also extended from 100 kHz to 1 MHz to resolve the PZT resonances of the AUX laser.
Duncan Macleod (original author of summary pages) has an updated version that I would like to import and work on. The code and installation instructions are found below.
I am not sure where we want to host this. I could put it in a new folder in /users/public_html/ on megatron, for example. Duncan appears to have just included the summary page code in the pylal repository. Should I reimport the whole repository? I'm not sure if this will mess up other things on megatron that use pylal. I am working on talking to Rana and Jamie to see what is best.
I am following the instructions here:
But there as an error when I run the ./00boot command near the beginning. I have asked Duncan Macleod about this and am waiting to hear back.
For now, I am putting things into /home/controls on allegra. My understanding is that this is not shared, so I don't have a chance of messing up anyone else's work. I have been moving slow and being extra cautious about what I do because I don't want to accidentally nuke anything.
I installed the new version of LAL on allegra. I don't think it has interfered with the existing version, but if anyone has problems, let me know. The old version on allegra was 6.9.1, but the new code uses 22.214.171.124. To use it, add . /opt/lscsoft/lal/etc/lal-user-ench.sh to the end of the .bashrc file (this is the simplest way, since it will automatically pull the new version).
I am having a little trouble getting some other unmet dependencies for the summary pages such as the new lalframe, etc. But I am working on it.
Once I get it working on allegra and know that I can get it without messing up current versions of lal, I will do this again on megatron so I can test and edit the new version of the summary pages.
LALFrame was successfully installed. Allegra had unmet dependencies with some of the library tools. I tried to install LALMetaIO, but there were unmet dependencies with other LSC software. After updating the LSC software, the problem has persisted. I will try some more, and ask Duncan if I'm not successful.
Installing these packages is rather time consuming, it would be nice if there was a way to do it all at once.
I am now working on megatron, installing in /home/controls/lal. I am having some unmet dependency issues that I have asked Duncan about.
I have figured out all the issues, and successfully installed the new versions of the LAL software. I am now going to get the summary pages set up using the new code.
There was an issue with running the new summary pages, because laldetchar was not included (the website I used for instructions doesn't mention that it is needed for the summary pages). I figured out how to include it with help from Duncan. There appear to be other needed dependencies, though. I have emailed Duncan to ask how these are imported into the code base. I am making a list of all the packages / dependencies that I needed that weren't included on the website, so this will be easier if/when it has to be done again.
Most dependencies are met. The next issue is that matplotlib.basemap is not installed, because it is not available for our version of python. We need to update python on megatron to fix this.
The nominal gain of the XARM for the POX11 error signal is 0.03 (instead of previous 0.3)
This is due to my increase of the gain in FM4 by 20dB so that we can turn of FM4 without changing the UGF when it is at 150Hz.
The YARM servo was not yet touched.
I borrowed the HP impedance test kit from Rich Abbott today. The purpose is to profile the impedance of the NPRO PZTs, as part of the AUX PDH servo investigations. It is presently at the X-end. I will do the test in the coming days.
On Friday, Koji helped me find various components required for the scatterometer setup. Like he suggested, I'll first set it up on the SP table and try it out with an usual mirror. Later on, once I know it's working, I'll move the setup to the flow bench near the south arm and measure the BRDF of a spare end test mass.
I acquired 2 raw frames of MC2 using "/users/mjenson/sensoray/sdk_2253_1.2.2_linux/capture -n -s 720x480 -f 1", one while the laser was off the mode cleaner and another while it was on:
I then used "/users/mjenson/sensoray/sdk_2253_1.2.2_linux/imsub/display-image.py" to generate bitmaps of the raw images, which I then subtracted using the Python Imaging Library to generate a new image:
It doesn't look all that different, but the first image didn't have that much lit up in it to begin with. I should be able to write a script that does all of this without needing to generate new files in between acquisition and subtraction.
It doesn't look all that different, but the first image didn't have that much lit up in it to begin with.
This is totally cool! You can see that the OSEM lights are almost entirely gone in the subtracted image.
Can you switch to trying with one of the *TM*F cameras? (ITMXF, ITMYF, ETMYF, ETMXF) They tend to have more background, so there should be a more dramatic subtraction. Den or Suresh should be able to lock one of the arms for you.
- Use LEDs of a wavelength that the OSEMs don't see. LEDs are also cool so that the
Suspension won't drift in alignment.
- Use 2 power supplies so that the power is balanced.
- Make is +/-12 V twisted AWG 14 wire so that the EMI is contained. Should also
be shielded cable.
1/4" exposure, standard room lights 3" exposure, slowly moving LED bar light from ~60 cm distance
Because of the light behind, the focus was attracted by the far objects...
Evenso the magnet ball looks better in the right picture.
The technique is as follows:
Use longer exposure time, move the LED bar illumination through the area like painting the light everywhere.
It is supposed to provide a picture with more uniform light and the diminished shadow.
JA - MIE - RO!
Koji asked me to look at what the ideal RF modulation frequency is, for just the PRMI case (no arms). If we had a perfect interferometer, with the sidebands exactly antiresonant in the arms when the arms resonate with the carrier, this wouldn't be an issue. However, due to vacuum envelope constraints, we do not have perfect antiresonance of the sidebands in the arm cavities. Rather, the sideband frequencies (and arm lengths) were chosen such that they pick up a minimum amount of extra phase on reflection from the arms. But, when the arms are off resonance (ex, the ETMs are misaligned), the sideband frequencies see a different amount of phase.
We want to know what a rough guess (since we don't have a precise number for the length of the PRC since our last vent) is for the ideal RF modulation frequency in just the PRMI.
If I take (from Manasa's kind measurements from the CAD drawing yesterday) the relevant distances to be:
L_P[meters] = 1.9045 + 2.1155 + 0.4067
L_X[meters] = 2.3070 + 0.0254*n
L_Y[meters] = 2.2372 + 0.0359*n + 0.0254*n
L_PRCL = L_P + (L_X + L_Y)/2 = 6.7616 meters.
The *n factors (n=1.44963) are due to travel through glass of the BS, and the substrate of the ITMs.
I find the FSR of the PRC to be 22.1686 MHz. For the sidebands to be antiresonant, we want them to be 11.0843 MHz. This would correspond to a mode cleaner length of 27.0466 meters. Our current modulation frequency of 11.066134 MHz corresponds to a MC length of 27.091 meters. So, if we want to use this 'ideal' modulation frequency for the PRC, we need to shorten the mode cleaner by 4.4cm! That's kind of a lot.
To change the MC length is not the point.
If we can improve the length sensing by the intentional shift of the modulation frequency from the MC FSR, that's worth to try, I thought.
But that is tough as the freq difference is 18kHz that is ~x4 of the line width of the MC.
Not only the 55MHz sidebands, but also the 11MHz sidebands will just be rejected.
Nevertheless: Is there any possibility that we can improve anything by shifting the modulation frequency by ~1kHz?
We have calibrated the overall actuators of each suspension independent of the optical levers. So, we know how much we are
moving the optic in POS in real units as a result of the dither we inject for the lockin measurement. The amount the oplev beam
appears to move if there is only POS motion is
where theta is the oplev's angle of incidence and d is the distance the optic has moved in POS. None of the of the steering mirrors in the
oplev path matter.
I propose that I will add an option in the lockin path to subtract away the apparent angle from the oplev output just before the signal
goes into the lockin module. Then we will be balancing the actuators based on only the actual angular motion.
The success of this technique depends on how well we know our actuator calibration and the oplev angle of incidence. This also
assumes that the oplev beam is centered on the optic, so we don't have beam displacement from A2L of the oplev beam, which then
makes another apparent angular motion. I suspect that we are close enough that we won't have to worry about this effect.
At ~930am, I vented the IY annulus by opening VAEV. I checked the particle count, seemed within the guidelines to allow door opening so I went ahead and loosened the bolts on the ITMY chamber.
Chub and I took the heavy door off with the vertex crane at ~1015am, and put the light door on.
Diagnosis plan is mainly inspection for now: take pictures of all OSEM/magnet positionings. Once we analyze those, we can decide which OSEMs we want to adjust in the holders (if any). I shut down the ITMY and SRM watchdogs in anticipation of in-chamber work.
Not related to this work: Since the annuli aren't being pumped on, the pressure has been slowly rising over the week. The unopened annuli are still at <1 torr, and the PAN region is at ~2 mtorr.
With rana's input, I changed the ITMx oplev servo gains given the beam path had been changed. The pitch gain was changed from 36 to 30, while the yaw gain was changed from -25 to -40. Transfer function plots attached. The UGF is ~8Hz for pitch and ~7Hz for yaw.
I had to change the envelope amplitudes in the templates for both pitch and yaw to improve the coherence. Above 3Hz, I multiplied the template presets by 10, and below 3Hz, I multiplied these by 25.
As mentioned in elog 8770, I wanted to give the POX beam a little more clearance from the pick-off mirror steering the outcoming oplev beam. I tweaked the position of this mirror a little this morning, re-centred the spot, and checked the loop transfer function once again. These were really close to those I measured last night (UGF for pitch ~8Hz, for yaw ~7Hz), reported in elog 8777, so I did not have to change the loop gains for either pitch or yaw. Plots attached.
Jenne just aligned the X arm and I got a chance to check the status of the POX beam coming out of the chamber. Turned the Oplev servo off so that the red beam could be blocked, turned all the lights off, and had a look at the beam in the vicinity of the mirror steering the Oplev-out beam to the QPD with an IR view-card. The beam is right now about half a centimeter from the pitch knob of the said mirror, so its not getting clipped at the moment. But perhaps the offending mirror can be repositioned slightly, along with the Oplev QPD such that more clearance is given to the POX beam. I will work this out with Steve tomorrow morning.
The ITMx Oplev was misaligned. Switched the ITMx Oplev back on and fixed the alignment.
EDIT, JCD: This is totally my fault, sorry. I turned it off the other day when I was working on the POP layout, and forgot to turn the laser back on. Also, I moved the fork on the lens directly in front of the laser (in order to accommodate one of the G&H mirrors), and I nudged that lens a bit, in both X and Y directions (although very minimally along the beam path). Anyhow, bad Jenne for forgetting to elog this part of my work.
It turned out that the earlier fix was not really a fix, because there was some confusion as to which of the two lenses Jenne moved while working, and while Manasa and I were re-aligning the beam, we may have moved the other lens.
Subsequently, when we checked the quadrant sum, it was low (in the region of 20), even though OPLEV_PERROR and OPLEV_YERROR were reasonably low. We called up a 30 day trend of the quadrant sum and found that it was typically closer to 4000. This warranted a visit to the table once again. Before going to the table, we did a preliminary check from the control room so as to make sure that the beam on the QPD was indeed the right one by exciting ITMx in pitch (we tried offsets of 500 and -500 counts, and the spot responded as it should). ITMx oplev servo was then switched off.
At the table, we traced the beam path from the laser and found, first, that the iris (I have marked it in one of the photos attached) was practically shut. Having rectified this, we found that the beam was getting clipped on the first steering mirror after the laser (also marked in the same photo, and a second photo showing the clipping is attached). The beam isn't very well centred on the first lens after the laser, which was the one disturbed in the first place. Nevertheless, the path of the entering beam seems alright. The proposed fix, then, is as follows;
Back in the control room we noticed that the quadrant sum had gone up to ~3500 after opening out the iris. The OPLEV_PERROR and OPLEV_YERROR counts however were rather high (~200 counts in pitch and ~100 counts in yaw). Jenne went back to the table and fixed the alignment such that these counts were sub-10, and the quadrant sum went up to ~3800, close to the trend value.
At the time of writing, the beam is still not centred on the lens immediately after the laser and is still getting clipped at the first steering mirror. Oplev servo back on.
Steve and I tried to fix the Oplev situation detailed in elog 8684, today afternoon. We have come up with a fix which needs to be adjusted, possibly completely overhauled depending on whether the mirror steering the return beam to the QPD is blocking the POX beam coming out.
Situation in the chamber: the black line is meant to indicate what was happening, the red is indicative of the present path.
Plan of action:
Sitting down to start cavity measurements, I found both ITMs tripped. It must have happened a while ago (I didn't bother to check dataviewer trends) because both had rms levels of <5 counts, so they've had a while to sit and quiet down.
Steve and Koji (Friday, Apr 02)
Intsallation of ITMs are going on. Two new ITMs were placed on the optical table in the vacuum chambers. ITM for the south arm was put at the right place in accordance to the CAD drawing. ITM for the east arm is still at a temporaly place.
Tower placement (10:30-11:30)
- Put the tower on the table at a temporary place such that we can easily work on the OSEMs.
ITM (South arm) (14:00-16:30)
- Put the tower on the table at a temporary place such that we can easily work on the OSEMs.
- Leveled the table approximately.
- Released the EQ stops
- Removed anchors for the OSEM cables as it was too short. The wire distribution will be changed later.
- Put the OSEMs. Adjust the insertion to the middle of the OSEM ranges.
- Clamped the EQ stops again
- Placed the tower to the right place according to the CAD drawing.
- Released the EQ stops again.
- Check the OSEM values. The LL sensor showed small value (~0.5). Needs to be adjusted.
ITM (South) damping adjustment
- Found the signs for the facing magnets are reversed.
- Otherwise it damps very well.
We may lost the UL magnet or LED
I think if the magnet fell off, we would see high DC signal, and not 0 as we do now. I suspect satellite box or PD readout board/cabling. I am looking into this, tester box is connected to ITMY sat. box for now. I will restore the suspension later in the evening.
Suspension has now been restored. With combination of multimeter, octopus cable and tester box, the problem is consistent with being in the readout board in 1X5/1X6 or the cable routing the signals there from the sat. box.
This bad connection is coming back
So if the SRM satellite box is good, than the ITMY sensor UL or vacuum cabeling from sersor to sat amp is bad.
Koji tweaked the alignment sliders till we were able to get the Y arm locked to green in a 00 mode, GTRY ~ 0.5 which is the prevent number I have in my head. The green input pointing looks slightly off in yaw, as the spot on the ITM looks a little misaligned - I will fix this tomorrow. But it is encouraging that we can lock to the green, suggests we are not crazily off in alignment.
[Ed by KA: slider values: ETMY (P, Y) = (-3.5459, 0.7050), ITMY (P, Y) = (0.3013, -0.2127)]
While we were locked to the green, ITMY UL coil acted up quite a bit - with a large number of clearly visible excursions. Since the damping was on, this translated to somewhat violent jerking of ITMY (though the green impressively remained locked). We need to fix this. In the interest of diagnosis, I have switched in the SRM satellite box for the ITM one, for overnight observation. It would be good to narrow this down to the electronics. Since SRM is EQ-stopped, I did not plug in any satellite box for SRM. The problem is a difficult one to diagnose, as we can't be sure if the problem is with the LED current driver stage or the PD amplifier stage (or for that matter, the LED/PD themselves), and because the glitches are so intermittent. I will see if any further information can be gleaned in this regard before embarking on some extreme measure like switching out all the 1125 OpAmps or something...
Does anyone know if we have a spare satellite box handy?
Is the spare sat amp is bad ?