A paltry two locks tonight, but not entirely useless. I had some issues keeping the PRMI locked, which some additional boosts helped with. But, my feeling was that our crossover process is not tuned well. 

At full lock, both sub-loops have high gain around the crossover region, so the usual DTT loop transfer function measurement produces a meausrement of Gdigital/G_aopath (or minus that. I.e. I'm not currently 100% which is the bad phase in this plot, though it intuitive looks like 0 ). Thus, we can directly look at the crossover frequency and the effect of the different filters there. (I've also been working on an up-to-date CARM loop model today, so this will help inform that). 

Below, the black traces are the crossover at the end of the script when using the 120:500 "helper," and purple is without it. As we turn up the AO path gain, the trace "falls" from above, which explains why we can see instabilities around the violin filter. 

Having the helper on definitely made the probability of surviving the first overall CARM gain ramp higher, but it's not currently intuitively clear to me why that is the case. Afterwards, we can turn the helper off, to keep the shallower crossover shape. This is what I've put in to the up script for now. I also added a few seconds delay for when the script wants to switch DARM to RF only; I found it was maybe speeding too fast through this point.

DTT xml attached

Here's the comparison of last night's crossover measurement to my loop model. Not stellar, but not totally off base. All of the digital filters are read directly from the foton filter file, and translated from their SOS coefficients, so they should be accurate. I may have tallied together the wrong arrangement of FMs, though. I will recheck. 

Although I don't have a measurement to compare it with yet (as I don't know where the crossover was, the filter statesolder, etc. for the older loop measurements), here's what my current CARM loop model looks like, just for kicks. Here, only the first CM board boost is on. If we turn on some super boosting, we can probably ease up on some of the digital boosts, lower the crossover frequency, and put some lowpass that suppress the violin filters' effect on the crossover and reduces digital sensing noise injection. 

Lastly, I'll just note that my current MIST model predicts that the CARM cavity pole should be at ~170Hz, and a peak arm transmission of 180 times single arm power. I saw powers of ~120 last night. 

Whoops, I implemented the IOP downsampling filters wrong. Once I did that, it looked like just delay mismatch, so I added two more computation cycles for a total of four 16k cycles, which is maybe not so justified... Nevertheless, model and measurement now agree much better. Here are the corrected plots. 

I have 12 tick marks for times I got all the way to 1f for all 4 degrees of freedom in the PRFPMI.  The CARM / DARM transitions now succeed more than they fail, which is nice. 

At Q's suggestion, I am turning off all the violin filters in the MC2 path during the CARM transition.  This also means that I don't need any of the notches that Den and I put into the CARM_A and CARM_B filter banks last week, which were right at the edges of the violin notches.  Anyhow, this seems to make the transition much more likely to succeed.  I don't ever use the CM_SLOW FM10 "crossover helper" that Q had to use last night.  The violin filters are turned back on after the CARM transition is complete.  We don't ever need those other notches.

I checked the REFL165 vs. REFL55 transfer functions for PRCL and MICH, and they are mostly flat.  REFL55 seems like it'll give us extra phase for some reason.

I tried setting offsets for PRMI, but they seem to be strongly dependent on arm alignment.  I ended up being pretty confused, and since all the REFL signals are pretty close to zero (when CARM/DARM on RF, PRMI on 3f), I have given up on that avenue for tonight. 

I think many of my locklosses tonight (lost from the all 1f state) have been fast things, faster than the ADCs can handle.  On the lockloss plots that I've looked at, the FSS PC drive is railed at 10V about 200msec before I lose lock.  So, something (presumably in the fast CARM path) is making the MC/FSS loop unhappy.  I have plugged in the Agilent to the Out2 of the CM board, so that it looks at REFL11.  Unfortunately, this is after the input gain slider, so we don't see much until we're locked, but that seems fine.  A video camera is pointed at the screen, so that I get real time spectra.  It's hard to watch the TV at the same time as everything else, so I haven't witnessed the moment of lockloss in the fast spectrum yet.  Be careful when walking down the Yarm.  The tripod is partly in the walkway.

Q, I took a few TFs of the total CARM loop, although none of them are particularly good below a few kHz.  I can't push hard enough to get coherence, without blowing the lock.  TF data is in /users/jenne/PRFPMI/CM_TFs/CM_TFs_2Apr2015/ . 

I was worried for a while that, after I transition PRMI to 1f, I hear lots of low frequency rumbling.  However, watching the spectra (relative to references taken with CARM and DARM on RF, but PRMI on 3f), the low frequency error and control signals are staying the same for all 4 DoFs, but the high frequency for PRCL and MICH goes down significantly, so it's probably just that the low frequency stuff sounds more obvious, since it's not drowning in high frequency fuzz. 

It was only a mediocre locking night.  I was foiled for a long time by 2 things, both of which are now taken care of in the scripts, so I don't waste so much time again.

