If the optics moved such amount, could you check the PD alignment once the optics are aligned?

I've done a few things to start waking up the IFO after it's week of conference-vacation.

PMC trans was at 0.679, aligned the input to the PMC, now it's up at 0.786.

MC transmission was very low, mostly from low PMC transmission.  Anyhow, MC locked, WFS relieved so that it will re-acquire faster.

Many of the optics had drifted away. AS port had no fringing, and almost every optic was far away from it's driftmon set val.  While putting the optics back to their driftmon spots, I noticed that some of the cds.servos had incorrect gain.  Previously, I had just been using the ETMX servo, which had the correct gain, but the ITMs needed smaller gain, and some of the optics needed the gain to be negative rather than positive.  So, now the script ..../scripts/SUS/DRIFT_MON/MoveOpticToMatchDriftMon.py has individually defined gains for the cds.servo. 

Next up (after lunch) will be locking an aligning the arms.  I still don't have MICH fringing at the AS port, so I suspect that the ASS will move some of the optics somewhat significantly (perhaps the input tip tilts, which I don't have DRIFT_MON for?)

Are the two  visible small srews holding the adapter plate only?

If yes, it is the weakest point of the IOO path.

           March  19, 2015   2  new  JDSU 1103P, sn P919645 & P919639 received from Thailand through Edmond Optics. Mfg date 12/2014............as spares

Polaris mounts ordered.

The autolocker was struggling to lock the IMC. I disabled the autolocker and locked the IMC manually. It seems happy right now. 

With PMC trans at 0.717 counts, the IMC trans sum is ~15230.

I have modified the DARM model from elog 11133, to include the fact that these are digital filters.

I have also extracted the data from elog 11143, and it together with the model.

The modeled loop has an arbitrary gain factor, to make it have the same 234Hz UGF as the measured data.

The modeled loop includes:

• Actuators
  • Pendulum (1Hz, Q of 4)
  • Violin filters
    • ETMs 1st, 2nd, 3rd order
    • MC2 1st, 2nd order
  • 3 16kHz delays for computation on the rfm model, transfer to the end sus models, and computation on end sus models.
  • Digital anti-imaging to get up to the IOP model
  • Delay of 64kHz for computation on IOP model
  • Analog anti-imaging
• Plant
  • Single 4.5kHz pole
• Sensor
  • Analog anti-aliasing
  • 64kHz delay for computation on IOP model
  • Digital anti-aliasing to get to LSC model rate
• Loop Shape (digital filters extracted from Foton file using FotonFilter.m)
  • DARM B's integrator (FM7)
  • DARM's low freq boost (FM3)
  • DARM's locking filter (FM5)
  • DARM's bounceRoll filter (FM6)
  • DARM's new lead filter (FM7)
  • Delay of 16kHz for computation on LSC model (includes Dolphin hop to c1sus rfm model)

There is a 1.5 degree phase discrepancy at 100Hz, and an 11 degree phase discrepancy at 900Hz, but other than that, the modeled and measured loops match pretty well.

For the measured frequencies, here are the residuals:

[Jenne, Koji, Rana]

Thanks to turning off the AS55 analog whitening as well as the 1k:6k lead filter that Koji put into Darm's FM7, the DARM transition was more stable early in the evening.

The AS55 gain and offset did not change noticeably when we switched the AA on or off (switching happened while *not* using AS for any feedback).  Earlier in the evening, we did also check what happened with PRMI and REFL33 AA on vs. off, and REFL33 did have a many tens of counts offset on both the I and Q input channels.  I have turned the AA filters back on, but run LSCoffsets before trying to lock.

I'm not sure what was up, but somehow I couldn't lock the PRMI for about half an hour or so.  Very frustrating.  Eventually after futzing around, I was able to get it to lock with REFL33 in PRMI-only, and after that it worked again in PRFPMI with REFL165. 

With FSS slow around 0.5, MC has been a bit fussy the last hour.  Also frustrating.

Later on in the evening, I started taking out a bunch of the "sleep" commands from the up script, and many of the "press enter to continue" spots, but I think it might be moving too fast.  That, or I'm just not catching where I have too much gain.  Anyhow, near the middle/end of the CARM transition I am getting severe gain peaking at several hundred Hz.  I think I need to use a lower final gain.

So, progress on DARM, but maybe a little more fine-tuning of CARM needed.

Here's a DARM loop measurement, taken after both CARM and DARM were RF-only:

DARM_RF-only_13Mar2015.pdf

The oplev situation still seems unresolved - notice this DTT. I guess there are still inconsistencies in the screens / models etc.

Could use some some investigation and ELOGGING from Eric.

Another thought about the mystery PCDRIVE noise: we've been thinking that it could be some slow death inside the NPRO, but it might also be a broken and intermittent thing in the MC servo or MC REFL PD.

Another possibility is that its frequency noise in the old oscillator used to drive the pre-PMC EOM (which is the Pockel Cell for the FSS). To check this, we should swap in a low noise oscillator for the PMC. I have one for testing which has 36 and 37 MHz outputs.

Since the DARM_OUT signal is only 500 counts_peak, I don't see why AS55 whitening needs to be switched on. Maybe in a couple weeks after the lock is robust. In any case, its much better to do the switching BEFORE you're using AS55, not after.

Much more success tonight.  I only started my tally after I got the CARM transition to work entirely by script, and I have 6 tally marks, so I probably made the CARM to RF-only transition 7 or maybe 8 times tonight in total.  Unfortunately, I only successfully made the DARM transition to AS55 once.    From the wall striptool, counting the number of times the transmitted power went high, I had about 40 lock trials total. 

The one RF-only lock ended around 1:27am.

I think 2 things were most important in their contributions to tonight's success.  I modified the bounceRoll filters in the CARM and DARM filter banks to eat less phase.  Also, using Q's recipe as inspiration, I started engaging the AO path partway through the CARM transition which makes it much less delicate. 

Bounce roll filter

Koji and I added a ~29Hz resonant gain in the bounce roll filter several months ago, to squish some noise that we were seeing in the CARM and DARM ALS error signals.  This does a lot of the phase-eating.  I'm assuming / hoping that that peak won't be present in the CARM and DARM RF error signals.  But even if it is, we can deal with it later.  For now, that peak is not causing so much motion that I require it.  So, it's gone. 

This allowed me to move the complex zero pair from 30 Hz down to 26 Hz.  Overall I think this gained me about 10 degrees of phase at 100Hz, and moved the low end of the phase bubble down by about 10Hz. 

