For PRMI + 2arm, we tried to make the ALS control noise better. As this entry we had huge 60 Hz comb noise in PDH loop of YARM.
So we tried to figure out the problem and fix it.
- What we did
We checked which power supply the staff in Y-end are connected to, and change some of them to connect to 1Y4 AC power supply from wall AC. What we changed was
1.Main end laser
3.Green REFL PD
We checked error signal of PDH control and compared before and after. The 60 Hz peak get better from -80 dBVpk to -90 dBVpk. Also I attached the plot of XARM, privious YARM (the data of Yesterday night), and current YARM ALS in-loop noises. The RMS of ALS in-loop noise of Y-arm get better by factor of 2. However, even the 60 Hz comb noise get better than before, RMS get worse by comb noise.
We would like to make these noise better at least until these noises don't affect to RMS, so we should continue to check.
Koji reminded me that we should also save the data from the PRMI+Xarm, just in case we want to look at it later.
Here is the time series, in which you can see us finding the Xarm IR resonance, moving the arm off resonance, locking PRMI, and bringing the arm back into resonance. At the very end, the arm is still held on resonance, but I had disabled the LSC locking, so we see very large flashes at TRX (of order 40, rather than 1).
The data is in the same folder as the 2arm data: /users/jenne/PRCL/PRMI_Xarm_ALS_16Oct2013/
The text files have been differentiated, so that the 2arm data has "_2arms" at the end of the filename, while the Xarm data had "_Xarm" appended to the filename. Since we left the cavities locked for many minutes (during which transfer functions were taken), the data set for the PRMI+Xarm is very long.
ETMX _OPLEV_...ERROR signals are effected by turning ON the flow bench motor at the south end
The broadband noise [~ 5-60 Hz] is much higher when the motor is running.
The flow bench was turned off.
Still to do:
* Put a little more stuff into the front end so that we get total mag and phase of the sensing matrix element, not just uncalibrated lockin outputs.
I worked today some more on the new Sensing Matrix situation. I have added stuff to the CAL model, so that the sensing matrix elements come out calibrated to W/m, with phase in degrees. The idea is that we can see time series of the calibrated lockin outputs, so that we have minimal post-processing to do, since these are things that will be interesting to look at live.
The first step is to go from I and Q to magnitude and phase. Each "sensor" (ex. REFL55Q) is demodulated with a lockin part, which outputs sub I and Q channels (so, something like REFL55Q_I and REFL55Q_Q). We are only interested in the _I component of the lockin. But, REFL55I also has a _I and _Q. Again, we only take the _I part. Now, we have REFL55I_I and REFL55Q_I. We call these the I and Q components of the sensors (this is exactly what we normally call them, but it can get confusing since the lockins also have _I and _Q before we discard the _Q part). Now, we want to take these I and Q components, and transform them to a magnitude and phase. After we do that, we want to calibrate the magnitude to "Watts per meter" from "counts sensed per counts driven". I also converted the phase to degrees, since that's the unit we usually use when talking about the sensing matrices.
To go from the I and Q components to Mag and Phase, I wrote a little block of c-code, which is in /opt/rtcds/caltech/c1/userapps/release/isc/c1/src/MagPhaseFromIQ.c . Since we can't use the arctan function, I approximated it using equation 17 from Full Quadrant Approximations for the Arctangent Function [Tips and Tricks] from IEEE. (I used x -> y/x in equation 17, so that I had a 2D situation). I also have an "if / else if" cascade to determine what quadrant I'm in. Since the formula in the paper is from [0,pi/2), I just needed to add pi, subtract the answer from pi, or negate the answer to get to the other quadrants. Also, note that they are using a "normalized" arctan function, so equation 17 is really from [0,1), and you have to remember to multiply by pi/2 on your own.
To get from drive counts to drive meters, I put in an EPICS variable for the optic's actuation constant (ex, PRM's constant can be found in elog 8255). Right now, we have to transfer the oscillation frequency from the oscillator part's _FREQ variable to a new EPICS variable, but Zach and Joe just today made a new oscillator part that makes it easier to access the frequency and amplitude of the drive within the front end. See LLO aLog 9139 for details on this new part. I had trouble compiling with their new part, but once I get that figured out, I won't need to do this transfer of information. Anyhow, the drive calibration is (optic actuation constant)/[(drive frequency)^2].
Then the total calibration of the magnitude is Mag in cts/m = 2 * mag / [(drive amplitude) * (drive calibration)] . The factor of 2 comes from the fact that the lockin output is a factor of 2 smaller than the true sensing matrix element. The lower case "mag" in the formula is the output of the c-code.
After this, there is yet another EPICS variable, to hold the calibration for the photodiode, to get from counts sensed to Watts of power at the actual port. By "actual port", I mean the true IFO port, taking into account any optical elements between the port and the photodiode, like beam splitters and dumps, or loss from the imperfect reverse isolation of the input Faraday.
The code all compiles and runs fine, although I haven't done any explicit testing yet.
Still to-do for Sensing Matrix:
* Find all of the numbers for all of the EPICS variables. In particular, I need to get the ratio of the power hitting each photodiode to the power at that port.
* Write a script to do a burt-restore with all the correct settings, and turn on the dither lines.
* Put the lowpass filters back in the demodulators, now that they have new (shorter) names.
* Try it, and compare with the optickle model, and previous measurements.
* Copy Anamaria's script to look at the error statistics for my measurements.
its time to get the CM servo hardware turned back on. We're going to want to switch it on when we're about ~1/50th of the way up the CARM fringe.
A good way to re-commission it is to lock it to the single arm, using a Pomona box filter to move the arm pole down to the coupled cavity pole frequency.
PRCL Open Loop Transfer Function. PRMI locked on REFL 165 I&Q, Xarm held on IR resonance using ALS, ETMY misaligned:
MICH Open Loop Transfer Function. PRMI locked on REFL 165 I&Q, Xarm held on IR resonance using ALS, ETMY misaligned:
Time series data during our PRMI + 2 arm attempt:
I wrote the script to scan the cavity using ALS until it finds IR resonance . This script is (script)/ALS/ALSfindIRresonance.py I attached the time series of the C1:ALS-OFFSETTER and IR transmission of XARM when the script was working.
When you start this script, it start rough scan. It steps the offset of the C1:ALS-OFFSETER with ramp time, and for each step it checks the value of C1:LSC-TR. At rough scan, one step is 0.1 count. When IR transmission become larger than threshold, this script start fine scan. In fine scan, this script steps the offset by 0.01 for the range of 2. For each step, C1:LSC_TR value is measured, and after fine scan it set the offset to the value which had the maximal C1:LSC-TR.
I put new button 'Scan %ARM' to the ALS screen. You can run this script by pushing that button.
Atm1 bandwidth 0.01 Hz ETMY plot is different from
Atm2 bandwidth 0.1 Hz normal ??????? They should be the same !!!!
We found that we need to look into the entire end PDH loop to figure out what causes the worse noise level of the Y-arm than before.(entry)
Today, I measured in-loop noise of the end PDH loop and the ALS loop with different end PDH servo gain of Y-arm to make sure the PDH servo gain change the noise level of the ALS control loop.
- What I did
Measuring the OLTF of the end PDH loop:
1. Measured the OLTF of the PDH loop with the end PDH servo gain 6 and 7.
The UGF and phase margine: 16 kHz and 53 degree(gain 7)
7.8 kHz and 86 degree(gain 6)
I couldn't measure the OLTF with higher servo gain than 7 because the loop was not stable enough. I guess that is because of the noise of the SR560, which I used for node of the excitation signal.
Calibration of the end PDH error signal
2. Locked the cavity using IR and turn on the notch filter at 580 Hz of the C1:LSC-XARM. Excited the ETMY using awg with sinusoidal signal at 580 Hz. Set the end PDH servo gain to 6 and measured error signal of the end PDH. The calibration factor of the end PDH error signal H is calculated by
H = abs(G + 1) / A * Verr / Vin
where G is the OLTF of the end PDH, A is the actuator response of the ETMY, Vin is the amplitude of the excitation signal and Verr is the error signal at 580 Hz. This H convert the error signal to the fluctuation of the cavity length, so it has the unit of V/m. We can change that unit to V/Hz by multiplying f/L, where f is the laser frequency of IR and L is the length of the arm. In this case the H convert the error signal to the fluctuation of the resonant frequency of the cavity.
The actual number was
H = 1.4e7 [V/m] (2.0e-6 [V/Hz])
In-loop noise of the end PDH loop
3. Measured the error signal of the PDH loop with the end PDH servo gain of 6.0, 7.0, 8.0 and 9.0. I calibrated these signals with above H, so these unit is Hz/rHz. I attached the result of these in-loop noise. When the end PDH servo gain is 9.0, the end PDH loop looks unstable. And 8.0 looks to be the optimal gain in terms of the in-loop noise of end PDH loop.
ALS in-loop noise:
4. Stabilized the Y-arm with ALS control loop with different end PDH servo gain, and measured in-loop noise of the ALS control loop. I attached these results and discussed about this results below.
Now we can say that too high PDH servo gain makes ALS loop very noisy. Compare to when the PDH servo gain is 7 or 8, the ALS in-loop noise is roughly 4 times higher when the PDH servo gain is 9.0, which means the PDH loop is not stable. However between 100 Hz and the end PDH in-loop noise has no big difference between when the servo gain is 6 and 9. If this high frequency noise comes from the end PDH control and this effect is linear, these noises should be same level. Also the PDH servo gain of 7.0 looks optimal gain in terms of the in-loop noise of ALS control loop, although the 8.0 has smallest end PDH in-loop noise. Actually PDH in-loop noise are smaller than ALS in-loop noise.
I'm wondering what causes the 60 Hz peak in black curve. When the gain become higher, the peak at 60 Hz looks to become larger. The UGF of the ALS loop is above 100Hz, so it's not because of that. I feel there is some hint for understanding this result in this peak.
From this observation, I could make sure that the end PDH servo gain change the ALS in-loop noise, but that effect doesn't look so simple.
By the way
We should take care about 60 Hz comb peaks. You can see huge peaks in PDH in-loop noise and also in ALS in-loop noise.
After staring and thinking, I remembered that there is a limit to the number of characters that a channel name can have. So, I removed the "_LOCKIN" part of the names, and recompiled, and everything seems to work. I modified the screens that I had made, and they show all the appropriate things now.
The symptoms were that the numbers in the filter banks (for example, INMON) were white with the usual black background. The numbers are supposed to be green with a black background. After I recompiled, all the numbers were green.
This also means I need to re-put in the low pass filters.
I wonder what's drifting between the laser and the PMC? And why is it getting worse lately?
The PMC refl is bad in pitch today, and the transmission is only 0.76, rather than our usual 0.83ish.
I did a quick, rough tweak-up of the alignment, and now we're at 0.825 in transmission.
Hmmmm, yup. I forgot to pay attention to what the UGFs of our LSC loops are when I was picking a low-noise region. Since they're (currently, at least) around 100Hz, I want to find a frequency in the few hundred Hz region. Masayuki has the IFO right now for ALS diagnostics, so I'll pick new frequencies later. If we decide to omit the bandpass filters, it's even easier to change frequencies on the fly (although we'll always still have to make the servo notch filters match).
I think that we always drive above the UGF for sensing matrix measurements since we like to put notches in the servo. In principle, we could drive within the control band and then take out the effect by measuring the control signal and undoing the gain in the digital filters. But that seems pretty complicated for any MIMO system.
I centered the oplev of the ETMY, because I found that Yarm lost lock every 10 minutes, and the ETMY oplev was misaligned very much. I attached the 40 minutes trend of oplev and LSC-TRY. Yarm looks more stable. After centering of the oplev, the YARM looks to be more stable.
* Decide what 5 frequencies to use for excitation.
* Put the bandpass and lowpass filters into the lockin modules.
I worked on some of these "to-do" things today for the new sensing matrix setup. I chose several frequencies around 90 Hz for my measurements. This was an area (while PRMI was locked with REFL 165 I&Q, and all 4 REFL PDs had their whitening on) there was a pretty wide clean space in the noise spectrum.
I put bandpass filters into the _SIG banks of the lockin modules, and lowpass filters into the _I banks. However, when I loaded the new filter coefficients, it looks like not all of them are showing up in the screens. I'm a little confused as to why. They are still there if I close and re-open Foton, so I think I really put them in.
Also, I don't think that I'm successfully getting any signal from the LSC model into the new lockin modules on the CAL model. I'm not sure if this is to do with the fact that I added 32 more IPC connections the other day. I've emailed Jamie to ask whether or not we may have hit some limit.
I also tried testing out a small bit of c-code for the calibration of the lockin outputs. It seems as though I cannot do an arctangent in the front end. When I compile the c1tst model, and start it up, if I have an "atan2" in the code, it tells me "No Sync". However, if I remove that line of c-code, the model compiles fine (which it did in the case with the arctan), and the model runs just fine (which it doesn't with the arctan). My backup plan is to include a Taylor expansion for the arctangent in some c-code.
We have stabilized the ALS for Y arm and concluded that although the PDH servo could be stabilized, it drifts and loses stability over a span of few hours. (See masayuki's elog today)
We wanted to follow the same systematic procedure like in the previous elog to look at the condition of the X arm as well.
In order to stabilize the green PDH servo, we held the arm using the IR PDH and aligned the end-green to the X arm.
We see 2 TEM00-like modes and one oblong TEM00+TEM01 mode that can lock to the cavity. It is not clear to me as yet as to how to differentiate between these 2 TEM-00 like modes and how we should decide between them.
One of the TEM00-like mode is strongly matched to the arm cavity. Normalized GTRX measures 0.6 counts. The other TEM00-like mode is weakly matched to the cavity. Normalized GTRX measures 0.12 counts. This might be the reason why Jenne and Masayuki were seeing a lower beat amplitude. Camera images are shown below.
On another note, we found that an oblong mode (looks like a TEM00+TEM10 mode) also locks to the cavity. The mode looks weird in that, only one half of the mode is seen moving due to seismic noise and the other part does not. I am not sure how I can describe this...so here is a 10 second video of how this mode looks like.
Our goal is to realize PRMI+one arm again. However we found that the noise level of the Y-arm is worse than before (entry).
Today we went through into the servo gains of the ALS related loops.
Step 1 to 6 is for Yarm
Alignment of the cavity and the green:
1. Locked arms using IR PDH, aligned the green beam to increase the transmission. Now the value of ALS-TRY_OUTPUT is more than 0.8.
Checking and adjustment of the end green PDH gain:
2. Measured the OLTF of green PDH loop.
3. The gain of the PDH box was 8.2. We found that the UGF was too high and the phase mergin was too low (20deg)
Therefore, the gain was reduced to the gain to 6.8. Now, the UGF and phase margin are 17.7 kHz, 41.96 degree, respectively.
Phase tracker loop:
4. Measured the OLTF of the phase tracker loop. The UGF was 2 kHz, and phase margin was 45 degree.
We found that these were already the nominal and optimized numbers.
For a reference: the filter bank C1:ALS-BEATX_FINE_PHASE has the gain of 110.
5. Disable the IR PDH lock, and stabilized Yarm by ALS. We measured the OLTF of the ALS loop (attachment 1).
The UGF and phase margin were turned out to be 125 Hz and 41 degree. respectively. This looks pretty optimal.
The ALS servo gain (the gain of the C1:ALS-YARM module) was 15.0.
6. We measured the in-loop noise of the ALS loop (C1:BEATY_FINE_PHASE_OUT_HZ) (attachment 2).
The comparison of the in-loop performance is discussed below.
After these adjustment, we found that the ALS in-loop noise of Yarm decreased in high frequency band.
(see this entry for the comparison. Sorry for my laziness! I don't have the overlaid plot)
If we believe this is true, lowering the end PDH gain improved the noise level between 100Hz to 1kHz.
This sounds weird as we decreased the PDH gain, rather than increased. We should confirm this effect by increasing the gain.
Now the in-loop RMS is started to be dominated by the peaks at 3, 16, and 24 Hz.
We should compare the current in-loop spectrum with the previous spectrum when the ALS was working fine.
By the way:
We suffered from frequent disruptions of the ALS servo during our investigation.
As we speculated that this was caused by the malfunction of the green PDH loop, we left the arm still and observed
how the green PDH lock is robust. Our discovery was that the green PDH loop had frequent interruptions (every 5~10min).
From this observation, we strongly feel that we need to look into the entire end PDH loop.
For my work designing a cost function, so that I can try out new feedback servo designs on the oplevs, I wanted to know what the dark noise of an oplev is. Since the pitch and yaw channels are divided by the sum channel, when the laser is off, the noise in the pitch and yaw channels looks much higher than it really is. So, I collected some data from the 4 individual quadrants of the ITMY oplev, when the laser was on (but damping was off), and when the laser was off. I used the values of the oplev input matrix to re-create the non-normalized pitch and yaw signals. What I see is that we have some kind of real signal below 1 kHz, but we're hitting the noise at around 1 kHz. So, we definitely don't want to use oplev error signal information above 1 kHz when designing new servos.
The last word in the title is "off". OSEM damping was on, but the oplev damping was off. These are uncalibrated, because the calibrations that we have to go from counts to microradians are for the normalized signals.
Power spetrum of ETMX and ETMY in the view of oplev pitch and yaw.
Chris Couste, our new undergrad help received 40m specific, basic safety training yesterday.
After Jenne and Masayuki told that they were not able to stabilize the ALS for either arms yesterday, I looked into things with the ALS servo.
I had trouble initially trying to even stabilize the loop for a few minutes. So I measured the OLTF of the phase tracker loop and the ALS X arm servo. I changed phase tracker gain to 125 and that rendered UGF of 2KHz and phase margin of 45 degrees for the phase tracker loop.
The ALS servo gain was set such that UGF was 125Hz and phase margin 38 degrees (attached is the transfer function measurement for the servo).
I could stabilize the arm to ~500 Hz/rtHz (rms), which is twice that of what we had while we did the (PRMI+1arm ALS).
But ALS was still not stable long enough with the higher rms to even allow a cavity scan to find IR resonance. I suspect the problem to now lie with the PDH loop. We should be looking to stabilize the PDH for green if we need a stable ALS.
After finishing up working on the models for today, I made corresponding screens.
The new Sensing Matrix (and lockin) overview screen is accessible from the sitemap: LSC -> Sensing Matrix.
From there, you have the oscillators, input matrices (one per degree of freedom), output matrix, and the lockin modules themselves. You can either look at several PDs for one degree of freedom (ex. there is a screen for all the AS RFPDs, demodulated for the DARM oscillation), or all the degrees of freedom for a single PD (ex. how are all the degrees of freedom seen in AS55Q?). The LSC screen has been updated to match - now you see 5 oscillator readbacks, and a larger output matrix. There is a button for the Sensing Matrix overview screen, and if you click on the cartoons of the oscillators, it'll take you to the oscillators screen.
* Put matching notch filters into each LSC servo.
* Re-write the sensing matrix scripts.
I wrote the down script for ALS. This script is (script)/ALS/ALSdown.py When this script is running, it watches the feedback signal of the ALS control loop so as to shut down the servo immediately when the suspension is kicked.
When the value of C1:ALS-X(Y)ARM_OUT becomes larger than the threshold (right now it is 4500 counts), it changes the servo gain to 0, turns off all filters except for FM5 (the filter for phase compensation), resets the history of the phase tracker of each arm and prints the time on window when the suspension kicked
I put the switch on the C1ALS screen, and if you push this switch the window will open (like when you turn on the c1ass script) and the script start to run. For stopping this script, you have to close that window or press Ctrl + C on that window. This is little bit inconvenient, but we will make autolocker script for ALS and this downscript will be included that script soon. So I think it is enough to protect the suspensions right now.
I modified the ALS down script. When the value of C1:ALS-X(Y)ARM_OUT becomes larger than the threshold, it turn off the output ON/OFF switch immediately. That is because the ALS servo has ramp time. When script changes the gain to 0, it takes some seconds. That is not good for suspensions.
After changing servo gain to 0 and turning off the filters, the script waits ramp time and turn on the servo output switch.
The modifications to the LSC model are now complete, and the new model has been compiled, installed, and is running. The sensing matrix lockins are all in the c1cal model. Masayuki is locking right now, so so far, things appear to be back to normal.
The longer version of the story, with all the detours and hiccups:
After several tries of deleting the GoTo and From flags / tags in the lockin area of the LSC model, and continually getting the "something is not connected" errors, I gave up and just drew several long lines. So, in the new Sensing Matrix block (which is actually in c1cal, not c1lsc, but that's a story for the next paragraph), we should eventually make things back to the more clean flags situation, but for right now, it's working, with lots of lines everywhere. I've tried to be very organized and clear about what lines go where, so that it's easy to see what's going on.
I eventually was able to compile c1lsc, and then installed it, and restarted the model. Adding in 5x the lockin modules (we had 27, but now we have 5x27, so that we can look at the sensing matrix elements for every degree of freedom, and every photodiode, all at the same time) was too much for the poor lsc cpu. I was consistently getting over 70usec per cycle, and was hitting a max of 77usec for the lsc cpu. Both of those numbers are greater than the allowed 60usec. So, I made the decision to put the whole sensing matrix / lockin stuff into the calibration model. This means that I have 27+5 more IPC signals than I used to, but so far things seem to be okay (no rigorous testing yet). (27 to send the 27 PD inputs over to the cal model, and another 5 to send the oscillator "clocks" from the cal model to the lsc model.) The lsc model is now running faster than before (because there were 27 lockin modules in the model), at 24-28 usec, and the cal model is running at 39usec.
All seemed well and good, both the lsc and cal models compiled, but the lsc burt restore wasn't working. Restarting the model did not successfully do a burt restore, and when I tried several different .snap files from today, and other times this month using burtgooey, I kept getting "NOT OK", and numbers weren't being restored into the epics channels. A very few settings were restored, but most were not. I ended up copying a .snap file from a few hours ago into a separate directory, then went in and by-hand removed all the lines referring to now non-existant lockin channels. Burtgooey still told me "NOT OK", but settings seem to be restored, so I think it's okay. I have not confirmed each and every one of the 10,000+ channels to ensure that the number is the same as the one in the .snap file, but as I glance around in the LSC screen and its dependants, all the numbers and buttons look about right.
After all this stuff, Masayuki is locking both arms simultaneously in IR, as he prepares to test some new ALS scripts, so things seem okay for now.
[Alan, Koji, Manasa]
Record number of 50 freshmen were given tour of the 40m this afternoon.
Valve configuration: Vacuum Normal
I have modified the LSC model (the currently-running model is checked into the svn), but it is not compiling for me. So, if you need to make changes to it, be careful, and probably save my version off to the side, and checkout the latest svn version. (I don't foresee anyone needing to modify this model any time soon though).
The change that I'm trying to make is adding several more lockin setups, so that we can measure the sensing matrix elements for several degrees of freedom simultaneously.
Right now, the error that I'm getting is the frustrating "something isn't connected" error, even though if you look in the model, the part that it mentions is fully connected. Usually the solution to this is to disconnect and reconnect everything, so I'll work on that after I return to the lab in a bit.
This was the second week without wet mopping the floor and wet wipe down of the vacuum envelope.
We changed filters on the 40m "HEPA" vacuum pump. It still has very dirty exhaust. Do not use it in clean room!
RA: I'm not sure how to interperet this; I think that the SUM channel is divided by the SUM so that this is supposed to be RIN, but not sure. Can someone please take a look into the SUS model and then explain in the elog what the SUM normalization algorithm is?
PRM is dark. PRM and SRM oplev servos are off. ETMY is not centered.
Step by step procedure for stabilizing arms using ALS servo:
The procedure is the same for both the arms.
0. Check that the ALS arm servos are turned OFF and not sending any signals to the ETM suspensions.
1. Find the beat note by varying the laser temperature (moving the slider for SLOW_SERVO2_OFFSET).
Tip: It is easier to have the arms locked using IR PDH while searching for the beat note. Also check the stability of the MC. Unstable MC will cause the PSL temperature to drift and thereby affect the beat frequency.
2. Once you have the beat note, check if the beat amplitude is ~ -15 to -20 dBm. If the amplitude is small, then the alignment needs to be fixed (either the green input pointing at the end tables or the PSL green alignment). This is important because the UGF of the phase tracking loop (should be above 1KHz) changes with the amplitude of the beat note.
Also the beat frequency should be < 100 MHz; preferably below 80 MHz.
3. Disable IR PDH locking if you had used it while searching for the beat note.
4. Press CLEAR HISTORY button for the phase tracker servo. Check if the phase tracking loop is stable (phase tracker servo output counts should not be ramping up). If the phase tracker is not stable, check the servo gain and phase margin of the loop.
5. Turn OFF all filters in the ALS arm servo filter module except for FM5 (phase compensation filter). With ALS arm servo gain set to zero, enable the arm servo and allow ALS control signals to be sent to the ETM suspensions.
5. Open dtt and look at the power spectrum of the ALS error signal (C1:ALS-BEAT?_FINE_PHASE_OUT_HZ).
6. Set ALS arm servo gain +/- 0.1 to check the sign of the servo gain. Wrong sign of gain will make the loop unstable (beat note moving all over the frequency range on the spectrum analyzer). If this happens, set the gain to zero immediately and clear history of phase tracker servo. If you have set the correct sign for gain, the servo will stabilize the beat note frequency right away.
7. Once you know the correct sign of the servo gain, increase the gain in steps while simultaneously looking at the power spectrum of error signal on dtt (it is convenient to set dtt measurements to low bandwidth and exponential measurement settings). Increase the gain until you can see a slight bump close to the UGF of the ALS servo (>100Hz).
There have been times when this servo gain was in a few hundreds; but right now it varies from +/- 10-20 for both the arms. So we are stepping up gain in steps of +/- 2.
8. Enable filters (FM2, FM3, FM6, FM7, FM8). Wait to see the rms noise of the error signal go down (a few seconds).
9. Enable boost filter (FM10). There also exists a weaker boost filter (FM4) which we don't use any more.
1. Beat frequency changes affect both the servo gain and sign of gain. So if you lose stability of ALS servo at any point, you should go through all the steps again.
2. At any point if the ALS arm servo becomes unstable (which can happen if the MC loses lock or if the beat frequency was too high ), change the servo gain to zero immediately. Turn OFF all the filters except for FM5 (if they were enabled) and reset phase tracker servo (CLEAR HISTORY button in the phase tracker filter module). Masayuki has written the down script that does all this. The script will detect arm servo loop instability by continuously looking at the feedback signal. Details about the script can be found here.
Here is a cheat sheet that can give you an idea of the SLOW SERVO2 offset range to scan in order to find the beat note:
PSL temperature X offset Y offset
31.58 5278 -10890
31.52 5140 (not recorded)
31.45 4810 (not recorded)
31.33 4640 -10440
31.28 4500 -10340
Bonus: notice how we have cleverly used the comb of bounce frequencies around the calibration line to determine that REFL11 is clipping!
Rana and I noticed last week that it looked like the REFL11 beam was clipping. This afternoon, I locked the PRMI with REFL 165 I&Q, and checked the REFL 11 path. The beam looks fine through all of the optics going to the diode, so I just realigned the beam onto the diode using the itty bitty steering mirror. I have not yet checked the change (hopefully improvement) in the REFL11 spectrum.
I discovered that I was not getting enough SNR on all the refl RFPDs when I actuated using the Sensing Matrix script. The problem was that the ITMs have actuation constants that are a factor of 5 lower than the PRM. So, I need to push on the ITMs (for MICH) about 5 times as hard as I push on the PRM (for PRCL). I have modified the sensing matrix scripts to allow different actuation amplitudes for each degree of freedom. If I watch the REFL PD spectra while the script is running, I see that I now have some actual SNR (as in, more than 1, which is what the SNR was for some diodes previously).
A consequence of this is that the script to analyze past data will no longer work on sensing matrix data taken before this afternoon. On the other hand, that data isn't very useful, since there was no SNR.
The upgrade of megatron broke the nds2 service. I have fixed things by
1) installing the latest version of framecpp (1.19.32) from the lsc debian repository (this was necessary because I couldn't link to the existing version)
2) built nds2-server-0.5.11 and installed it in the system directories (/usr/bin)
3) there were a few scripts/links/etc that didn't seem to be set up correctly and I fixed them to correspond with my preious message.
nds2 is now running and the channel list should be updated regularly and the service restarted as appropriate.
I have resaved the PRMI locking settings in the IFO Config screen. Nothing has changed, except that I have put a 1e-4 into the PRCL matrix elements for REFL11I, REFL33I and REFL55I. So, PRMI still locks on REFL165 I&Q, but the other 3 REFL diodes' whitening gets triggered when the cavity is locked. I think this will help the LSC sensing matrix measurements, which I'm going to test out now.
Something is really excellent with the alignment today, or something has changed with the POP path / electronics. While usually we see ~120 counts on POP22_I and ~175 counts on POP110_I (cf elog 9193), today I have ~175 counts on POP22_I and ~265 counts on POP110_I.
Someone left the arms aligned, and the LSC engaged, so the arms have been locked almost continuously for several days hours. The trend below is for 4 days hours. What is most impressive to me is that we don't see a big degredation in the transmitted power over this time.
EDIT: Okay, I got excited without paying attention to units. It was only several hours, which is not too unusual. Although the lack of transmission degredation is still unusual. However, this may be due to improved oplevs? I'm not sure why, but we're not seeing (at least in this plot) the degredation to ~0.7 after an hour or so.
Tried a bunch of stuff, but eventually just turned off the TRANS_QPD loops and loops are stable. Needs more debugging.
Back around June 18, Jamie was debugging some Guardian code here to replace our MC autolocker. Afterwards our MC WFS stopped working. We never figured out what went wrong, but at the time we turned off the feedback from the MC trans QPD and it stabilized the response at DC.
Today, I noticed that the trans QPD feedback is on. Did anyone do this on purpose?
Its problem causing behavior is slow, but you can catch it if you wait. With the nominal WFS gain of 0.4 the control signal ramps up monotonically at a rate of ~100 counts/minute. Depending upon the static alignment of the MC, this could let it take 10 minutes or a few hours before it rails the MC SUS actuators and breaks the lock. Very sneaky. Don't turn this loop back on without making sure its working and not breaking. I would trend it for you, but the SLOW channels associated with the TRANS QPD servo are not trended --- does anyone know how to get them in the channel list?
I noticed that the MC3 LL sensor was apparently dead according to its suspension screen. Since it was only the fast ADC channel and not the SLOW PDmon, I could tell that it was just in the ADC cabling. I pushed in a few of the MC3 sensor cables on the front and back of the PD whitening board and it came back OK. According to this trend of the past 40 days and 40 nights, it started slipping on this past Wednesday morning.
Was anyone walking near MC2 or the suspension electronics racks before noon on Wednesday (Oct. 2nd)?
MC3 watchdog gets tripped sometimes when lock is lost. I noticed that there were no limits set in the MC WFS drive. The attached plot shows that over 40 days, the OUT16 channels from the WFS don't exceed 1000 counts. So I've set the limit to be 2000 in all 6 of the MC ASCPIT/YAW filter banks. Please don't turn them off.
OUT16 is really not the right way to measure this, but for some reason, we don't have any DQ channels from the MC WFS screen ??? So we're not able to measure the trend of the high frequency drive signal.
So I added the WFS(1,2)_I_(PIT,YAW)_OUT_DQ and WFS(1,2)_(PIT,YAW)_OUT_DQ channels to the c1ioo.mdl at 2048 Hz. I used Jamie's excellent 'rtcds' utility to build and install:
1) after making the edits to c1ioo.mdl I saved the file/
2) sshing to c1ioo
3) rtcds stop c1ioo
4) rtcds make c1ioo
5) rtcds install c1ioo
6) rtcds start c1ioo
7) telnet fb 8087
8) daqd> shutdown
That seemed to do it OK.
Unfortunately, all of the instructions that we have in the Wiki for adding channels and model building are misleading and don't mention any of this. There are a few different methods listed which all instruct us to do the whole make and make install business in a bunch of non existent directories.
I centered the ETMY OL today and found that the UGF was around 3-4x too LOW after the laser swap and re-alignment. That's why the Y arm has been shaking so much today.
NO more OL work without loop measurements and noise measurements.
MC unlocked over the weekend and also got severely mis-aligned. It all started around midnight on Saturday.
At first I thought that this was due to the MCS CPU meter being railed at 60 us, so I deleted a bunch of filters in MC1,2,3 that are unused and left over from Den's quantization noise investigations. This reduced the CPU load somewhat, but didn't make any real improvements. Turning on the ASC filter banks in the MC SUS still mis-aligned the MC.
With the MC WFS and MC ASS turned off, there is still some digital junk coming in and misaligning things. Plot attached.
Similar stuff coming in on ITMX, but not ITMY.
Tried restarting various FEs, but there was no effect. Also tried rebooting c1lsc, c1ioo, & c1sus. Finally did 'shutdown -r now' on all 5 computers on the CDS overview screen and simultaneously (almost) pressed the reset button on the RFM switch above the old c1pem crate. Everything came back OK except for c1oaf (I had to manually button his BURT button) and now the ASC inputs on all the SUS are zero when they should be and MC is well locked and aligned.
Rob and I used to do this trick when he thought that a cosmic ray had corrupted a bit in the RFM network.
That's good, but please no more Oplev work. We want to do all of it at once and to make no more changes until we have all the parts (e.g. dumps and correct lenses) in hand and then talk over what the new design will be. I don't want to tune the beam size and loop shape every week.
We replaced the laser for optical lever of ETMY. And also we aligned the path so that beam spot hits the center for each optics. I attached the spectrum of the SUS-ETMY_OPLEV_SUM, the red curve is with old laser, and blue curve is with the new laser. We also measured without laser so as to measure the QPD dark noise (green curve). The change is significant, and seems much closer to other oplev spectrum.(Brown curve is the oplev spectrum of ITMY)
The new laser is:
Manufacture name: JDSU, Model number: 1103P, Serial number: PA892324
The injection power is 3.7 mW and the out coming power is 197 uW (measured just before the QPD). The output value of the SUS-ETMY_OPLEV_SUM is about 8500.
First we measure 2 spectrum ( including the dark noise). After that we replace the laser and align the optical lever path. We changed the post of one of the mirror (just before the QPD) because the hight was too low. Inside of the chamber is darker than before - actually we had scattering light inside the chamber before. We dumped the reflected light from QPD. And then we measured the spectrum of the oplev output. I also aligned oplev of ETMY after restoring the YARM configuration using IFO configure screen.
We don't know actually what was the problem, laser quality or the scattering light or some clipping. But the oplev seems to be better.
Steve: Atm2 shows increased gains correction later for UGF elog 9206
We locked MICH with 2 arms stabilized by ALS control.
We measured the power spectrum of the LSC-MICH_IN1 at each step so as to know the in-loop noise of MICH. And also we measured the OLTF of MICH loop and the error signal with BS excited at 580 Hz and MICH notch filter at same frequency enabled to obtain the MICH calibration factor.
1. We locked MICH using the AS55Q error signal and fedback to BS actuator. (Red curve)
2. We locked MICH and locked both the arms using POX11 and POY11 error signals and fedback to ETMs actuators.(Blue curve)
3. We stabilized both the arms using ALS. We use the ALS error signals and fedback to ETMs actuators. And then we locked MICH.(Magenta curve)
The green and brown curve are the ALS in-loop noise, which is the _PHASE_OUT_Hz calibrated error signals. So for these two curves the unit of vertical axis is Hz/rHz. The other curves are the MICH in-loop noises and these are not calibrated. So for these curves the unit of vertical axis is counts/rHz.
The UGF of MICH loop is 10 Hz with phase margin of 45 degrees (measured today). The FPMI noise with ALS stabilized arms is much larger than the FPMI with IR PDH locked arms above 30 Hz. That is because the ALS arm stability is not as good as the stability of PDH locked arms. We have to analyze and verify the calibrated numbers for FPMI + ALS with model.
I checked the BK precision 1856D manual. I found that although this frequency counter can measure upto 3.5GHz, it has 2 separate input channels to measure two range of frequencies.
One input to measure between 0.1Hz to 100 MHz and the other to measure between 80MHz to 3.5GHz. Our beat frequency desirable range is <100MHz for stable ALS. Also, the beat PD response falls off beyond ~150MHz . Should we be happy with this frequency counter and use it in the 0.1Hz-100MHz range or look for one with a better measuring range?
P.S. Right now we are using the spectrum analyzer in the control room set to frequency range from 10MHz - 140 MHz for beat note search.
We succeeded in stabilizing both the arms using ALS and get IR to resonate at the sametime.
At each step we measured the _PHASE_OUT_Hz calibrated error signals for Y in this configuration so as to get the in-loop noise of ALS control of YARM
1. we stabilized YARM off IR resonance by using ALS, misaligned ETMX, closed XARM green shutter. That means no IR flashing and no green in XARM.
2. we aligned the ETMX with XARM green shutter closed.
3. we opened the green shutter and locked the green laser with PDH to the XARM.
4. we stabilized the XARM using ALS and off resonance for IR.
5.We brought the XARM to IR resonance with YARM stabilized off IR resonance.
6. we brought the YARM to IR resonance
Beat frequencies when both the arms were stabilized and had IR resonating :
X arm beat frequency = 73.2 MHz; Y arm beat frequency = 26.6 MHz.
1.the ALS in-loop noise in X and Y arms with IR off resonance and resonating.
2.the ALS in-loop noise in Y arm in each step from 1 to 6.(will follow soon)
The Y arm ALS in-loop noise doesn't seem to be different in any of the configurations in step 1 to 6. This seems to mean that the ALS of the two arms are decoupled.
Actually we are not sure what changed from the last few days (when we were seeing some sort of coupling between the ALS of X and Y arm) except for YARM green PDH servo gain changed (see this entry),