• Somehow FM4 (LP700) in the CARM_A filter bank was turned off.  It took me a long time to figure this one out. 
  • At first, I had a 2056Hz oscillation, and then if I notched that, I would have problems at the edges of my notch.
  • I turned on the LP1000 in CARM_B (which we don't usually use) to fight the 2k resonances, but then I had violin mode problems. 
  • I couldn't turn off the violin mode filters on MC2 for the transition, so the edges of these notches were causing instability.
  • Anyhow, in the end, I realized that FM4 of CARM_B wasn't on, but it usually is.
  • It is now turned on in the carm_cm_up.sh script.
• After that fiasco, I had trouble turning on the ASC loops.
  • Turns out we had left the offsets in place from last night in the ASC loops, so that when I zeroed the outputs of the transmission QPDs, the offsets in the ASC loops didn't make any sense, and they pushed the IFO severely out of alignment.
  • Now the ASC down script (which is run by the carm down script) zeros the filter bank offset values

Scripts are checked into the svn.

I used Q's handy-dandy 2D histogram plotter (..../scripts/general/dataHist, which I have taken the liberty of adding to the svn) to set the PRCL offset when I was locked on REFL165.  Here is a version of the plot, when I had an offset of +10 in the PRCL filter bank. There was so much noise on the PRCL input that I quit bothering to try and put in an excitation or ramp the offset value.  Note that I have since moved this offset to PRCL_A's offset instead, so taking this plot again should have PRCL_IN1 centered around zero.

I had trouble doing something similar for PRCL when I was locked on REFL55.  At first, the offset was so poor that POP110 was only about half the value it was when locked on REFL165, and it had a huge amount of RIN.  I tried just doing a z avg of the PRCL_B_IN1 (REFL55I) while locked on REFL165, and that said that REFL55I had an offset of +33.8 counts, so I tried an offset of -33.8 counts to get to zero.  But, that was still terrible for POP110 power.  As I increased the offset, eventually up to +30 counts, POP110 kept getting better and better.  I lost lock at that point (while trying to get 10 sec of histogram data), so I'm not sure that +30 is the final value.  I want to also get equivalent histograms with POP22 and POPDC (and maybe arm transmissions?) as the X-axis on these plots.  There's no excitation, so all of these can be collected at once.

By babysitting the ITM alignment (looking at the rough DC values of the optical lever error siganls), and doing a little adjustment of the ASC differential offset, I was able to keep lock a few times for more than 2 or 3 minutes while all 1f.  Not a whole lot longer than that though, even if I wasn't "poking" the interferometer other than maintaining alignment.

As the POP55 demod board is actually demodulating the REFL55 signal, I have connected its outputs to the REFL55 ADC inputs. Now, we can go back to using the REFL55 input matrix elements, and the data will be recorded. 

I have changed the relevant lines in the locking script to reflect this change. 

blarg. Chrome ate my elog. 

112607010 is the start of five minutes on all whitened 1F PDs. REFL55 has more low frequency noise than REFL165, I think we may need more CARM supression (i.e. we need to think about the required gain). This is also supported by the difference in shape of these two histograms, taken at the same time in 3f full lock. The CARM fluctuations seem to spread REFL55 out much more.  

I made some filters and scripts to do DC coupling of the ITM oplevs. This makes maintaining stable alignment in full lock much easier. 

I had a few 15+ minute locks on 3f, that only broke because I did something to break it.  

Here's one of the few "quick" locklosses I had. I think it really is CARM/AO action, since the IMC sees it right away, but I don't see anything ringing up; just a spontaneous freakout. 

Small steps tonight, but all in the forward direction.

On one of my better locks, I saw a kind of weird phenomenon with the PRMI sideband powers versus the carrier powers:

For the last 100 seconds of this plot, I'm all 1f.  Alignment is being handled mostly by Q's DC coupled ITM oplevs, and the transmission QPD ASC loops, although I was trying to adjust the offsets in the ASC loops to improve transmission for a bit.

At the very end, the last 10 seconds or so, the POP110 power goes down, and sits at about half it's maximum value.  POP22 isn't quite as bad, in that it still touches the max, but the RIN is about 50%.  The carrier DC signals (TRX, TRY, POPDC) don't see this huge jump.  I don't think I was touching anything the last few tens of seconds.  I'm not sure yet how I can so significantly lose sideband power, without losing a similar amount of carrier power. 

The ring-ups at about -70sec in the CARM and DARM outs are the bounce mode. 

I tried looking at 2D histograms of different combinations of channels, for the time around -30 seconds where things looked pretty clean.  It looks like the offsets that Q put in last night (+1 for MICH_B and -3 for PRCL_B) are still about right.  The PRCL_IN1 and MICH_IN1 were centered around zero at the maximum power points.  CARM and DARM had small offsets, which I put into the DARM_B and CARM_B filter banks (0.0066 for DARM_B, and 0.027 for CARM_B), although these are small enough that I don't know that they really do anything.

As a break from locking for a little while, I tried to see if I could get the TT3 and TT4 DAC channels to work for me.  I had hoped it would be a quick and easy task, but I'm not seeing signal out.  Since it wasn't working, I decided to go back to locking for the night, and look into the DAC in the daytime.  I want to use one channel as the IN2 input of the CM board, and another as the external modulation input to the Marconi for transfer functions, so I need them to work. 

As a side note on the input to the Marconi situation, it occurred to me that instead of laying a new cable, I can borrow the POP55 heliax.  We don't have a POP55 diode right now, and the other end comes out across the hall from the Marconi, so it would be pretty easy to have a medium-length cable go from ITMX table to the Marconi.  Objections to this? 

I saw this same kind of behavior in my locklosses on Wednesday night; we should check out the 165 data, and see if the 3f PRCL error signal shows some drift away from zero.

Also, it's odd that CARM_IN1 and REFL11_I_ERR have different low frequency behavior in the plot you posted. I guess they have some difference in demodulation phase.  REFL11_I's bump at -40sec coincides with the dip in arm power and a rise in REFLDC, but ASDC seems pretty smooth, so maybe it is a real CARM fluctuation.

I set the REFL11 analog demodulation angle (via cable length) about a year ago (ELOG 9850), with some assumption about PRCL having the same demod angle as CARM, but this was probably set with the arms misaligned. We should recheck this; maybe we're coupling some other junk into CARM. 

I did a quick measurement get an idea of the ETM actuator calibration, relative to the ITMs. This will still hold if/when we revisit the ITM calibration via the Michelson. 

For the test masses, I locked the arms individually using MC2 as the actuator, and took transfer functions from the SUS-[OPTIC]_LSC_EXC point to the PO[X/Y]_I_ERR error signals. There were two points with coherence less than 99% that I threw away. I then took the fraction at each point, and am using the standard deviation of those fractions as the reported random error, since the coherence was super high for all points, making the error of each point negligible relative to their spread. 

This gives:

• ETMX/ITMX: 2.765 +- 0.046
• ETMY/ITMY: 2.857 +- 0.029

With the data from ELOG 8242, this implies:

• ETMX: 13.00 +- 0.22 x 10 ^-9 / f² m/counts
• ETMY: 13.31 +- 0.15x 10 ^-9 / f² m/counts

MC2 data was taken with the arms locked with the ETMs. The results are not so clean, the fractions don't line up; there is some trend with excitation frequency... The ratio is around the same as the ETMs, but I'm not going to quote any sort of precision, since I don't fully understand what's happening. Kind of a bummer, because it struck me that we could get an idea of the arm length mismatch by the difference in IMC frequency / arm FSR. I'll think about this some more...

I didn't verify that the loop gain was low enough at the excitation frequencies.

I put a 1kHz ELP in both arm servos, and got cleaner data for both. The ETM numbers are pretty much consistent with the previously posted ones, and the MC2 data now is consistent across frequencies. However, the MC2 numbers derived from each arm are not consistent.

Now:

• ETMX / ITMX: 2.831 +- 0.043
• MC2 / ITMX: 3.260 +- 0.062
• ETMY / ITMY: 2.916 +- 0.041
• MC2 / ITMY: 3.014 +- 0.036

With the data from ELOG 8242, this implies:

• ETMX: 13.31 +- 0.21 x 10^-9 / f² m/counts
• ETMY: 13.59 +- 0.20 x 10^-9 / f² m/counts
• MC2 in Xarm meters : 15.32 +- 0.30 x 10^-9 / f² m/counts
• MC2 in Yarm meters : 14.04 +- 0.18 x 10^-9 / f² m/counts

I spent some time tonight trying to revive DRMI locking, with the arms held off on ALS. Not much news, I haven't been able to get more than a few short spurts of resonance, using 1F signals.

I did use SRY to measure the BS->SRCL coupling by exciting each mirror and looking at their relative coupling to AS55Q. I found that we should use a value of +0.28 +-0.01 in the MICH->SRM element.

The DAC was fine.  I realized tonight that the digital filter bank outputs were off, so I wasn't actually sending signals out.  Oooops. 

I have unplugged POXDC and POYDC from their whitening inputs.  They have labels on them which whitening channel they belong to (POY=5, POX=6) on the DCPD whitening board.

TT3_LR's DAC output is Tee-ed, going to the POYDC input and also to an SR560 near the Marconi.

TT4_LR's DAC output is Tee-ed, going to the POXDC input and also to the CM board's ExcB input.

I'm sad.  And frustrated. 

The PRCL angular feed forward is not working, and without it I am having a very difficult time keeping the PRMI locked while the arms are at high power (either buzzing, or the one time I got stable high power partway through the transition).  Obviously if the PRMI unlocks once CARM and DARM are mostly relying on the REFL signals, I lose the whole IFO. 

Q and I had been noticing over the last few weeks that the angular feed forward wasn't seeming quite as awesome as it did when I first implemented it.  We speculated that this was likely because we had started DC coupling the ITM optical levers, which changes the way seismic motion is propagated to cavity axis motion (since the ITMs are reacting differently).

Anyhow, today it does not work at all.  It just pushes the PRM until the PRMI loses lock. I am worried that, even though Rana re-tuned the BS and PRM oplev servos to be very similar to how they used to be, there is enough of a difference (especially when compounded with the DC coupled ITMs) that the feed forward transfer functions just aren't valid anymore.

Since this prevents whole IFO locking, I spent some time trying to get it back under control, although it's still not working. 

I remeasured the actuator transfer function of how moving PRM affects the sideband spot at the QPD, in the PRMI-only situation.  I didn't make a comparison plot for the yaw degree of freedom, but you can see that the pitch transfer function is pretty different below ~20Hz, which is the whole region that we care about.  In the plot below, black is from January (PRMI-only, no DC-coupled ITMs) and blue is from today (PRMI-only, with DC-coupled ITMs, and somewhat different BS/PRM oplev setup):

Pitch_oldVsNew.pdf

I calculated new Wiener filters, and tried to put them in, but sometimes (and I don't understand what the pattern is yet) I get "error" in the Alternate box, rather than the zpk version of my sos filter.  It seems to go away if you use fewer and fewer poles for fitting the Wiener filters, but then the fit is so poor that you're not going to get any subtraction (according to the residual estimation plot that uses the fitted filters rather than the ideal Wiener filters). The pitch filters could only handle 6 poles, although the yaw filters were fine with 20.

The feed forward just keeps pushing the PRM away though.  I flipped the signs on the Wiener filters, I tried recalculating without the actuator pre-filtering, I don't know why it's failing.  But, I'm not able to lock the interferometer.  Which sucks, because I was hoping to finally get most of my noise coupling measurements done today.

http://www.ligo.caltech.edu/~misi/summary/day/20150504/

I left the arms locked last night. Looks like the drift in the Y arm power is related to the Y arm control signal being much bigger than X.

Why would it be that Y > X  ?

Why is the Y arm drifting so much?

The " PSL FSS Slow Actuator Adjust " was brought back to range from 1.5 to 0.3 yesterday as ususual. Nothing else was touched.

I'm not sure if the timing scale is working correctly on theses summery plots. What is the definition of today?

The y-arm became much better as I noticed it at 5pm

Rana suspects that the lack of X beatnote is related to the PSL laser temperature change (ELOG 11294). 

I used the information on the wiki and old elogs (wiki-40m, ELOG 6732), to deduce that the new end laser temperatures should be:

• X end-> 38.98 C
• Y end-> 35.80 C

I went out to the X end and found the laser crystal temperature set to 40.87, which is not what the measurements I linked to suggest would be the ideal temperature for the previous NPRO laser temperature of 30.89, which would be 37.02. I could not find any elog describing the choice of this setpoint.  

I've changed the X end laser crystal temperature to the value above. I've hooked up the X IR and green beatnotes to go the control room analzyer, and have been looking for the beatnote as I adjust the digital temperature offset, but haven't found it yet...

If this proves totally fruitless, we can just put the lasers back to their original temperatures, since it's unclear if it helped the PC drive noise levels. 

Both green beatnotes have been found with nominal amplitudes. (X: -30dBm Y: -20dBm), at temperatures which don't seem to be prone to mode hopping. 

X = 42.64, Y ~40.15

Both arms can lock on ALS, but as Koji mentioned in ELOG 11334, the ALS noise seems anomalously high. 

Details

The temperatures I posted in the previous log ended up not being so useful. To find the right end laser temperatures, I looked at the IR beatnotes on the control room analyzer out to 1GHz, and swept around the SLOW_SERVO2_OFFSET channels to change the laser temperature. During this time, the end green shutters were closed, the PSL shutter was closed, the FSS slow servo was off, and the FSS_SLOWDC was set to 0.0. (The green PSL shutter had to be open, because the IR beat fiber is coupled after it.)

For each arm, I found three temperatures where an IR beat could be observed; as Koji mentioned on Wednesday, we should use the middle mode. For each of the arms, scanning around from the middle to move the beat by +-1GHz did not cause a mode hop - the beat stayed visible on the scope. Once I found a real IR beat for the X arm, I took at look at the RF output of the X BBPD, and found my alignment from the other night was actually pretty good; I made a minor touch up to maximize the green beat. 

For the AUX X innolight, I was able to find the actual temperature of the laser crystal when at the correct point, remove the digital offset, and return to the same temperature with the controller front panel dial. This temperature is 42.64 degrees Celcius. There is no diode temperature control on the unit, as far as I could tell, but the maximum green transmitted power through the X arm is about the same as it's ever been, around GTRX=0.5. 

My motivation for doing this was that I always have problems remembering the historical typical values for the digital temperature offset. It seems much cleaner to me to set things up such that a beat is visible "at the origin" (i.e. FSS_SLOWDC=0 and SLOW_SERVO2_OFFSET=0) I suppose that this will also depend on what mode of the PMC we're locked to. During my time working today, its been locked near the middle of its range, currently sitting at 145V. 

However, for the AUX Y lightwave, I was a little perplexed to find that moving the the laser crystal setpoint around does not apear to change the real laser temperature at all. Thus I could not offload the digital offset in the same way. Aditionally, the lightwave controller does not have the same temperature measuring accuracy as the innolight, even with the back panel voltage readout that is hooked up to the multimeter that lives under the optical table. The best I can tell is around 40.1-40.2 degrees C. Y_SLOW_SERVO2_OFFSET of -10690 counts gives a beat <100MHz at FSS_SLOWDC=0. This is actually very close to the previous operating point, so the same mode seems to still work. 

The arms now easily lock on ALS, albeit with higher noise. With arms locked on ALS, POX and POY show >1kHz rms noise.  

I gave the PRFPMI locking script a few tries, but it's having problems keeping the PRMI locked. The ALS is a few times noisier than usual, and I haven't revisited the validity of the PRC angular feedforward, so I'm not so surprised. 

Looking over the old noise budget in the green locking paper, it seems the main technical noise sources were the AUX PDH error and DFD noise. I'm working on quantifying the current state of these noises. 

Rather than lugging out the analyzers every time I wanted to make a measurement of the AUX PDH error signals, I set out to make the existing digitized channels (ALS-[X/Y]_ERR_MON) usable for easier, and continuous, monitoring. Sadly, up until now the signals were poorly conditioned, and drowning in ADC noise. (When locked, the Y error signal was only +-10 counts!)

Of course, given the bandwidth of the green servos (10kHz), this won't tell us the full story of the what the green PDH lock is doing, but does indicate how much residual frequency noise exists in the ALS control band. 

I'm currently using SR560s at G=20 at each end to amplify the ERR MON outputs of the uPDH boards before sending them to the ADCs; now that I've found a gain that works, I'll modify the error point monitor buffer opamps inside the uPDH boards themselves during the daytime. 

The AUX Y error signal was going into an AA board with some funky filtering going on that I didn't want to mess with. Instead, I've moved the signal to the pentek generic board whose first four channels are used for the oplev segments, and the second quartet are unused, save for the TST channel I hooked up yesterday. 

On the pentek board, I changed the 4th order 800Hz lowpass to a 4th order 8kHz lowpass on the last three channels through some resistor swapping. (At first it was just the last two, but I found I was getting weird signals in the 32nd channel; and if I recall correctly from my cymac work, the 32 ADC channel is used for some timing signal or something...). I also turned off the 1:10 whitening filters on the last four channels via PCB jumper. 

I then unhooked the PZT drive and let the PDH error signals swing around, to calibrate the ADC counts into HZ. Now, the ALS-[X/Y]_ERR_MON_OUT_DQ are calibrated in green Hz! Here are the spectra.

As we've seen in the past (ELOG 10464), the X green is limited by the dark noise of the PD from 10-100Hz. This isn't so great. The RMS noise from 300Hz downwards (which is maybe the band where the ALS control would inject noise into the mirror motion) is about Y:10Hz X:40Hz.

During this time, the test masses were not under any longnitudinal control, so I'm not sure why there is such a difference in the height of the suspension resonance peaks, unless there's some differene in the low frequency PDH TFs that I've forgotten about. 

Now, with these references, we can easily check if the PDH loops change qualitatively over longer time periods.

I'll be including the effect of these noises in the upcoming revised ALS noise budget.

Short entry just to preview a new development; more detail about this investigation will soon follow. 

The beatbox I and Q signals are too small at the ADC! I was able to reduce the RMS out of loop ALS sensitivity (arm locked on POX) by 300Hz with G=10 SR560s between the beatbox output and the ADC whitening chassis input. Increasing the beat note amplitude via RF amplifier had no positive effect. 

There is still a reasonable gap between this and the beatbox's noise levels, as measured with a marconi. There may be additional headroom for whitening gain; the SR560 maximum output range is smaller than the ADC input range. 

The high frequency noise has >0.5 coherence with the PDH error signal above a kHz or so, but not much below that. 

We should probably either modify the output whitening of the beatbox, or introduce some (variable?) whitening gain in a seperate circuit. 

Here are the promised details!

I was worried about the lack of whitening gain, as I saw that the DC phase tracker Q output (which is the magnitude of the signal in the beatbox's I-Q plane) was no more than 200 ADC counts for X (~120mV), and 800 for Y (~500mV). I.e. this is the largest DC value that either the I or Q ADC channels can see, and the RMS fluctuations are on the order of mV, meaning we're wasting our entire ADC range. 

However, I also had doubts about this since, even in the nominal state, the ASD of the ADC signals before dewhitening was higher than the expected ADC noise level. However, because of the non-linearity of the conversion of the BEAT_I and Q signals into the phase tracker output, evaluating the contribution of the beatbox output and ADC input voltage noises takes a few more steps. 

So, I hooked up a Marconi as the signal source for the beatbox's X channel , with no modulation (presumably the phase noise of the Marconi output is significantly lower than the sensitivity of the beatbox). For all of these measurements, the beat frequency was kept around 50MHz, with an amplitude of -30dBm on the control room analyzer, which is a typical X ALS operating point. 

At this point, the beatbox output noise was below the ADC noise (as measured by an SR785). Nevertheless, I found that the beat spectrum driven by the Marconi lined up to be very close to the ALS beat spectrum across a wide band, explaining much of the noise. 

Going back to the real green beat signal with the SR560s still at G=10, I obtained the result shown in ELOG 11355. I will soon repeat this process with the Y ALS. 

As I mentioned in the previous ELOG, we may be further helped by more whitening gain than can be provided by the SR560s (and we obviously need a robust long term circuit for this gain). If it then turns out we are limited by beatbox noise to a degree we are not happy with, we could perhaps look into reintroducing some RF gain into the X beat. As Koji mentions in ELOG 8855, the beatbox operates best at an RF input of around -4dBm.

Nice find!

We ought to use our noise model of the ALS signal chain to determine what the right gains are, rather than hunt and peck. More likely we'll start from the right gains.​

Once the gains and/or whitening filters make sense, maybe we'll see some effect from fixing the green PDH loops.

I took measurements at the green beat setup on the PSL table, and found that our power / mode overlap situation is still consistent with what Koji and Manasa measured last September [ELOG 10492]. I also measured the powers at the BBPDs with the Ophir power meter.

Both mode overlaps are around 50%, which is fine. 

The beatnote amplitudes at the BBPD outputs at a frequency of about 50MHz are -20.0 and -27.5 dBm for the X and Y beats, respectively. This is consistent with the measured optical power levels and a PD response of ~0.25 A/W at 532nm. The main reason for the disparity is that there is much more X green light than Y green light on the table (factor of ~20), and the greater amount of green PSL light on the Y BBPD (factor of ~3) does not quite make up for it. 

One way to punch up the Y beat a little might be to adjust the pickoff optics. Of 25uW of Y arm transmitted green light incident on the polarizing beamsplitter that seperates the X and Y beams, only 13uW makes it to the Y BBPD, but this would only win us a couple dBms at most. 

In any case, with the beat setup as it exists, it looks like we should design the next beatbox iteration to accept RF inputs of around -20 to -30 dBm. 

In the style of the referenced ELOG, here are today's numbers. 

            XARM   YARM 
o BBPD DC output (mV)
 V_DARK:   +  1.0  + 2.2
 V_PSL:    +  7.1  +21.3
 V_ARM:    +165.0  + 8.2

o BBPD DC photocurrent (uA)
I_DC = V_DC / R_DC ... R_DC: DC transimpedance (2kOhm)

 I_PSL:       3.6   10.7
 I_ARM:      82.5    4.1

o Expected beat note amplitude
I_beat_full = I1 + I2 + 2 sqrt(e I1 I2) cos(w t) ... e: mode overwrap (in power)

I_beat_RF = 2 sqrt(e I1 I2)

V_RF = 2 R sqrt(e I1 I2) ... R: RF transimpedance (2kOhm)

P_RF = V_RF^2/2/50 [Watt]
     = 10 log10(V_RF^2/2/50*1000) [dBm]
     = 10 log10(e I1 I2) + 82.0412 [dBm]
     = 10 log10(e) +10 log10(I1 I2) + 82.0412 [dBm]

for e=1, the expected RF power at the PDs [dBm]
 P_RF:      -13.2  -21.5

o Measured beat note power (no alignment done)     
 P_RF:      -20.0  -27.5  [dBm] (53.0MHz and 46.5MHz) 
    e:       45.7   50.1  [%]                         
 

• Why is there a factor of 20 power difference? Some of it is the IR laser power difference, but I thought that was just a factor of 4 in green.
• Why is the mode overlap only 50% and not more like 75%?
• IF we have enough PSL green power, we could do the Y-beat with a 80/20 instead of a 50/50 and get better SNR.
• The FFD-100 response is more like 0.33 A/W at 532 nm, not 0.25 A/W.

In any case, this signal difference is not big, so we should not need a different amplifier chain for the two signals. The 20 dB of amplification in the BeatBox was a fine way, but not great in circuit layout.

The BBPD has an input referred current noise of 10 pA/rHz and a transimpedance of 2 kOhm, so an output voltage noise of 20 nV/rHz (into 50 Ohms). This would be matched by an Amp with NF = 26 dB, which is way worse than anything we could bur from mini-circuits, so we should definitely NOT use anything like the low-noise, low output power amps used currently (e.g. ZFL-1000LN....never, ever use these for anything). We should use a single ZHL-3A-S (G = 25 dB, NF < 6 dB, Max Out = 30 dBm) for each channel (and nothing else) before driving the cables over to the LSC rack into the aLIGO demod board. I just ordered two of these now.

I've been thinking a bit about what the ideal cable length / delay time for the upgraded ALS beatbox should be. Here are some thoughts, but no conclusions yet. 

If you're not running your beatbox mixer in compression, there are two competing effects when you change the cable length. At first, more delay gives better sensitivity, but this does not go on to infinity, because cable attenuation eventually kills your signal. It turns out that the ideal length can be derived to be whatever length gives you 20/ln(10) = -8.7dB of attenuation. Frank found this out in PSL ELOG 825, and I found an HP document that derives this (and other useful DFD math) to the wiki, here.

In PSL ELOG 826, Frank calculated this ideal length for a 160MHz carrier in various kinds of cables. 

However, this is not the end of the story. In the case of the DFD, we actually benefit from operating the mixer in compression, as makes our sensitivity less sensitive to flucuations in the beat amplitude. In this situation, the HP doc states "For maximum sensitivity, more delay can be added until the signal level out of the delay line is 8.7dB below the phase detector (mixer) compression point." I'm not sure I really understand the logic behind this statement, though. 

Lastly, Koji mentioned the fact that the splitter in the demod board does not split at exactly 90 degrees, making the trajectory in the IQ plane an ellipse. This means that if the beat signal is moving around the ellipse a lot, or even wrapping around it, we can suffer from some nonlinear signal conversion. Also, if the raw DFD sensitivity is very high, the free swinging mirrors will cause the signal to swing around faster than the phase tracker can keep up. This should be easy to avoid, however; I doubt we will use so much cable that the beat would move by so much. 

I intend to take all of this into account when picking a cable length! Jessica is going to help us make a nice box for them, too. 

This afternoon, I had a fruitful conversation with Rich Abbott about various kinds of cables.

I've sent an email to Steve to ask him to buy 2 x 50m LMR-195 cables, with male SMA connectors. Rich highly recommends these for their polyethylene insulation, which makes them less microphonic and less susceptible to thermal expansion, low loss, and multi-ply bonded foil shielding.

50m means that the peak to peak mixer output swing corresponds to about a MHz. 1nV of mixer output noise looks like ~6mHz frequency noise, for a Level 3 mixer appropriately driven. As a comparison, the lowest our in-loop green PDH error signals get is 0.1Hz/rtHz. 

The cable attenuation should be around 4.2dB at 50MHz, and 7.3dB at 150MHz, according to the data sheet. Thus, we should not be in the regieme where we are losing sensitivity to the attenuation. 

By my rough geometric estimation, these two should fit in the 2U box I got ahold of today fine. Jessica is designing the front panel. 

We currently have ~30m of RG-408 and RG-142 as our delay lines. 

I've been working on getting a working ALS up and running. Things are in a bit of a transient state right now; I'm off to softball and dinner, and will resume work tonight. There will be a more detailed ELOG then, but here are some quick notes:

• c1als has been gutted, phase trackers are working successfully in c1lsc frontend. All channel names remain the same. 
• BEATX is on the ADC channels where AS165 used to live, BEATY at POP55. 
• Used a marconi to drive the aLIGO LSC demod board in the LSC rack, was able to lock digital phase tracker on two channels
• Noise looks pretty cruddy. Lots of 60Hz harmonics on both channels, maybe from marconi drive? Pickup in the delay line?
• BEATX whitening filter maybe has something fishy going on; excess noise at 2kHz
• Unclear if BEATY whitening filter is actually doing anything. 
• Whitening gain switching works fine for both, though. Haven't revisited the switching code, so its controlled in the old RFPD place for now.
• Whitening triggering is not set up, will require some thought and model work that isn't neccesary yet. 
• Agilent analyzer, marconi, and old delay lines are currently stashed behind the LSC rack; I will resume work with them tonight. 

The main thing left to do is to install the RF amplifiers at the PSL table and route the green beat signals over to the LSC rack. I fear that some investigation into the whitening filters will be neccesary to make the performance adequate, however. 

Too sleepy to make full ELOG. Stay tuned. 

Two 25dB amplifiers (with fins!) are living in the top shelf on the PSL table, inputs currently grounded. I broke out the fused 24V power from the AOM driver to power the two amps and the AOM driver. I used the POP55 and AS165 heliax cables to get their outputs to the LSC rack, through delay lines, into demod board. 

Driving with -20dBm at 55MHz, the BEATX signal chain has about 60Hz RMS noise, which is about what I measured for driving the old beatbox with a marconi. High frequency noise is a much nicer shape, though. The BEATY signal didn't seem to be getting through, will double check soon. 

Still old delay cables, not nicely shielded or isolated or anything. We'll have to pipe the monitor signal from the LSC rack over to the control room analyzer now. 

Turns out the reason that the BEATY signal wasn't working is that one of the two RF amplifiers (both of which are model ZHL-32A), isn't amplifying. Voltage at the pins is fine, so maybe its just broken. When the ZHL-3As that Rana ordered arrive, I'll install those. 

Switching the working amplifier between the two channels, and using a Marconi driving -20dBm (the Y green beatnote amplitude), the phase tracker output RMSs are 70Hz and 150Hz for X and Y, respectively, which isn't too exciting. There is enough whitening gain and filtering that I don't think ADC noise is an issue (The magnitude of the phase tracker Q is ~10kcounts after +6dB whitening gain). 

The RMS in both channels mostly comes from a whole mess of 60Hz harmonics. I'll see what I can do by taking better care of the delay line cables, but it is kind of weird that this would be worse now, given that there was little care given to them before either.

Also, for now, so I don't have to lug the marconi around everywhere, I'm currently driving both channels of the demod board with a spare 55MHz LO output of the LSC LO distribution box, which ends up being a factor of 5 smaller phase tracker error signal, but the noise level is about the same as with the marconi. 

BALUNs

I was having issues trying to get reasonable noise performance out of the aLIGO demod board as an ALS DFD. Terminating the inputs to the LSC whitening inputs did not show much 60Hz noise, and an RMS in the single Hz range. 

A 60Hz line of hundreds of uV was visible in the power spectrum of the single ended BNC and double-ended DB25 outputs of the board no matter how I drove or terminated.

So, I tried out hooking up the ALS beatbox. It turns out to work better for the time being; not only is the 60Hz line in the analog outputs about ten times smaller, the broadband noise floor in the resultant beat spectrum when driven by a 55MHz LO on the LSC rack is a fair bit lower too. I wonder if this is due to not driving the aLIGO board LO at the +10dBm it expects. With the amplifiers and beat note amplitudes we have, we'd only be able to supply around 0 dBm anyways. 

Here's a comparison of the aLIGO board (black) and ALS beatbox (dark green) driven with the 55MHz LO, both going through the LSC whitening filters for a resultant magnitude of 3kCounts in the I-Q plane. The RMS sensing noise is about 30 times lower for the beatbox. (Note, this is with the old delay cables. When we switch to the 50m cables, we'll win further frequency noise sensitivity through the better degrees->Hz calibration.) I'm very interested to see what the green beat spectrum looks like with this setup. 

Not only is the 60Hz line smaller, there is simply less junk in the beatbox signal. I did not expect this to be the case. 

There were some indications of funky status of the aLIGO board: channels 3 and 4 are totally nonfunctioning, so who knows what's going on in there. I've pulled it out, to take a gander if I can figure out how to make it suitiable for our purposes. 

I'm a little mystified. Peeking inside the aLIGO demod board, I saw that the reason that two of the channels weren't working was that their power connectors weren't plugged in, so no real mystery there. 

I hooked up the board at the electronics bench, and found the noise to be completely well behaved, in contrast to the measurements I made when it was in the LSC rack. I've taken it back out to the LSC rack, and given it the X beatnote, and it seems to be performing pretty well. 

I switched between the aLIGO demod board and beatbox during the same lock / beat. The LSC board performs margnially better from 3-100 Hz. The high frequency noise comes from the green PDH loop (coherence is near one above a few hundred Hz), so we don't expect any difference there. 

To me, the beatbox noise looks like there is a broad feature that is roughly the same level as the real cavity motion in the 10-100 Hz range. So, I think we should use the aLIGO board afterall, presuming the noise doesn't shoot back up when I remount it in the rack...

The ALS noise is getting low enough where our normal approach of measuring ALS sensing noise by simply taking the PSD of the signal when the arm is PDH locked is not quite valid anymore, as it is sensing the real cavity fluctuations. Doing a frequency domain coherent subtration of the PSDs suggests a sensing noise RMS of ~150Hz for ALSX. 

When the X arm is locked on ALS, POX sees about 250Hz RMS out of loop noise, which isn't the greatest; however, I used to be happy with 500Hz. By eye, sweeping through IR resonance is smoother. The real test is to get the Y arm ALS running, and swing it through PRFPMI resonance...

Fair warning, the LSC rack area is not so tidy right now, the demod board is resting on a stool (but not in the way of walking down the arm). I'll clean this up tomorrow. 

Jessica and I took 45 mins  (GPS times from 1122099200 to 1122101950) worth of data from the following channels:

C1:IOO-MC_L_DQ (mode cleaner)
C1:LSC-XARM_IN1_DQ (X arm length)
C1:LSC-YARM_IN1_DQ (Y arm length)

and for the STS, GUR1, and GUR2 seismometer signals.

The PSD for MCL and the arm length signals is shown below,

I looked at the coherence between the arm length and each of the three seismometers, plot overload incoming below,

For the coherence between STS and XARM and YARM,

For GUR1,

Finally for GUR2,

A few remarks:

1) From the coherence plots, we can see that the arm length signals are coherent with the seismometer signals the most from 0.5 - 50 Hz. This is most evident in the coherence with STS. I think subtraction will be most useful in this range. This agrees with what we see in the PSD of the arm length signals, the magnitude of the PSD starts increasing from 1 Hz and reaches a maximum at about 30 Hz. This is indicative of which frequencies most of the noise is present.

2) Eric did not remember which of  GUR1 and GUR2 corresponded to the ends of XARM and YARM. So, I went to the end of XARM, and jumped for a couple seconds to disturb whatever Gurald was in there. Using dataviewer I determined it was GUR1. Anyways, my point is, why is GUR1 less coherent with both arms and not just XARM?  Since it is at the end of XARM, I was expecting GUR1 to be more coherent with XARM. Is it because, though different arms, the PSD's of both arms are roughly the same? 

