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.
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.
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.
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.
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 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)?
I wonder what's drifting between the laser and the PMC? And why is it getting worse lately?
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?
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?
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.
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.
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.
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 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.
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.
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
PRM is dark. PRM and SRM oplev servos are off. ETMY is not centered.
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!
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.
Valve configuration: Vacuum Normal
[Alan, Koji, Manasa]
Record number of 50 freshmen were given tour of the 40m this afternoon.
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.
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.
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.
Still to do:
* Decide what 5 frequencies to use for excitation.
* Put the bandpass and lowpass filters into the lockin modules.
* Put matching notch filters into each LSC servo.
* Re-write the sensing matrix scripts.
* 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.
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.
Chris Couste, our new undergrad help received 40m specific, basic safety training yesterday.
Power spetrum of ETMX and ETMY in the view of oplev pitch and yaw.
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.
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.
- What we did
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.
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.
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.
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.
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.
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).
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.
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.
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.
Atm1 bandwidth 0.01 Hz ETMY plot is different from
Atm2 bandwidth 0.1 Hz normal ??????? They should be the same !!!!
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.
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:
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.
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.
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.
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.
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.
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.
I locked the PRMI, and tried to turn on the ASS, but this caused PRMI to lose lock.
Since this is similar to what happened the other night (see elog 9243, 2nd big paragraph), I looked into it a little further. I noticed that the POP QPD pitch was very close to the edge of the QPD, so I went out and (while PRMI was locked) recentered the POP QPD. After doing so, I was able to run the PRM ASS, and it worked very nicely, just as it has before. So, it looks like something drifted, such that the optimal PRM alignment caused the POP beam to not be fully on the QPD. Since the ASC loop is triggered by PRMI lock, and is constantly on, falling off the QPD causes lockloss.
While I was out there, I tweaked up the PMC pitch alignment yet again. The FSS numbers all looked reasonable, however PMC transmission was ~0.75 . I did a tiny bit of work in pitch, and now we're back to 0.83 transmission.
I locked PRMI, and (after fixing the POP QPD situation, noted in elog 9249) took power spectra of all the REFL RFPDs. It looks like the area above 500 Hz is pretty clean and flat for all the signals, so I'm going to use 560Hz, 562Hz, 564Hz, 566Hz and 568Hz for my 5 sensing matrix frequencies.
Also, I'm not sure what is going on with REFL11, but there's a weird dip between 630 Hz and 660 Hz in both I and Q. I recentered this guy not too long ago (elog 9218), but it clearly needs some more looking-at.
While Manasa, Jenne, and Masayuki are working on the preparing the interferometer, I write the elog for them.
- 6PM-ish: X and Y arms were was locked. They were aligned with ASS.
- PRMI was locked. The PRM was aligned with ASS.
- Jenne went into the lab and aligned the PRM ASC QPD.
- Jenne also aligned all of the oplev spots except for the SRM.
- 6:40PM Then, Manasa and Masayuki checked the out-of-loop stability of the arms.
The X and Y arms have the rms of 2.2kHz and 600Hz, respectively.
The X arm is significantly worse than the Y arm.
Masayuki saved the plot somewhere in his directory.
- 7:20PM X beat: 41.2MHz, Y beat: 14.8MHz
- 7:22PM PRMI locked POP110 115-120
- 7:30PM Lost lock of everything. Start over. Taking the arm alignment.
- 7:45PM start the 2nd trial. PRMI+one arm ready.
- 8:00PM explosion! Lost lock.
- 8:30PM The Xarm ALS is not stable anymore. It loses the control in ~10sec.
We are investigating the out-of-loop stability of the Yarm ALS.
(i.e. Look at the beat note error signal while locking the Yarm with the IR PDH)
PSL temperature changed
The beat note of Xarm looked somehow strange before (elog). It should be the highest when the green transmission power is highest, in other words when the end green PDH locks with a TEM00 mode. But it was not like that. When the end PDH locked with other modes (GTRX: below 0.3), the beat note was higher than TEM00 mode (GTRX: around 0.5).
We guessed that end green laser was somewhere around the point where there were 2 stable TEM00 modes . In order to move away from this unstable region of the end laser, we changed PSL temperature to obtain beat note at a different green laser frequency where we do not have any of the weird modes oscillating.
We changed the PSL temperature from 31.63 degree to 31.33 degree. We measured the in-loop noise of ALS loop and I attached it. There is not big difference in Yarm, but the Xarm in-loop noise become better in high frequency region. We think before the xend green laser was in a not-so-good state and the laser had more frequency noise then.
After change PSL temperature, Xarm ALS is so stable. Actually Xarm is being locked right now and it is locked for more than 50 minutes!!
Although the Xarm ALS is so stable, Yarm ALS is not stable right now. It lost lock by ~5min. We don't know what is the reason, so we will try to fix it tomorrow.