Prep for REFL 11 I through the CM board and CM_SLOW

In order to use Q's recipe (elog 11138), I wanted to be able to lock CARM on REFL11 using the CM_SLOW filter bank. 

I did a few sweeps through CARM resonance while holding on ALS, and determined that the REFL1 input to the CM board needed a gain of -20dB in order to match the slope of CM_SLOW_OUT to CARM_IN (ALS), leaving all of Q's other settings alone.  Q had been using a REFL1 gain of 0dB for the PRY earlier today.

I needed to flip the sign in the input matrix relative to what Q had (he was using +1 in the CM_SLOW -> CARM_B, I used -1 there).  To match this in the fast path, I flipped the polarity of the CM board (Q was using minus polarity, I am using positive).

The CM_SLOW filter bank had a gain of 0.000189733.  I assume that Q did this so that the input matrix element could be unity.  I left this number alone.  It is of the same order as the plain REFL11I->CARM input matrix element of 1e-4 from Saturday night, so it seemed fine.

During my sweeps through CARM resonance, I also saw that I needed an offset to make CM_SLOW's average about 0.  With the crazy gain number, I needed an offest of -475 in the CM_SLOW filter bank.  As I type this though, it occurs to me that I should have put this in the CM board, since the fast path will have an offset that isn't handled.  Ooops. 

Trying Q's recipe for engaging AO path