3) Similarly, GUR2 shows about the same levels of coherence for both arms, but it is more coherent. Is GUR2 noisier because of its location?

Code: ARMS_COH.m.zip

Ignacio and I downloaded data from the STS, GUR1, and GUR2 seismometers and from the mode cleaner and the x and y arms. The PSDs along the arms have the most noise at frequencies greater than 1 Hz, so we should focus on filtering in that area. The noise levels start dropping at around 30 Hz, but are still much higher than is seen at frequencies below 1 Hz. However, because the spectra is so low at frequencies below that, Wiener filtering alone injected a significant amount of noise into those frequencies and did not do much to reduce the noise at higher frequencies. Pre-filtering will be required, and I have started implementing a pre-filter, but with no improvements yet. So far, I have tried making a bandpass filter, but a highpass filter may be ideal in this case because so much of the noise is above 1 Hz. 

The refreshed ALS didn't look so bad today (elog forthcoming), so I decided to give PRFPMI locking a shot tonight. I was able to hold the PRMI while swinging through resonsance, but transitions to RF signals failed. Demod angles / whitening gains/ etc. etc. all need to be rechecked

Some little things here and there that got cleaned up...

• The PRM oplev beam was being blocked. Why? I removed the block. Should recheck OLTF/spot size on QPD. 
• ALS -> CARM, DARM signs changed, maybe because I've used the delayed beat as the RF input on the demod board, whereas I imagine it may have been the LO in the beatbox. No big deal.
• REFL165 whitening gain and input matrix updated. Should recheck demod angles.
• PRMI triggering settings weren't being set in the script. It's important to include arm transmission signals, since POP2F signals can momentarily dive when swinging through resonance. 
• I should revisit phase tracker UGF normalization. I/Q amplitudes are varying quite a bit from lock to lock. 
• PRC angular feedforward disabled for now; need to remeasure the witness/target data with DC coupled ITM oplevs
• I think there has been a little bit of MC servo tweaking since our last locks, may need to recheck AO TF / gains. 

