ELOG 40m

DRFPMI, PRFPMI HOM resonances

I did some simulations to see if we are susceptible to HOM resonances as we reduce the CARM offset. I restricted my search to HG modes of the Carrier+[-55,-11,0,+11,+55]MHz fields with n+m<6, and used all the real physical parameters I could get ahold of.

In short, as I change the CARM offset, I don't see any stray resonances within 2nm of zero, either in PRFPMI or DRFPMI.

Now, the mode matching in my simulation is not the real mode matching our real interferometer has. Thus, it can't tell us how much power we may see in a given mode, but it can tell us about our susceptibility to different modes. I.e. if we were to have some power in a certain mode coming out of the IMC, or present in the vertex, we can see what it would do in the arms.

Since my simulation has some random amounts of power in each HOM coming into the interferometer, I simply swept the CARM offset and looked for peaks in the power of each mode. Many of the fields exhibited gentle slopes over the range, and we know we ok from 3nm->~100pm, so I made the selection rule that a "peak" must be at least 10 times as big as the minimum value over the whole range, in order to see fields that really do have CARM dependence.

In the following plots, normalized IFO power is plotted and the locations of HOM peaks are indicated with circles; their actual heights are arbitrary, since I don't know our real mode content. However, I'm not really too concerned, since all I see is some -11MHz modes between 2-3nm of full resonance, where we have no problem controlling things... Also, all of the carrier HOMs effectively co-resonate with the 00 mode, which isn't too surprising, and I didn't include these modes in the plots.

Finally, I visually inspected the traces for all of the modes, and didn't really find anything else peeking out.

Code, plots attached.

10701

Wed Nov 12 03:22:23 2014

Koji pointed out something to me that I think he had told me ages ago, and Rana alluded to last night: Since I'm not tuning my "demod phase" for the sensing matrix lockins, unless I happened to get very lucky, I was throwing away most of the signal. Lame.

So, now the magnitude is sqrt(real^2 + imag^2), where real and imag here are the I and Q outputs of the lockin demodulator, after the 0.1Hz lowpass. (I put in the low pass into all of the Q filter banks). To keep the signs consistent, I did do a rough tuning of those angles, so that I can use the sign of the real part as the sign of my signal. When I was PRMI locked, I set the phase for all things acutated by MICH to be 79deg, all things actuated by PRCL to be 20 deg, and when DRMI locked set all things SRCL to be 50deg.