I am able to get the MC2 AO gain slider up to -10dB (-7 is also okay).  If I increase the digital CARM gain too much, I see gain peaking at about 800Hz, so something good is happening.  (That was with a CARM_B gain of 2.0 and CARM_A gain of 0.  Don't go to 2.0)

I tried once without engaging his 300:80 1/f^2 filter in the CM_SLOW filter banks to start stepping up the CM REFL1 and MC AO gains together, but I only made it 2 steps of 1dB each before I lost lock. 

I tried once or twice turning on that 300:80 filter that Q said over the phone really helped his PRY locking, but it causes loop oscillations in CARM.  Also, I forgot to turn it off for ~45 minutes, and it caused several locklosses.  Ooops.  Anyhow, this isn't the right filter for this situation.

AS55 whitening problem

Twice I tried turning on the AS55 whitening.  Once, I was only partly transitioned from ALSdiff to AS55, the other time was the one time I made the full transition.  It caused the lockloss from the only RF-only lock I had tonight :(

Unfortunately I don't have the time series before the whitening filters (not _DQ-ed), but you can see a giant jump in the _ERR signals when I turn on the whitening, just before the arm power dies:

AS55whitening_lockloss_12March2015.pdf

The AS55 phase is -30, I has an offset of 28.2 and Q has an offset of 6.4.  Both have a gain of 1.  This should give us enough info to back out what the _IN1 signals looked like before I turned on the whitening if that's useful.

Other random notes

Ramp times for CARM_A, CARM_B, DARM_A and DARM_B are all 5 seconds.  This is set in the carm_cm_up script.

carm_cm_up script freezes the arm ASS before it starts the IR->ALS transition, to make it more convenient to run the ASS each lockloss.

carm_cm_up script no longer has a bunch of stuff at the bottom that we're not using.  It's all archived in the svn, but the remnants from things like variable finesse aren't actively  useful.

carm_cm_down script turns off the CM_SLOW whitening (which gets set in the up script)

carm_cm_down script clears the history of the ETM oplevs, in case they went bad (from some near divide-by-zero action?), but the watchdog isn't tripped. This clears away all the high freq crap and lets them do their job.

FSS Slow has been larger than 0.55 all night, larger than 0.6 most of the night, and larger than 0.7 for the last bit of the night.  MC seems happy.

both carm_cm_up and carm_cm_down are checked into the svn.  The up script is rev 45336 and the down script is 45337.

Some offset (maybe the fact that the fast AO path had an un-compensated offset?) is pulling the arm powers down as I make the transitions:

Recipe overview

• Lock PRMI with arms held on ALS at 3nm CARM offset.  Bring CARM offset to 0.
• Turn on CARM_B and DARM_B a little bit, then turn on their integrators
• Lower the PRCL and MICH gains a little.
• Increase the CARM_B gain a bit, then turn off FM1 for both CARM and DARM.
• Increase CARM_B gain, lowering CARM_A gain.
• Increase DARM_B gain, lowering DARM_A gain.  Now the power should definitely be stable (usually ends up around 80).
• Partly engage AO path.
  • CM board REFL1 gain = -20dB
  • CM board AO gain = 0dB
  • MC2 board AO gain starts at -32dB, stepped up to -20dB
• Increase CARM_B gain a bit
• More AO path:  MC2 board AO gain steps from -20dB to -10dB
• Increase CARM_B gain to 1.5, turn CARM_A gain to zero
• CM_SLOW whitening on

After that, I by-hand made the DARM transition on the 6th successful scripted CARM transition, and tried to script what I did, although I was never able to complete the DARM transition again.  So, starting where the recipe left off above,

• Turn off DARM's FM2 boost to win some more phase margin.
• Increase DARM_B gain to 0.5, lower DARM_A gain to 0.

Since DARM doesn't have an analog fast path, it is stuck in the delicate filter situation.  I think that I should probably start using the UGF servo once the arm power is stable so that DARM stays in the middle of its phase bubble.

Rather than typing out the details of the recipe, I am attaching the up script.

Q doesn't like elogging, but he sent me this nice detailed email, so I'm copying it into the log:

I’ve locked the power recycled Y arm numerous times today, to try and find a usable AO recipe for the full locking.

BTW, during this trouble shoot, we looked at the IR beatnote spectrum between the Xend and the PSL.
It showed a set of sidebands at ~200kHz, which is the modulation frequency.
There was another eminent component present at ~30kHz.
I'm afraid that there is some feature like large servo bump, a mechanical resonance, or something else, at 30kHz.

We should check it. Probably it is my job.

No wins tonight.

I've tried playing with the shapes of the loops a little bit (mostly CARM so far), to no avail.  I think I made it to CARM RF-only only one time tonight.  I was able to turn on the REFL11 whitening, although I lost lock while about halfway through the DARM transition. 

I tried making a double integrator instead of a single integrator for CARM_B, since that would allow me to make a complex zero pair which could help win back some phase. I also tried just straight copying FM1 from CARM into CARM_B, so that it could be turned off for the ALS part of the loop, but left on for the REFL part, but that didn't work very well.  Like Rana and I saw last Friday, we really need the REFL signal to have a true integrator, to force the PDH signal toward zero, before we can complete the transition.

I moved the cavity pole compensator's zero back up to 120 Hz, since that was what had worked on Saturday night.  That helped me get farther before running into gain peaking problems at ~50Hz.  This is because, as seen in my simulation earlier tonight, I win back some gain margin by having the pole compensator more closely matched with the pole frequency.

I've been turning off both FM1 and FM2 in CARM and DARM.  I think this is helping a lot, when I can get far enough to do so.  I don't want to turn off the second boost until after I'm about 50/50 on REFL.  (When  I have that much REFL, with the true integrator, the PDH signal sticks to zero).

I tried once turning off the bounce/roll filters for CARM and DARM, rather than the FM1 boost, since the bounce roll filters eat lots of phase, but I got pushed off resonance.  I think not having that focused boost may have made my overall RMS larger, which caused me to randomly jump too far outside of the good PDH range.

Early on in the evening, I turned off the MC2 violin filters in the ETM LSC-SUS filter banks, since I am actuating on only the ETMs tonight. However, I saw a violin mode ring up at ~642, which showed up in POX but not POY.  This was causing up-conversion, beating against the 40-50Hz buzzing from the IR resonance.   The MC2vio1,2 filter covers this frequency (because it's an absurdly wide notch), but the EXYvio1 filter does not.  There seems to be some confusion on the wiki as to what the ETMX violin mode frequency is - it says 631 (638??).  The notch that is in the EXYvio1 filter is for 631 Hz, but this is not correct.  DAYTIME self: Make the MC2 violin filter smaller than 40Hz(!) wide, and move the ETMX notch up to the correct frequency.  For tonight, I just turned back on the MC2 filter, and the mode has rung down.

Idea:  MICH offset, or ETM misalignment, enough to keep the power recycling low-ish, so that the CARM cavity pole doesn't come down too far in frequency?  Daytime brain should think about this.

There is a frequency counter code written by the summer student.
The code needed some cleaning up.
It's still there in /opt/rtcds/caltech/c1/scripts/FOL as armFC.c

This code did not provide unified way to send commands to the FCs.
Therefore I made a code to change the frequency range of the FCs
by removing unused variables and instructions, adding more comments,
adding reasonable help messages and trouble shooting feedbacks.

Obviously these codes only run on domenica (raphsberry Pi host)

/opt/rtcds/caltech/c1/scripts/FOL/change_frange

change_frange : change the freq range of the frequency counter UFC-6000

Usage: ./change_frange DEVICE VALUE
    DEVICE: '/dev/hidraw0' for Xarm, '/dev/hidraw1' for Yarm
    VALUE:
0 - automatic
1 -    1MHz to   40MHz
2 -   40MHz to  190MHz
3 -  190MHz to 1400MHz
4 - 1400MHz to 6000MHz

I made very rough calibration of the DARM spectra before and after the transition for the second lock on Mar 8.

The cavity pole (expected to be 4.3kHz) was not compensated. Also the servo bump was not compensated.

[Error calibration]

While the DARM/CARM were controlled with ALS, the calibration of them are provided by the ALS phase tracker calibration.
i.e 1 degree = 19.23kHz

This means that the calibration factor is

DARM [deg] * 19.23e3 [Hz/deg] / c [m Hz] * lambda [m] * L_arm [m]
= DARM* 19.23e3/299792458*1064e-9*38.5 = 2.6e-9 *DARM [m]

[Feedback calibration]

Then, the feedback signal was calibrated by the suspension response (f=1Hz, Q=5)
so that the error and feedback signals can match at 100Hz.

This gave me the DC factor of 5e-8.

The spectra at 1109832200 (ALS only, even not on the resonance) and 1109832500 (after DARM/CARM transitions) were taken.
Jenne said that the whitening filters for AS55Q was not on.

I have looked at the CARM and DARM RF loops, assuming the loop shapes that we've been using, and it pretty much looks like a miracle that we were ever able to make the transition.  The CARM and DARM loops are very marginal.

The ALS CARM loop was already pretty close to marginal, but we lose an extra 12 degrees of phase with the REFL loop:

• -4 deg because REFL has analog AA, but ALS does not.
• -6 deg because FM1 is designed to have minimal phase loss at 100Hz, but the REFL integrator is not.
• -2 deg because the cavity pole compensator must have a zero at finite frequency.

However, if our cavity pole compensator's zero frequency is too low, we get all of that phase back, at the sacrifice of 2dB of gain margin at both ends of the phase bubble.

I looked at an Optical simulation to check what the cavity pole frequencies are expected to be, with the losses that we've measured.  In both cases, I assume the Xarm has about 150ppm of loss.  The DARM cavity pole is about 4.5kHz no matter what the Yarm loss is.  The CARM cavity pole is about 172 Hz if the Yarm has 500ppm of loss, or 120 Hz if the Yarm has 200ppm of loss.

In the plots below, I use a CARM cavity pole frequency of 150 Hz, to roughly split the difference.

Edit, 13Mar2015, JCD:  Rana points out to me that I was using from Foton the analog design strings, without including the fact that these are actually digital filters. This means that I am missing some phase lag.  Eeek.

The ALS loop includes:

• Actuator
  • 3 16kHz computation cycles (includes computer hops)
  • Pendulum
  • Analog anti-imaging
  • Digital anti-imaging
  • 1 64kHz computation cycle
  • Violin filters: ETM 1st, 2nd, 3rd order notches
• Plant
  • Flat, not including the cavity pole at ~17kHz
• Sensor
  • Closed loop response of phase tracker
  • Digital anti-aliasing
  • 1 64kHz computation cycle
  • 1 16kHz computation cycle
• Servo (CARM filter bank)
  • FM1
  • FM2
  • FM3
  • FM5
  • FM6
  • 1 16kHz computation cycle

The REFL loop includes:

• Actuator
  • 3 16kHz computation cycles (includes computer hops)
  • Pendulum
  • Analog anti-imaging
  • Digital anti-imaging
  • 1 64kHz computation cycle
  • Violin filters: ETM 1st, 2nd, 3rd order notches
• Plant
  • 150 Hz cavity pole
• Sensor
  • Analog anti-aliasing
  • Digital anti-aliasing
  • 1 64kHz computation cycle
• Servo (CARM_B filter bank and CARM filter bank)
  • Cavity pole compensator
  • Integrator (20:0)
  • FM2
  • FM3
  • FM5
  • FM6
  • 1 16kHz computation cycle

The first plot is the case of perfectly matched cavity pole and compensating zero (150Hz, with compensator having 3kHz pole):

This next version is the case where the compensating zero is a little too low, which is the case I think we have now:

The last plot is a DARM loop.  Everything is the same, except that the RF plant has a 4.5kHz pole, and no compensation:

I was around the 1Y1 rack today. Trials were done to get the PDFR of AS55.

Green glass for aLIGO OMC shield is temporarly stored in the inside of the Y-arm.

I have successfully backported the cdsRampMuxMatrix part for use in our RCG v2.5 system. This involved grabbing new files, merging changes, and hacking around missing features from RCG 2.9. 

The added/changed files, with relative paths referred to /opt/rtcds/rtscore/release/src/, are:

• M include/drv/tRamp.c
  • New C functions to directly report current ramping value and ramping state 
• M epics/util/feCodeGen.pl
  • Added if statements to main simulink parser to properly handle the part
• AM epics/util/lib/RampMuxMatrix.pm
  • New Perl script that writes the frontend code for a given ramp matrix
• A epics/util/mkrampmatrix.pl
  • New perl script that creates the default MEDM screen
• A epics/simLink/lib/cdsRampMuxMatrix.mdl
  • Simulink block for the part
• M epics/simLink/CDS_PARTS.mdl
  • Added block and doc for the part (which is missing an underscore in its definition of EPICS field names)

[A means the file was added, M means the file was modified]

Most of the trouble came from the EPICS reporting of the live ramping value and ramping state, since this depended on some future RCG value masking function. I had to rewrite the C-code writing perl script to define and update these EPICS variables in a more old-school way. 

This leaves us vunerable to the fact that a user/program can directly write to the live matrix element and ramping state, which would cause bad and unexpected behavior of the matrix.

So, when using a ramping matrix: NEVER WRITE to [MAT]_[N]_[N] as you would for a normal matrix. Use [MAT]_SETTING_[N]_[M] and trigger [MAT]_LOAD_MATRIX.

Similary, [MAT]_RAMPING_[N]_[N] is off limits. 

I tested the new part in the c1tst model. There are two EPICS input (TST-RAMP1_IN and TST-RAMP2_IN) that are the inputs to a 2x2 ramp matrix called TST-RAMP, and the outputs go to two testpoints (TST-RAMP1_OUT and TST-RAMP2_OUT) and two epics outputs (TST-RAMP1_OUTMON and TST-RAMP2_OUTMON). You can write something to the inputs from ezca or whatever, and use the C1TST_RAMP.adl medm screen in the c1tst directory to try it out. The buttons turn red when you've input a new matrix, yellow when a ramp is ongoing and green when the live value agrees with the setting. 

At this time, I have not rebuilt any of our operational models in search of potential issues.

I have created backups of the files I modified, such that a file such as feCodeGen.pl was renamed feCodeGen.40m.pl, and left next to the modified file. I am open to more robust ways of doing the backup; since our RCG source is an svn checkout of the v2.5 branch (with local modifications, to boot), I suppose we don't want to commit there. Maybe we make a 40m branch? A seperate repo? 

[Koji, Manasa]

This problem was solved by changing the Frequency Counter range settings.

Frequency counter automatic range setting has been modified and now the range can be manually set depending on the input frequency. New codes have been written to do this. The scripts will be polished and wrapped up shortly.

PMC was locked in a bad state. FSS slow actuator adjust was at ~ -0.7 and PZT voltage at ~45.

So I set these right by moving the appropriate sliders and relocked it. FSS slow actuator adjust brought back to zero and PZT voltage ~115. PMC trans after relock is 0.789.
 

[Q, J]

Not much luck locking tonight; we made the RF transition to CARM numerous times, but it never lasted more than a minute or so. We were able to take a couple of loop and spectrum measurements as we transistioned. 

Here are some spectra showing the noise evolution of CARM_IN1 and DARM_IN1 as we start to transition CARM to RF. We did not manage to grab spectra while CARM was RF only; we can go back in the DQ to find some data. 

As we transition, our phase bubble is shrinking, which may explain our poor stability. On the following plot, I actually mistyped the legend. The cyan trace is ALL RF. I'm not sure why we have a 1/f^2 shape from 100->200Hz. 

[

We adjusted the pole compensation frequency by looking at REFL11/ALS during a CARM swept sine measurement, the -3db/-45degree point looked more like 80Hz. Strangely, the compensated REFL11 signal appears to lag the ALS signal around the UGF. Maybe this is a loop effect? 

In terms of practical improvements, I've written a script that reliably transitions from POX/POY IR lock to ALS CARM/DARM lock already on resonance. This is saving us a bunch of time. I've svn'd the new ALS script and the new carm_cm_up that uses it. 

We looked into the odd oplev behavior as well. We had earlier seen what looked like railed values on the FM output medm screen (which seemed unexpected for an AC coupled loop), but dataviewer showed it was actually ringing/railing at some 10+Hz as the oplev beam fell off the QPD. The ringing continues even after the quadrant values stop crossing zero, so I think it may be the filters themselves misbehaving. Why there is new behavior here is still beyond me. 

We lost a fair bit of time to a fussy mode cleaner tonight; there was a good 45 minute stretch where it refused to lock for more than a minute or so, the PC drive angriliy never falling below 5. The thing I changed when it started working was using the fast C1:IOO-MC_F channel instead of the slow C1:IOO-MC_FAST_MON as a readback for the FSS input offset; oddly there is a DC difference between the two. This has resulted in a FSS offset of ~4.2, whereas it was previously ~1.8. After this change, the PC drive fell to ~1.0 levels, and the IMC has been mostly ok. 

Given our problems stabilizing the RF lock, we attempted to give the FOOL path a shot, since we now had a better idea of the neccesary REFL11 gain. In short, no luck. Every attempt to use some RF signal just disturbed the lock further. We didn't really pursue it too much after a couple of attempts showed little promise. 

Back on Feb 20th (elog 11056) Q replaced all of our oplev parts with the aLIGO version. 

Unfortunately, after this it has seemed like there was something not quite right with the optical lever servos.

• When we would restore kicked optics, after the osem rms values come down the scripts try to engage the optical levers.  This would often kick and ring up the optics (I've seen this with ETMX and ETMY, and once or twice with the beam splitter)  Not good.
• Sometimes, if the optic wasn't kicked, it would oscillate.  I would see this in particular with ETMY, by seeing the green transmission at the PSL table oscillating.
• Q noticed that sometimes when the oplevs' outputs were turned off, the outputs were railed at the limiter values.

Since, when the models were changed which gave us an extra underscore in the oplev names, Q did a find-and-replace in the foton text files, I was worried that this might have broken things.  I'm not entirely sure how it would have broken them (I didn't see any difference in a diff), but I've heard enough horror stories about the delicacy of the foton text files.

Anyhow, I opened the last archived foton files from just before Q made the change, and copy-and-pasted the design strings from the old filter banks to the new ones.  Hopefully this fixes things.

Figuring out the problem with frequency counter readouts:

The frequency counter has 4 ranges of operation: 
Range 1 : 1 - 40MHz
Range 2: 40 - 190MHz
Range 3: 190 - 1400MHz  
Range 4: 1400 - 6000MHz

I set up the beat frequency readout in various configurations to troubleshoot and have recorded my observation (attachments). The amplifiers in all cases is just a single ZFL-500LN.

There seems to be a problem with the RF amplifier and the frequency counter when they are set together. I am not able to figure it out and stuck right here

Attachment 1: schematic for readout and corresponding observations

Attachment 2: Oscilloscope screen snapshot for schematic 3

Attachment 3: Spectrum analyzer screen snapshot for schematic 3

More info: RFPD used is Thorlabs FPD310 and frequency counter is Mini Circuits UFC-6000. The RF amplifier has decoupling capacitors soldered across the power supply.

Here is a longer stretch of data, from the first RF-only lock on Saturday night.  Unfortunately daqd had died about 400 seconds before the lockloss, so I can't show the RF signals coming on.  

ALS was on the _A channels for CARM and DARM, so when those go to zero (about -300 seconds for CARM, and about -200 seconds for DARM), we're using RF signals only for the error signals.

CARM noise definitely improves, but holy smokes does DARM start to look good!  Although, right at the end it starts to look like REFL11I is getting bigger.  Not sure why, but we'll have to watch out for this.

Here's the equivalent plot for the second lock stretch. This is the one that was handled by the carm_up script. It looks like I had about 150 seconds of RF-only lock here. 

DARM error is getting bigger with time jnear the end, even though I wasn't working on alignment here.  Zooming in, DARM is oscillating at 16.4 Hz, which is the bounce frequency.  I thought I had my bounce/roll filters on, but somehow it still got a little rung up.  It just rings up to a steady state though, it's not getting huge, so I don't know that it was the cause of the lockloss.

According to the official rules, we only need 8 seconds to declare it "locked".

I wonder if the double cavity pole compensation filter for CARM was on for all the attempts yesterday? IF it looks like it will not saturate, it would be more stable to have the whitening on for REFL11 / AS55. Since on Friday, I set the REFL165 demod phase just by minimizing the MICH control signal with the arms on resonance, we ought to check out the PRMI degeneracy with the ETMs misaligned.

Speaking of signal mixing: Although we weren't able to get the carrier term cancelled in the 3*f1 signals by the relative mod phase method, I wonder if we can do it by mixing the 3*f1 and 3*f2 signals in the input matrix. Might help to keep the PRMI more stable, if that's an issue.

P.S. I have done some scripts directory / SVN cleanup. Adding some directories that were not in (like lockloss) and then removing stuff from the repo using 'svn rm --keep-local  filenames' for the image and data files.

As I (very excitedly) reported in elog 11116, I was able to follow the error signal blending procedure from last night, and get CARM and DARM onto digital non-normalized RF signals.  The lock held for about 3 minutes after this transition (elog 11118 has plot of this).

I was then able to script what I did (in the carm_up script), and repeat the transition. Q joined me in the control room, but we have not been able to complete the transition a third time.

Here's the sequence that worked the two times:

• Go to zero CARM and DARM offsets 
  • CARM is locked on ALS comm through the CARM_A filter bank (CARM_A gain = 1)
  • DARM is locked on ALS diff through the DARM_A filter bank (DARM_A gain = 1)
• Lower CARM servo gain to 5 (from 7)
• Lower DARM servo gain to 5 (from 7)
• Lower PRCL servo gain to -0.03 (from -0.04)
• Lower MICH servo gain to 2.5 (from 3.0)
• Set up _B error signals
  • CARM_B has 1e-4*REFL11I, no normalization
  • DARM_B has -1e-4*AS55Q, no normalization
• Give CARM_B a gain of 0.15
• Turn on CARM_B FM7 (integrator)
• Give DARM_B a gain of 0.1
• Turn on DARM_B FM7 (integrator)
• Slowly increase CARM_B gain, lowering CARM_A gain when gain peaking happens
  • CARM_B to 0.3, sleep 2
  • CARM_B to 0.5, sleep 2
  • CARM_A to 0.8, sleep 2
  • CARM_B to 0.6, sleep 2
  • CARM_A to 0.6, sleep 2
  • CARM_B to 0.7, sleep 2
  • CARM_A to 0.4, sleep 2
  • CARM_A to 0.2, sleep 2
  • CARM_B to 0.8, sleep 2
  • CARM_A to 0
• Slowly increase DARM_B gain, lowering DARM_A gain when gain peaking happens
  • DARM_B to 0.2, sleep 2
  • DARM_A to 0.8, sleep 2
  • DARM_B to 0.3, sleep 2
  • DARM_A to 0.6, sleep 2
  • DARM_B to 0.4, sleep 2
  • DARM_A to 0.4, sleep 2
  • DARM_B to 0.5, sleep 2
  • DARM_A to 0
• This is where I started working on the ETMX alignment to improve dark port contrast.  DARM kept having gain peaking, so I was lowering the DARM servo gain as I worked on the ETMX alignment.  I didn't make note of what the final gain was when I lost lock, but whatever it was, it wasn't right.

After those two attempts, we ran the LSC offset script, since that hadn't been done since early yesterday.  We did a quick CARM sweep, and REFL11 seemed to be centered around 0 counts, so we removed the 0.025 count offset from the CARM_B filter bank.

For later attempts, we keep seeing oscillations in the lockloss plots around 50 Hz, as if we're seeing gain peaking at the low side of the phase bubble.  We have tried turning off various filters at various levels of RF gain, but none of the combinations seems to be excellent.  Turning off the FM6 bounce/roll filter in CARM was particularly bad (immediately lost arm transmitted power), but others weren't good either (eg turning off FM3 boost lost arm powers within a second or so).  When we lose arm powers, the RF signals aren't valid, so if you don't turn them off fast enough (and ALS is still on with enough gain), you'll lose the full IFO lock.  If you're fast though, you can turn off the CARM and DARM _B outputs and not have to start from scratch. 

There seemed to be a very fine line to walk between not enough gain (~50Hz oscillations), and too much gain (200-300Hz oscillations).  It has been pretty frustrating later in the evening.  We seem to only have about 3dB of gain margin on the low side, when all the boosts are on.  Not excellent. 

When the RF signals had a moderate amount of gain, but ALS was still holding CARM and DARM, Q checked the phases of REFL11 and AS55 with excitation lines.  He rotated AS55 from -55 deg to -30 deg (+25 deg) and REFL11 from 144 deg to 164 deg (+20 deg).

Prior to the all-digital attempts, I tried several times to turn on the AO path, without success.  I think that the best that I got was 0dB on the CM board input 1 gain, +14dB on the CM board's AO gain, and -30dB on the MC board's AO gain before the mode cleaner lost lock. 

I was hoping that I could get CARM entirely to RF signals, and that would make things more stable and less complicated, and I could try again to turn on the AO path, but we haven't been able to do this tonight.

A few times in the later attempts we tried turning on the UGF servos for CARM or DARM.  I'm not sure if the lines kicked things out of lock, or if the UGF servos went a little crazy, or what, but we never survived for more than a few seconds after turning on the excitations.

There is a problem with the optical lever servos.  I had thought I'd been seeing it ever since Q re-did the models, and now I'm pretty sure that's what's up.  Q is hot on the trail of figuring out what may have changed that shouldn't have.  We may want to revert to an old Foton file, and re-copy the old filters into the new filter banks just in case.  The watchdog damprestore scripts have been tweaked to clear the oplev filter bank histories before turning on the oplevs, and this seems to solve the symptom of kicking the optic when oplevs are engaged. 

Although we haven't been able to make the transition to RF-only a third time, I think we're getting there.  Progress has certainly been made in the last 2 days!

This elog will be about work that happened yesterday.  I will write a reply to this with work from this evening's success.

[Rana, Jenne]

Work started with the plan of trying ALS fool, using the new triggering scheme (elog 11114).

The PRMI was having a bit of trouble holding lock with REFL165, so we checked its demod phase.  On Monday (elog 11095) we rotated the REFL165 phase from -91 deg to -48 deg while in PRFPMI configuration (I think the -91 was from PRMI-only phase setting).  However, Friday night we saw that MICH was super noisy, especially when the CARM and DARM offsets were near zero.  Rana rotated REFL165's phase until the MICH noise seemed to get lower (by at least an order of magnitude in the control signal), while we were at zero offset everywhere. We were not driving and looking at any lines/peaks, just the overall spectra.  The final REFL165 demod phase is -80. 

We tried engaging the fool path with no success. 

First, Rana moved the low frequency boost in the MC filter bank from 20:1 to 0.3:0.03.  This gave the whole loop at least 20 or 30 degrees of phase at all frequencies below the design UGF (a few hundred Hz?  Don't quite remember).  To check this, we put in a "plant" filter, and turned on the locking filter (3:3000^2) and the low freq boost and the plant, and the phase never touched 180 at any low freq.  This is so that we can ramp on this filter bank's gain without having an unstable unity gain crossing anywhere.  Also, I added two +10dB filters to the first two filter modules, so that we could ramp on the gain at the input rather than the output.

Last night we were actuating CARM on MC2 and DARM on the ETMs, and the MC filter bank was set to actuate on MC2.  Even with super duper low gain in the MC filter bank, so that the control signal was much less than one (1) count, it would make CARM unhappy.  The CARM filter bank's output was doing +/- a hundred or more counts, so why a few tenths of a count mattered, we couldn't figure out.  We were using the power trigger for the MC filter bank, but not the zero-crossing trigger.  Since the fool tuning was checked while actuating on the ETMs, we wonder if maybe the tuning isn't valid for MC2 actuation?  Maybe there's enough of a difference between them that the fool needs to be re-tuned for MC2 actuation?  Fool had the complex pair of poles at 1Hz, the "comp1" filter to give phase lag, and a gain of 22. 

I think that at some point we even turned off the fool path, but left the MC path on with a little bit of gain, and the audible noise over the speakers didn't seem to change in character at all. Weird. 

We ended up leaving the fool path for another time, and started working on error signal blending at the CARM filter bank input.  This is pretty similar to Kiwamu's self-locking principle.

Our goal was to ramp up the gain of the RF error signal at low frequency, while letting ALS keep hold of things at higher frequencies. 

CARM and DARM sweeps from earlier seemed to indicate that the RF signals are valid without normalization above transmitted powers of 50 or so, so we thought we'd give those a whirl for this error signal blending.

From doing a CARM sweep through resonance, we guessed roughly that the REFL11 (non-normalized) slope was about a factor of 10,000 larger than the ALS slope.  We put a 1e-4 into the input matrix element REFL11I -> CARM_B.  For some reason, REFL11 seemed to be centered around -250 counts, so we put an offset of +0.025 ( = 250*1e-4) into the CARM_B filter module to compensate for this. 

Since we thought that a gain of 1 in the CARM_B filter bank would make it equal to ALS, we tried some lower gains to start with.  0.3 kicked it out of lock, so we ended up liking and using 0.15.  With this low gain on, we tried turning on a low frequency boost, 20:1, but that didn't do very much.  We turned that off, and instead turned on an integrator, 20:0, which totally made things better.  The transmitted arm power was staying higher more of the time.

From a DARM sweep, we thought that AS55Q (non-normalized) should also have an input matrix element of 1e-4 for DARM.  We gave DARM_B a gain of 0.1, which seemed good and not too high.  Again, trying the gentle boost didn't do much, so we went with the integrator. 

At this point, since both RF signals were being used as error signals with integrators, we declared that at least at DC we were on RF signals.  Hooray!! 

After this, we started increasing the CARM_B gain a little, and decreasing the CARM_A gain.  When Rana finally set the CARM_A element to zero, we lost lock.  We realized that this is because we didn't include a zero to compensate for the arm cavity pole, which the IR signal will see, but the ALS won't. 

We decided that the plan of attack would be to get back to where we were (DC error signals on RF), and try to start engaging the AO path. 

I have in my notebook that at 9:49pm CARM was no longer using ALS as an error signal, and at 9:50pm, DARM was no longer using ALS as an error signal.  It looks like I was locked for 3+ minutes after getting to RF-only signals.

The increase in power near the end of the lock stretch was me trying to improve the dark port contrast by touching the ETMX alignment.  DARM was definitely oscillating as I improved the dark port contrast, so I was trying to hand-lower the gain as I worked on the alignment.

Exciting! How long was it?

[Jenne, with Matt and Fujimi as witnesses]

It might be about time to throw that champagne in the fridge.  Nice. Not quite close enough to talk about popping it open, but we'll want it chilled just in case... 

I still haven't logged yesterday's work, and I'm still working now, so no details, but I just handed both CARM and DARM over to non-normalized RF signals, and had the arms stable at powers of about 105.  I was workinig on the ETM alignment, and the power was increasing, so I think that's where the extra power will come from. I was lowering the DARM gain as I improved the alignment, because the optical gain was increasing so much.  I probably just didn't do that fast enough for the last aligning, which is why I lost lock.

Anyhow, here's a plot, because I'm excited:

Last report on model change / screen work from yesterday.

The ALSwatch script has always been just looking at the EPICS output of the CARM and DARM filter banks, and if it saw a single saturation, it would run the down script.  This was non-ideal because (a) the EPICS channels aren't the real signals, and (b) sometimes we'll hit the rails briefly and that's okay - we want to shut things down only when we're constantly saturating.

It turns out that there was a pre-existing saturation monitor part in CDS_PARTS, which I have used.  There is one each looking at the output of the CARM and DARM filter banks.  The threshold for what saturation means is set as an epics input.  The part outputs a running count (number of saturations since the last time it was not saturated, resets each time it goes non-saturating) and a total number since the last reset (also an epics input). 

(To be continued... still writing)

More work from yesterday. 

Rana and I had discussed on Thursday night that we probably want to be able to use the zero crossing of an error signal to trigger a servo on, but not to un-trigger it.  So, now the zero crossing trigger is latched, using the power trigger to reset the latch. 

Also, the input to the zero crossing trigger is the input to the MC servo, before the triggered switch.  This allows us to look at the normalized error signals rather than just the non-normalized ones, if that's what we're trying to lock on.  This signal is taken before the triggered switch, so that it's looking at whatever is coming out of the input matrix (including normalization).

So.  If the absolute value of the MC error signal goes below the threshold, it outputs a 1, no matter what the arm power is.  If the arm power is high, the power trigger also outputs a 1.  These are AND-ed together, so only if both are 1 do you actually trigger the MC filter bank.  If the zero crossing trigger has been set to 1, it will stay at 1 until the arm power goes low enough to untrigger the power trigger.  So, even if you have a little bit of noise on the error signal and it pops above the threshold momentarily, this won't cause the servo to un-trigger.

This is implemented using a "set-reset latch".  The output of the latch is the zero crossing trigger, which is AND-ed with the power trigger.  This final AND-ing, in addition to doing what we want, solves the ambiguity that is inherent in SR-latches for one combination of inputs. 

The trigger screen has been modified to reflect these model changes.

Here's a screenshot of the model, which includes some notes for anyone who opens the model since it's a bit confusing:

This is work that I did yesterday but didn't have time to elog.  Since it seems non-trivial to give ourselves ramping matrices, but we only really needed the ramping in the DoF selector matrices, I've replaced the separate _A and _B parts with full filterbanks.  Recall from elog 10910 that I had given each degree of freedom's _A and _B input options an offset, an epics monitor and a test point.  Now those are removed, and handled inside of the filter banks.  The outputs of the filter banks sum together.

This required some screen modifications, but everything should work the same way that it did before this change.  I've also changed the DAQ channels from the _A_ERR and _B_ERRs that I had hand-created to now be the _A_OUT and _B_OUT test points from the filter banks (acquired at 2048Hz). 

I have not yet modified the burt snapshots for the ifo configure screen.  The arms will work the same as always, since they didn't have any selector matrix stuff ever, but the rest still need tweaking.

MC Refl alignment follow up: the alignment from last night seems still good today. We should keep an  on the MC WFS DC spots and not let them get beyond 0.5.

The fit FWHM is 10.444kHz +-55Hz. 

If we take the FSR from ELOG 9804, this implies an Xarm fineese of 380 +- 2. 

Assuming an ITMX transmission of 1.4%, this means an Xarm loss of 240 +- 90ppm. 

This is substatially lower than the ~500ppm I had measured via the unlocked/locked ASDC power method, but still pretty high. 

Since we were able to get continuous frequency counter values into the digital system, I decided to give it a quick spin with a calibrated single arm ALS scan. This should be repeated when amplifiers are in place, because the Y IR beatnote is wandering around in a way I don't trust and I'm not sure if the frequency counters have good absolute calibration...

Neverthess, I did a 5 minute scan through the Xarm, and fit it nicely to a lorentzian peak. 

[EricQ, Manasa]

Domenica:
Since Domenica was not picking up an IP address and hence not responding to pings or ssh even after power cycling, I pulled it out from the IOO rack and connected it to a monitor. After a bunch of hit and trials, we figured out that the problem was related to the power adapter of the Rpi discussed here : http://www.raspberrypi.org/forums/viewtopic.php?f=28&t=39055

The power adapter has been swapped and this issue has been resolved. Domenica has been remounted on the IOO rack but left with the top lid off for the timebeing.

RF amplifier box:
The frequency counter was setup to read the beat frequency after amplification of the RFPD signals. The output as seen on the frequency counter screen as well as the epics values was intermittent. Also, locking the arms and changing the end laser frequencies did not change the frequency counter outputs. It looks like the RF amplifier is oscillating (Oscillating frequencies were ~107 MHz and 218 MHz) and the input circuit needs to be modified and the connections need better insulation.

As of now, I have connected the RFPD outputs to the frequency counter sans any amplification and we are able to get a readout of the beat frequency at > 40MHz (Frequency counter requires much higher amplitude signals for frequencies lower than that).

I was asked by Koji to point out where a schematic of the triple resonant circuit is.
It seems that I had posted a schematic of what currently is installed (see elog 4562 from almost 4 yrs ago!).

(Some transfomer story)
Then I immediately noticed that it did not show two components which were wideband RF transformers. In order to get an effective turns ratio of 1:9.8 (as indicated in the schematic) from a CoilCrfat's transformer kit in the electronics table, I had put two more transformers in series to a PWB1040L which is shown in the schematic. If I am not mistaken, this PWB1040L must be followed by a PWB1015L and PWB-16-AL in the order from the input side to the EOM side. This gives an impedance ratio of 96 or an effective turns ratio of sqrt(96) = 9.8.

(An upgrade plan document)

Also, if one wants to review and/or upgrade the circuit, this document may be helpful:
https://wiki-40m.ligo.caltech.edu/Electronics/Multi_Resonant_EOM?action=AttachFile&do=get&target=design_EOM.pdf
This is a document that I wrote some time ago describing how I wanted to make the circuit better. Apparently I did not get a chance to do it.

[Jenne, Ranah]

We played around tonight with different possible ways of transitioning DARM to normalized AS55Q.  Before each try, we would use ezcaservo (or just eyeball it) to make sure that the normalized RF signals had a mean of zero, so that we knew we were pretty close to zero offset in both CARM and DARM.

We tried something that is similar in flavor to Kiwamu's self-locking technique - we summed in some normalized AS55Q to the DARM error point (using the DoF selector matrix that I created a few weeks ago), and then tried to engage a little low frequency boost.  We tried several times, but we never successfully made the transition.

In the end, we just did a direct transition over to normalized AS55Q, and lost lock after several seconds.  The buzzing that we hear didn't change noticeably after the transition, which indicates that most of the noise is due to CARM (which makes since, since it has a much smaller linewidth).  The problem with holding DARM is that occassionally we will have a CARM fluctuation that lets the arm power dip too low, and DARM's error signal isn't valid at low arm powers. So, we need to work on getting CARM stabilized before we will have a hope of holding on to DARM. 

Here's the lockloss plot from that last lock:

Also this evening, I scanned back and forth over the CARM zero crossing while locked on ALS, to see what the RF error signals looked like.  Normalized REFL55 seems to have much more high frequency noise near the edges of the linear range than does REFL11.  Also, the REFL 11 signal is much larger.  So, what I think I want to try to do is use ALS fool to lower the CARM noise by a bit, then make the DARM transition.  Then, we can come back to CARM and ramp up the gain. 

With these CARM sweeps, I think that I know the relative gain and sign between ALScomm and the normalized REFL signals, and the REFL signals versus the normalized versions.  I think that 100*REFL11I/(TRX+TRY) gives the same slope at the zero crossing as just plain REFL11I.  Same factor of 100 is true for REFL55I.  The REFL11 slope is 20,000 times larger than the ALS slope, while the REFL55 slope is -500 times the ALS slope (note that REFL55 has a minus sign).  We can probably trigger the Fool on when the arm powers are above 50, and trigger off when they're below 20.  For the zero crossings, the REFL55 threshold should be about 20, and the REFL11 threshold should be about 500. 

I also need to re-think the triggering logic for ALSfool.  We probably don't want the zero crossing logic to be able to un-trigger the lock, just in case we get an extra noise blip.  So, we want to trigger on with an AND, but only trigger off if the arm powers go too low.  Also, the zero crossing logic should look at the normalized error signals, not the plain signals.

We need to modify the ALSwatch logic so that it doesn't look at EPICS values for the thresholding.  There may be an updated filter module that includes a saturation monitor, but otherwise we can use the saturation monitor part that is in the OSC section of CDS_PARTS.  We'll set the threshold on this to match the limiter in the filter bank.  Then, if the filterbank output is constantly hitting the limiter, we should run the down scripts.

This has been done before:

http://nodus.ligo.caltech.edu:8080/40m/6938

Arm length measurements and g-factor estimates in 2012, but only with an accuracy of ~30 cm. However, Yuta was able to get many FSRs somehow.

In the attached plot you can see that the MC REFL fluctuations started getting larger on Feb 24 just after midnight. Its been bad ever since. What happened that night or the afternoon of Feb 23?
The WFS DC spot positions were far off (~0.9), so I unlocked the IMC and aligned the spots on there using the nearby steering mirrors - lets see if this helps.

Also, these mounts should be improved. Steve, can you please prepare 5 mounts with the Thorlabs BA2 or BA3 base, the 3/4" diameter steel posts, and the Polanski steel mirror mounts? We should replace the mirror mounts for the 1" diameter mirrors during the daytime next week to reduce drift.

I think we've seen this in simulations, but it's a little disheartening to see in real life.  AS55Q looks like it flattens out pretty significantly right around the DARM=0 point. 

Right now I have the arms held on ALS (CARM=-1*MC2, DARM=2*ETMY, as Q used last night), and the PRFPMI is on REFL165I&Q.  I have set CARM to be as close to zero offset as I can (so I get all the usual buzzing), and then I'm sweeping the DARM offset between +3 and -3 counts (roughly +/-3nm) with a 3 second ramp and looking at normalized AS55Q.  The channel called "DARM_B_ERR" is 0.006*AS55Q/(TRX + TRY).  The arm transmissions, as well as the ASDC are plotted as well - ASDC is scaled to fit on the same axes as the transmissions.

Anyhow, here's the time series of the DARM sweeps.  AS55 demod phase of -55 degrees seems to give the cleanest signal (within 5deg steps); this is the same phase that we've been using all week.

DARM_TimeSeries_5March2015.pdf

I just realized that the "damprestore" script that can be called from the watchdog screen did not have the new oplev names.  I have updated it, and added it to the svn.

Working around the PSL table

I have put the FOL fiber box on the PSL table. The fibers carrying AUX and PSL light are connected and the RFPDs have been powered up. I can see the beat frequency on the frequency counters; but for some reason Domenica (that brings the frequency counter values on the medm screens) is not visible on the network even after hard reboot of the raspberry pi. I am neither able to ping nor ssh into the machine. I have to pull the module out and add a monitor cable to troubleshoot (my bad I should have left the monitor cable with the raspberry pi in the first place). Anyways, I have handed over the IFO to Q and will play with things again sometime later.

The fiber box on the PSL table is only left there temporariliy till I have things working. It will be stowed on the rack properly later.

In case someone wants the fiber box out of the PSL table, please make sure to power down the RFPDs using the black rocker switches on the side of the box and then disconnect the cables and fibers.

I pulled out the RF amplifier box from the IOO rack and swapped the amplifiers for FOL beat frequency amplification. The earlier gain of 62dB (ZFL500LN + ZFL500LN) was reduced to 40dB gain (ZFL500LN+ZFL2AD).

I also swapped one of the broken sma cables that was connecting the two amplifiers with a good one. Front ports of the module were relabeled and the box was put back on the rack.

During the course of this work, I had to turn OFF the green BBPDs on the PSL table to protect them and they have been powered up after putting the module back.