ALS is not currently limited by the demod board or whitening electronics.

The noise budget in the green locking paper shows the main noise sources to be these two, plus the residual fluctuations of the green PDH loop. 

So, one next step is AUX PDH noise budget. 

However, I wonder how much of the low frequency noise can be explained by instability of the beat alignement on the PSL table, and how this might be quantified. 

Yesterday, I put together a few measurements to asses whether the new demod board has moved us in the right direction. Specifically I measured the output of the phase tracker in the following states, adjusting the phase tracker gain to maintain a ~2kHz UGH (but no boost on):

• Whitening chassis inputs terminated. BEAT_I input channels were given a 3000 count offset to give the phase tracker something to work with. This is a typical beatnote amplitude with the new RF amplifiers. 
• aLIGO LSC demod board driven with an SRS SD345 at 30MHz. (First with +3dBm into the splitter, which is about what it sees with the green beatnotes, then with +13dBm into the splitter, to give the board the +10dBm LO it expects)
• Arms locked with POX, POY. AUX laser temperature servos on. Green beatnotes in the 20-40MHz range. 

Results: The beat frequency spectrum is above the measured demod board and whitening chassis/ADC noise at all frequencies. It's a little close at 10Hz. 

One nice feature is that the beat spectra are far more similar to each other than they used to be. RMS noise is in the 300-400Hz range, which isn't mindblowing, but not terrible. On the order of 50 pm for each arm. Most of this comes from below 10Hz. 