After doing this, the phases of my sensing matrix output matches Koji's careful analyses. I don't know where the W/ct numbers I was using came from (I don't think I made them up out of the blue, but I didn't document where they're from, so I need to remeasure them). Anyhow, for now I have 1's in the calibration screen for the W/ct calibration for all PDs, so my sensing matrices are coming out in cts/m, which is the same unit that Koji's analysis is in. (Plot for comparing to Koji is at end of entry).

While reducing the CARM offset, I left the sensing matrix lines on, and watched how they evolved. The phases don't seem to change all that much, but the magnitudes start to decrease as I increase the arm power.

For this screenshot, the left plot is the phases of the sensing matrix elements (all the REFL signals, MICH and PRCL), and the right plot is the magnitudes of those same elements. Also plotted is the TRX power, as a proxy for CARM offset. The y-scale for the TRX trace is 0-15. The y-scale for all the phases is -360 to +360. The y-scale of the magnitude traces are each one decade, on a log scale.

Bonus plot, same situation, but the next lock held for 20 minutes at arm powers of 8. We don't know why we lost lock (none of the loops were oscillating, that I could see in the lockloss plot).

Here are some individual sensing matrix plots, for a single lock stretch, at various times. One thing that you can see in the striptool screenshots that I don't know yet how to deal with for the radar plots is the error bars when the phase flips around by 360 degrees. Anyhow, the errors in the phases certainly aren't as big as the error boxes make them look.

PRMI just locked, CARM offset about 3nm, CARM and DARM on ALS comm and diff, arm powers below 1:

PRMI still on REFL33 I&Q, CARM and DARM both on DC transmissions, arm powers about 4:

CARM offset reduced further, arm powers about 6:

CARM offset reduced even more, arm powers about 7:

For this plot for comparing with Koji's analysis, I had not yet put 1's in the calibration screen, so this is still in "W"/m, where "W" is meant to indicate that I don't really know the calibration at all. What is good to see though is that the angles agree very well with Koji's analysis, even though he was analyzing data from yesterday, and this data was taken today. This sensing matrix is DRMI-only (no arms), 1f locking.

Bonus plot, PRMI-only sensing matrix, with PRMI held using REFL 33 I&Q:

10703

Wed Nov 12 18:08:35 2014

In my previous meditations about RIN, particularly elog 10258, I was only thinking about the RIN contribution at the offset that I was currently sitting at. Also, In elog 10258 I was comparing to the ALS signals and just said that the trans signals are better which is true, although isn't super helpful when thinking of reduced CARM offsets.

My summary today is that I think we want to reduce the RIN in arm transmissions by a factor of 3.

Rather than dig around, I just remeasured the RIN, for both the single arm transmissions and the MC transmission. (Data attached as .xml file)

The RMS RIN for the Xarm is 1.3e-2. The RMS RIN for the Yarm is 8.9e-3. The RMS RIN for MCtrans is 4.0e-3. For the simulations below, I will use 1e-2 as an average RIN for the arms.

As an estimate of the RIN's contribution to cavity fluctuations, I divide the RIN by the slope of the CARM transmission peak. The slope (from optickle) gives me [ delta-W / delta-m ], and the inverse of that gives me [ delta-m / delta-W ]. I multiply this by RIN, which is [ delta-W / W ] to get [delta-m / W].

Then, since I'm using the DC transmission signals as my error signals, I use just TRX (normalized to be 1 for single arm resonance) as my Watts.

So, in total, the traces plotted are { TRX * RIN / slope }.

The 2 plots are the same data, one with linear-x and the other with log-x. They both include my estimate of the cavity length fluctuations due to RIN at the arm transmission, as well as an estimate of the cavity length fluctuations if the arm RIN was as good as the MC RIN. I also show the DRFPMI CARM linewidth (23 pm for HWHM), and 1% of that linewidth. The last trace is 1% of the half-width of the transmission peak, at the current CARM offset. For example, 1000 pm away from full resonance the half-width is 1000 pm and 1% of that is 10 pm.

What we want to see here is that the solid blue line is below one of the dotted lines. I think that using the overall linewidth (purple dotted line) isn't really the right thing to look at. Our goal is to prevent excursions that will get too close to the resonance peak, and cause a lockloss. A one picometer excursion is a much bigger problem (relatively) below say 100 pm, as opposed to above 100 pm. So, I think that we should be looking at the half-width of the resonance peak at whatever the current CARM offset is (orange dotted line). Above 25 pm, the blue line is below the orange line for all offsets plotted. If we made the arm RIN as good as the MC RIN, that would be true down to 12-ish pm.

We should be able to safely transition to non-normalized RF signals at 10pm or below. This implies that (since any RF signals normalized by this RIN-y trans signal will have the RIN), we want to improve the RIN of the transmission PDs by about a factor of 3. (This will lower the blue line such that it crosses the orange dotted line at 10 pm).

10705

Wed Nov 12 21:18:32 2014

DRFPMI, PRFPMI HOM resonances

So, with my last entry, I was guilty of just throwing stuff into the simulation and not thinking about physics... so I retreated to Siegman for some algebraic calculations of the additional Guoy phase accumulated by the HOMs in the arms -> their resonant frequencies -> the arm length offset where they should resonate. Really, this isn't completely precise, as I treated the arms independently, with slightly differing ETM radii of curvature, but I would expect the "CARM Arm" to behave as a sort of average of the two arm cavities in this regard. (EDIT: Also, I didn't really consider the effect of the coupled vertex cavities... so there's more to be done)

The basic idea I used was:

Assume ITMs are effectively flat, infinite Rc
Use 40mwiki values for ETM curvatures
Each additional HG order adds arccos(sqrt(1 - Larm/Rc)) of Guoy phase for a one way trip down the cavity (Eqn 19.19 in Sigman)
For each HOM order up to 5 of the carrier and first order sidebands, add the appropriate phase shift
fold it onto +-FSR/2 of the carrier 00 resonance, convert to m

In practice, I threw together a python script to do this all and print out a table. I've highlighted the values within 10nm, but the closet one is 3.8nm

Results:

########## X Arm HOM Resonance Locations in nm ##########

Mode Order: 0 , 1 , 2 , 3 , 4 , 5

Carrier : +0, +156.21, -219.58, -63.376, +92.832, +249.04

LSB 11 : +59.563, +215.77, -160.02, -3.8126, +152.4, -223.4

USB 11 : -59.563, +96.645, +252.85, -122.94, +33.269, +189.48

LSB 55 : -234.18, -77.975, +78.233, +234.44, -141.35, +14.857

USB 55 : +234.18, -141.61, +14.6, +170.81, -204.98, -48.776

########## Y Arm HOM Resonance Locations in nm ##########

Mode Order: 0 , 1 , 2 , 3 , 4 , 5

Carrier : +0, +154.82, -222.35, -67.531, +87.292, +242.11

LSB 11 : +59.313, +214.14, -163.04, -8.218, +146.6, -230.57

USB 11 : -59.313, +95.51, +250.33, -126.84, +27.978, +182.8

LSB 55 : -235.43, -80.611, +74.212, +229.04, -148.14, +6.6809

USB 55 : +235.43, -141.74, +13.08, +167.9, -209.27, -54.452

Code is attached. Hopefully no glaring mistakes!

10707

Thu Nov 13 01:00:37 2014

rana

I modified the MC2 trans optical setup a little bit: the reflection from the QPD was not dumped and so it was hitting the wall of the black box.

I angled the QPD slightly and moved the dump so that the reflection hit it. The leakage through the 50/50 steering mirror for the QPD was already being dumped and I made sure that that one stayed dumped on its razor dump. After doing this we turned off the WFS and re-aligned the MC2 trans beam onto the QPD to zero the pit/yaw signals.

10709

Thu Nov 13 04:28:28 2014

[Jenne, Rana, Koji]

We did some thinking on what could be causing the excess RIN that we see in the arm transmissions but not in the MC transmission. Unfortunately, I don't think we have anything conclusive yet.

We thought about:

Test mass oplevs
Input tip tilt jitter
MC motion

Oplevs

As Rana reported in elog 10708, we tuned the oplev servos for ITMX, ETMX, ITMY and ETMY. They all now look like the new SRM oplevs that Rana described in elog 10694. However, when we re-looked at the RIN after the oplev tuning, we did not see a noticeable change. So, fixing up the oplevs didn't fix up the RIN.

Side notes:

Several optics had low gains for suspos, which were increased to give Qs of ~5ish.
When we gave ITMX a 500 count step in pitch (the same size used for all other optics in both pit and yaw), it didn't come back afterward. This is a little disconcerting. Rana had to move the alignment slider to get it back so that we had MICH fringing at the AS port again.

Input Tip Tilts

Koji did some work, reported in elog 10706, on how much the jitter of the input pointing tip tilts should affect us. We don't think that they are moving enough to be the cause of the excess RIN that we see.

Mode Cleaner Motion

We see some coherence between MC2 suspit and TRX/TRY, so we suspect that the MC's motion could be causing problems.

I looked at the WFS vs. TRX & TRY, and saw significant coherence at the 3 Hz stack resonance. I think it's clear that the WFS can help suppress this motion more. The WFS noise level was too bad to see any other coherence at other frequencies. (Side note: We should consider increasing the analog WFS signal. As Rana mentioned back in 2008 in elog 454, the signal is super small. Increasing the analog gain could allow us to suppress motion at more frequencies, although it would be a bit of a pain.)

To try and get some more signal, I routed the IPPOS beam over to the PRM oplev temporarily. The idea was to be able to look at the IPPOS port, but with a fast channel. I turned off the BS/PRM HeNe, and removed the last steering mirror before the QPD. I put in 2 Y1 steering mirrors to get the IPPOS beam across the table and pointing at IPPOS. I took my measurements 3 times, with different beam sizes on the QPD, to try to image different gouy phases. I used absorptive ND filters (0.6 + 0.1) to get the light level on the PD such that I had about 10,000 counts per quadrant, where 16,000 counts seemed to be the saturation point. I also reset the dark offsets of the QPD quadrants, although they were so small that I don't think it did much. I also took out the optical lever calibration from counts to microradians, since that number isn't meaningful for what I was doing. So, the IPPOS signals (using the PRM oplev channels) are in raw ADC counts. The first measurement had no lens, and the beam was probably at least half the size of the QPD. The second measurement had a lens, and the beam on the QPD was about half the original size. The third measurement had the lens closer to the QPD, so that the beam was about 1mm on the diode. In none of these cases do I see any significant coherence with the TRX/TRY RIN signals, except at 3 Hz. After my measurements I put the oplev back including all of the digital settings, although for now I just left the IPPOS beam dumped on a razor dump, since it wasn't being used anyway. I need to realign IPPOS when it's not the middle of the night.

Some thoughts that we have:

Maybe it's time to resurrect seismic feedforward on MC length, to suppress some of this 3 Hz motion?
Maybe we should be using the MC_L path to offload some of the frequency feedback, so that we're not pushing on MC2 so hard (because if we have bad F2P coupling, this creates beam motion)

I have plots for each of my IPPOS vs. TRX/TRY measurements. The data is attached. For each, I looked at the transfer function between IPPOS (using the SUS-PRM_OPLEV channels) and TRX/TRY to get the 'calibration' between input beam motion and transmission RIN. In all cases, at 3 Hz the coefficient was about 1, so in the power spectra on the right side, there is no calibration applied to the IPPOS signals.

IPPOS vs. Transmission RIN, no lens, big beam on QPD:

(Just kidding about the other 2 plots - the elog can't handle it. They're in the zippyzip file though, and I don't think they look qualitatively different from the no-lens case).

10712

Thu Nov 13 23:42:01 2014

After Kate, Diego and I moved the seismometers to the corner for a huddle test (see elog 10711), I wanted to check the coherence between the seismometers and the arm transmissions.

First of all, it looks like either the Guralp or the T-240 have their X and Y backwards. Diego is going to check this tomorrow.

Between 0.9Hz - 3.5Hz, we have pretty strong coherence with the horizontal seismic channels. Interestingly, between 8-10Hz, the Yarm has pretty strong coherence with the Z-axes of the seismometers (the coherence is only about 0.6, but it's consistent over a 2-ish Hz wide band).

The MC transmission doesn't have as much coherence with the seismic, which surprised me. So, we can try some FF to the MC, but we may also have to do some to the arms.

10713

Fri Nov 14 02:43:05 2014

PRFPMI HOM resonances

I've extended my analysis to the PRFPMI case, with the current working knowledge of radii of curvature and cavity lengths. However, losses were not included.

I do not see any HOM activity within about 20nm of the carrier TM00 resonance.

Basically, what I did was use the standard formulae for the reflection and transmission coefficients of FB cavities viewed as compound mirrors. However, I modified the normal spatial propagation terms to include the additional Guoy phase accumulated by the HOMs. I created these coefficients for each arm individually, and then used (rX + rY)/2 as a mirror in the PRC, and used that to create the transmission coefficient for the PRFPMI as a whole, as a function of frequency offset from the carrier, spatial mode order and CARM offset. As a check, this produced the correct finesse for the carrier lock to the single arm and PRFPMI.

Here is a PRFPMI CARM FSR of all of the fields' power transmission coefficients, up to order n+m=5.

One can observe some split peaks. There are two causes, the biggest effect is the mismatch between ETM radii of curvatures (ETMX:59.48, ETMY:60.26):, followed by asymmetric arm length(X:37.79, Y:37.81). (I judged this by the visual change of the plot when changing different factors).

In the following plot, I broke down the peaks by mode order:

Code, plots attached!

10718

Fri Nov 14 17:08:17 2014

T-240 has a different convention than we use. It assumes that North is aligned with the Y-axis. Since this is the new guy, and we've been using the Guralps with North = X for many years, Diego and I rotated the T-240, and put a label on it that N/S is Y, and E/W is X. Obviously Vert is still Z.

10720

Fri Nov 14 20:31:13 2014

I took a quick look at single arm RIN. Actuating on MC2 vs. the ETM, or using AS55 instead of POY11 made no noticeable difference in the arm cavity RIN. Not too surprising, but there it is.

10725

Tue Nov 18 15:20:58 2014

Some lockloss plots from PRFPMI

Elog from ~5am last night:

Tonight was just several trials of PRFPMI locking, while trying to pay more attention to the lockloss plots each time.

General notes:

I tried once to acquire DRMI on 1f while the arms were held off resonance. I wasn't catching lock, so I went back to PRMI+arms. I aligned the PMC, which I noted in a separate elog.

I was able to hold the PRMI on REFL33I&Q, and have ALS CARM and DARM at zero CARM offset. The arm would "buzz" through the resonance regularly. I use the word buzz because that's kind of what it sounded like. This is the noise of the ALS system.

I think we want to add the transmission QPD angular signals to the frames. Right now, we just keep the sums. It would have been handy to glance at them, and see if they were wiggling in the same way that some other signal was waggling.

All the data files are in /opt/rtcds/caltech/c1/scripts/LSC/LocklossData. Each folder is one lockloss. It includes text files for each trace, as well as any plots that I've made, and any notes taken. The text files are several MB each, so I'm not going to bog the elog down with them. There are a few folders that end in "_notInteresting". These ones are, as one might guess, not interesting. 2 were MC locklosses (I'm not actuating on MC2, so I declared these independent from my work) and one was when I knew that my ALS was bad - the beatnotes weren't in good places, and so the ALS noise was high.

Folder: 1100342268_POP22goesLow

Working notes: Lost lock because POP22 went too low. PRCL and MICH triggered off. After this, changed PRCL and MICH "down" thresholds to 0.5, from 10.

Plots:

Conclusion: Easy fix. Changed the down thresholds for MICH and PRCL to be lower, although still low enough that they will trigger off for a true lockloss. Why though do we lose so much sideband power when the arm transmission goes high? POP22 dipped below 10 when TRX went above 29. Does this happen on both sides of the CARM offset? Quick simulation needed.

------------------------------------------------------------------------

Folder: 1100330534_maybePRCLangular

Working notes: PRFPMI, reducing CARM offset to arm powers of 7. CARM on sqrtInv, DARM on DCtrans. PRMI on REFL33 I&Q. Don't know why I lost lock. Maybe angular stuff in PRC? I think POP spot was moving in yaw as it started to go bad.
Note, later: regathered data to also get POP angular stuff. Don't think it's POP angular. Not sure what it is.

Plots:

Conclusion: I'm not sure what this lockloss was caused by, although it is not something that I can see in the POP QPD (which was my initial suspicion). It is, like many of the rest of the cases, one where I see significant bounce and roll mode oscillations (error and control signals oscillating at 16 and 24 Hz). I don't think those are causing the locklosses though.

--------------------------------------------------------------------

Folder: 1100334680_unknown_highArmPowers

Working notes: PRFPMI, carm_up script finished, sitting at arm powers of 8. CARM, DARM on DC trans. PRMI on REFL33. Don't know why lost lock.

Plots:

[Don't have any? - I'll make some]

Conclusion: Again, I see 16 and 24 Hz oscillations, but I don't think those are causing the lockloss.

---------------------------------------------------------------------

Folder: 1100331950_unknown

Working notes: PRFPMI, arms about 8. CARM, DARM on DC trans. PRMI on REFL33. Don't know why I lost lock.

Plots:

Conclusion: Don't have an answer.

--------------------------------------------------------

Folder: 1100345981_unknown

Working notes: Lockloss while going to arm powers of 7ish from 6ish. Not POP angular, POP22 didn't go low.

Plots:

Conclusions: This one wasn't from POP22 going too low, but again, I don't see anything other than 16 and 24Hz stuff.

10726

Tue Nov 18 17:11:30 2014

Some lockloss plots from PRFPMI

I am still staring at / trying to figure out the latter 4 locklosses posted earlier. But, I have just included the transmission QPD angular output signals to the frames, so we should be able to look at that with locklosses tonight.

To get the lockloss plots: in ..../scripts/LSC/LocklossData/ , first run ./FindLockloss.sh <gps time> . This just pulls the TRX and TRY data, and doesn't save it, so it is pretty quick. Adjust the gps time until you capture the lockloss in your plot window. Then run ./LockLossAutoPlot.sh <gps time> to download and save the data. Since it has become so many channels, it first makes a plot with all of the error and control signals, and then it makes a plot with the power levels and angular signals. The data folder is just called <gps time>. I have started also including a text file called notes inside of the folder, with things that I notice in the moment, when I lose lock. Don't use .txt for the suffix of the notes file, since the ./PlotLockloss.py <folder name> script that will plot data after the fact tries to plot all .txt files. I have also been appending the folder name with keywords, particularly _notInteresting or _unknown for either obvious lockloss causes or mysterious lockloss cases.

10727

Tue Nov 18 22:34:28 2014

Some other plots from PRFPMI

Quote:

Here is a plot of when the arm powers went pretty high from last night. CARM and DARM were on ALS comm and diff, PRMI was on REFL33 I&Q. I set the CARM offset so that I was getting some full arm resonances, and it goes back and forth over the resonance.

The Y axes aren't perfect when I zoom, but the maximum TRX value was 98 in this plot, while the max TRY value was 107.

MICH_OUT was hitting its digital rails sometimes, and also it looks like PRCL and MICH occasionally lost lock for very brief periods of time.

Glitch-like events in PRCL_OUT are at the edges of these mini-locklosses. I don't know why POPDC has glitch-y things, but we should see if that's real.

Okay, I've zoomed in a bit, and have found that, interestingly, I see that both POP22 and POP110 decrease, then increase, then decrease again as we pass through full resonance. This happens in enough places that I'm pretty sure we're not just going back and forth on one side of the resonance, but that we're actually passing through it. Q pointed out that maybe our demod phase angle is rotating, so I've made some zoom-in plots to see that that's not a significant effect. I plot the I and Q phases individually, as well as the total=sqrt(I**2 + Q**2), along with TRY (since the increases and decreases are common to both arms, as seen in the plot above).

For POP 22:

For POP 110:

I also plot the MICH and PRCL error signals along with TRY and POP22 total. You can see that both MICH and PRCL were triggered off about 0.1msec after POP22 total this it's first super low point. Then, as soon as POP22 becomes large enough, they're triggered back on, which happens about 1.5msec later. (The triggering was actually on POP22I, not POP22tot, but the shapes are the same, and I didn't want to overcrowd my plots).

I am not sure if we consistently lose sideband signal in the PRC more on one side of the CARM resonance than the other, but at least POP22 and POP110 are both lower on the farther side of this particular peak. I want to think about this more in relation to the simulations that we've done. One of the more recent things that I see from Q is from September: elog 10502, although this is looking specifically at the REFL signals at 3f, not the 2f circulating PRCL power as a function of CARM offset.

10729

Fri Nov 21 02:22:25 2014

More ALS PRFPMI exploration

Similar to what Jenne did the other night, I kept the PRFPMI arm DoFs locked on ALS, in hopes to check out the RF error signals.

I was able to stably sit at nominally zero offset in both CARM and DARM, tens of minutes at a time, and the PRMI could reacquire without a fuss. Arm powers would rest between 10 and 20, intermittently exhibiting the "buzzing" behavior that Jenne mentioned when passing through resonance. 100pm CARM offset means arm powers of around 10, so since our ALS RMS is on this order, this seems ok. I saw TRX get as high as 212 counts, which is just about the same that I've simulated as the maximum power in our IFO.

To get this stable, I turned off all boosts on MICH and PRCL except PRCL FM6, and added matrix elements of 0.25 for TRX and TRY in the trigger line for the PRMI DoFs. The logic for this is that if the arm powers are higher than 1, power recycling is happening, so we want to keep things above the trigger down value of 0.5, even if POP22 momentarily drops.

I also played around a bit with DARM offsets. We know from experience that the ALS IR resonance finding is not super precise, and thus zero in the CARM FM is not zero CARM offset when on ALS. The same obviously holds for DARM, so I moved the DARM offset around, and could see the relative strengths of flashes change between the arms as expected.

I've written down some GPS times that I'm going to go back and look at, to try to back out some information about our error signals.

Lastly, there may be something undesirable happening with the TRX QPD; during some buzzing, the signal would fluctuate into negative values and did not resemble the TRY signal as it nominally would. Perhaps the whitening filters are acting up...

10734

Tue Nov 25 02:04:19 2014

PRFPMI tonight - need some PRCL and MICH tuning at high arm powers

Take-away for the night: We need to do some more fine-tuning of the PRCL and MICH loops when we have arm resonance.

Koji sat with me for the first part of the night, and we looked back at the data from last week (elog 10727), as well as some fresh data from tonight. Looking at the spectra, we noticed that last week, and early in the evening today, I had a fairly broad peak centered around ~51Hz. We are not at all sure where this is coming from. The PRMI was locked on REFL 33 I&Q, and CARM and DARM were both on ALS comm and diff. This peak would repeat-ably come and go when I changed the CARM offset. At high arm powers (above a few tens? I don't know where exactly), the peak would show up. Move off resonance, and the peak goes away. However, later in the night, after an IFO realignment, I wasn't able to reproduce this effect. So. We aren't sure where it comes from, but it is visible only in the CARM spectra, so there's some definite feedback funny business going on.

Anyhow, after that, since I couldn't reproduce it, I went on to trying to hold the PRMI at high arm powers, but wasn't so successful. I would reduce the CARM offset, and instead of a 50Hz peak, I would get broadband noise in the PRMI error signals, that would eventually also couple in to the CARM (but not DARM) error signal, and I would lose PRMI lock. I measured the PRCL and MICH transfer functions while the arms were at some few units of power, and found that while MICH was fine, PRCL was losing too much phase at 100Hz, so I took away the FM3 boost. This helped, but not enough. I had 1's in the triggering matrix for TRX and TRY to both PRCL and MICH, so that even if POP22 went low, if the arms were still locked then the PRMI wouldn't lose lock unnecessarily, but I was still having trouble. In an effort to get around this, I transitioned PRMI over to REFL 165 I&Q.

While the arms were held around powers of 2ish, I readjusted the REFL 165 demod phase. I found it set to 150 deg, but 75 deg is better for PRMI locking with the arms. For either acquiring or transitioning from REFL33, I would use REFL165I * -1.5 for PRCL, and REFL 165Q * 0.75 for MICH. (Actually, I was using -2 for REFL165I->PRCL, and +0.9 for REFL165Q->MICH, but I had to lower the servo gains, so doing some a posteriori math gives me -1.5 and +0.75 for what my matrix elements should have been, if I wanted to leave my servo gains at 2.4 for MICH and -0.02 for PRCL.) I don't always acquire on REFL165, and if it's taking a while I'll go back to putting 1's in the REFL33 I&Q matrix elements and then make the transition.

With PRMI on REFL 165 I&Q, I no longer had any trouble keeping the PRMI locked at arbitrarily high arm powers. I was still using 1*POP22I + 1*TRX + 1*TRY for triggering PRCL and MICH. My thresholds were 50 up, 0.1 down. The idea is that even if POP goes low (which we've seen about halfway up the CARM resonance), if we're getting some power recycling and the arms are above 1ish, then that means that the PRMI is still locked and we shouldn't un-trigger anything. I didn't try switching over to POP110 for triggering, because POP22 was working fine.

Earlier in the night, Koji and I had seen brief linear regions in POX and POY, as well as some of the REFL signals when we passed quickly through the CARM resonance. I don't have plots of these, but they should be easy to reproduce tomorrow night. Koji tried a few times to blend in some POY to the CARM error signal, but we were not ever successful with that. But, since we can see the PDH-y looking regions, there may be some hope, especially if Q tells us about his super secret new CESAR plan.

Okay, I'm clearly too tired to be writing, but here are some plots. The message from these is that the PRMI loops are causing us to fluctuate wildly in arm transmission power. We should fix this, since it won't go away by getting off of ALS. The plots are from a time when I had the PRMI locked on REFL165, and CARM and DARM were still on ALS comm and diff. All 3 of these colored plots have the same x-axis. They should really be one giant stacked plot.

Also, bonus plot of a time when the arm powers went almost to 200:

10736

Wed Nov 26 05:15:48 2014

PRFPMI tonight PRMI 100Hz osc?

[Jenne, EricQ]

Just to get our day started right, we tweaked up the alignment of the Ygreen to the Yarm (after IR alignment), and also touched up the X beatnote alignment on the PSL table. Ran the LSC offsets script, and then started locking.

All of the locking tonight has been based on CARM and DARM held on ALS comm/diff, and PRMI held on REFL165. Today, CARM was actuated using MC2. No special reason for the switch from ETMs. The AS port is noticeably darker when using REFL165 instead of REFL33.

Around 12:33am(ish), we were able to hold the arms at powers of about 100, for almost a minute. The fluctuations were at least 50% of that value, but the average was pretty high. Exciting.

Q and I tried a few times to engage the AO path while the arms were held at these high powers. Q hopefully remembers what the gain and sign values were where we lost lock. We didn't pursue this very far, since I was seeing the 50Hz oscillation that Koji and I saw the other day. I increased the CARM gain from 6 to 10, and that seemed to help significantly. Also, messing with the PRMI loops a bit helped. Q increased the pole frequency in FM 5 for both MICH and PRCL from 2k to 3k. While he had Foton open, he made sure that all of the LSC DoF filters use the z:p notation.

I then did a few trials of trying to transition CARM over to normalized REFL11I. Now that I'm typing, it occurs to me that I should have checked REFL11's demod phase. Ooops. Anyhow, using the phase that was in there, I turned on a cal line pushing on ETMs CARM, and found that using -0.002*REFL11I / (TRX + TRY) was the right set of elements. I also put an offset of 0.05 into the CARM CESAR RF place, and started moving. I tried several times, but never got past about 30% normalized REFL11 and 70% ALS comm.

During these trials, Q and I worked also on tweaking up the PRMI lock. As mentioned last night, PRCL FM3 eats too much phase (~30deg at 100Hz!), so I don't turn that on ever. But, I do turn on FM1 (which is new tonight), FM2, 6, 8 and 9. FM8 is a flat gain of 0.6 that I use so I can have higher gain to make acquisition faster, but immediately turn the gain down to keep the loop in the center of the phase bubble. MICH needed a lowpass, so in addition to FM2, I am now also triggering FM 8, which is a 400Hz lowpass that was already in there.

Now, my MICH gain is 2.4, with +0.75*REFL165Q, and PRCL gain is -0.02 with -3*REFL165I. Triggering for both MICH and PRCL is 1*POP22I + 5*TRX with 50 up, 0.1 down.

In my latest set of locks, I have been losing lock semi-regularly due to a 100Hz oscillation in either the PRCL or MICH loops. If I watch the spectra, most times I take a step in CARM offset reduction, I get a broad peak in both the MICH and PRCL error signals. Most of the time, I stay locked, and the oscillation dies away. Sometimes though it is large enough to put me out of lock. I'm not sure yet where this is coming from, but I think it's the next thing that needs fixing.

Here is a shot of the spectra just as one of these 100Hz oscillations shows up. The dashed traces are the nominal error signals when I'm sitting at some CARM offset, and the solid traces are just after a step has been made. The glitch is only happening in the PRMI, not CARM and DARM.

10737

Wed Nov 26 22:24:28 2014

DARM loop improved, other work

[Jenne, Koji]

We have done several things this evening, which have incrementally helped the lock stability. We are still locking CARM and DARM on ALS, and PRMI on REFL165.

Saw peaks in CARM error signal at 24Hz and 29 Hz, so put in moderate-Q resonant gains.
DARM at low frequency was much noisier than CARM. We discovered that we had put in a nice boost at some point for CARM in FM1, but hadn't transferred that over to DARM. Copying FM1 from CARM to DARM (so replacing an integrator with a boost below ~10Hz) dropped the DARM noise down to match the CARM noise at low frequencies.
Koji noticed that we were really only illuminating one quadrant of the Xend QPD, so we aligned both trans QPDs. Also, I reset the transmission normalization so that all 4 diodes (Thorlabs and QPDs at each end) all read 1 with good alignment.
We've got some concerns about the ASS. It needs some attention and tuning.
- The X ASS needs an overall gain of about 0.3. This may be because I forgot to put the new lower gains into the burt restore after Rana's oplev work, or this may be something new.
- When Koji did a very careful arm alignment, we turned on the Y ASS and saw it methodically reduce the transmitted power. Mostly it was moving ETMY in yaw. Why is the DC response of the ASS not good? The oplev work shouldn't have affected DC.
- We don't like the way the ASS offloads the alignment. Maybe there's a better way to do it overall, but one thought is to have an option to offload (for long-term alignment fixing, so maybe once a day) and another option to just freeze the current output (for the continual tweak-ups that we do throughout the evening). We'd want the ASS to start up again with these frozen values, and not clear them.
ETMY was being fussy, in the same way that ETMX had been for the last few months. I went down to squish the cables, and found that it was totally not strain-relieved, and that the cable was pulling on the connector. I have zip tied the cable to the rack so that it's not pulling anymore.
At high arm powers, it is hard to see what is going on at the AS port because there is so much light. Koji has added an ND filter to the AS camera so that we can more easily tweak alignment to improve the contrast.

Something that has been bothering me the last few days is that early in the evening, I would be able to get to very high arm powers, but later on I couldn't. I think this has to do with setting the contrast at the AS port separately for the sideband versus the carrier. I had been minimizing the AS port power with the arms held off resonance, PRMI locked. But, this is mostly sideband. If instead I optimize the Michelson fringes when the arms are held with ALS at arm powers of 1, and PRM is still misaligned, I end up with much higher arm powers later. Some notes about this though: most of this alignment was done with the arm cavity mirrors, specifically the ETMs, to get the nice Michelson fringes. When the PRM is restored and the PRMI locked, the AS port contrast doesn't look very good. However, when I leave the alignment alone at this point, I get up to arm powers above 100, whereas if I touch the BS, I have trouble getting above 50.

Around GPS time 1101094920, I moved the DARM offset after optimizing the CARM offset. We were able to see a pretty nice zero crossing in AS55, although that wasn't at the same place as the ALS diff zero offset (close though). At this time, the arm powers got above 250, and TRY claimed almost 200. These are the plots below, first as a wide-view, then zoomed in. During this time, PRCL still has a broadband increase in noise when the arm powers are high, and CARM is seeing a resonance at a few tens of Hz. But, we can nicely see the zerocrossing in AS55, so I think there's hope of being able to transition DARM over.

Now, the same data, but zoomed in more.

During the 40m meeting, we had a few ideas of directions to pursue for locking:

Look into using POX or POY as a proxy for POP and instead of REFL, for CARM control. Maybe we have some nice juicy SNR.
Check the linearity of our REFL signals by holding the arms on (or close to) resonance, then do a swept sine exciting CARM ctrl and taking a transfer function to the RF signals.
Q is going to look into the TRX QPD, since he thought it looked funny last week, although this may no longer be necessary after we put the beam at the center of the QPD.
Koji had a thought for making it easier to blend the CARM error signals. What if we put a pole into the ALS CARM signals at the place where the final coupled cavity pole will be, and then compensate for this in the CARM loop. Since any IR signals will naturally have this pole, we want the CARM loop to be stable when it's present.
Diego tells us that the Xarm IR beatnote is basically ready to go. We need to see how big the peak is so we can put it into the frequency counter and read it out via EPICS. The freq counter wants at least -15dBm, so we may need an amplifier.

10743

Mon Dec 1 17:43:22 2014

Reset Yarm trans normalization

After Koji and I reset the transmission normalizations last Friday, he did some alignment work that increased the Yarm power. So, I had set the transmission normalization when we weren't really at full Yarm power. Today I reset the normalization so that instead of ~1.2, the Y transmission PDs read ~1.0.

10746

Tue Dec 2 02:44:45 2014

Tried cav pole compensation trick - fail

[Jenne, Diego]

First, random notes:

saw a violin peak in CARM / DARM at 638.0Hz. Assumed it was one of the ETMs, even though it doesn't match any of the frequencies in our handy-dandy chart: wiki resonances
- Put an extra notch in the ETM violin filters.
- Just now realized that I was actuating MC2 at the time for CARM (although 638 is also not what we have in the chart for MC2). The MC2/ETM violin filters should be shared between eachother.
Measured CARM and DARM loops on ALS comm and diff, gains should be 8, not 6. Fixed in Lock_ALS_CARM_and_DARM script.
MC has been fussy tonight. I started actuating CARM on ETMs, and that helped, but we've still had several unexplained MC locklosses.
- PC and FSS Slow are okay right now, but they have been mad earlier tonight. Do we need to check the PID tuning for FSS slow?
When I first started locking this evening, I was able to hold nice high arm powers (with the usual factor of 2+ RIN), so the IFO seemed okay except for the fussy MC.

Koji suggested last week that we put a cavity pole filter into the ALS error signals, and then compensate for that in the CARM and DARM servos. The idea is that any RF signals we want to transfer to will have some kind of frequency dependence, and at the final zero CARM offset that will be a simple cavity pole.

I put a pole at 200 Hz, with a zero at 6 kHz into the LSC-ALS[X,Y] filter banks in FM1, and then also put a zero at 200 Hz with a pole at 6 kHz into both the CARM and DARM servos at FM7. Ideally I wouldn't have the 6kHz in there, but the compensation filter in the CARM/DARM servos needs a pole somewhere, so I put in the zero in the ALS signals so that they match. Foton thinks that multiplying the two filters should give a flat response, to within 1e-6dB and 1e-6 deg.

We can lock CARM and DARM on ALS with the new filters, but it seems to be not very stable. We've measured transfer functions in both configurations, and between 50-500Hz, there is no difference (i.e., our matching filters are matching, and cancelling each other out). We sometimes spontaneously lose lock when we're just sitting somewhere with the new configuration, and we cannot run any find IR resonance scripts and stay locked. We've tried the regular old script, as well as Diego's new gentler script. We always fail with the regular script during the coarse scan. With Diego's script, we made it through the coarse scan, but spontaneously lost lock while the script was calculating the location of the peak. So, we determine that there is something unstable about the new configuration that we don't understand. Turning off all the new filters and going back to the old configuration is just as robust as always. Confusing.

10747

Wed Dec 3 01:18:15 2014

diego

IR Resonance Script Status

Tonight I started testing a new method for the fine scan:

the idea is to use the zero crossings of the PO*11_ERR_DQ signals after (or as an alternative of) the fine scan, but such signals are quite dirty, so I need to find some good way to smooth/filter them;
I didn't manage to make many tests, because:
- once arms were locked fine with ALS, the CARM & DARM lock wasn't very robust, in both acquiring and maintaining lock;
- during the night, the slow OFSs of the arms misbehaved, and at least once per arm they raised their warning box (independently from each other, and it was hastily recovered), even for values that had been perfectly fine before; I am confused about this;
- as a result, notwithstanding many tries, the beatnotes are gone;
I have enough information to push the script a little further, but I'll do more testing soon;

10748

Wed Dec 3 01:46:12 2014

Koji

Tried cav pole compensation trick - fail

Where did these 200Hz, 6kHz come from?

I wonder what are the correct filters to be incorporated in the filter banks for the cav pole compensarion.

Facts:

1. ALS Common and Diff have the cavity pole for the green (fcav_GR)

2. IR DARM has the cavity pole of the arms for IR (fcav_IR_DARM)

3. IR CARM (REFL, POP, POX, or POY) has the double cavity pole (fcav_IR_CARM)

Calculations:

1. T(ITM_GR) = 1.094%, T(ETM_GR) = 4.579% => F=108.6 (cf. https://wiki-40m.ligo.caltech.edu/Core_Optics)
L = 37.8 m (cf. http://nodus.ligo.caltech.edu:8080/40m/9804)
=> fcav_GR = c /( 4 L F) = 18.3 kHz ... ignore

2. T(ITM_IR) = 1.384%, T(ETM_IR) = 13.7ppm => F=450.4
=> fcav_IR_DARM = 4.40 kHz

3. The common cavity pole is lower than fcav_IR by factor of power recycling gain.
=> fcav_IR_CARM = fcav_IR / (P_TR * T_PRM)
P_TR is normalized for the locked arm cavity with the PRM misaligned.
T_PRM is 5.637%

e.g. for the TR of 100, fcav_IR_CARM = 4.40/(100*0.05637) = 780Hz

(IR CARM) o--| +--[CARM 780Hz zero / ??? pole] (ALSX) o--| |-[ALS C 780Hz pole]----| | M | (ALSY) o--| |-[ALS D 4.40kHz pole]--| +--[DARM 4.40kHz zero / ??? pole] (IR DARM) o--|
???Hz pole is to ensure the servo filters does not have infinite gain at f=infinite, but in practice we probably can ignore it as long as it is provided by a roll-off filter

10749

Wed Dec 3 02:01:57 2014

Koji

IR Resonance Script Status

The other night (before the holidays), I tried ALS offset tuning with IR POX/POY signals and it worked pretty good.
I didn't need to tune the offset after the scanning script stopped.

Once we are at the foot hill of the main resonance, I ran something like

ezcaservo -r C1:LSC-POX11_I_MON C1:LSC-ALSX_OFFSET -g -0.003 &
ezcaservo -r C1:LSC-POY11_I_MON C1:LSC-ALSY_OFFSET -g -0.003 &

(... I am writing this with my memory. I could be wrong but conceptually the commands looked like these)

10750

Wed Dec 3 08:36:49 2014

Thu Dec 4 02:59:05 2014

[J,Q]

After some housekeeping (ASS is wonky, alignment of X green beat was bad, tuning of demod angles, fm gains for REFL165), we were able to bring the PRFPMI up to arm powers of 8 very stably.

We were keeping an eye on the DARM OLG, to make sure the gain was correct. We then saw a bump around 120Hz. Here is the bump.

Changing CARM offset changes its amplitude. Maybe it's a DARM optical spring. It didn't occur to me until after we lost lock that we could have tweaked the DARM offset to move it around if this was the case.

Unfortunately, due to some unexplained locklosses, we weren't able to get back into a state to measure this more... which is annoying. During that stable lock, Jenne stated that PRCL and DARM noises were looking particularly good.

We may want to tweak the way we handle the transmission PD handoff; maybe we want to force the switch at a certain place in the carm_up script, so that we're not flipping back and forth during an IR handoff; I think this may have been responsible for a lock loss or two.

10755

Thu Dec 4 03:09:06 2014

Bump in Darm Plant: Lockloss after measurement

We were sitting around arm powers of 6, and that loop measurement had finished. I was about to go down to arm powers of 5ish, but we lost lock. I'm not sure why. There's some slow stuff going on in some of the servos, but nothing jumps out at me as a loop oscillation. It does however kind of look like the PRMI lost lock just before the arm powers went down? Perhaps this somehow triggered a lockloss?

The time is 1101721675.

Wide view plots:

Zooms:

We're stopping for tonight because ETMX is back to its lame-o jumping around. I went in and squished the cables, but it's still happening.

Also, the FSS PC drive has been high the last few minutes (only starting after we quit for the night). When the MC re-locks, it sounds like an ocean wave dying out as the noise goes down a little bit. But, after a few minutes, it'll get mad again and unlock the MC.

Also, also, I noticed this on Monday with Diego, but the LSC-ALS[x,y] filter module gains sometimes mysteriously get set to zero. WTF? Eric and I have both independently checked, and we cannot find a single script in the scripts directory with the string "LSC-ALS", so we aren't deliberately changing those. Does anyone know what might be going on here?

10785

Thu Dec 11 18:12:46 2014

(Fixed) Y end whitening board

Quote:

Gain mystery

- It was not sure how the whitening gains have been given.

- The corresponding database entry was found in /cvs/cds/caltech/target/c1auxey/ETMYaux.db as

grecord(ao,"C1:ASC-QPDY_S1WhiteGain") grecord(ao,"C1:ASC-QPDY_S2WhiteGain") grecord(ao,"C1:ASC-QPDY_S3WhiteGain") grecord(ao,"C1:ASC-QPDY_S4WhiteGain")

- The gains for S2-S4 were set to be 30. However, C1:ASC-QPDY_S1WhiteGain was set to be 8.62068.
And it was not writable.

- After some investigation, it was found that the database was wrong. The DAC channel was changed from S100 to S0.
The corrected entry is shown here.

grecord(ao,"C1:ASC-QPDY_S1WhiteGain") { field(DESC,"Whitening gain for QPDY Seg 1") field(DTYP,"VMIVME-4116") field(OUT,"#C0 S0 @") field(PREC,"1") field(EGUF,"42") field(EGUL,"-22") field(EGU,"dB") field(LINR,"LINEAR") field(DRVH,"30") field(DRVL,"-10") field(HOPR,"30") field(LOPR,"-10") }

- Once c1auxey was rebooted, the S1 whitening gain became writable. Now all of the channels were set to be +30dB (max).

This exact situation was happening at ETMX. I did the exact same change to the database, now I can read and write all four gain segments.

10786

Thu Dec 11 22:44:23 2014

All of the QPDX matrix fields had a missing underscore in them. So I committed all of the c1asc screens to the SVN (because no one but me and Jamie seems to be able to remember to do this).

Then I did find/replace on the QPDY screen and saved it over the QPDX screen and committed the new thing to SVN as well. Values are now accessible.

10796

Sat Dec 13 14:26:36 2014

Mismatched gains on ETMY Transmon QPD

Yesterday, we were seeing anomalously high low frequency RIN in the y-arm (rms of 4% or so). I swung by the lab briefly to check this out. Turns out, despite TRY of 1.0, there was reasonable misalignment. ASS with the excitation lowered by a factor of two, and overall gain at 0.5 or so aligned things to TRY=1.2, and the RIN is back down to ~0.5% I reset the Thorlabs FM to make the power = 1.0

I then went to center the transmitted beam on the transmon QPD. Looking at the quadrant counts as I moved the beam around, things looked odd, and I poked around a little...

I strongly suspect that we have significantly mismatched gains for the different quadrants on the ETMY QPD.

Reasoning: With the y-arm POY locked, I used a lens to focus down the TRY beam, to illuminate the quadrants individually. Quadrants 2 and 3 would go up to 3 counts, while 1 and 4 would go up to 0.3 and 0.6, respectively. (These counts are in some arbitrary units that were set by setting the sum to 1.0 when pitch and yaw claimed to be centered, but mismatched gains makes that meaningless.)

I haven't looked more deeply into where the mismatch is occurring. The four individual whitening gain sliders did affect the signals, so the sliders don't seem sticky, however I didn't check the actual change in gains. Will the latest round of whitening board modifications help this?

Hopefully, once this is resolved, the DC transmission signals will be much more reliable when locking...

10803

Tue Dec 16 01:50:27 2014

This is ridiculous.

How many RGs can I fit into one button???

10804

Tue Dec 16 03:43:09 2014

[Jenne, Rana, Diego]

After deciding that the Yend QPD situation was not significant enough to prevent us from locking tonight, we got started. However, the PRMI would not acquire lock with the arms held off resonance.

This started some PRMI investigations.

With no arms, we can lock the PRMI with both REFL55 I&Q or REFL165 I&Q. We checked the demod phase for both Refl 55 and 165. REFL55 did not need changing, but REFL165 was off significantly (which probably contributed to the difficulty in using it to acquire lock). I didn't write down what REFL165 was, but it is now -3 degrees. To set the phase (this is also how Rana checked the 55 phase), I put in an oscillation using the sensing matrix oscillators. For both REFL165I and 165Q, I set the sensing matrix demod phases such that all of the signal was in the I phase (so I_I and Q_I, and basically zero in I_Q and Q_Q). Then, I set the main PD demod phase so that the REFL165Q phase (the Q_I phase) was about zero.

Here are the recipes for PRMI-only, REFL55 and REFL165:

Both cases, actuation was PRCL = 1*PRM and MICH = (0.5*BS - 0.2625*PRM). Trigger thresholds for DoFs and FMs were always POP22I, 10 up and 0.5 down.

REFL55, demod phase = 31deg.

MICH = 2*R55Q, gain = 2.4, trig FMs 2, 6, 8.

PRCL = 12*R55I, gain = -0.022, trig FMs 2,6,9.

REFL165, demod phase = -3deg.

MICH = -1*R165Q, gain = 2.4, trig FMs 2,6,8.

PRCL = 2.2*R165I, gain = -0.022, trig FMs 2,6,9.

These recipes assume Rana's new resonant gain filter for MICH's FM6, with only 2 resonant gains at 16 and 24 Hz instead of a whole mess of them: elog 10803. Also, we have turned down the waiting time between the MICH loop locking, and the filters coming on. It used to be a 5 second delay, but now is 2 sec. We have been using various delays for the PRCL filters, between 0.2s and 0.7s, with no particular preference in the end.

We compared the PRCL loop with both PDs, and note that the REFL 165 error signal has slightly more phase lag, although we do not yet know why. This means that if we only have a marginally stable PRCL loop for REFL55, we will not be stable with REFL165. Also, both loops have a non-1/f shape at a few hundred Hz. This bump is still there even if all filters except the acquisition ones (FM4,5 for both MICH and PRCL) are turned off, and all of the violin filters are turned off. I will try to model this to see where it comes from.

To Do list:

Go back to the QPDY situation during the daytime, to see if tapping various parts of the board makes the noise worse. Since it goes up to such high frequencies, it might not be just acoustic. Also, it's got to be in something common like the power or something, since we see the same spectra in all 4 quadrants.

The ASS needs to be re-tuned.

Rana was talking about perhaps opening up the ETMX chamber and wiggling the optic around in the wire. Apparently it's not too unusual for the wire to get a bit twisted underneath, which creates a set of places that the optic likes to go to.

Diego is going to give us some spectra of the MC error point at various levels of pockel's cell drive. Is it always the same frequencies that are popping up, or is it random?

10806

Tue Dec 16 20:51:18 2014

Quote:

[...]

Diego is going to give us some spectra of the MC error point at various levels of pockel's cell drive. Is it always the same frequencies that are popping up, or is it random?

I found out that the Spectrum Analyzer gives bogus data... Since now is locking time, tomorrow I'll go and figure out what is not working

10809

Wed Dec 17 13:14:38 2014

Quote:

However, the PRMI would not acquire lock with the arms held off resonance.

This is entirely my fault.

Last week, while doing some stuff with PRY, I put this filter in SUS_PRM_LSC, to stop some saturations from high frequency sensing noise

After the discussion at today's meeting, it struck me that I might have left it on. Turns out I did.

20 degree phase lag at 200Hz can explain the instability, some non-flat shape at few hundreds of Hz explains the non 1/f shape.

Sorry about all that...

10810

Wed Dec 17 14:42:13 2014

EricQ's crazy people filter has been deleted. I'm trying to lock right now, to see if all is well in the world.

10814

Thu Dec 18 02:23:34 2014

[ericq, Diego]

Some locking efforts tonight; many locklosses due to PRC angular motion. Furthest progress was arm powers of 15, and I've stared at the corresponding lockloss plot, with little insight into what went wrong. (BTW, lastlock.sh seems to catch the lock loss reliably in the window)

CARM and DARM loops were measured not long before this lock loss, and had nominal UGFs (~120Hz, ~20deg PM). However, there was a reasonably clear 01 mode shape at the AS camera, which I did nothing to correct. Here's a spectrum from *just* before the lockloss, recovered via nds. Nothing stands out to me, other than a possible loss of DARM optical gain. (I believe the references are the error signal spectra taken in ALS arms held away + PRMI on 3F configuration)

The shape in the DARM OLTF that we had previously observed and hypothesized as possible DARM optical spring was not ever observed tonight. I didn't induce a DARM offset to try and look for it either, though.

Looking into some of the times when I was measuring OLTFs, the AS55 signals do show coherence with the live DARM error signal at the excitation frequencies, but little to no coherence under 30Hz, which probably means we weren't close enough to swap DARM error signals yet. This arm power regime is where the AS55 sign flip has been modeled to be...

A fair amount of time was spent in pre-locking prep, including:

The usual X green beat alignment tweak, to make the X ALS control not terrible
Both ITM oplevs were centered
For some reason, I had to flip the signs of the REFL165 matrix elements for the PRMI...
"Restore PRMI SB" has ASC automatically enabled, which results in unexpected kicks even with LSC off, which caused a few minutes head-scratching

10818

Fri Dec 19 15:59:49 2014

I swapped out one of the channels on Q's lockloss plotter - we don't need POP22Q, but I do want the PC drive.

So, we still need to look into why the PC drive goes crazy, and if it is related to the buildup in the arms or just something intrinsic in the current FSS setup, but it looks like that was the cause of the lockloss that Q and Diego had on Wednesday.

10856

Tue Jan 6 03:09:17 2015

diego

PRFPMI status & IFO status

[Jenne, Rana, EricQ, Diego]

Tonight we worked on getting the IFO back in a working status after the break, and then tried some locking.

the MC is behaving better, it could stay in a stable condition for hours, even if a couple of times it lost lock, and one of them persisted for a little time;
we managed to get to arm power of 20ish, before losing lock (this happened a couple of times);
the main thing seems to be that we have only ~ 20 degrees of phase margin at UGF for DARM, which is evidently too little;
one hypothesis is that DARM may change sign due to some weird length/angular interaction, and that this messes up the actuation causing the lockloss;
one other possibility is that maybe, when arm power rises, there are some weird flashes that go back to the MC and then cause the locklosses, but this has to be verified;
attached there is a plot of the last lockloss (and a zoom of it), which seems to point at DARM as the culprit;

We left the IFO uncontrolled and in a "flashy" state so that tomorrow we can look into the "back-flashing to the MC" hypothesis.

10857

Tue Jan 6 03:13:09 2015

PRFPMI status & IFO status

Two plots from tonight:

Lock loss. Based on the fact that it looked like the DARM servo was running away, Rana posited an effective sign flip in the DARM loop, perhaps due to a parasitic angular feedback mechanism.

While Jenne was probing the IFO at lower powers, we noticed a sudden jump in ASDC. Found the GPS time and fed it to the lockloss plotter. Seems fairly evident that some sudden ETMX motion was to blame. (~2urad kick in yaw)

10860

Wed Jan 7 02:54:09 2015

Fiddling with DARM filters

One of the things that we had talked about last night was the totally tiny amount of phase margin that we have in the CARM and DARM loops. DARM seemed to be the most obnoxious loop last night, so I focused on that today, although the CARM and DARM loops are pretty much identical.

(Q tells me via email that the phase budget has the same ~14 degree discrepancy between what we expect and what we measure as his estimate last night. However, the Caltech network issues prevented his posting an elog.)

So, we definitely need to figure out where this 14 deg is going, but for now, I wanted to see if I could recover a couple of extra degrees just by modifying the filters.

The original filters do seem to eat a lot of phase:

The short version of the story is that I didn't leave the filters changed at all. I reverted back to the last version of the filter file from Monday night, so currently everything is as it was.

I tried increasing the Q of the zeros on the cyan and brown filters, which would sacrifice some gain at ~20 Hz, but hopefully win us 10+ degrees of phase. This gave me a dip of about a factor of 2 between the new and old filters (all servo filters combined added up to this factor of 2 in magnitude) between ~20Hz - 70Hz.

When we were locked using DARM for just the Yarm (for the UGF servo commissioning), I took a spectra of the error signal (which was POY) as a reference, then loaded in my new filters. For the most part, the spectra didn't change (which is good, since the magnitude of the filter didn't change much.). The spectra was bigger though between 50-70Hz, in kind of a sharp bandpass-looking shape that I wasn't expecting. I don't know exactly why that's happening.

Anyhow, we tried the new filters once or twice with the full IFO, but kept losing lock. Since I clearly haven't put in enough thought yet for these (particularly, how much suppression do we really need? what are our requirements???), I reverted back to the filter file from last night. We continued locking, and checking out the new UGF servo that Diego is elogging about.

10861

Wed Jan 7 02:56:15 2015

[Jenne, Diego]

Today we began implementing the UGF Servos. Things we did:

we updated the LSC model with both DARM and CARM servos, and moved them from after the control system to before it, at the level of the error signal;
we updated the medm screens; new buttons are located in the main LSC screen;
we started commissioning the DARM servo, at first using DARM for the lock of the single Y arm, then we moved on to the PRFPMI lock and the usual transition from ALS to Transmission;
although we had several lock losses during the night, we managed to tweak the parameters of the DARM UGF servo (phases, excitation, gains), which now seems to work sufficiently fine;
the filters added to the I and Q filter banks are a single lowpass in each, while the only filter in the main servio is a standard integrator;
we don't have a step response at the moment, but we can say that the settling time of the servo is in the range of 10 seconds;
we updated the ALSdown.py and ALSwatch.py scripts with a call to a new UGFdown.py script; this script, located in the scripts/PRFPMI folder, takes care of disabling the servos and putting the excitation to zero in case of a lock loss; re-enablement of such things must be done manually;

10862

Wed Jan 7 03:04:13 2015

TRY (thorlabs pd) weird noise

[Jenne, Diego, Rana]

This is a note about work done last night.

We were starting to lock, and saw glitches in the Thorlabs TRY PD about once every 1/60th of a second. It is not a sine wave, so it is not 60Hz line noise directly. It looks like this:

Rana pointed out that this looks like it could be from a power supply that is converting AC to DC.

We went down to the Yend, and noticed some weird symptoms. So far, we do not know where the noise is coming from. Rather, we are just using the QPD for locking.

* The noise comes and goes, particularly if someone is moving around at the end station.

* Moving the Thorlabs power supply farther from the HeNe power supply didn't do much. Turning off and disconnecting the HeNe supply didn't make the noise go away, so we conclude that it is not the HeNe's fault.

* We suspected the loops of excess cable that were sitting on top of iscey, but moving the coils away from the computer did not make the noise go away.

* We removed a few disconnected BNC cables that were near or touching the end table, but that didn't fix things.

* We disconnected the PD's signal cable and pulled it out of the table enclosure, and then put it back. Noise was gone when cable was disconnected (good), but it was back after plugging the cable back in.

* The noise still comes and goes, but we don't have to use the Thorlabs PD for locking, so we leave it for another day.

RXA: also moved the Thorlabs power supply to a different power strip and tried putting it closer/farther to the Uniblitz shutter controller. Another suspect is that its some PWM type noise from the doubler crystal temperature driver. Need to try turning off the heater and the Raspberry PI to if it effects the noise.

10863

Wed Jan 7 03:09:15 2015

PRFPMI status & IFO status

As a warm-up after the holidays, before the real locking began, I installed 1064nm bandpass filters in front of the transmission QPDs to eliminate the stray green light that is there.

The Yend had threads epoxied to it, so that end should be good. Steve is going to repeat that for the Xend QPD at some point. Right now, the filter is just on a lens mount about 2cm away from the PD box aperture, since that's as close as I could get it.

Also, while I was at the Xend, I noticed that the transmission camera is gone. I assume that it was in the way of Manasa's fiber work, and that it'll get put back somehow, sometime. She elogged that she had removed it, but I mistakenly thought that it was already replaced. We don't use that camera much, so I'm not worried.

10864

Wed Jan 7 09:44:33 2015

As Jenne mentioned, I created a model of the DARM OLG to see why we have so little phase margin. However, it turns out I can explain the phase after all.

Chris sent me his work for the aLIGO DARM phase budget, which I adapted for our situation. Here's a stacked-area plot that shows the contributions of various filters and delays on our phase margin, and a real measurement from a few days ago .

This isn't so great! Informed by Chris's model, the digital delays look like: (Here I'm only listing pure delays, not phase lags from filters)

64k cycle (End IOP)
16k cycle (End isce[x/y])
16k cycle x 2 (end to LSC through RFM) [See ELOG 10811]
16k cycle (LSC)
16k cycle (LSC to SUS through dolphin) [See ELOG 9881]
16k cycle (SUS)
16k cycle x2 (SUS to end through RFM)
16k cycle (End isce[x/y])
64k cycle (SUS IOP)
DAC zero order hold

This adds up to about 570usec, 20.5 degrees at 100Hz, largely due to the sheer number of computer hops the transmission loops involve.

As a check, I divided the measured OLG by my model OLG, to see if there is any shape to the residual, that my model doesn't explain. It looks like it fits pretty well. Plot:

So, unless we undertake a bunch of computer work, we can only improve our transmission loops through our control filter design.

Everything I used to generate these plots is attached.

10865

Wed Jan 7 11:20:22 2015

Steve