I've checked out cdsutils-274 to /opt/rtcds/cdsutils, and updated the /ligo/apps/ligoapps-user-env.sh to have the newer machines use it by default. This was to gain access to the cdsutils.Step methods for use in the smooth ASS handoffs script.
I noticed some weird behavior on the ETMY oplev that led me to check them all out.
The short of it is that the ETMY oplev has a pretty small angular range, compared to the displays and other oplevs. I measured how much angular motion each oplev can sense before the beam no longer hits all four quadrants (thus losing the ability to sense). This could account for some of the additional angular motion of the mirrors... maybe.
Also, some of the QPD quadrants had offsets as big as 400 counts, thus distorting the zero point. Anyways, here are the angular ranges of each QPD, assuming the current urad/cnt calibrations are valid.
(Note: ITMX's oplev pitch and yaw is almost 30 degrees off of the alignment sliders' pitch/yaw coordinates. Steve tells me this is due to the tight nature of getting the oplev beam to the mirror without clipping.)
I wrote a script to zero all of the QPD quadrants' offsets (it lives in /scripts/OL) and have used it successfully. The oplev laser must be off before using it.
I have measured the current boosted MC CLG below 100kHz with an SR785. Swept sine only could get me down to 10kHz, but I was able to get down to 5kHz with a noise-injection measurement.
I am attaching the SR785 outputs, which are in dB and Degrees. Additionally I pruned the areas of bad coherence out of these, and merged them to provide data files for the CLG and OLG in Real,Imaginary format.
I did some further measurements, to try and see what corresponds to what. In the end I performed four measurements:
I then converted OLGs to CLG and vice-versa with CLG = 1/(1-OLG)
Here are two plots showing the measured and inferred loop TFs for both closed and open.
The best agreement seems to be between the directly measured OLGs. Maybe I did something weird with the CLG measurements, or input impedances are distorting things ...
All data is attached, along with code used to generate the plots.
Here's the magnitude plot of the board TF. As mentioned above, this was done with Marconi+Scope, so we were not able to get the phase of this transfer function.
Oddly enough, the bump that I saw is not included in Minicircuit's data on the SCLF-5.
# F(Hz) RMS(mV)
I took over the IFO, after Jenne's locking efforts, which included manual alignment, since the ASS was doing bad things.
For whatever reason, the Yarm ASS TT gains needed to be flipped back to go in the right direction. I've restored the old BURT snap file, and the ASS seems to work for now.
Furthermore, I added some FMs to the Yarm ASS to be able to ramp down gains, to be done as new offsets are ramped in, so that a smooth offset transition is possible. The new version of the script works reasonably, but could be smoother still... Once I iron this out, I'll do the same change to the Xarm, and update the buttons.
In any case, I was able to run ASS on both arms; single arm lock maxed out at around 0.85, maybe because we're only getting 0.78 from the PMC and 16k from the MC? I then aligned and locked the PRM, then reentered the oplevs on all of the PRMI optics. Oddly, the ETMs were at single uRads on their oplevs.
With this arm alignment, I was able to get the green TRX to ~0.55, and thus the beatnote to around -25dBm, which is still lower than we'd like. I didn't touch the Y green alignment, though it is pretty bad, at transmission of below 0.2 when "locked" on the 00 mode.
When I try to lock things, the initial ALS CARM and DARM locking seems to go fine, actuating on the ETMs for both DoFs, but ETMX is getting kicked during the resonance search every time. Maybe improving green alignment / increasing beatnote amplitudes will hopefully help some.
I'm leaving the interferometer with the PRM aligned, so that all optics (except SRM) are near the center of their oplev range. I'm curious as to what their variance will be over the next day; this can inform whether we need to improve the ETMY oplev's angular range or not.
Here's an 12 hour minute-trend of all of the oplevs. The worst offenders are ITMY pitch and yaw, and ITMX pitch.
Additionally, ETMY's yaw range is +-30urad, and here we see it wandering by 10 urad in a half day. We probably need more range.
I made some measurements of the FSS box today, to have TFs for a loop model, but also to see what the difference between the different inputs was.
As a reminder, the FSS box takes the error signal from the MC servo, does some filtering, and sends out two outputs: one to the laser PZT via KojiBox and Thorlabs HV amplifier, and one to be summed with the PMC modulation signal to the PC. Rana found the schematic at D040105
The MC error signal currently enters via a port called "IN1", but there is also a "Test 1 in," which experiences different filtering. I measured the TFs from each of these inputs to both the FAST and PC outputs. There is also an IN2, that is added after the offset point, but was not able to make a good measurement, for reasons unknown. From these TFs, I inferred the difference between the PC and FAST path, as well as the difference between IN1 and Test 1 in.
Specifically, I plugged the cable that is usually connected to the MC servo output, labelled "TO FSS BOX", into the RF out of the AG4395. I then took a BNC cable from the FAST out, or PC out, and fed it into a mini circuits DC block (BLK-89-S+), and then into input A, after checking on a scope that the signal was roughly zeroed and not too huge. Unbeknownst to me at the time, the PC drive output can be pretty big, and could potentially fry the analyzer's input. Fortunately, I think I avoided this fate.
A ~1.3 MHz bump can be seen here, which would conspire with the bump in the demod board I measured yesterday, to steal even more phase around 1MHz. Maybe we can modify the FSS box to help our gain peaking situation out.
The data is attached.
[Jenne, Rana, ericq]
No luck locking tonight, as spent a while trying to figure out the complete absence of the green beatnotes. Long story short, we ended up having to adjust the pointing on the PSL table.
Unrelated to this, we also turned on the noise eater on the PSL laser because why not.
We hooked the BBPDs directly up to a 300MHz scope to try to see the beat as it happened. We witnessed a very strange intermittent ~800MHz oscillation on the Y BBPD, and weirder still, on both the RF and DC outputs of the PD, and the frequency was independent of the laser temperatures. This is to be investigated in the future, but was not related to the beat note state.
Some progress was made when we took some components out, and looked at the far field of the PSL-Ygreen overlap, and saw some misalignment, and corrected it. Putting the end laser temperature in the usual area allowed the beat note to be found, with the eventual amplitude of ~-40dBm directly out of the BBPD. The Y green alignment was pretty bad throughout, so this can be improved to bring the beat amplitude up. We should also check and make sure we're well aligned to the SHG with the PSL light. We're leaving the X beat for tomorrow, now knowing that we should be able to get it with careful alignment.
Based on the game plan, I have created a slew of updated pretty plots about our signals and loops.
First: With measured arm losses, when do we start to see REFL DC dip? At what arm buildup powers?
I updated my MIST model with the arm losses I've measured (Y:130ppm, X:530ppm), and some measured transmissions from the wiki, vs. the design parameters, as I used to have. Here is the DC sweep plot which is now hanging up in the control room.
In this plot, I also calculated what MIST thinks the full arm power buildup will be as compared to our single arm locking, and I get something of order 200, rather than the 600 we've tossed around in discussions. Nothing else is very different in this plot from the old version; though the REFLDC dip is a little bit wider.
Now, here are some radiation-pressure inclusive sensing transfer functions, for the anti-spring case (which in Rob's day was easier to lock for unknown reasons):
Next: Include new AO path TFs into CM model Look at possibilities for engaging AO path
One question answered, but another raised. The offset came from LSC-TRY switching to the ETMY-QPD signal from ETMY-TRY (Hi gain pd).
Q already did the tweak up of the PSL SHG crystal alignment. HE SHOULD ELOG ABOUT THIS. What was the final power of green that you got? Do we have any record of a previous measurement to compare to?
As Jenne mentioned, I did this.
Specifically, I first tweaked the mirror pointing the IR into the SGH in pitch and yaw to maximize the green power, and then adjusted the little set screws on the side of the SHG to maximize further. Power after the harmonic separator was of order 150uW. On the Y Green BBPD, I got ~48uW, instead of the 40uW Rana, Jenne, and myself saw the other night.
now that I look through old ELOGs, I find some posts by Kiwamu saying the power should be around 650uW, and that he was able to get 640uW out. So: I should do this again, systematically, more carefully, etc., etc. (Linked ELOG also states that optimum SHG temperature is alignment dependent...)
A few things that I have neglected to ELOG yet:
scripts/offsets/LSCoffsets is a new script that uses ezcaservo to set FM offsets of our LSC PDs. It still warns about large changes, and lets you revert. It reads the FM gain to pick the right gain for the ezcaservo call.
MC refl DC was all over the place today, and has recently been "fuzzier" on the wall StripTool than I like. I touched the MC2 pointing a little bit, and the WFS seemed to find a sweet spot where the refl got steady back at around and under 0.5. I then ran "offload WFS" to try and stay there.
Incidentally, the PMC transmission drifted up to 0.81 at some point today. This is weird, since not too long ago, we were not able to reach this level even with careful alignment. This coincided with the MC power being back up to ~17k, and arms locking at around 0.95.
Last week I quickly tried cranking up the x-end green modulation frequency to ~1.3MHz (corresponding to a notch in the PZT AM response), and using a 550k lowpass on the mixer output, instead of a 70k, to try to buy more phase and increase the UGF. It didn't work. I didn't have a way to tune the mixer phase angle, and the mixer output was super noisy, but there were instants where I could convince myself that a mode was briefly locked to the arm... I'm going to do the Right Thing and characterize the loop properly, to figure out how to get at least 10kHz of control bandwidth out of these things.
So far today, I've been working with the Y-end green PDH locking. Using a SR560 to roll off the AG4395A output to take a loop measurement at the servo output, I measured the following OLG, and inferred the CLG from it. The SR560 really helped it getting good coherence without introducing a big offset that changes the optical gain, thus distorting the loop shape, etc. etc.
You would think this loop looks pretty good, 10k UGF, and 45 degrees of phase margin, gain peaking is sane, and pretty smooth slope. But, the thing still was flipping out of lock while I measured this.
I suspect shenanigans at >100k. This is motivated by the fact that I've seen some big noise in the error signal around 150k. I don't have a good noise plot right now, because I'm trying to get a scheme going where I stitch together a bunch of 1 decade spectra from the 4395, but the noise floor isn't consistent across each patch (even though the attenuation stays the same, and I confirmed I'm in "noise" mode). I'm working on a loop measurement up there, too, but I haven't been able to get the right filter/amplitude settings yet.
So, even though this plot is not totally correct (read: wrong and bad), I include it just for the sake of showing the big honking spike of noise at ~150K.
Heading to dinner, going to come back for more green fun, but here's a quick update:
Xarm Peak-to-Peak of the PDH signal in the mixer output is about 70mV when GTRX was about 0.4. The sideband-generating function generator has an output of 2V (forgot to note rms or pp)
Yarm Peak-to-Peak of the PDH signal in the mixer output is about 640uV when GTRX was about 0.71. The sideband-generating function generator has an output of 0.091V (forgot to note rms or pp)
The Yarm signal thus correspondingly has a waaay noisier trace. I would've had scope plots to show here, but the scope freaked out about how large my USB drive capacity was and refused to talk to it >:|
This suggests to me that our modulation depth for the Yarm may be much too small, and may be part of our problems with it.
Reasonable amounts of time were spent bending the AG4395 to my will; i.e. figuring out the calibration things Jenne and Rana did, finding the right excitation amplitude and profile that would leave the light steadily locked, and finding the right GPIB incantation for getting spectra in PSD units instead of power units. I'm nearing completion of a newer version of AG4395 scripts that have proper units, and pseudo-log spectra (i.e. logarithmically spaced linear sweeps)
Here is too many traces on one plot showing parts of the OLTF for the x green PDH. One notable omission is the PD response (note to self:check model and bandwidth). The servo oddly seems to have a notch around 100k. My calibration for the CLG injection may not have been perfect, instead of flattening out at 0dB, I had 2dB residual. I tried to correct for it after the fact, assuming that certain regions were truly flat at 0dB, but I want to revisit it to be thorough. I found some old measurements of the Innolight PZT PM response, which claims to be in rad/V, and have included that on the plot.
In the end, the mixer and PZT response make it look like getting over 10kHz bandwidth may be tough. Even finding a good higher modulation frequency to be able to scoot the LP up would leave us with the sharp slope in the PZT phase loss, and could cause bad gain peaking. Maybe it's worth thinking about a faster way of modulating the green light?
Tomorrow morning, I'll calibrate all the noise spectra I have into real units. These include:
However, looking at the floors, it occurs to me that I may have left the attenuation on the input too high, in an effort to protect the input the PDH box, which rails all the time when not locked to a 00 mode, sometimes even with the input terminated or open. It's kind of a pain that the agilent makes it really hard to see the data when you're in V/rtHz mode, because I should've caught this while measuring :/
I used a scope to capture a pdh signal happening, which will let me transform the mixer output into cavity motion. The control signal goes to the innolight PZT with a ~1MHz/V factor. Here are the uncalibrated plots, for now.
Summary: After today's meeting, Gabriele and I looked into the arm loss situation, to see if we should really believe the losses that had been suggested by my previous measurements. We made some observations that we're not sure how to explain, and we're thinking about other ways to try and estimate the losses to corroborate previous findings.
We first looked to see if the ASS had some effective offset, leaving the alignment not quite right. Once ASS'd, we twiddled each arm cavity mirror in pitch and yaw to see if we could achieve higher transmission. We could not, so this suggested that ASS works properly.
We then looked at potential offsets in the Xarm loop. We found that an input offset of 25 counts increased the transmission, but only very slightly. With this offset adjusted, we confirmed the qualitative observation that locking/unlocking the xarm causes a much bigger change in ASDC than doing the same with the harm.
However, we noted that the ASDC data (which is the DC value of the AS55 RFPD) was quite noisy, hovering around 50 counts. Looking at the c1lsc model, we found that we were looking at direct ADC counts, so the signal conditioning was not so great. We went to the LSC rack and stole the SR560 that had been hooked up as a REFLDC offsetter, and used it to give ASDC a gain of 100, and a LP at 100Hz, since we only care about DC values. We then undid the gain in the input FM; and this calmed the trace down a fair bit. The effects due to each arm locking/unlocking was still consistent with previous observations.
At this point, we looked at the arm transmission and ASDC signals simultaneously. Normally, when misaligning a cavity, one would expect the reflected power to rise and the transmission to fall.
However, we saw that when misalignment the Yarm in yaw in either direction, or the Xarm in one direction, both the IR transmission and ASDC would fall. This initially made us think of clipping effects.
So, we checked out the AS beam situation on the AP table. On a card, the beam looks round as we could tell, and the beam spot on AS55 was nice and small. (We tweaked its steering a little bit in pitch to put it at the center of the "falling-off" points) The reflection and transmission falling effect remained.
At this point, we're not really sure what could be causing this effect. After the reflected beams recombine at the BS, the output path is common, so it's strange that this odd effect would be the same for both arms.
Lastly, we discussed other ways that we may be able to see if the Xarm really has ~500ppm loss. Since its transmission is ~1.4%, Gabriele estimated that we may be able to see a ~300Hz difference in the arm cavity pole frequency between the two arms, based on the modification of the cavity finesse due to loss. Since we don't currently have the AOM set up to inject intensity noise, we talked about using frequency noise injection to measure the arm cavity poles, though this would be coupled with the IMC pole, but this could hopefully be accounted for.
A MIST simulation tells me that the green pdh horn-to-horn displacement is about 1.2nm, or ~18kHz. I used this, along with the scope trace attached to the previous post, to calibrate the mixer output at 193419 Hz per V. (EDIT: I was a little too hasty here. What I'm really after is the slope of the zero crossing, which turns out to be almost exactly twice my earlier naïve estimate. See later post for correct spectra)
For the control signal, I assumed a flat Innolight PZT PM response of 1MHz/V. ( Under 10kHz, it is indeed flat, and this is the region where the control signal is above the servo output noise in yesterday's measurements)
Here are all of the same spectra from last night, with the above calibrations.
Going off Jenne's earlier plot, it looks like the in-loop error signal RMS is ten times bigger than the CARM linewidth.
I remeasured all of the noise spectra again today, making sure the input attenuation was as low as it could safely be. I also got a snap of the y green PDH signal; it's fairly larger than I saw the other day, which is good. I used this to calibrate the error signal voltage spectra.
Here are the noise traces for each arm. During these measurements GTRX was about .6, GTRY about 1.0 The Yarm noise doesn't look so good: the error signal is just barely above the mixer+lowpass output noise, and the RMS is plauged by 60Hz lines. (Is this related to what we see in IR TRY sometimes?)
Here are the arms error signals compared directly:
I found that the barrel of one the BNC to BNC connectors used for getting the output of the PDH servo box to the laser controller was touching the ETMY chamber. When I held it away, all of the 60Hz harmonics disappeared from the mixer output spectrum; this was pretty repeatable. This inspired me to replace the refl PD and PZT signal cables (which were 2 and 3 cables stitched together, respectively) with 20' long BNCs. I also cleaned up a lot of the routing of signal and power cables in the little rack, and moved the big T->DC Block->Attenuator combo off of the panel mount, because I didn't like how it was wiggling. It and the summing pomona box are sitting on top of the PDH box and function generator, instead of hanging freely.
All of the 60Hz harmonics were banished afterwards, and the green locked happily.
This required me touching the Y end table, to remove the old cable and its cable ties, and putting the new one in. I don't think I did anything immediately apparently bad; the green and IR transmissions both are within nominal ranges.
I haven't had luck measuring the CLG yet, which I wanted to do to get and set the UGF before measuring the noises. However, here is a scope trace of the in-lock error signal, which compares quite favorably to the trace posted in the previous post; the scope indicates that the signal has 1/3 of the RMS that it did before I replaced the cables.
I hope to measure up the current status after I get back from dinner.
Yesterday I measured the spectra and OLTF of the Y-Arm green PDH, after the LO touch-up and 60Hz hunt from last week. I also went to lower frequencies with the SR785, but forgot to take some of the background spectra down there, so I don't have the full breakdown plots yet. Nevertheless, here is the improvement in the PDH error signal:
I also measured the OLTF (SR785 injection at the error signal, Auto level ref 5mV at channel 2, 10mV/s source ramping, 50mV max output)
As you can see, we have tons of phase margin. Flipping the local boost switch had no visible effect on the OLTF; we should change it to something that puts this surplus of phase to good use, and squash the error signal even more. Putting an integrator at 5kHz should still leave about 45 degrees phase margin at 10k. I've started making a LISO model of the PDH board from the DCC drawing, and then I'll inspect the boards individually to make sure I catch the homegrown modifications.
Data, and code used to generate the plots is attached.
I decided to see what I could do with the new WFS setup.
First, I adjusted the WFS digital demod angles. Once I ensured that the static MC alignment and DC alignment onto the WFS was good, I drove MC2 in pitch with the WFS output off. I then did the usual thing of making the Q peak at the excitation frequency go away. Here are the changes:
I then drove each MC mirror in pitch and yaw respectively, and measured the TF from excitation to the WFS signal (dB Magnitude, sign):
I looked through some old ELOG's of Suresh's and used similar logic to scripts/MC/WFS/wfsmatrix2.m to generate a new output matrix. (This involves creating a null sensing vector that is orthogonal to the measured ones, and inverting that matrix)
I had to flip a gain or two to keep things stable, then measured the WFS error signal spectra to see if this made anything better. The WFS1 spectra look better, but WFS2 not so much.
The loops would need a more thorough investigation, but for now, they're at least a little calmer. The MC is stabler than immediately after the upgrade, but there's still room for improvement.
Quick post of plots and data; I'll fill in more detail tonight.
TL;DR: I pulled both green PDH boxes and made LISO models, compared TFs and noise levels.
Pictures of X and Y boards, respectively
TF comparison to LISO. (Normalized to coincide at 1Hz)
Noise comparison to LISO
All data, EAGLE schematics, LISO source and plots in the attached zip.
We want both the X and Y phase trackers to have the same UGF, so that the X and Y ALS signals are subject to the same phase characteristics and can be nicely decoupled into CARM/DARM.
I've started implementing a simple normalization scheme that Koji suggested, namely, dividing the I output of the phase tracker by a low passed version of the Q output. (Since the I is servoed to zero, the radius of the error signal in the IQ plane is essentially equal to the Q value) I put some simulink logic into the IQLOCK library part that BEAT[XY]_FINE are instances of to switch the normalization on/off, and to protect from divide-by-zeros. I also exposed the switching and FM on the ALS screen.
I then tried using it, to mediocre results. I put a 10mHz LP in the filter module, found a Y-Arm beat, set the phase tracker gain to give me a 2kHz UGF, and then set the gain of the UGH normalization FM to turn the current average Q to unity.
I then moved the laser temperature around to get different beatnote locations/amplitudes, hoping that the phase tracker UGF would stay the same when the UGH normalization was on.
It did not.
It did, however, correct it in the right direction... more work will be done with this, to try and make it useful. There's also the unfortunate effect that locking/unlocking the green causes erratic phase tracker output, which messes with the input to the normalizing LP filter, so if one were to leave it switched on, wonky stuff would come out. I don't want to go overboard with triggering shenanigans before I even get it working in the first place, though.
I had noticed in the past, that the digital control signal monitor for the X end would saturate well before the ADC should saturate (C1:ALS-X_SLOW_SERVO_IN1, which is from the "output mon" BNC on the box). It turns out that there is some odd saturation happening inside the box itself.
In this scope trace, the servo input is being driven with a 0.02Vpp, 0.1Hz sine wave, gain knob at 1.0. This is bad.
Evan and I poked around the board, and discover that for some reason currently unknown to us, the variable gain amplifier (AD8336) can't reach its negative rail, despite the +-12V arriving safely at its power supply pins.
I also realized that the LF356 in the integrator stage in this box had been replaced with a LT1792 by Kiwamu in ELOG 4373. I've updated my schematic, and will upload both boxes' schematics to the DCC page Jenne created for them. (D1400293 and D1400294)
I had pulled out both X and Y servo boxes for inspection, put the Y box back, soldered in a missing op amp power capacitor on the X end box, and had not yet put back the X end box yet because of the saturation issue I was looking into. Otherwise nothing was changed at the ends; I didn't open the tables at all, or touch laser/SHG settings, just unplugged the servo boxes.
I narrowed down the saturation point in the X green PDH box to the preamp inside the AD8336, but there is still no clear answer as to why it's happening.
As per Jenne's request, I put the X end PDH box back for tonight's work. It locks, but we have an artificially low actuation range. With SR785, I confirmed a PDH UGF around 5k. Higher than that, and I couldn't reliably measure the UGF due to SR560 saturations. The analyzer is not currently in the loop.
Both arms lock to green, but I haven't looked at beatnotes today.
The traces were from the front panel output BNCs, but the VGA preamp exhibited this asymmetric saturation at its output.
In any case, I tried to replace the Xend box's AD8336 with a new one, and in doing so, did some irreparable damage to the traces on the board I was not able to get a new AD8336 into the board. There are some ATF ELOGs where Zach found the AD8336 noise to be bad at low frequencies (link), and its form factor is totally unsuitable for any design that may involve hand modification, since it doesn't even have legs, just tiny little pads. I suggest we never use it for anything in the future.
Instead, I've hacked on a little daughter board with an OP27 as an inverting op-amp with the gain resistor on the front panel as its feedback resistor, which can swing from 0 to x20 gain (the old gain setting was around 15dB=~x6). I've checked out the TF and output noise, and they look ok. The board can output both rails as well.
I don't really like this as a long term solution, but I didn't want to leave things in a totally broken state when I left for dinner.
Going off some discussion we had at lunch today, here is my current knowledge of the state of cavity lengths.
Acknowledging that Koji changed the sideband modulation frequency recently, the ideal cavity lengths are (to the nearest mm):
We when last hand measured distances, after moving PR2, we found:
However, when I looked at the sideband splitting interferometrically, I found:
This is only 5mm from the hand measured value, so we can believe that the SRC length is between 5 and 6 cm too long. I'm building a MIST model to try and see what this may entail.
Jenne made her board modifications, and the measured TF agreed with the design. Alas, the green would not lock to the arm in this state.
I think that the reason is that the new TF does not have nearly as much low frequency gain as the old one, for a given UGF. Thus, for example, the 1Hz noise due to the pendulum resonance, has 30dB less loop gain suppressing it.
Koji correctly points out that I naïvely overlooked various factors. With a similar analysis to the wiki page, I get:
This means that:
Next step is to see how this may affect our ability to sense, and thereby control, the SRC when the arms are going.
MIST simulations and plots are in the attached zip.
Just a quick note, plots and data will come tomorrow:
I grabbed an unused uPDH board from the ATF (thanks Zach!), and re-stuffed almost the entire thing to match Jenne's latest schematic for the y end box. I also threw some 22uF caps on the regulators, as Koji did with the previous box, to eliminate some oscillations up in the high 10s of kHz. I replaced the tragedy of a box that I created on Wednesday with this new box. The arm locks pretty stably with the boost on, 30 degrees of phase margin with 10kHz UGF, and locks pretty darn reliably.
Now we should now have two nicely boosted PDH loops. I'll do a noise/loop breakdown again in the upcoming days.
I measured the noise spectra and loop TF of the green PDH with the newly stuffed board. Unfortunately, I never took the noise below 100Hz of the previous box, so we can't see what has happened to the overall RMS, or more specifically, the RMS due to the pendulum resonance. All of these plots are in the boosted state, as that is how we intend to use the box.
Here is the loop, which does not have quite as much margin as the y-arm, but 10dB of gain peaking is probably ok, since the RMS at 10s of kHz is not so important to ALS. (OL measured, CL inferred) We see the 1/f shape from 1k to 50k or so, and 1/f^2 under 1k, as desired.
Comparing in the in loop error signals, we see the effect from the increased gain from 100Hz to 10kHz. (Here is where I regret not looking at the low frequency spectrum two weeks ago)
Finally, here is the noise breakdown.
The error signal RMS is now dominated by the 1Hz peak. We have talked about using digital feedback for this, since we have the PDH error signal coming into an ADC, and can sum in a DAC signal into the servo output. This also lets us intelligently trigger a sub-10Hz boost once the PDH box locks itself. With a good boost, we maybe could bring the in-loop RMS of the error signal to under 1kHz.
Something odd that Rana brought to my attention, however, is that my measurement and calibration indicates an RMS of ~5kHz, but the cavity pole should be something like 18kHz. If this is true, how can we be seeing stable power? This maybe means that my calibration is too many Hz per Volt.
I performed the calibration by creating a MIST model of the arm, and generating the PDH error signal on a demodulated PD, I then find the slope of Hz per arbitrary error signal unit. Then, looking at a scope trace, I match up the horn-to-horn voltage to the horn-to-horn arbitrary error signal units, which lets me finally find Hz per error signal volt.
However, there is some qualitative difference in the shape between the simulated and observed error signals, namely, that the outer horns are larger than the inner horns in the real signal.
Does this matter? Is there something in my simulation that I can correct that would give a more accurate calibration?
Data, plots, code, attached.
I used a modulation depth of 0.3, which, if I recall correctly, is what we aimed for on the Y-arm when we adjusted the LO signal there. However, this is probably not the case for the X arm.
In any case, I found the bug in my RMS calculation. (I had forgotten to flip the x array in addition to the y array for the right-to-left integration, and had uneven bin spacing, so the integration bandwidths weren't correct...)
Here are the updated plots. The properly evaluated RMS is ~600Hz, which seems to mostly come in around 10k, so we may want to turn down the gain for less gain peaking in that region.
Q and Steve will follow elog 10028 entry to prepare the vacuum system for safe reboot
Here's the sequence of the morning so far:
The IFO is still down, as the PMC won't lock without the rack power, and we haven't pinned down the shorting mechanism. We don't want the replacement sorensen to immediately blow when plugged in.
We replaced the +15V sorensen at 1X1, and brought the power supplies back up symmetrically, and everything seems fine. I noted that a quarter turn counter-clockwise took the current limit down by one amp, so I set the knob to just letting 2.8A (the nominal current), and then added one half turn, shooting for ~4A current limit.
In doing so, we had to cut power to the c1psl VME box. It didn't come back happily. We had to do the chiara /etc/hosts things, like we did for c1auxexx, to get it back.
I checked chiara's tables, all seemed fine. I switched ethernet cables from the black one labelled "allegra," which seemed maybe fragile, for the teal one that may have been chiara's old ethernet cable. It's back on the network now; hopefully it lasts.
Some small things I did tonight which did little to nothing to help:
My main concern with tonights situation was the huge low frequency fluctuations of TRY while CARM/DARM locked on ALS. We saw this being very smooth very recently, but when one arm is fluctuating by multiple line widths, it isn't surprising that locks aren't stable. I want to know why the out of loop stability is so unpredictable.
I took a quick measurement of the ALS stability, using POX and POY as out of loop sensors, using a CARM calibration line to line POX and POY up to the calibrated PHASE_OUT channels at 503Hz.
Since DRMI didn't get fully commissioned, I tried my hand at PRFPMI locking with the newly improved ALS performance.
ALS seemed reliable, I think my main limiting factor was the PRMI locking. We should set up a restore script for PRFPMI that is a superset of the ALS CARM DARM, because the current restore script doesn't put all the vertex settings back, so I was trying to lock for a while without the FM boosts on PRCL and MICH, which really hurt my stability.
Transitioning to SqrtInv works fine; a couple of times I've gotten to arm power of ~10, and have been able to sit there for a while as I set up excitation line comparisons with the CM board's REFLDC, but the PRC would always lose it before I did anything interesting.
The PRMI locks with a reasonable MICH offset, I found that adding a offset of 20 to 40 makes the AS spot visibly dimmer, and ASDC falls to ~0.05 from .1-.2.
I looked into adding a boost to the CARM loop after transitioning to sqrtInv, but we only have 30 degrees of margin, and the error signal is already fairly white, so there isn't much to do, really.
The ALS locking script is sporadically hanging a fair while, as well, which is strange. Otherwise, not much to report...
REFL11 I, as seen in digital land, is connected to the slow output of the CM board. I tuned the demod angle of the REFL11 demodulator board by cable length back in ELOG 9850. It would be good to check that the phase is still good. If the CM board gains are at 0dB, we should be able to used the digital angle adjustment as normal.
We need to get an interferometric estimation of the SRC length error / SRC sideband splitting, because if the 7.5cm hand-measured error is true, it looks like it might be hard to control the DRMI on 3F.
I did some DRMI sensing simulations, to get an idea if sensing matrix elements might change as the CARM offset changes. Last night, I tried just going to zero CARM offset on ALS, and was having problems keeping the PRMI locked on REFL33, so I wanted to confirm that it should at least work in theory.
Thus, I simulated what happens to the sensing matrix element in the vertex DoFs as the CARM offset is reduced, in both the PR and SR cases. I normalized all of the elements to PRCL at zero carm offset, to get an idea of what the good relative gains should be for MICH and SRCL.
In the end, there don't seem to be significant DC gain changes, or demod angle fluctuations, in either the PRFPMI or DRFPMI case, as the CARM offset changes, which is good.
However, the SRC length as hand-measured, seems to mess up the MICH angle in the DRFPMI case, and really lowers the SRCL signal amplitude.
To be fair, past efforts of simulating demodulation angles haven't always been borne out on the IFO, so we should still forge ahead experimentally until it becomes apparent that there is a real problem.
Here are the simulations for the IFO as-is:
(A note on the plots. Though they kind of look like Bodes, they're just the sensing element represented as a complex number in the I-Q plane,I being phase=0 and Q = 90)
All three signals are along the I axis in the DRMI case, which seems like it would be tough to control, since we only have 2 3F diodes... We've been using REFL33Q when PRMIing, which is simulated at around 45 deg; it should be easy to verify this empirically.
Here are the same plots with the SRC length corrected. Now MICH shows up mostly in the Q phase as desired in the DRMI case. SRCL in REFL165 also wins 20dB of optical gain, as well.
To drive the point home, here's a simulated scan of AS110 and REFL55 Q to show the effect of the measured length error:
Our janitor turned off the laser accidentally.
The PMC wasn't locking very happily after this. I tweaked the pointing onto the PMC REFL diode, to make sure it was centered, and touched the alignment into the PMC. I also reset the FSS Slow output to zero. It took a little while for the laser to settle in, for some reason, but the transmission is up at 0.80 now.
Tweaked MC2 pointing to get the MC transmission high enough to let WFS kick in, which nicely got the rest of the MC alignment done. After that, I offloaded the WFS into the MC suspensions.
Lastly, I ran the command that Rana posted in ELOG 10391, to set the FSS input offset (From -0.18 to -0.06)
I have not had any success the past two days in getting an interferometric measurement of the SRC length.
So, the question posed at today's meeting was: "How precisely do we need to change the SRC length to be able to lock the DRMI on 3F"
The two ways I could think to quantify this are:
REFL33 should have its phase set to put PRCL along I, and REFL165 should have SRCL along I, so the simulation result that matters is the angle of MICH in these planes. The cross couplings are then given by the appropriate trigonometric projections. In the following plots, I used 10% as the acceptable cross coupling in either direction.
Code (finesse + pykat + ipython notebook) and plots are attached.
More AO efforts. No huge news.
Came at AO from each side. For each sign, I lost lock just a few dB from the AO portion of the loop crossing unity gain. Both attempts were about arm powers of 1, which should correspond to ~300pm CARM offset, which I have simulated the crossover as possible with my current loop models (including latest MC loop). The gain steps were usually 6dB in between measurements.
Positive polarity on CM board screen:
I made it to +5 dB of the last plot here, but the 6th broke it open. Gains on CM In2, CM AO, and MC In2 were -6, -4, -2 on that last, lock breaking, step.
Negative polarity on CM board screen:
Lost it just 2dB above the last trace. Gains were -6, +1, -2 (So, overall 5dB higher than the other polarization)
Many things happened in between these two lock stretches, but I'm not sure what may or may not have affected things. They include:
The location of the CARM resonance peak lines up with my simulation, which is good, but there appears to be less phase than expected... I tried making sure that we don't have any whitening uncompensated for, but it looked ok. All my AO path loop model contains is the CM board TF (measured and fitted), the IMC seen as an actuator(measured and fitted), and the REFLDC optical TF (simulated in MIST). Maybe the DC path of whatever diode this is coming from needs to be included...
Discontinuities / glitches could be seen in the CM board fast output when MC board gains were changed, which isn't so nice. Incidentally, I notice now that each lock loss corresponded to a step of AO gain on the CM board.
Rather than using a CAD drawing, I used Gabriele's code from ELOG 9590 to try and judge if we could shorten the SRC by the appropriate length, without clipping the SR3-SR2 beam.
Specifically, I used these lines:
% Move SRM 7.5 towards SR2, parallel to beam
dAS = BS2-AS; % Vector from SRM to SR2
dASmag = sqrt(dAS(1)^2+dAS(2)^2);
dMove = delta*dAS/dASmag; % delta times unit vector
CS = CS+dMove;
As a reminder, Gabriele's code used the following logic:
In my opinion, this is the best estimate of beam trajectory that we currently have.
Thus, from looking at the plot above, I claim we can correct the SRC length without clipping the beam by moving the SRM forward by the required 7.5cm.
Although the measured distance may be off on the order of a cm (since our PRC correction had a 0.5cm disagreement between interferometric and hand distance measurements), this will nevertheless markedly improve our 3F DRMI sensing, based on my previous ELOG.
Hence, given our discussions last week, Jenne and I will proceed to ready the interferometer for venting in the morning, by following the vent checklist.
Our sole objective for this vent is this move of the SRM.
Steve, please check the jam nuts, and begin the vent when you get in. Thanks!
Interferometer alignment is restored
ASS has been run on each arm, recycling mirrors were aligned by overlapping on AS camera.
ETMY was not getting its ASC pitch and yaw signals. C1SCY had a red RFM bit (although, it still does now...)
I took a look at the c1rfm simulink diagram and found that C1RFM had an RFM block called C1:RFM-TST_ETMY_[PIT/YAW] and C1SCY had one called C1:TST-SCY_ETMY_[PIT/YAW].
It seems that C1TST was illegally being used in a real signal chain, and Jenne's recent work with c1tst broke it. I renamed the channels in C1RFM and C1SCY to C1:RFM-SCY_ETMY_[PIT/YAW], saved, compiled, installed, restarted. All was well.
There are still some in SCY that have this TST stuff going on, however. They have to do with ALS, it seems, but are SHMEM blocks, not RFM. Namely:
Ottavia was having some severe interaction latency today. Xorg was taking up >90% of the CPU, just sitting around. The machine was logged in to a desktop session with lots of graphical effects turned on. I changed the system default session to "gnome-fallback" in /etc/lightdm/lightdm.conf, which was already set as the default for controls, but wouldn't get chosen for the autologin that happens on boot.
Hopefully this helps ottavia stay usable...
I think I found out why rossa was mad.
An apt-get update on the 18th downloaded kernel 2.6.32-65-generic, so 2.6.32-58-generic, which what was previously chosen as a working kernel, had moved down in the grub ordering.
It turns out the grub configuration accepts strings, so I changed it to GRUB_DEFAULT="Ubuntu, with Linux 2.6.32-58-generic", ran sudo update-grub, and Rossa now seems to boot happily.
GRUB_DEFAULT="Ubuntu, with Linux 2.6.32-58-generic",
[q, Jenne, Manasa]