Another thing to note is that, when we switch in the 50m cables, we should win a fair bit of Hz/V gain and push down these noises futher. (We're currently using 30m cables.)

By looking at some coherences, we can attribute some of the noise when IR locked to both colors of PDH loops. 

Specifically, the coherence with the Green PDH error implicates the residual frequency noise of the AUX laser above a few hundred Hz, whereas the feature from 20-50Hz is probably real cavity motion, not ALS sensing noise. Some of the 1-3Hz noise is from real suspension/stack resonances too. 

If it turns out that we do want to push the demod board noise down further, we could think about increasing the RF amplification. Driving the board harder translates directly to better noise performance. The 60Hz harmonics aren't so exciting, but not the end of the world.

Data files are attached, if you're in to that sort of thing. 

I followed my hunch, and the truth comes out.

I recalled that the aLIGO demod board has a handy DB9 output on the back panel for the detected power at the RF and LO inputs. I hooked this up into the BEATY ADC channels while checking the ALSX spectrum in IR lock. 

This is assuredly the limiting factor in our ALS sensitivity.

Note: I'm calling the fluctuations of the beatnote amplitude "RF Amplitude RIN," to put things in reasonble units. I haven't looked up the board's conversion of dBm to V, but the LO should be around 0dBm in this measurement. 

The coherence between the phase tracker output and the LO amplitude is significant over a broad range, mostly dipping where real cavity motion peeks up into the spectrum. 

Also, the feature from 10-100Hz in the RIN spectrum is one I've often seen directly in ALS spectra when beatnote alignement is bad or the beatnote frequency is high, convincing me further that this is what's to blame. 

So: what do we do? Is there anything we can do to make the green alignment more stable?

Notes from tonight's work:

• PMC alignment tweaked. Not much gained
• WFS/MC2 offsets tweaked after recentering beams on WFS and some hand alignment. 
• Vertex oplevs realigned for the first time in forever
• With an RF coupler, measured the X green beatnote to be +5dBm into the splitter. This resulted in -33dBm at the control room analyzer. 
• Switched the ALS demod board inputs, from piping the delayed signal to the RF input, to sendingit to the LO input. This was motivated by wanting the mixer closer to compression, hopefully to reduce beatnote amplitude fluctuation sensitivity. This won some noise >100Hz.
  • This led to record ALS noise levels - X:217Hz, Y:203Hz 
  • +2dBm into the board still leaves us some headroom for futher amplification. Board schematic lists +10dBm LO as "nominal," but maybe this isn't worth it... 
• ​PRFPMI locking is still stalled at bringing in the RF signals. Debugging continues.
• Some beatnote amplitude fluctuation investigations (see below)
• Note to self: demod board schematics include an unspecified RF lowpass. Check out what got stuffed in there. 

I've explored the beatnote fluctuations a bit further. 

First, I realized that we already had a channel than functions much like an RF level monitor: the phase tracker Q output. I verified that indeed, the Q signal agrees with the RF monitor signals from the demod board within the phase tracker bandwidth. This simplifies things a little.

I also found that the Y beat suffers a fair bit less from these effects; which isn't too surprising given our experience with the alignment stability.

One possible caveat to my earlier conclusions is that the beatnote amplitude could be fluctuating due to real RIN of the green light transmitted through the cavity. In fact, this effect is indeed present, but can't explain all of the coherence. If it did, we would expect the DC green PDs (ALS-TR[X/Y]) to show the same coherence profile as the RF monitors, which they don't.  

The next thing I was interested was whether the noise level predicted via coherence was realistic. 

To this end, I implemented a least-squares subtraction of the RF level signal from the phase tracker output. I included a quadratic term of the RF power, but this turned out to be insiginficant. 

Indeed, using the right gain, it is possible to subtract some noise, reproducing nearly the same spectrum as the coherence based estimate. The discrepency at 1Hz is possible from 1Hz cavity RIN, as suggested by the presence of some coherence with TRX. 

However, this is actually kind of weird. In reality, I would've expected the coupling of RF level fluctuations to be more like a bilinear coupling; changing the gain of the mixer, rather than directly introducing a linearly added noise component. Maybe I just discovered the linear part, and the bilinear coupling is the left over low frequency noise... I need to think this over a little more.  

Jessica will soon ELOG about some measurements suggesting that the conductive connector-ized ALS delay line enclosure is the way to go, when considering crosstalk between the delay lines. It is currently mounted and hooked up on the LSC rack, though I need to make a bunch of new SMA cables now that I think a semi-permanent arrangement has been reached. 

I did a rough re-calibration of the phase tracker output, since the increased cable delay changes the degree/Hz gain. This was done by fitting a line to a slow sawtooth FM of the SRS DS345's (1Hz rate, 10kHz deviation, 30MHz carrier). This resulted in the following calibration updates

• ALSX: 19230 -> 13051 Hz/count, 3.4dB more sensitive

• ALSY: 19425 -> 12585 Hz/count, 3.8db more sensitive

Again, this is a rough calibration. Nevertheless, it is not so surprising we don't get the 50m/30m = 4.4dB increase we would expect just from the lengths; the (I presume) increased cable loss matters. Also, the loss' frequency dependance is an additional reason that the phase tracker calibration is not constant over all frequencies. 

I took spectra with the arms in IR lock, but didn't see any real improvement beyond a possible dip in the floor from 100-200Hz. This doesn't surprise me too much, however, since I don't believe that we are currently dominated by electronic noises that this gain increase would help overcome. 

Last week, Koji mentioned the ALS phase noise added due to the post-cavity table motion the arm-transmitted green beams experience before hitting the beat PD. I should estimate the size of this effect for our situation. 

The mode cleaner FF static filtering is by no means done. More work has to be done in order to succefuly implement it, by the means of fine tuning the IIR fit and finding better MISO Wiener filters. 

I have begun to look at implementing FF to the YARM cavity for several reasons.

1) Even if the mode cleaner FF is set up as best as we can, there will still be seismic noise coupling into the arm cavities.

