Summary of the work done today:
Alignment and other work on PSL table
As mentioned in a previous elog, the beatnote amplitude I obtained was tiny - so I checked the alignment of the two beams onto the PD. I did this as follows:
After doing all of this, I found a beatnote at ~-10dBm at a temperature of 45.3002 degrees on the Lightwave. The DC level was ~8V (~4V contribution from each beam).
PLL and frequency nosie measurements:
Pretty much the same procedure as that described in this elog was followed for setting up the PLL and taking the measurements, except that this time, I used the two SR560s in a better way to measure the open loop TF of the PLL. This measurement suggested a UGF of ~ 10kHz, which seems reasonable to me. I turned the 11MHz marconi off because some extra peaks were showing up in the beat signal spectrum. I judged that the beatnote was not large enough to require the use of an attenuator between the PD and the mixer. I was able to lock the PLL easily enough, and I've attached spectra of the control signal (both uncalibrated and calibrated). To calibrate the spectrum, I did a quick check to determine the actuator gain of the spare Lightwave laser, by sweeping the fast PZT with a low frequency (0.5Hz) 1Vpp sine wave, and looking at the peak in the beat signal spectrum move on the network analyzer. This admittedly rough calibration suggests that the coefficient is ~5MHz/V, consistent with the other Lightwave. Eric suggested a more accurate way to do this would be to match up spectra taken using this method and by locking the PLL by actuating on the FM input of the Marconi - I didn't try this, but given the relatively large low-frequency drifts of the beatnote that I was seeing, and that the control signal was regularly hitting ~2V (i.e shifting the frequency by ~10MHz), I don't think this is viable with a low MHz/V coefficient on the Marconi, which we found is desirable as described here.
The spare Lightwave frequency noise seems comparable to the other two measurements (see attachment #2). If anything, it is a factor of a few worse, though this could be due to an error in the calibration? I'm also not sure why the shapes of the spectra from today's measurement differ qualitatively from those in elog 11929 above ~7kHz.
Some random notes:
Before distrubing the beat setup with the spare Lightwave laser, I wanted to see if I could resolve the apparent difference in behaviour between the measured free running noise of the spare Lightwave laser and my earlier measurements with the existing X and Y end lasers above ~5kHz. So I redid the measurement, but this time, on Eric's suggestion, while taking spectra on the SR785, I was careful to maintain the same "CH1 input range" while measuring the control signal spectrum and the measurement noise spectra. The level used was -20dBvpk. I think the measured spectrum shape now makes sense - above ~4kHz, the SR560 noise means that the SNR is poor and so we can only trust the spectra up to this value (the spectra for the end lasers are from earlier measurements where I did not take care to keep the input range constant). Anyways, I think the conclusion is that the spare Lightwave seems to have a free-running frequency noise that is approximately a factor of 3 worse than the Lightwave laser at the Y-end, though this may be because I didn't take the measurement at the optimal operating conditions (diode current, power etc). But I guess this is tolerable and that we can go ahead with the planned swapping out of the existing Innolight at the X-end with this laser.
I will now move the Lightwave laser off the PSL table onto the SP table where I will do some beam characterization and see if I can come up with a satisfactory mode-matching solution for the swap. I've borrowed a beam profiler from the TCN lab for this purpose.
Lightwave NPRO information:
Serial Number: 337
Manufactured: December 1998!!
Details of checks performed:
Koji tuned the parameters on the laser controller and we observed the following:
Ericq has begun the characterization of the repaired Innolight. We checked that it outputs 1W of power. We will now have to perform the following measurements:
All of these will have to be done before installing this laser at the endtable.
I believe the consensus as of now is to go ahead with carrying out the above measurements. Meanwhile, we will keep the Lightwave NPRO on and see if there is some miraculous improvement. So the decision as to whether to use the Innolight is deferred for a day or two.
I re-measured the power levels today.
We have ~205mW out of the NPRO, and ~190mW after the Faraday. It doesn't look like the situation is going to improve dramatically. I'm going to work on a revised layout with the Innolight as soon as I've profiled the beam from it, and hopefully, by Monday, we can decide that we are going ahead with using the Innolight.
I set the limitters of the MC WFS servos not to inject the feedback more than 2000.
The residual of the WFS shakes the MC SUSs at every lock loss.
Because I keep taking a long time to search for these, since I can't remember the keywords in the different entries, here are the links:
elog 3759 : Green X end aux laser temperature setting vs. PSL laser temperature setting
elog 4439 : Green Y end aux laser temperature setting vs. PSL laser temperature setting
More words: beat note, doubling, second harmonic.
T_Xend = 8.31 + 0.9293*T_PSL
T_Yend = 6.9825 + 0.87326*T_PSL
Also, C1:GCY-SLOW_SERVO2_OFFSET was 29725 (twenty nine thousand seven hundred twenty five) cts when we sat down to start today.
C1:GCX-SLOW_SERVO2_OFFSET was 80 (eighty) cts when we sat down to start today. Why the offsets are so different, I don't know. But I was able to find the X green beatnote with this small number offset, so it is approximately correct.
nodus was rebooted by Alex at Fri Aug 14 13:53. I launched elogd.
./elogd -p 8080 -c /export/elog/elog-2.7.5/elogd.cfg -D
It looks like Alex also rebooted all of the control room computers. Or something. The alarm handler and strip tool aren't running.....after I fix susvme2 (which was down when I got in earlier today), I'll figure out how to restart those.
Alex switched the mount point for /cvs/cds on Linux1 to the 1.5 TB RAID array after he finished copying the data from old drives. This required a reboot of linux1, with all the resulting /cvs/cds mount points on the other computers becoming stale. Easiest way to fix that he found was to do a reboot of all the control room machines. In addition, a reboot fest should probably happen in the near futuer for all the front end machines since they will also have stale mount points as well from linux1.
The 1.5 TB RAID array mount is now mounted on /home of linux1, which was the old mount point of the ~300 GB drive. The old drive is now at /oldhome on linux1.
While meditating on other things, I have noticed / found the following today:
YARM ASS works okay. Yesterday I measured the sensing matrix for the ASS for both arms (although I forgot to copy one of the matrix elements to my text file for Xarm - needs remeasuring). I put the Yarm matrix in (after appropriate inversion, only non-zero pitch-to-pitch, yaw-to-yaw elements). I turned on the Yarm ASS, and the yaw converged pretty quickly (couple of minutes), with gains of -1 in the servos, overall gain of anywhere between 0.005 and 0.010. The pitch took much longer, and I had to 'pause' several times by turning off the overall gain for the yarm ass when the MC lost lock (which has happened several times tonight - unknown cause). Eventually, the pitch settled out, and quit changing, but the lockin outputs weren't zero, even though the error signal for the servos were almost zero (gains for the pitch servos were -0.5, overall gain ~0.005 was better than 0.01 - higher gain caused oscillations in the lockin outputs). I think this means that I need to remeasure the yarm pitch ass matrix. It's still much, much faster to just turn on the dithers, watch the striptool of the lockin outputs, and align the cavity by hand.
I think the ETMX Trans camera view is clipped a little bit. I went down there, and it doesn't seem to be on the last optic before the camera, and moving the spot on the camera doesn't change the shape of the image, so I don't think it's on the camera. We should look into this, since it's either clipping on the BS that separates some camera beam from the TRX beam, or TRX is getting a clipped beam too. If the clipping is any earlier in the Trans path, the Trans QPD could also have some clipping. This requires investigation. The xarm trigger needs to be reset/disabled so we don't lose lock every time we block the TRX beam (as was happening to me).
XARM really doesn't like to relock unless the POX whitening is turned off. Good flashes, doesn't really catch (10+ min waiting (while working on Yarm stuff) ). After turning off the whitening, it catches almost immediately. Even though it's on the to-do list to rethink the tuning of our whitening, we should probably implement the whitening triggering now anyway. It'll make things easier.
The double integrator that Rana implemented in the X and Y arm servo filters last week take 8 seconds to turn off (due to Foton settings), so even though they are triggered to turn off immediately upon lockloss, they sit around and integrate for 8 seconds, so have huge signals. If the cavity flashes and the locking trigger engages during that 8 seconds, we send a huge kick to the ETMs. I'm modeling the response of the filters to an impulse and noise, particularly in the case of ramping on the double integrators. The problem is that a flat filter has 0deg phase, but the double integrator has 180deg phase at low frequencies, so there's some weird sign flipping that can happen as we ramp - this is part of what I'm modeling.
MC is losing lock unusually often tonight. Everything on the servo board screen looks normal (which is good since that's all set by the autolocker). I just disabled the test exc in, but that's been left enabled for a while now, and it hasn't (I think?) been a problem since there shouldn't be anything connected to the board there. PMC transmission is a little low, 0.816, and FSS is starting to get near -1 on the slow actuator adjust, but we've seen locking of the PMC problems around -1.5 or -2 of the FSS, and the adjust value was at -0.8 earlier tonight and we still had MC locking problems. I have had the seismic channels open on Dataviewer for the last several hours, and I'm not seeing any spikes in any of the Guralp channels which correspond to the times that the MC loses lock. BLRMS don't seem particularly high, so MC lockloss cause is still a mystery for today.
The ETMX monitor selector on the VIDEO screen seems not to be switching the actual camera that's shown on the monitor. Using the script command itself works, so my screen is wrong.
I'd like to get a concrete list of measurements written down, so that it's clear what needs to be done before I graduate.
Are there things that I'm missing? I've never had an IFO to characterize before.
Here are some tests we should script.
Checking the Acromag DAC calibration is more complicated I think. There are measurements of the actuator calibration in units of nm/ct for the fast DACs. But these are only valid above the pendulum resonance frequency and I'm not sure we can synchronously drive a 10 Hz sine wave using the EPICs channels. The current test which drives the PIT/YAW DoFs with a DC misalingment and measures the response in the PDmon channels is a bit ad hoc in the way we set the "expected" response which is the PASS/FAIL criterion for the test. Moreover, the cross-coupling between the PDmon channels may be quite high. Needs some thought...
Never mind. This is just the low pass filter that Den put in to try to deal with the moving cavity pole.
Before I realized this, just in case it was a computer quirk, Koji and I rebooted the end station front end machines. This had no effect other than to keep me searching and measuring until I figured it out. If I turn off the low pass, the phase pops back up to very close to the reference. The low pass currently comes on automatically as part of the carm_cm_up script.
I need to figure this out before it's worth trying any acrobatic AO path turn-on scenarios.
Also this evening, I went to the Yend and did another tweak-up of the green beam alignment.
We opened up the little Thorlabs battery operated PD to see what was inside. Rana took some pictures, and I drew a schematic (attached). It's just a diode, biased with a battery (albeit a crazy 22.5V battery).
Comment by KA: PD is Hamamatsu S1223-01 Si PIN diode.
What a crazy battery. The main point is that it looks like this can be used for reasonable purposes: uses a load resistor on the BNC connector and you can use some pre-amp (e.g. Busby box or SR560) to have a low noise PD readout. You can also use the SR560 in its A-B mode as an 'opamp'. Ground the A input and the use a pole at 1 Hz and make the Output go into the B input through some large series resistor. The BNC from the PD gets Teed into the B input as well.
Then this becomes a transimpedance circuit readout of the diode, using the current noise of the SR560 as the limit.
I tried to figure out why offline LMS filter subtract seismic noise much better from MC_F then the Wiener filter. I did the calculations twice - with my codes and with Matlab in-build functions, the results are the same. So this is not a code error.
The coherence between GUR 1, 2 and MC_F is still poor. Wiener filter is linear and its performance is confined to the frequency ranges where we see coherence. Lms filter is non-linear and it may be possible to subtract the noise even if non-linear effects are present in the system.
I've checked seismometer readout box again. I've soldered 50 Ohms to plus and minus inputs to VERT 1,2 N/S 1,2, E/W 1,2 - GUR 1 and 2 use these channels. Then I put the box back and connected it to the ADC.
The plot shows that the readout box noise is below the ADC noise. It is possible that amplifiers introduce non-linear effects. To check this I plotted the coherence between OSEM sensors and GUR1X signal:
The coherence between OSEM sensors and GUR1X is pretty good, so may be witness path is not responsible for low coherence at 0.1 - 0.5 Hz between MC_F and GUR 1,2. IT seems that MC_F is bad at low frequencies. I terminated the input to the Channel 1 of the Pentek Generic board, where MC_F is plugged in.
ADC is also good. Something else is wrong.
Larry and Nicolas
Larry's transfer function measurements suddenly started returning 0dB 0degrees when before there was some fake filter in the C1:ALS-OFFSETTER2 filter bank.
We looked in the filter bank and his filter was gone. So I created a new filter called LARRYP in FM2. We also disabled the output so he could drive the filter bank and test his TF code.
I'll bring a file binder "40m wiring diagram" to home at the next chance.
There is another one on the shelf in the control room.
(I thought I put it in my bag, but it looks like that I left it somewhere around the fax area)
Koji has provided a 2TB USB3 external hard drive that will get daily backups of chiara:/home/cds, the idea being that if the internal HD at /dev/sdb1 fails, we can physically open the external up, and swap the hard drive into chiara.
We're running an rsync job on it right now, which should be done in a few hours. (USB3 is fast!)
I've also written a backup script at scripts/backup/rsync_chiara.backup which keeps its books in scripts/backup/rsync_chiara.backup.log
I'm adding a entry to the root crontab on chiara to execute the script every day at 7am.
I had some syntax errors in the script that prevented the script from doing the right thing. The backup is now up to date, and the cronjob should work.
We found that the caput commands were taking much longer to execute on megatron than on pianosa (for example). Suspecting that this had something to do with the fact that megatron was using EPICS binaries from the shared NFS drive which were compiled for a much older OS, I installed the latest stable release of EPICS on megatron. The new caput commands execute much faster. I also added the local EPICS directory to the head of the $PATH variable used by the MC autolocker and FSS Slow scripts, so that they use the new caput command. But mcup is still slow - maybe my new path definition isn't picked up and it is still using the NFS binaries? To be looked into...
There were a bunch of medm processes stalled on megatron (connected with screenshot taking). To see if they were interfering with the other scripts, I killed all of the medm processes, and commented out the line in the crontab that runs the screenshots every 10 mins. Let's see if this improves stability.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "en_US.ISO8859-1",
LC_MONETARY = "en_US.ISO8859-1",
LC_CTYPE = "en_US.ISO8859-1",
LC_COLLATE = "en_US.ISO8859-1",
LC_MESSAGES = "C",
LC_NUMERIC = "en_US.ISO8859-1",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Between the 40m meeting, and chatting with Gabriele, there was lots of talking yesterday about our 40m Lock Acquisition game plan.
From those talks, here is my current understanding of the plan, in a Ward-style cartoon:
(This is a 2 page document - description of steps is on 2nd page)
If you look closely, you will notice that there are several places that I have used "?" rather than numbers, to indicate what RFPD signal we should be using. To fill these in, I need to look at some more simulations, and think more carefully about what signals exist at what ports, and what SNR we have at each of those ports.
Also, while the overall scale of the arm power plot is correct, the power level at each step is totally arbitrary right now, and should just be taken to mean places (in time) where the CARM offset is reduced a little more.
There are several things at this point that we know we need to look into:
* POP 22/110 PD and filtering electronics should be switched to a broadband PD, rather than the Thorlabs PD + Miniciruits filters. (Hardware)
* Whitening for the transmission QPDs needs to be thought about more carefully. (Calculation, then hardware)
* Chose a good SNR REFL DC signal, which may or may not be from the PD we are currently using (I think it's the DC of REFL11, but I'll have to check). (Calculation)
* For DRMI locking, what is the size of the SRCL error signal at AS55, AS165, and the REFL ports? Do we need to lock with AS port, and then switch over to a REFL 3f port, to make acquisition easier? (Simulation)
* Similarly, I want to make the equivalent of Figure 3 of T1000294, with our 40m parameters. (Simulation)
* To set the phase of AS110, simulate the demod phase of AS110 in both DRMI and SRMI cases. If no (significant) change, maybe we can set the phase in the real system by misaligning the PRM, and watching the SRMI flash. (Simulation)
* Simulate an arm sweep, up to many orders of the sidebands, to see how close to the carrier resonance any sideband resonances might be. If something like the 4th order sideband resonates, and then beats with a 1st order sideband, is that signal big enough to disturb our 3f locking of the PRMI / DRMI? We want to be holding the arms off resonance with ALS closer to the carrier than any "important" sideband resonances (where the definition of "important" is still undetermined). (Simulation)
* Check if we can hand DARM from the DC transmission signals to the final RF signal while we still have a large CARM offset. Is there a point where the CARM offset is too large, and we must be still using the DC signals? (Simulation)
* At what arm power level can we transition from ALS to IR DC transmission signals for the individual arms? (Simulation)
* Still need to finish calculating what could be causing our big arm power fluctuations (Test mass angular motion? PRM angular motion? ALS noise?) (Calculation)
Replys, and comments are welcome, particularly to help me understand where I may have (likely did) go wrong in drawing my cartoon.
Here is a lock loss from around 11 PM tonight. Might be due to poor PRC signals.
This is with arm powers of ~6-10. You can see that with such a large MICH offset, POP22 signal has gone done to zero. Perhaps this is why the optical gain for PRCL has also dropped by a factor of 30 .
This seems untenable . We must try this whole thing with less MICH offset so that we can have a reasonable PRCL signal.
Provided the IMC is cooperative, the input pointing isn't drifting, and the RF offsets aren't jumping around too much, the locking sequence is now pretty robust.
Most of the analysis uses data between the GPS times 1274418176 and 1274419654 that are recorded to frames.
Here, I provide some details of the sequence. Obviously, I am presenting one of the quickest transitions to the fully locked state, I don't claim that every attempt is so smooth. But it is pretty cool that the whole thing can be done in ~3 minutes.
See Attachment #1 for the labels.
This particular lock held for ~20 minutes so I could run some loop characterization measurements etc.
I am struggling to explain:
I see. At the 40m, we have the direct transition from ALS to RF. But it's hard to compare them as the storage time is very different.
Which 1f signals are you going to use? PRCL has sign flipping at the carrier critical coupling. So if the IFO is close to that condition, 1f PRCL suffers from the sign flipping or large gain variation.
For these initial attempts, I was just trying to transition MICH to REFL55Q. I agree, the PRCL situation may be more complicated.
Thursday morning I found the control room emergency exit not locked.
Please check the doors when leaving the lab , specially when you are the last one out.
I finally managed to get long stretches of PRMI lock, up to many minutes. The lock is not yest very stable, it seems to me that we are limited by some yaw oscillation that I could not trace down. The oscillation is very well visible on POP.
Presently, PRCL is controlled with REFL55_I, while MICH is controlled with AS55_Q. This configuration is maybe not optimal from the point of view of phase noise couplings, but at least it works quite well. I believe that the limit on the length of locks is given by the angular oscillation. I attach to this entry few plots showing some of the lock stretches. The alignment is not optimal, as visible from a quite large TEM01 mode at the dark port.
Here are the parameters I used:
MICH gain -10 PRCL gain -0.1
Normalization of both error signal on POP22_I with factor 0.004
Triggering on POP22: in at 100, out at 20 for both MICH and PRCL.
POP55 demodulation phase -9
MICH and PRCL control signal limits at 2000 counts
There is a high frequency (628 Hz) oscillation going on when locked (very annoying on the speakers...), but reducing the gain made the lock less stable. I could go down to MICH=-1.5 and PRCL=-0.02, still being able to acquire the lock. But the oscillation was still there. I suspect that it is not due to the loops, but maybe some resonance of the suspension or payload (violin mode?). There is still some room for fine tuning...
Lock is acquired without problems and maintained for minutes.
Have a nice week-end!
Our first move has to be fixing the whitening switching for REFL55. That's the configuration we need to start and then move onto REFL165 to get to FPPRMI.
I put a notch in FM10 for both MICH and PRCL at 628Hz, to try to prevent us from exciting the mode that Gabriele saw on Friday. Since those filter banks were all full, I have removed an ELP50 (ellip("LowPass",4,1,40,50)). I write it down here, so we can put it back if so desired.
I was going to try some locking, but things are a little too noisy.
Just so Kiwamu knows what I did today, in case he comes back....
I ran LSCoffsets, and aligned both X and Y arms and saved their positions, and aligned MICH, and saved the BS position.
I'll play with it more later, when there aren't trucks driving around outside that I can hear / feel in the control room.
After giving up on locking, the MC is getting unlocked every now and again (2 times so far in the last few minutes) from transient seismic stuff.
Could not load filters into the C1:SUS-ETMX_LOCKIN1_SIG filter bank.
Apparently the filter bank name was too long. I'm not sure why this isn't caught by the real time code generator, I'm planning on asking Alex and Rolf about it today.
Reduce the name of the components. Basically LOCKIN1 needs to become something like LOCK1 or LIN1.
In related news, it looks like the initial filters are hard coded to be 2048 Hz. Given that they start out empty they won't cause things to break immediately, and if you're editing the file you can update the rate as you add the filter. I'll also bring this up with Alex and Rolf and see if the RCG can't be more intelligent about its filter generation.
we decided to give the PRFPMI lock a go early-ish. Summary of findings today eve:
The ALS--> IR CARM handoff is the problematic step. In the past, getting over this hump has just required some systematic loop TF measurements / gain slider readjustments. We will do this in the next few days. I don't think the ALS noise is any higher than it used to be, and I could do the direct handoff as recently as March, so probably something minor has changed.
Main goals tonight were:
I took a look at the TRX/TRY RIN reported in the single arm POX/POY lock, and compared the performance of the two available PDs at each of the two ends. Attachment #1 shows the results. Some remarks:
Some ideas Koji suggested:
For the second idea, it is convenient to be able to control the arms in the XARM/YARM basis as opposed to the CARM/DARM basis as we usually do when going through the locking sequence. After some fiddling, I am able to reliably execute this transition, and achieve a state where the FP arm cavities are resonant for the IR with the ALS beat note frequency being the error signal being used. Some important differences:
We were able to lock the Y-arm using Megatron and the RCG generated code, with nothing connected to c1iscey.
All relevant cables were disconnected from c1iscey and plugged into the approriate I/O ports, including the digital output. Turns out the logic for the digital output is opposite what I expected and added XOR bitwise operators in the tst.mdl model just before it went out to DO board. Once that was added, the Y arm locked within 10 seconds or so. (Compared to the previous 30 minutes trying to figure out why it wouldn't lock).
[Jenne, Rana, EricQ]
We tried a few times to engage the AO path while holding CARM on sqrtTrans and DARM on ALS, but failed every time. Since we cannot stably hold lock at arm powers of 1, even though we were able to do so early last week, we think that we have a problem (obviously). One noticeable thing is that while held with ALS, the Xarm transmission fluctuates almost full power.
As we were seeing late last week, the Xarm IR transmission while held with ALS was fluctuating wildly, whether we were locked on individual arms or on CARM/DARM.
Tonight we took some out of loop spectra, with different HEPA settings, to see how that affected things. It looks like HEPA at the nominal ~20% is okay, but anything higher than that starts to affect the Xarm beatnote sensing, while it mostly leaves the Yarm beatnote sensing okay. Perhaps this is something that isn't tightened enough in the Xarm path, or something on a skinny floppy mount that needs to be more secure.
I am still a little confused though, why we don't see large power fluctuations in *both* arms while using ALS to control CARM/DARM. Why are we not seeing this Xarm noise being fed back into the Yarm, through either the ETM via DARM, or common stuff via CARM actuating on MC2.
Note that the change at high frequency is because I switched from using non-DQ channels to DQ channels, so that's not anything to pay attention to. The noise reduction we see is below about 20Hz.
Rana pointed out that our POPDC level was very small. We don't have screens for them, but the DC PDs have the same analog whitening as the RF PD signals do. I changed C1:LSC-POPDC_WhiteGain.VAL from 0 to 11. Now our POPDC while locked on sidebands is about 8,000 counts.
We also swapped the cables between the SR785 and the CM board around. Now channel 2 of the 785 goes to TP2A, channel 1 goes to TP2B, and the source goes to EXCB. This is so that we can break the AO loop with the disable switch just after the slow/fast split, and look at the transfer function before we close the loop.
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.