Slightly updated Game Plan. Mostly, Q is continuing to check out the Xend PDH box saturation, and I am thinking on what our requirements are for ALS, and thus for the green PDH 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.
What monitor point is being plotted here? Or is it a scope probe output?
If this saturation is in the uPDH-X but not in the uPDH-Y, then just replace the VGA chip. Because these things have fixed attenuation inside, they often can't go the rails even when the chip is new.
In any case, we need to make a fix to get this box on the air in a fixed state before tomorrow evening.
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)
Q put the X PDH box back, so that I could try locking, and remember which end is up after a week away.
I am unable to hold ALS comm/diff for any length of time. Only once today did I hold it through the FM3 boost turn-on. So, I looked at the individual arms.
Xarm, even though it's the one that Q is seeing this saturation problem with, seems fine.
Yarm however is having trouble holding lock for more than a few minutes at a time. The green beam stays locked to the arm for ~infinity, so I'm not so worried about the PDH box right now. If I look at the error and control points of the ALS digital servo, the Yarm is much more noisy above about 20 Hz. Something that I might think of for this kind of mismatch at higher frequencies is poorly matched whitening / dewhitening, or none at all for the Yarm, however this doesn't look like that to me. Based on the shape of the spectra, I don't think that we're running into ADC noise. For this plot, both arms are individually locked with ALS feeding back to the ETM, gain magnitude of 15 (Xarm gets a minus sign because of our temperature / beatnote moving direction convention), FMs 1,2,3,5,6 on. Something that seems critical for getting the Yarm to have the FM3 boost without losing lock is having the SLOW temperature servos on for a little while so that the PZT output (as monitored on the temp servo screen) for the end lasers fluctuate around zero. Right now, both beatnotes are at about 62MHz, with an amplitude of about -31dBm.
I still need to do a somewhat more thorough investigation of what might be causing the Yarm locklosses. Is the length-to-angle decoupling worse for ETMY than for ETMX? Am I moving the arm length so far that the PZT can't follow within its actuation limits? Does the Yend PDH box have a similar saturation to the Xend box, but somehow (a) worse, and (b) not as obvious so we didn't suspect it before?
I need to put this plot into calibrated units, and also include the low frequency monitor that we have of the PDH error point (all of which are _DQ channels).
Things to do:
* Figure out Xend PDH box saturation issue. Is Yend seeing same saturation in the variable gain amplifier? We have 3 spares of these chips in the Plateau Tournant Bleu, if we need them.
* Check Yarm ALS stability. (NB: The arms have been individually locked for the last 15 min or so while I've been writing, so maybe letting the slow servo settle is the key, and this is not something that needs work).
* Get CARM on DC Trans, DARM on AS55Q (after arm powers of about 1). Can we see good REFL DC dip? Should we try using just the transmission PD signal as the error signal for the CM board, if we aren't close enough to resonance to use REFL DC?
From EricQ's simulations reported in elog 10390, we want to transition from ALS comm to DC transmission signals around 500 pm. However, around 100 pm, the DC transmission signals have a sign flip, so we don't want to have the ALS swing that close to the CARM resonance. So. We want to be at about 500 pm, and not touch 100 pm. So, we don't want our peak ALS motion to go beyond ~400 pm. Which means that we need to have less than about 40 pm in-loop RMS, to avoid hitting 400 pm. This is an ALS requirement, but since the analog PDH box is what forces the end laser to follow the arm cavity, and thus give us information about the arm length fluctuations, the PDH residual noise is part of our sensor noise for the full ALS. So, we need to have the PDH in-loop RMS be less than 40 pm, integrated from a few kHz down to at least 30 mHz. Recall that above the ALS UGF (of about 200 Hz), the sensor noise will be suppressed by 1/f, so we should take that into account when we are looking at the PDH error signal, before we calculate the RMS motion.
Q also measured the in-loop error signal with the current Yend PDH box in elog 10430, and it looks like most of the RMS is coming from a few hundred Hz. I designed a hack to the PDH board boost that has a zero at about 2kHz, and a gain of 30 at DC, so that we will win by squishing all that RMS. Also, it shouldn't be too aggressive, so we should be able to leave it on all the time, and still acquire lock of the green laser to the arm, without having to do triggering.
The board schematic is at DCC D1400294. The boost is also called the "integrator stage", although it will no longer be a simple integrator.
EDIT, JCD: This cartoon is not correct for the non-boosted state, doesn't include effect of R16.
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.
Okay, went back to the drawing board with Rana and Koji on PDH box stuff.
Currently (at least for the Yend), in the boost OFF state, we have an overall gain of about 50. This is crazy big. Also, the zero in the "transfer function stage" is around 1kHz, however our green cavity pole is (calculated) to be around 20 kHz. Since these are supposed to cancel but they're not, we have a wide weird flat region in our loop TF.
So. I calculated the changes to the TF stage that I'll need so that I have an increase of about 20 in DC gain, kept the pole at the same ~20Hz, but moved the zero way out to 18kHz. I also calculated the changes needed for the integrator stage to make it effective at much higher frequency than it was designed for. Now the pole is at 75 Hz, and the zero will be at 1.6kHz, and the high frequency gain will stay pretty close to the same with and without the boost.
Planned new TF stage:
Planned boost stage (with and without boost activated):
New boost stage only, so you can see the phase:
The schematic, modified to show my planned changes (which I will put in the DCC after I make the changes):
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.
Com'on. This is just a 60ppm change of the mod frequency from the nominal. How can it change the recycling cav length by more than a cm?
This describes how the desirable recycling cavity lengths are affected by the phase of the sidebands at non-resonant reflection of the arms.
If we believe these numbers, L_PRC = 6.7538 [m] and L_SRC = 5.39915 [m].
Compare them with the measured numbers
You should definitely run MIST to see what is the optimal length of the RCs, and what is the effect of the given length deviations.
As EricQ mentioned in last night's elog, the modifications were made to the Yend (SN 17) uPDH board.
R31 became 49.9 Ohms, R30 became 45.3kOhm, R24 became 1.02k, R16 became 1k, a new flying resistor is tombstoned up against R24 and connected by purple wire to C6 and it is 20k. C28 is 183nF and C6 is 100nF. These numbers were used in Q's simulation last night.
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.
I changed the Martian wireless router to use channel 10 instead of something random (as it was). Using the Android app 'Wifi Analyzer' we could see that the usual channels are dominated by FlumeLab and Caltech Beaver.
The range from 9-13 looked clean so we put it up there. Also, the signal strength drops from -45 to -70 dBm as we walk from the BS down to the ends. We need to tweak the router position and orientation to give us another 10 dB so that we can reliably run the laptops at the ends.
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.
[Rana, Jenne, EricQ]
* Too much gain overall on Yend box, needed attenuator on output to get lock. Rethought gain allocation. Resoldered board, installed, Ygreen locks nicely. Error point and control point spectra, box TF and open loop TF data collected, to be plotted.
* Q replaced the Xend box, with a matching TF.
* Locked both arms individually, Yend has lots of low freq fluctuation, Xend has some. Can't do out of loop measurement since we're going well beyond the range of the PDH signals (Yarm RIN is between 1/2 and 1.) Plot TRX and TRY spectra with ALS lock vs. IR lock to get an idea of what frequencies we have a problem with.
* Tried comm/diff locking anyway. Works. Used cm_up script to get CARM to sqrtInvTrans. Went to powers of about 0.5 (hard to say really, because of fluctuations), put sine at 611.1 Hz, 200 cts onto ETMs (-1*x, +1*y), looked at TF between ALS diff and AS55Q. Put that amount into the static power normalization spot for AS55. In steps of 0.1, reduced ALSdiff input matrix elements and increased AS55->DARM element. 2 (3?) times was able to get to AS55Q for DARM. Lost lock once unknown reason, while reducing CARM offset. Lost lock once trying to turn on FM4 LSC boost for DARM.
The SRM qpd was moved to accommodate the HeNe laser qualification test for LIGO Oplev use.
The qpd was saturating at 65,000 counts of 3 mW
ND1 filter lowering the power by 10 got rid of saturation. I epoxied an adapter ring to the qpd.
Atm3 was taken before saturation was realized with Koji's help.
Atm4 ND1 on SRM qpd. Now it is working and everything is moving.
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.
ITMY oplev should be centered. I worked too much around it.
I locked the arms with IR, and measured the beatnote spectra to get the out of loop noise for the PDH boxes.
Unfortunately, we don't have a reference saved (that I can find), so we're going to have to compare to an elog of Koji's from a month ago. I have created an out of loop ALS reference .xml file in the Templates/ALS folder.
As we can see from Koji's elog 10302, the Xarm seems to have stayed the same, but the Yarm seems to have increased by about an order of magnitude below 100 Hz. :(
What modulation depth are you using for the simulation? I have never seen a real measurement of that in our elog for the end-PDH systems.
I also disbelieve your RMS calculations. It looks like in the 1.5-0.5 Hz band we're picking up 50 kHz of frequency noise even though the 1 Hz peak is only 80 Hz/rHz, even though math says "80 * sqrt(1) = 80".
Take a look at:
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.
600 Hz seems ~OK. From the measured reflectivities for 532 nm, the green Finesse = 108. So the green cavity pole should be 18.3 kHz given an arm length of 37.8 m.
600 Hz of green frequency noise means that we would get 38 pm RMS of arm mirror motion. We should assumed a peak/RMS factor of 10, so this would allow us to get to ~0.4 nm CARM offset.
However, its better than that. What we really care about for ALS is the amount of this green frequency noise which is put onto the arm. With an ALS feedback bandwidth of 100 Hz, my eyeball estimate say that the contribution from green PDH error will be ~100 Hz RMS, since we don't care too much about the 10 kHz stuff. So this seems good enough for now; let's figure out what's up with PDH-Y and get back to locking.
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.
FYI: in that rack, the +15V pulls ~0.5 A more than -15V usually. I think this is due to some RF amplifiers which are powered by this (e.g. the AOM that Manasa set up). The Sorensen's can source ~30A in principle, so we should make sure to set the current limit appropriately so as to not overheat them when there is a short.
Was this power supply not fused for all of its connections? I remember that this was connected to at least one un-fused connection in the past year.
+15V supply powers the following (from what I see):
1. PMC and MC boards on the rack.
2. RF amplifiers on the rack for the beat signals from the green beat PDs.
3. Beatbox itself.
The beatbox was the one that had an un-fused connection last year. I re-did it properly to go through a fuse quite sometime ago.
I dont see any other un-fused connections now from the +15V supply right now.
P.S. AOM driver takes a 0 to +28V power supply and not connected to the +15V
These are plots and notes from last week's PDH adventures.
For the PDH servo box re-design, we wanted to think a little bit about what we actually wanted out of the box.
* We want the zero of the main transfer function to be at the same frequency as the cavity pole for green, which is about 18kHz.
* We want the boost to suppress noise at a few hundred Hz. We don't need super-duper low-frequency boost, nor do we want it. We'd like to leave the boost on all the time.
* Wanted to get rid of 10dB attenuator on PD input, so needed to lower the overall gain.
* We acknowledge that the gain of the raw error signal times the PZT response is very high, so no matter what, we will have to have a low-gain servo, even perhaps have the servo shape be less than unity gain.
---> We reduced the gain of the first amplification stage from a gain of 20 to a gain of 3.
---> Made the boost stage have a DC gain of 1. Pole at 75 Hz and Zero at 1.6kHz to give suppression at a few hundred Hz. Boost is *not* a pure integrator, so that we can leave it on. (If we required triggering anyway, we would have made it a pure integrator).
---> In transfer function stage, put zero at 17.7kHz to match cavity pole. Pole of servo was going to be at 20 Hz, but we wanted a little more gain, so we lowered it to 2 Hz.
Here is the final measured servo box transfer function for the Yend box (with an arbitrary gain knob setting):
Once installed, I set the gain knob for the Yend at 4.0, which gave an overall UGF of about 10kHz. Then I measured the loop:
I also measured the error point and the control point, and compared them to Q's measurements in elog 10430.
In order to see what we might expect for a contribution to ALS noise, I looked at the error point spectra and lowpassed it with a pole at 200Hz. I do this because the PDH error is like sensor noise for the ALS, but the ALS UGF is around 200 Hz, so noise at frequencies higher than that will be suppressed like 1/f. So, I lowpass the error signal, then look at the RMS, and see that we should be pretty happy with our result. I include also the Xend error spectrum, as measured and reported by Q in elog 10460.
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.
This afternoon, after Q and Manasa finished recovering from the activities of the morning, I aligned the IFO, and went to the Yend to touch up the alignment of the green to the arm. I don't know if it was the alignment (I didn't do the PSL table), or I happened to have a good combination of laser temperatures, or what, but the Yend ALS noise was super good. After that, the low frequency noise contribution is different lock-to-lock, and I haven't discerned a pattern yet.
One thing that we want to try is to get DARM to AS55 so that we're entirely off of ALS (assuming we've already gotten CARM to sqrtInvTrans). However, according to Q's simulations, we have to get past arm power of a few before we are within the AS55 linewidth. I have a DTT running showing me the phase between AS55 and ALSdiff as I reduce the CARM offset, but I haven't been able to get close enough to see the sign flip when CARM is on sqrtInvTrans. If I just sweep through with both CARM and DARM on ALS, I see the sign flip. I've tried a few different things, but I have not successfully gotten a transition to AS55 while the arm powers were above 1. Empirically, I think I want them at at least 3 or 4.
Koji suggested locking the DRMI rather than PRMI, to widen the AS55 linewidth, but I haven't tried that tonight. Maybe tomorrow night.
I have made a ruidimentary lockloss plotting script, that I have put in ..../scripts/LSC/LockLossData, but I'm not satisfied with it yet. Somehow it's not catching the lockloss, even though it's supposed to run when the ALS watch/down scripts run. I'll need to look into this when I'm not so sleepy.
Q, can you please work on figuring out the phase tracker gain tracker? It will be nice to have that functional so we don't have to fret about the phase tracker gains.
Manasa, can you please estimate what kind of mode matching we have on the PSL table between the arm greens and the PSL green? We *do not* want to touch any optics at this point. Just stick in a power meter to see how much power we're getting from each beam, and then think about the peak height we see, and what that might tell us about our mode overlap. If we determine it is total crap, we can think about measuring the beams that go either toward the camera, or the DC PDs, since neither of those paths require careful alignment, and they are already picked off from the main beatnote path. But first, what is our current efficiency? Yarm is first, then Xarm, since Yarm seems worse (peak height is larger for non-00 modes!)
SRM as set up in Atm4 26,000 count compared with ETMY oplev servo in operation 7,500 counts for 3 days
Next steps: measure beam size at qpd,
place qpd on translation stage for calibration,
change 1103P mount to single one
Smoking Sorensen could have triggered the smoke alarm!
Yesterday I called CIT Fire Protection Services very first to deactivate the sensors temporarily. The smoke alarm was turned back on right after the particle count dropped.
Their phone number is posted at the entry doors 104M and 104W as shown below.
Vacuum safe reboot required one hour of no pumping of the vac envelope.
We developed a fairly sophisticated lockloss script at the sites, which you could try using as well. It's at:
It requires a reasonably up-to-date install of cdsutils, and the tconvert utility. It uses guardian at the sites to determine when locklosses happen, but you can use it without guardian by just feeding it a specific time to plot. It also accepts a list of channels to plot, one per line.
SRM qpd is installed on translation stage and the shims removed from laser V mounts.
The ETMY oplev servo is on.
SRM oplev servo: 100 microrad/count is an estimate, not calibrated one.
Today the network connection of OTTAVIA was sporadic.
Then in the evening OTTAVIA lost completely it. I tried jiggle the cables to recover it, but in vain.
We wonder if the network card (on-board one) has an issue.
Q has pointed out that we expect a sign flip in the AS55 signal for DARM as we reduce the CARM offset in the PRFPMI case. Koji also mentioned that the SRC will help broaden the DARM linewidth. I wanted to check and think about these things with my Optickle simulation. Q is working on confirming my results with Mist.
The simulation situation:
* The demod phase for AS55 is set in the MICH-only case so that the MICH signal is maximized in the Q-phase. I do not change the demod phase at all in these simulations.
* Cavity lengths (arms, recycling cavities) are the measured lengths.
* I look at AS55 I and Q as DARM sensors (i.e. I'm doing DARM sweeps) as a function of CARM offset, for both PRFPMI and DRFPMI cases.
Spoiler alert! Conclusions:
* In the PRFPMI case, the DARM signal shows up with approximately equal strength in the I and Q phases, so we suffer only about a factor of 2 if we do not re-optimize the demod angle for AS55.
* In the DRFPMI case, the DARM signal is a factor of 1,000 smaller in the Q-phase than the I-phase, which means that the ideal demod phase angle has moved by about 90 degrees from the MICH-only case. We must either use the I-phase signal or change the demod phase by 90 degrees in order to acquire lock.
* In the PRFPMI case, there is a sign flip for DARM on the AS55 PD around 100pm, so we don't want to use AS55 for DARM until we are well inside 50pm, and aren't going to fluctuate out of that range.
* In the DRFPMI case, there is no such sign flip, at least out to 1nm, so we can use AS55 for DARM as soon as we see a viable signal. This is super awesome. The caveat is that the gain changes significantly as we reduce the CARM offset, so we either need a UGF servo (eventually) or careful watching (for now).
* The AS55 linear(-ish) range is much broader in the dual recycled case, which is yet another reason why getting DARM on AS55 will be easier for DRFPMI.
Why didn't we do it already?
* To put the SRM QPD back, we'd also have to move Steve/EricG's laser. Since I had other things to do, I left the setup for tonight, but I think I will want it for tomorrow night.
* Monday night (and tonight) we can pretty reliably get DARM onto AS55Q for the PRFPMI case, and I don't know what the cause has been for my locklosses, so I thought I'd try to figure that out first.
First up, the current transition we've been trying to handle, PRFPMI DARM to AS55Q. I also plot AS55I, and we see that the signals are roughly the same magnitude (the x axis isn't the same between these plots! sorry), so we aren't screwed if we don't change the demod phase angle. We'll be better off once we can do a re-optimization, but this is assuming we are stuck (at first) with our MICH-only demod phase angle.
Next up, the same plots, but for the DRFPMI case. Note here that there is a factor of about 1000 in the y-axis scales, and also that there is no switch in the sign of the zero-crossing slope for the I-phase.
And here is the same data (DRFPMI case), but zoomed out for the Q-phase, so you can see the craziness of this phase. Again, this is much smaller than the signals in the I-phase, so I'm not too worried.
* Steve leaves the SRM oplev back in its nominal location (we can worry about aligning the mirror, and aligning the beam on the PD, but please put it back approximately where it came from).
* Try DRMI + 2 arm locking, which I don't think we have ever actually done before. Hopefully there won't be any tricks, and we can get to an equivalent place and successfully get DARM to AS55.
* .... Keep going?
I would also suspect IP conflicts; I had temporarily put the iMac on the Ottavia IP wire a few weeks ago. Hopefully its not back on there.
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.
No major progress today.
I fixed a bug in my lockloss script that was asking it to start gathering data just after the lockloss, rather than some seconds beforehand. Ooops. Anyhow, with this handy-dandy plotting, I still don't know why we are losing lock when we have PRMI on REFL33, CARM on sqrtInvTrans, and DARM on AS55. I don't see any oscillations, just the arm power drops off, and a moment later the POP power drops.
For example, here is one of the best states we got to tonight. Data for this is in ..../scripts/LSC/LocklossData/1094369700 . You can re-create the plot by going to ..../scripts/LSC/LocklossData/ and doing ./PlotLockloss.py 1094369700 . We had set the triggers for the trans PD/QPD such that we were using the QPD transmission signals the whole time (above trans of 0.2). We saw that the noise at high frequency during low transmission powers for sqrtInvTrans as an error signal was higher using the QPDs than with the Thorlabs PDs, but that both cases are below the noise for ALS. The arm powers were pretty steady above 3 for the last bit of this lock stretch. I lost lock while trying to transition DARM over to AS55Q. CARM was on sqrtInvTrans(QPDs), PRMI on REFL33 I&Q as usual.
./PlotLockloss.py 1094369700 .
Other things from this evening:
* When I was starting, I saw that when I locked the PRMI, the PRM was oscillating in pitch. Oscillation only happened when PRM pitch oplev was on. I'm not sure what could have changed to make the oplev loop unstable, but the gain was 7.0, and now I have left it at 5.0.
* I recentered the PRM and ITMY oplevs.
* Plugged in the Yend PDH error monitor and pzt output monitors, since I forgot them last week. Hopefully this will allow the Yend SLOW servo to work, and keep us away from the limits of the PZT range.
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.
Estimate loss along the Y arm beat path:
1. Measured the beam powers (before the beam combiner):
Y Arm green = 35 uW
Y PSL green = 90 uW
==> Pbeat ~ 2 * sqrt (35 uW * 90 uW) ~ 112 uW
2. Expected power of RF signal
Assuming the PD to have transimpedance ~ 2kV/A and responsivity ~ 0.3A/W,
the expected power of the RF signal = (Pbeat * Transimpledance* Responsivity)^2 / (2 * 50ohm) ~ 45uW = -13.5 dBm
3. Measured power of Y arm beat signal
Turned OFF the beat PDs and rerouted the RF cables such that the spectrum analyzer was reading the RF signal from the Y beat PD itself (without any amplifiers or the beat box itself in the path).
Turned ON the beat PDs and the Y arm beat signal power on the spectrum analyzer measured -58dBm
Even if we consider for losses along the length of the cables, we are still at a very bad state.
4. Bad mode matching??
I don't think mode matching is our main problem here.
Toggling the shutter several times, even with the non-00 modes, the maximum beat power we can see is -50dBm which is still very far from the actual expected value.
Steve and EricG are moving their oplev test for aLIGO over to the SP table, so that we can have the SRM optical lever back.
I have pulled out an Ontrak PSM2-10 position sensor and accompanying driver for the sensor. This, like the POP QPD, has BNC outputs that we can take straight to the ADC.
In the c1pem model I have created 3 new filter modules: C1:PEM-OLTEST_X, C1:PEM-OLTEST_Y, and C1:PEM-OLTEST_SUM. I built, installed and restarted the model, and also restarted the daqd process on the frame builder. On the AA breakout board on the 1X7 rack, these correspond to:
BNC # 29 = OLTEST_X
BNC # 30 = OLTEST_Y
BNC # 31 = OLTEST_SUM
By putting 1Vpp, 0.1Hz into each of these channels one at a time, I see on StripTool that they correspond as I expect.
Everything should be plug-and-play at this point, as soon as Steve is ready with the hardware.
SRM qpd is back to its normal position. The mount base is still on delrin base. SRM and ITMY need centering.
Tomorrow I will set up the HeNe laser test at the SP table with Ontrack qpd
ETMY oplev servo on. SRM qpd with ND1 ------no component------- 1103P
Sitting down to work on the IFO, I couldn't lock the Yarm. I looked at the error signal as well as the transmission on Dataviewer, as usual, and saw that the POY error signal was almost non-existant.
Since there was work on the POY table today (Steve removed the oplev test setup, elog 10489 and Q centered the SRM oplev after doing SRMI alignment, no elog yet), I went out to have a look at the table.
There was nothing occluding the POY beam, which I traced back to the edge of the table. The beam looked nice and round, so I decided that wasn't it. I jiggled the PD cables, and lo and behold, the POY RF out cable almost came off in my hand it was so loose. My suspicion is that whomever was the last to put the POY RF out back didn't tighten the cable and then the work today jiggled the cable loose. I tightened the cable, and by the time I was back to the control room the arm was locked and Koji was already running the alignment scripts.
Koji and Manasa did some work on the PSL green situation today (Koji is still writing that log post up), but I just measured the Yarm out of loop sensitivity, and WOAH.
The beat is -11.5dBm at 42.8 MHz. Koji said the sweet spot is around 30 MHz. The out of loop sensitivity is 400 Hz RMS! Something to note is that the Y beatnote still has a 20dB amplifier before going to the beatbox, but the X does not. We had been worried about saturation issues with the X, so we took out the amplifier. However, I might put it back if we win big like this.
Recall from elog 10462 that I had saved a reference of the out of loop noise for both X and Y, but Y was much noisier than X. The references below are from that elog, and the new Y is in dark blue. (Edit, 9:18pm, updated plot measuring down to 0.01Hz. This is the new reference on the ALS_outOfLoop_Ref.xml template).
EDIT: (Don't worry, I'm going to measure X too, but right now the beam overlap on the camera is not good, as if something drifted after Koji and Manasa closed up the PSL table)
Touched up the alignment for X on the PSL table. Current beatnotes are: [Y, -13.5 dBm, 74.1 MHz], [X, -22 dBm, 13.9 MHz]. Red is the current X out of loop, and I've saved it as the new X reference on the template.
The sum vs. pitch and yaw signals for the SRM QPD weren't making sense to me - centering on the PD lowered the sum, etc. So, I had a look at the SRM oplev setup.
The beam going in to the chamber looked fine, but the beam coming out was weird, like it was being clipped, or diffracted off of a sharp edge. The beam was spread out in yaw over almost 1cm as seen by eye. I looked into the vacuum window, and the beam was sitting on the edge of one of the in-vac steering optics. So, I adjusted the yaw of the beam-launching optic on the out of vac table so that I was roughly centered on both of the in-vac SRM steering mirrors. This required moving the first out of vac mirror for the SRM oplev path on the way to the QPD to move a small amount to one side, since the beam was near-ish the edge of the optic. I then centered the beam on the oplev (I had the SRM roughly aligned already).
Now the SRM oplev makes more sense to me. I have turned on FMs 1, 2, 5, 9 to match ITMY's loop shape. I have set the gains to -10 for pitch and +10 for yaw, to make the upper UGF about 6 Hz.
No breakthroughs tonight.
DRMI didn't want to lock with either the recipe that we used a year ago (elog 9116) or that was used in May (elog 9968). Being lazy and sleepy, I chickened out and went back to PRFPMI locking.
Many attempts, I'll highlight 2 here.
(1) I had done the CARM -> sqrtInvTrans transition, and reduced the CARM offset to arm powers of about 7, and lost lock. I don't remember now if I was trying to transition DARM to AS55, or if I was just prepping (measuring error signal ratio and relative sign).
(2) I stopped the carm_cm_up script just before it wanted to do the CARM -> sqrtInvTrans transition, and stayed with CARM and DARM both on ALS. I got to reasonably high powers, and was measuring the error signal ratios I needed for CARM -> REFL DC and DARM -> AS55. Things were too noisy to get good coherence for the DARM coefficient, but I thought I was in good shape to transition CARM to REFL DC (which looks like REFL11I, since REFLDC goes to the CM board, and the OUT2 of that board is used to monitor the input to the board. ) Anyhow, I set the offset such that it matched my current CARM offset value, and started the transition, but lost lock about halfway through. CARM started ringing up here, and I think that's what caused this lockloss. Could have been the CARM peak, which I wasn't considering / remembering at the time.
Daytime activity for Thurs: Lock DRMI, maybe first on 1f signals, but then also on 3f signals.
IP POS cable was swapped with old SP-QPD sn222 at the LSC rack. So there is NO IP POS temporarily.
This QPDsn222 will be used the HeNe oplev test for aLIGO