2) YARM is in the way of the beam path. When locking the IFO, one locks YARM first, then XARM. This means that it makes sense to look at YARM FF first rather than XARM.

3) XARM FF can't be done now since GUR2 is sketchy.

I'm planning on using this eLOG entry to document my Journey and Adventures (Chapter 2: YARM) to the OPTIMAL land of zero-seismic-noise (ZSN) at the 40m telescope.

I took data from 1123495750 to 1123498750 GPS time (Aug 13 at 3AM, 50 mins of data) for  C1:LSC-YARM_OUT_DQ, and all T240 and GUR1 channels.

Here is the PSD of the YARM_OUT, showing the data that I will use to train the FIR filter:

Coherence plots for YARM and all channels of T240 and GUR1 sesimometers are shown below. This will help determine what regions to preweight the best before computing FIR filter. They also show how GUR1 is back to work compared to those of elog:11457.

Plotte below are the resultant subtractions for YARM using different witness configurations,

The best subtraction happens with all the channels of both the GUR1 and T240 seismometers, but one gets just as good subtraction without using the z channels as witnesses. 

Also, why is the T240 seismometer better at subtracting noise for YARM compared to what GUR1 alone can acomplish? Using only the X and Y channels for the T240 gave the third best subtraction(purple trace). 

My plan for now is as follows:

1) Measure the transfer function from the ETMY actuator to the YARM control signal

2) Collect data for YARM when FF for MCL is on in order to see what kind of subtractions can be done.

In my last post I calculated the different subtractions (offline) that could be done to YARM alone just to get a sense of what seismometers were better witnesses for the Wiener filter calculation. 

In this eLOG I show what subtractions can be done when the MCL has FF on (as well as Eric's PRC FF), with the SISO filter described on elog:11496.

The plot below shows what can be done offline,

What is great about this results is that the T240-X and T240-Y channels are plenty enough to mitigate any remaining YARM seismic noise but also to get rid of that nasty peak at 55 Hz induced by the MCL FF filter.

The caviat, I haven't measured the TF for the ETMY actuator to YARM control signal. I need to do this and recompute the FIR filters with the prefiltered witnesses in order to move on to the IIR converions and online FF!

Now that the updated ALS is stable, and the PRC angular FF is revived, I've been working on relocking PRFPMI. While the RMS arm fluctuations are surely smaller than they used to be, there is no noticible difference to the ears when buzzing around resonance, but this doesn't really mean much. 

Frustratingly, I am not able to stably blend in any RF CARM error signal into the slow length control path (i.e. CARM_B). Bringing AS55 Q into DARM with the 20:0 integrator is working fine, but we really need to supress CARM to get anywhere. I'm not sure why this isn't working; poking around into the settings that were used when we were regularly locking didn't turn up any differences as far as I could tell. Investigations continue... 

Some minor changes to the locking script were made, to account for the increased ALS displacement sensitivity from the longer delay line. 

Since the ALS is now in a fairly stable state, I've updated the calibrated PSD template at /users/Templates/ALS/ALS_outOfLoop_Ref.xml, and added some coherence plots for some commonly coupled quantities (beat signal amplitude, IR error signal, green PDH error signal and green transmission). 

Yesterday, Rana, Jessica and I measured the Transfer function from LSC-YARM-EXC to LSC-YARM-IN1. 

The plot below shows the magnitude and the phase of the measured transfer function. It also shows the normalized standard error in the estimated transfer function magnitude; the same quantity can be applied to the phase, only in this case it is interpreted as its standard deviation (not normalized). It is given by

where  is the ordinary coherence function and  is the number of averages used at each point of the estimate, in the case here we used 9 averages. This quantity is of interest to us in order to understand how the accuracy of transfer function measurement affects the ammount of subtraction that can be achieved online.

Since this transfer function is flat from 1-10 Hz (out of phase by 180 deg), this means that we can apply our IIR wiener filters direclty into YARM without taking into account the TF by prefiltering our witnesses with it. Of course this is not the case if we care about subtractions at frequencies higher than 10 Hz, but since we are dealing with seismic noise this is not a concern.

The coherence for this transfer function measurement is shown below,

PRFPMI locking has been revived.

I've had 6 5min+ locks so far; arm powers usually hit ~125 for a recycling gain of about 7; visibility is about 75%

The locking script takes a little under 4 minutes to take you from POX/POY lock to PRFPMI if you don't have to stop and adjust anything.

At Koji's suggestion, I used digital REFL11 instead of CM_SLOW, which got me to a semistable lock with some RF, at which time I could check the CM_SLOW situtation. It seemed like the whitening Binary IO switch got out of sync with the digital FM status somehow... 

I've been making the neccesary changes to the carm_cm_up script. I also added a small script which uses the magnitude of the I and Q signals to set the phase tracker gain automatically based on some algebra Koji posted in an ELOG some years ago. 

The RF transition seems much smoother now, most likely due to the improved PRC and ALS stability. In fact, it is possible to hold at arm powers of >100 solely on the digital servos; I don't think we were able to do this before until the AO had kicked in. 

Right now I'm losing lock when trying to engage the CARM super boost. I also haven't switched the PRMI over to 1F signals yet. Would be good to hook the SR785 back up for a loop TF, but I'll stop here for tonight since our SURFs are presenting bright and early tomorrow morning. 

As per Ignacio's request, I restored the arm locking.

- MC WFS relief

- Slow DC restored to ~0V

- Turned off DARM/CARM

- XARM/YARM turned on

- XARM/YARM ASS& Offset offloading

More PRFPMI locks tonight. Right now, it's been locked for 22+ minutes, though with the PRMI still on 3F signals. I think the MC2/AO crossover needs some reshaping; there's a whole bunch of noise injected into CARM around 600 Hz, which is where the two paths differ by 180deg. (Addendum: broke lock at ~27 minutes, 4:16AM)

For most of this lock, sensing matrix excitations have been running for daytime analysis. 

The nominal IMC loop gain / EOM crossover were making the AO path very marginal. I've adjusted the nominal settings and autolocker scripts. 

There was some weird behavior of X green PDH earlier... Broadband RIN seen in ALS-TRX, coherent with the DC output of the beat PD, so really on the light. I fiddled with the end setup, and it mostly went away, though I didn't intentionally change anything. Disconcerting. 

I spent some time tonight chasing down the cause of huge RIN in the X green PDH transmitted light, which I had started seeing on Monday. This was preventing robust locking, since the ALS sensing noise was ~10x worse above 50Hz, thus making the AO transition much flakier (though, impressively, not impossible!)

I went down to the X end, and found that turning the laser diode current down by 0.1A (from 2.0 to 1.9) smoothed things out completely. Unfortunately, this causes the power to drop, from GTRX of 0.45 to 0.3, but the ALSX sensitivity is unchanged, as compared with the recenent "out of loop" template. 

This also seems to have changed the temperatures of the good modes, as no beat was evident at the previously good temperature. Beats were found at +5400 and +10500 counts on the slow servo offset slider; I suspect the third lies around the edge of the DAC range which is why I couldn't uncover it. In any case, I've parked it at 10500 for now, and will continue locking; nailing it down more precisely and offloading the slider offset to the laser controller will happen during daytime work...