40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 220 of 339  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  11941   Thu Jan 21 00:02:11 2016 KojiUpdateLSCHopeful signs

That's a good news. Only quantitative analysis will tell us if it is true or not.

Also we still want to analyze the traffic with the new switch.

Quote:

On a brighter note, I've only noticed one brief EPICS freeze all night. In addition, the wall StripTools seem totally contiuous since ~4pm, whereas I'm used to seeing some blocky shapes particularly in the seismic rainbow. Could this possibly mean that the old WiFi router was somehow involved in all this? 

 

  11942   Thu Jan 21 18:34:04 2016 ranaUpdateLSCPSL and AUX-X temperatures changed

Is the black ref spectrum from this year or from May of 2015 or ?

I wonder if the noise is a bunch of fast spikes or if its a true broadband rumble. Maybe we can tell by looking at the analog DFD or PLL outputs?

  11943   Fri Jan 22 01:56:01 2016 ericqUpdateLSCAudio ALSX

I hooked up the ALSX DFD output to the fibox, and used the adjustable delay line to set the phase properly. I recorded the noise on pianosa, and have attached it. Of course, this doesn't really capture the low frequency behavior. 

Unrelated to this: I found the MC WFS turned off, and the loops ran away when turning them on. I tweaked the alignment, and reset the WFS offsets. Seems stable for now. 

Attachment 1: ALSX.wav
  11957   Thu Jan 28 14:54:49 2016 ericqUpdateLSCStatus of the green PDH circuits

Yesterday, I uploaded some EAGLE schematic files and a LISO source file for the green PDH servo electronics to the 40m LISO git repository. In doing so, I realized that the DCC document for the X box (D1400293) was not updated at the end of the electronics work we did in Aug/Sep 2014. This is entirely my fault. 

The Y box document (D1400294) is currently accurate. 

The missing information is that, as I posted In ELOG 10457, I ended up destroying our original X box, and replaced it with a spare from the ATF. It was restuffed to match the Y end box pretty much exactly. We will update the X circuit DCC page with an accurate schematic and photo. 

Gautam tells me that he and Rana were looking at the outdated schematic and thinking about improvements, but at least some of this was already done back in 2014 (specifically, the resistors used to specify the AD8336 preamp gain were changed).

  11958   Thu Jan 28 19:10:16 2016 gautamUpdateLSCStatus of the green PDH circuits

 

Quote:

We will update the X circuit DCC page with an accurate schematic and photo. 

I've uploaded reasonably high-resolution photographs of the uPDH box for the X-end and Y-end on their respective wiki pages. I've uploaded two photos for each box, one of the circuit board (I checked that these photos are clear enough that we can zoom in and read off component values if necessary), and one of the box with the peripherals not integrated into the circuit board (i.e. the minicircuits mixer ZAD-8+ and the little Pomona box that is an LP filter for the output from the mixer). Since I pulled the boxes out, I thought it might not be a bad idea to measure the TFs of these Pomona boxes and make sure nothing weird is going on, I'll put up some plots later. 

Rana and I discussed some things to look at earlier today:

  • Check the voltages at test-points 1,7 and 9, and make sure they are as expected
  • Change the gain of the pre-amp from x2 to x4 - as Eric mentioned in the previous elog, these had already been swapped out. Right now a 600 ohm and 200 ohm resistor pair are being used, so the preamp gain is x4, which should be okay as per the datasheet of the AD8336 VGA amplifier (although the "recommended" resistor pairing is 301 ohm and 100 ohm, but I don't think this is critical?
  • Track down the reason for the difference in Gain settings at the X and Y ends - typically, the X-end PDH box "Gain" knob is set to 10, while that for the Y-end is set to ~4. The fact that the PZT actuator gain for the Y-end is ~5 times larger than for the X-end doesn't seem to account for all of this. As per the attached plot, the difference in gain between the ends is ~35 dB, which is a factor of 50!

I also did a quick check of the behaviour of the Servo Gain potentiometer by checking the resistance at various positions of the knob - we had suspected that the potentiometer may be logarithmic, but I found that it was in fact linear. I'll put up a plot of the gain as a function of the Servo Gain knob position soon,(plot added) along with results from the other checks.

While disassembling the setup at the X-end to get the PDH box out, I noticed that the signal from the LO is going to the mixer through a Pomona box (no such Pomona box is used at the Y-end). I opened it up and found that it contains just a pair of capacitors in parallel, so it's a phase shifter?. The LO signal also goes through an attenuator. The mixer in both boxes is a ZAD-8+, so why is this part of the setup different?

Both PDH boxes are not hooked up at the moment, I will restore the setups at both ends after running a few more checks on the boxes...

Attachment 1: Servo_gain_calibration.pdf
Servo_gain_calibration.pdf
  12028   Thu Mar 10 03:03:11 2016 ericqUpdateLSCDRFPMI Power stable, but no RF handoff

[ericq, Gautam]

We worked on getting the DRFPMI back up and running, hoping the ALS performance was good enough. 

We did succeed in bringing in enough of the AO path to stabilize arm powers > 100, but failed at the full RF DARM handoff. 

REFL165 angle was adjusted to -86 to minimize PRCL in the Q signal. 

The AS110 signals are mysteriously huger than they used to be. Whitening gain reduced to 15dB from 27dB. Old trigger thresholds are still fine.

The new AUX X laser has a different sign for the temperature-> frequency coupling, so our usual convention of "beatnote goes up when temp slider goes up" meant the ALSX input matrix elements had to change sign.

We think the POPDC PD (which I think is the POP2F PD) may be miscentered, since in PRMI configuration, its maximum does not coincide with the REFLDC minimum, and leaves a sizeable TEM10 lobe on the REFL camera. This was a pain. 

  12053   Tue Mar 29 03:16:21 2016 ericqUpdateLSCDRFPMI Locked Once More

[ericq, Gautam]

Three RF-only locks longer than a minute tonight, out of 5 total attempts. 

Last week, I determined that the beam spot on the RF POP PD is too large. This still needs to be fixed. I updated the ASS model to use REFLDC as a PRCL dither error signal; it works. 

There seems to be some excess angular motion of ETMY tonight. This is evident in the oplev spectra (as compared to ETMX), and the GTRY camera, and even the retroreflected beam from a misalgined ETMY on the ITMY face when the PRC is carrier locked.

Gautam and I mostly focused on setting up the CAL-DARM_CINV block to produce this (mostly) calibrated spectrum starting from GPS 1143274087. [Darm on unwhitened AS55, DRMI on 3F, one CARM boost]

Here are the control and error signal spectra:

[DTT files attached]

Note to self: archive some of this data 

Attachment 1: 2016-03-29_calibdarm.pdf
2016-03-29_calibdarm.pdf
Attachment 2: 2016-03-29_DRFPMI_errctrl.pdf
2016-03-29_DRFPMI_errctrl.pdf
Attachment 3: DRFPMI_DTT.zip
  12055   Wed Mar 30 16:40:24 2016 ericqUpdateLSC2016 vs 2010

I haven't found any data files for the DARM spectrum of the previous generation of 40m, but with some GIMP-fu, I have plotted Monday's spectrum (green) on top of one of the figures from Rob's thesis.

  12069   Mon Apr 11 16:06:30 2016 ericqUpdateLSCDRFPMI Data Archived

I have copied over the complete frame files from two DRFPMI lock acquisitions + locks to /frames/archive. The data should be safe from the wiper script here.

One, under the subfolder DRFPMI_Mar29_cal is the lock where the CAL-DARM channel is properly calibrated at GPS time 1143274087.

The other lock, under DRFPMI_MAR29_nocal, does not have the calibration set up yet, but was a much quicker acquistion (<2 min from ALS acquisition to DRFPMI) and longer lock (~8min).

  12097   Thu Apr 28 15:23:11 2016 ericqUpdateLSCGreen PDH demod lowpass

The 2F product out of the mixer is a natural concern when demodulating. However, I think this isn't so big of a deal in our green PDH servos; 420kHz isn't so high of a frequency that the servo amplifiers are bandwidth or slew-rate limited. Furthermore, the amplitude of this line is supressed by the loop somewhat, since it arises from the same field product that the loop is acting on. Measuring the Y end mixer output with a high impedance probe and the AG4395 shows it to be something like -50dBm. 

In fact, the main thing that the pomona LPFs are accomplishing right now is filtering the 1F content of the mixer output that arises from the second order sideband creating a signal at 2F, and beating with the LO at (2F-1F)=1F. This line is something like -30dBm (5mVrms) at the mixer output; I can reproduce this amplitude with a back-of-the envelope calculation using a modulation depth of 0.3, 8V out of the PD at DC when unlocked, the mixer datasheet, and the nominal cavity parameters. 

The nice thing about this is that we don't need to filter this after the mixer, we can use a [bandpass/lowpass/notch] filter before the mixer (as is done in the LSC demod boards) to filter out the 2F (420kHz) content of the PD signal, which will only introduce some small amount of linear time delay to the PDH loop, instead of the wicked phase loss from the current post-mixer LPF. We can then replace that 70kHz filter with something of lower order or higher corner frequency to win a good deal of phase in the PDH loop. 

  12098   Thu Apr 28 18:53:05 2016 ranaUpdateLSCGreen PDH demod lowpass

OK - but give us a circuit diagram and the expected before/after loop plots. Got to make sure we keep the right impedance from PD to mixer. Some of the Thorlabs PDs have a 50 Ohm instead of 0 Ohm source impedance. Maybe you can try it out now since the green arm is ready.

  12101   Fri Apr 29 16:13:36 2016 ericqUpdateLSCGreen PDH demod lowpass

We can get as much, if not more, attenuation of the 1F line in the mixer output that we get from the post-mixer LPF from using the following passive filter between the PD and mixer RF input:

There should still be some kind of LPF after the mixer, but I haven't yet determined what it should be; this will determine how much phase the PDH loop wins. At most, this should win around 25 degrees at 10kHz.


The filter was designed by referencing the "Handbook of Filter Synthesis" by Zverev, looking for an elliptic filter for matched source and load impedences, 40dB min attenuation in the stopband, a stopband frequency that starts at twice the corner frequency, and minimizing the VSWR between the PD and filter in the passband.

In terms of the tables in the book, this means: n=5, rho=2%, theta=30deg, K**2 = 1.0. The dimensionless component values were scaled by the corner frequency of 200kHz, and reference impedence of 50 Ohm. (The corner is a little lower than the real modulation frequency, since the nonzero resistance of the inductors pushes the frequency up a bit)

The ideal capactior values do not correspond to things we have in hand, so I checked our stock and chose the closest value to each one.Unsurprisingly, due to these component substitutions, and the fact that the coilcraft inductors have a resistance of about 7 Ohms, the predicted TF of the realizable filter does not match the design filter exactly. However, the predicition still looks like it will meet the requirement of 40dB of supression of the 2F line in the PD signal. (Since we have tunable inductors, I've used the ideal inductor values in generating the TF. In practice I'll inspect the TF while I tune them)

  Desired Realizable
C1 8.28 nF 10 nF
C2 1.39 nF 1.5 nF
C3 19.6 nF 22 nF
C4 4.22 nF 4.7 nF
C5 6.08 nF 6.8 nF
L2 43.1 nH 32-48 nH + 7 Ohm
L4 34.4 nH 32-48 nH + 7 Ohm

[In this TF plot, I've multiplied the real response by 2 to account for the voltage division that occurs with ideal 50 Ohm impedance matching, to make 0dB the reference for proper matching]

The filter's phase delay at the modulation frequency is just about 180, which as a time delay of 5usec works out to 9 degrees of phase loss at 10kHz in the PDH loop. According to some old measurements, the current LPF costs something like 35 degrees at 10k, so this wins at most around 25 degrees, depedent on what LPF we put after the mixer.

LISO source both traces is attached!

Attachment 3: elp_liso.zip
  12106   Thu May 5 04:05:03 2016 ericqUpdateLSCAux X PDH checks

We took an OLG measurement of the green PDH loop. It seems consistent with past measurements. I've added a trace for the the post-mixer lowpass, to show its contribution to the phase loss. (EDIT: updated with measured LPF TF)

I used this measured OLG and the datasheet laser PZT conversion factor to calibrate the control signal monitor into the AUX laser frequency noise, it looks consistent with the frequency noise measured via the PSL PLL (300 Hz/rtHz @ 100Hz). Above a few tens of kHz, the control signal measurement is all analyzer noise floor, due to the fourth order 70kHz lowpass after the mixer (the peaks change height significantly depending on the analyzer input range, so I don't think they're on the laser). Gautam will follow up with more detailed measurements of both the error and control signals as he noisebudgets, this was just intended as a quick consistency check.

  12107   Thu May 5 14:03:52 2016 ericqUpdateLSCFurther Aux X PDH tweaks

This morning I poked around with the green layout a bit. I found that the iris immediately preceding the viewport was clipping the ingoing green beam too much, opening it up allowed for better coupling to the arm. I also tweaked the positions of the mode matching lenses and did some alignment, and have since been able to achieve GTRX values of around 0.5.

I also removed the 20db attenuator after the mixer, and turned the servo gain way down and was able to lock easily. I then adjusted the gain while measuring the CLG, and set it where the maximum gain peaking was 6dB, which worked out to be a UGF of around 8kHz. On the input monitor, the PDH horn-to-horn voltage going into the VGA is 2.44V, which shouldn't saturate the G=4 preamp stage of the AD8336, which seems ok.

The ALS sensitivity is now approaching the good nominal state:

There remains some things to be done, including comprehensive dumping of all beams at the end table (especially the reflections off of the viewport) and the new filters to replace the current post-mixer LPF, but things look pretty good.

Attachment 1: 2016-05-05_newals.pdf
2016-05-05_newals.pdf
  12110   Fri May 6 16:42:12 2016 ericqUpdateLSCGreen PDH demod lowpass

I've build the filter, and it seems to have the desired TF shape.

I also re-purposed the 70k lowass to a ~120k lowpass by changing the 68nF caps to 22nF caps, since we still want some post-mixer rolloff. 

However, putting the ELPF in the chain caused some weird shapes in the OLG. I still need to get to the bottom of it. However, just with the post-mixer LPF modification, here's what the OLG looks like:

As Rana surmises, we definitely still add a boost and maintain a 10k UGF. I still need to look into the state of the remote boost....

  12111   Fri May 6 19:08:52 2016 ranaUpdateLSCGreen PDH demod lowpass

Seems weird to design a PD lowpass with a corner at the modulation frequency. Recall what our strategy is with the other photodetectors we use for PDH servos: bandpass, not low-pass, and the band has to be wide enough to not effect the phase of the servo.

  12112   Sat May 7 09:40:40 2016 ericqUpdateLSCGreen PDH demod lowpass

As I was looking at filter designs, it seemed difficult to get 40dB of supression at 2F with a bandpass without going to a pretty high order, which would mean a fair number of lossy inductors.

I'll keep working on it. Maybe we don't need 40dB...

  12113   Sun May 8 08:39:21 2016 ranaUpdateLSCGreen PDH demod lowpass

Indeed. This is why the LSC PDs have a 2f notch in addition to the 1f resonance. In recent versions, we also put a 2f notch in the feedback of the preamp which comes after the diode but before the mixer. The overall 1f to 2f ratio that we get is in the 50-60 dB region. I don't think we have to go that far with this thing; having a double LC already seems like it should be pretty good, or we could have a single LC bandpass with a 2f notch all in one Pomona box.

  12114   Tue May 10 03:44:59 2016 ericqUpdateLSCRelocked

ALSX noise is solidly within past acceptable performance levels. The DRFPMI was locked on four out of six attempts. 

Some housekeeping was done:

  • PMC aligned
  • Static alignment voltages of X end PZT mirrors offloaded by turning mount screws
  • Rough comissioning of AUX X dither alignment
  • Locking scripts reverted to AUX X Innolight voltage/temperature sign convention

The recombination of the QPD signals to common / differential is imperfect, and limited how well we could keep the interferometer aligned, since the QPD at X has changed. This needs some daytime work. 

Some sensing matrix measurements were made, to be meditated upon for how to 1F the DRMI.

Other to-dos:

  • Bandpass + notch combo for green refl PDs
  • SRCL, and to a lesser extant, MICH feedforward subtraction (See DARM vs. other length DOF coherence plot below)
  • Fiber couple AUX X light
  • Make IFO work good


As an aside, Gautam and I noticed numerous green beams coming from inside the vacuum system onto the PSL table. They exist only when green is locked to the arms. Some of them come out at very non-level angles and shine in many places. This doesn't make me feel very happy; I suppose we've been living with it for some time. 

Attachment 1: 2016-05-10_DARMcoherence.pdf
2016-05-10_DARMcoherence.pdf
  12124   Fri May 20 17:36:06 2016 gautamUpdateLSCNew stands for TransMon/Oplev QPDs

As we realized during the EX table switch, the transmitted beam height from the arm is not exactly 4" relative to the endtable, it is more like 4.75" at the X-end (yet to be investigated at the Y-end). As a result, the present configuration involves the steering optics immediately before the Oplev and TransMon QPDs sending the beam downwards at about 5 degrees. Although this isn't an extremely large angle, we would like to have things more level. For this purpose, Steve has ordered some Aluminium I-beams (1/2 " thick) which we can cut to size as we require. The idea is to have the QPD enclosures mounted on these beams and then clamped to the table. One concern was electrical isolation - but Steve thinks Delrin washers between the QPD enclosure and the mount will suffice. We will move ahead with getting these machined once I investigate the situation at the Y end as well.. The I beams should be here sometime next week...

  12138   Fri May 27 02:52:53 2016 ericqUpdateLSCRestoring high BW single arm control

I've been futzing with the common mode servo, trying to engage the AO path with POY for high bandwidth control of a single arm lock. I'm able to pull in the crossover and get a nice loop shape, but keep getting tripped up by the offset glitches from the CM board gain steps, so can't get much more than a 1kHz UGF.

As yutaro measured, these can be especially nasty at the major carrier transitions (i.e. something like 0111->1000). This happens at the +15->+16dB input gain step; the offset step is ~200x larger than the in-loop error signal RMS, so obviously there is no hope of keeping the loop engaged when recieving this kind of kick. Neither of the CM board inputs are immune from this, as I have empirically discovered. I can turn down the initial input gain to try and avoid this step occuring anywhere in the sequence, but then the SNR at high frequencies get terrible and I inject all kinds of crud into the mode cleaner, making the PC drive furious.

I think we're able to escape this when locking the full IFO because the voltages coming out of REFL11 are so much larger than the puny POY signals so the input-referred glitches aren't as bad. I think in the past, we used AS55 with a misaligned ITMX for this kind of single arm thing, which probably gives better SNR, but the whole point of this is to keep the X arm aligned and lock it to the Y-arm stabilized PSL. 

  12142   Wed Jun 1 09:06:38 2016 SteveUpdateLSCNew stands for TransMon/Oplev QPDs

Machined from I-beam 6061 T6 Aluminum 5" x 0.5 x 3.25

Quote:

As we realized during the EX table switch, the transmitted beam height from the arm is not exactly 4" relative to the endtable, it is more like 4.75" at the X-end (yet to be investigated at the Y-end). As a result, the present configuration involves the steering optics immediately before the Oplev and TransMon QPDs sending the beam downwards at about 5 degrees. Although this isn't an extremely large angle, we would like to have things more level. For this purpose, Steve has ordered some Aluminium I-beams (1/2 " thick) which we can cut to size as we require. The idea is to have the QPD enclosures mounted on these beams and then clamped to the table. One concern was electrical isolation - but Steve thinks Delrin washers between the QPD enclosure and the mount will suffice. We will move ahead with getting these machined once I investigate the situation at the Y end as well.. The I beams should be here sometime next week...

Atm2, version 2 "pdstand" will allow you to clamp from any direction ( Koji was right )

Attachment 1: pdIb.PDF
pdIb.PDF pdIb.PDF
Attachment 2: pdstand.pdf
pdstand.pdf
  12188   Thu Jun 16 11:25:00 2016 JohannesUpdateLSCY-Arm round-trip loss measurement with ALS

Using the ALS green beat and armlength feedback I mapped an IR resonance of the Y-Arm by stepping through a ramp of offset values.

First I optimized the IR alignment with the dither scripts while LSC kept the arm on resonance, and then transitioned the length control to ALS. The beat frequency I obtained between the Y-arm green and the PSL was about 25 MHz. Then I applied a controlled ramp signal (stepping through small offset increments applied to LSC-ALSY_OFFSET, while logging the readback from channels LSC-TRY_OUT16 and ALS-Y_FC_SERVO_INMON with an averaging time of 1s.

The plots show the acquired data with fits to  T(x)=\frac{T_0}{1+\frac{(x-x_0)^2}{\mathrm{HWHM}^2}}+\mathrm{offset} and f(x)=mx+b, respectively.

 

The fits, weighted with inverse rms uncertainty of the data points as reported by the cds system, returned HWHM = 0.6663 ± 0.0013 [offset units] and m = -0.007666 ± 0.000023 [MHz/offset unit], which gives a combined FWHM = 10,215 ± 36 Hz. The error is based purely on the fit and does not reflect uncertainties in the calibration of the phase tracker.

This yields a finesse of 388.4 ± 1.4, corresponding to a total loss (including transmissivities) of 16178 ± 58 ppm. These uncertainties include the reported accuracies of FSR and phase tracker calibration from elog 9804 and elog 11761.

The resulting loss is a little lower than that of elog 11712, which was done before the phase tracker re-calibration. Need to check for consistency.

Attachment 1: T_vs_steps.pdf
T_vs_steps.pdf
Attachment 2: f_vs_steps.pdf
f_vs_steps.pdf
  12189   Thu Jun 16 12:06:59 2016 ericqUpdateLSCRF Amp installed at POY11 RF output

I have installed a ZFL-500LN on the RF output of POY11. This should reduce the effect of the CM board voltage offsets by increasing the size of the error signal coming into the board. Checking with an oscilloscope at the LSC rack, the single arm PDH peak to peak voltage was something like 4mV, now it is something like 80mVyes

The setup is similar to the REFL165 situation, but with the amplifier in proximity with the PD, instead of at the end of a long cable at the LSC rack. 

The PD RF output is T'd between an 11MHz minicircuits bandpass filter and a 50 Ohm terminator (which makes sure that signals outside of the filter's passband don't get reflected back into the PD). The output of the filter is connected directly to the input of the ZFL-500LN, which is powered (temporarily) by picking off the +15V from the PD interface cable via Dsub15 breakout. (I say temporarily, as Koji is going to pick out some fancy pi-filter feedthrough which we can use to make a permanent power terminal on the PD housing.)

The max current draw of this amplifier is 60mA. Gazing at the LSC interface (D990543), I think the +15V on the DSUB cable is being passed from the eurocard crate; I don't see any 15V regulator, so maybe this is ok...

The free swinging PDH signal looked clean enough on a scope. Jamie is doing stuff with the framebuilder, so I can't look at spectra right now. However, turning the POY whitening gain down to +18dB from +45dB lets the Y arm lock on POY with all other settings nominal, which is about what we expect from the nominal +23dB gain of the amplifier.

I would see CM board offsets of ~5mV before, which was more a little more than a linewidth before this change. Now it will be 5% of that, and hopefully more manageable.

  12205   Tue Jun 21 04:01:09 2016 ericqUpdateLSCY arm @ 30kHz UGF w/POY, AO

With the newly amplified POY signal, locking the mode cleaner to the Y arm at ~30kHz bandwidth was quite straightforward. The offset jumps still happen, and are visible in POY11_I_ERR, but are never big enough to cause much power degradation in TRY (except when turning on CM board boosts, but its still not enough to lose lock). The script which accomplishes this is at scripts/YARM, and is in the svn. The MC2/AO crossover is at about 150Hz with 40deg margin.

For now, I'm using IN1 of the CM board, because I haven't removed the op27s that I put into IN2's gain stages. I believe the slew rate limitations of these prevent them from working completely during the offset jumps. I'll put AD829s back soon. 

At first, I had ITMX misalgined to use AS55 as an out of loop sensor, then I aligned and locked the X arm on POX to compare.

Weirdly enough, locking the mode cleaner to the Y arm with 30kHz UGF and two boosts on make no real visible difference in the X arm control signal. This is strange, as the whole point of this affair was to remove the presumably large influence of frequency noise on the X arm signals... Maybe this is injecting too much POY sensor noise?

 

Attachment 1: inloop_outloop.pdf
inloop_outloop.pdf
Attachment 2: xarm.pdf
xarm.pdf
  12210   Wed Jun 22 08:40:42 2016 ranaUpdateLSCY arm @ 30kHz UGF w/POY, AO

Below 100 Hz, I suppose this means that the X arm is now limited by the quadrature sum of the X and Y arm seismic noise.

  12535   Thu Oct 6 03:56:43 2016 ericqUpdateLSCRevival Attempt

[ericq, Gautam, Lydia]

We spent some time tonight trying to revive the PRFPMI. (Why PR instead of DR? Not having to deal with SRM alignment and potentially get a better idea of our best-case PRG). After the usual set up and warm up, we found ourselves unable to hold on to the PRMI while the arms flash. In the past, this was generally solved through clever trigger matrix manipulations, but this didn't really work tonight. We will meditate on the solution.

  12547   Tue Oct 11 02:48:43 2016 ericqUpdateLSCRevival Attempts

Still no luck relocking, but got a little further. I disabled the output of the problematic PRM OSEM, it seems to work ok. Looking at the sensing of the PRMI with the arms held off, REFL165 has better MICH SNR due to its larger seperation in demod angle. So, I tried the slightly odd arrangement of 33I for PRCL and 165Q for MICH. This can indefinitely hold through the buzzing resonance. However, I haven't been able to find the sweet spot for turning on the CARM_B (CM_SLOW) integrator, which is neccesary for turning up the AO and overall CARM gain. This is a familiar problem, usually solved by looking at the value far from resonance on either side, and taking the midpoint as the filter module offset, but this didn't work tonight. Tried different gains and signs to no avail.

  12587   Fri Oct 28 15:46:29 2016 gautamSummaryLSCX/Y green beat mode overlap measurement redone

I've been meaning to do this analysis ever since putting in the new laser at the X-end, and finally got down to getting all the required measurements. Here is a summary of my results, in the style of the preceeding elogs in this thread. I dither aligned the arms and maximized the green transmission DC levels, and also the alignment on the PSL table to maximize the beat note amplitude (both near and far field alignment was done), before taking these measurements. I measured the beat amplitude in a few ways, and have reported all of them below...

             XARM   YARM 
o BBPD DC output (mV), all measured with Fluke DMM
 V_DARK:     +1.0    +3.0
 V_PSL:      +8.0    +14.0
 V_ARM:      +175.0  +11.0


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

 I_PSL:       3.5    5.5
 I_ARM:      87.0    4.0


o Expected beat note amplitude
I_beat_full = I1 + I2 + 2 sqrt(e I1 I2) cos(w t) ... e: mode overlap (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.1  -24.5


o Measured beat note power (measured with oscilloscope, 50 ohm input impedance)      
 P_RF:      -17.8dBm (81.4mVpp)  -29.8dBm (20.5mVpp)   (38.3MHz and 34.4MHz)  
    e:        34                    30  [%]                          
o Measured beat note power (measured with Agilent RF spectrum analyzer)       
 P_RF:      -19.2  -33.5  [dBm] (33.2MHz and 40.9MHz)  
    e:       25     13    [%]                          

I also measured the various green powers with the Ophir power meter: 

o Green light power (uW) [measured just before PD, does not consider reflection off the PD]
 P_PSL:       16.3    27.2
 P_ARM:       380     19.1

Measured beat note power at the RF analyzer in the control room
 P_CR:      -36    -40.5    [dBm] (at the time of measurement with oscilloscope)
Expected    -17    - 9    [dBm] (TO BE UPDATED)

Expected Power: (TO BE UPDATED)
Pin + External Amp Gain (25dB for X, Y from ZHL-3A-S)
    - Isolation trans (1dB)
    + GAV81 amp (10dB)
    - Coupler (10.5dB)


The expected numbers for the control room analyzer in red have to be updated. 

The main difference seems to be that the PSL power on the Y broadband PD has gone down by about 50% from what it used to be. In either measurement, it looks like the mode matching is only 25-30%, which is pretty abysmal. I will investigate the situation further - I have been wanting to fiddle around with the PSL green path in any case so as to facilitate having an IR beat even when the PSL green shutter is closed, I will try and optimize the mode matching as well... I should point out that at this point, the poor mode-matching on the PSL table isn't limiting the ALS noise performance as we are able to lock reliably...

  12611   Sat Nov 12 01:09:56 2016 gautamUpdateLSCRecovering DRMI locking

Now that we have all Satellite boxes working again, I've been working on trying to recover the DRMI 1f locking over the last couple of days, in preparation for getting back to DRFPMI locking. Given that the AS light levels have changed, I had to change the whitening gains on the AS55 and AS110 channels to take this into account. I found that I also had to tune a number of demod phases to get the lock going. I had some success with the locks tonight, but noticed that the lock would be lost when the MICH/SRCL boosts were triggered ON - when I turned off the triggering for these, the lock would hold for ~1min, but I couldn't get a loop shape measurement in tonight.


As an aside, we have noticed in the last couple of months glitchy behaviour in the ITMY UL shadow sensor PD output - qualitatively, these were similar to what was seen in the PRM sat. box, and since I was able to get that working again, I did a similar analysis on the ITMY sat. box today with the help of Ben's tester box. However, I found nothing obviously wrong, as I did for the PRM sat. box. Looking back at the trend, the glitchy behaviour seems to have stopped some days ago, the UL channel has been well behaved over the last week. Not sure what has changed, but we should keep an eye on this...

  12619   Wed Nov 16 03:10:01 2016 gautamUpdateLSCDRMI locked on 1f and 3f signals

After much trial and error with whitening gains, demod phases and overall loop gains, I was finally able to lock the DRMI on both 1f and 3f signals! I went through things in the following order tonight:

  1. Lock the arms, dither align
  2. Lock the PRMI on carrier and dither align the PRM to get good alignment
  3. Tried to lock the DRMI on 1f signals - this took a while. I realized the reason I had little to no success with this over the last few days was because I did not turn off the automatic unwhitening filter triggering on the demod screens. I had to tweak the SRM alignment while looking at the AS camera, and also adjust the demod phases for AS55 (MICH is on AS55Q) and REFL55 (SRCL is on REFL55I). Once I was able to get locks of a few seconds, I used the UGF servos to set the overall loop gain for MICH, PRCL and SRCL, after which I was able to revert the filter triggering to the usual settings
  4. Once I adjusted the overall gains and demod phases, the DRMI locks were very stable - I left a lock alone for ~20mins, and then took loop shape measurements for all 3 loops
  5. Then I decided to try transfering to 3f signals - I first averaged the IN1s to the 'B' channels for the 3 vertex DOFs using cds avg while locked on the 1f signals. I then set a ramp time of 5 seconds and turned the gain of the 'A' channels to 0 and 'B' channels to 1. The transition wasn't smooth in that the lock was broken but was reacquired in a couple of seconds.
  6. The lock on 3f signals was also pretty stable, the current one has been going for >10 minutes and even when it loses lock, it is able to reacquire in a few seconds

I have noted all the settings I used tonight, I will post them tomorrow. I was planning to try a DRFPMI lock if I was successful with the DRMI earlier tonight, but I'm calling it a night for now. But I think the DRMI locking is now back to a reliable level, and we can push ahead with the full IFO lock...

It remains to update the auto-configure scripts to restore the optimized settings from tonight, I am leaving this to tomorrow as well...


Updated 16 Nov 2016 1130am

Settings used were as follows:

1f/3f DOF Error signal Whitening gain (dB) Demod phase (deg) Loop gain Trigger
DRMI Locking 16 Nov 2016
1f MICH (A) AS55Q 0 -42 -0.026 POP22I=1
1f PRCL (A) REFL11I 18 18 -0.0029 POP22I=1
1f SRCL (A) REFL55I 18 -175 -0.035 POP22I=10
3f MICH (B) REFL165Q 24 -86 -0.026 POP22I=1
3f PRCL (B) REFL33I 30 136 -0.0029 POP22I=1
3f SRCL (B) REFL165I and REFL33I - - -0.035 POP22I=10

 

  12620   Wed Nov 16 08:14:43 2016 SteveUpdateLSCDRMI locked on 1f and 3f signals

Nice job.

Quote:

After much trial and error with whitening gains, demod phases and overall loop gains, I was finally able to lock the DRMI on both 1f and 3f signals! I went through things in the following order tonight:

  1. Lock the arms, dither align
  2. Lock the PRMI on carrier and dither align the PRM to get good alignment
  3. Tried to lock the DRMI on 1f signals - this took a while. I realized the reason I had little to no success with this over the last few days was because I did not turn off the automatic unwhitening filter triggering on the demod screens. I had to tweak the SRM alignment while looking at the AS camera, and also adjust the demod phases for AS55 (MICH is on AS55Q) and REFL55 (SRCL is on REFL55I). Once I was able to get locks of a few seconds, I used the UGF servos to set the overall loop gain for MICH, PRCL and SRCL, after which I was able to revert the filter triggering to the usual settings
  4. Once I adjusted the overall gains and demod phases, the DRMI locks were very stable - I left a lock alone for ~20mins, and then took loop shape measurements for all 3 loops
  5. Then I decided to try transfering to 3f signals - I first averaged the IN1s to the 'B' channels for the 3 vertex DOFs using cds avg while locked on the 1f signals. I then set a ramp time of 5 seconds and turned the gain of the 'A' channels to 0 and 'B' channels to 1. The transition wasn't smooth in that the lock was broken but was reacquired in a couple of seconds.
  6. The lock on 3f signals was also pretty stable, the current one has been going for >10 minutes and even when it loses lock, it is able to reacquire in a few seconds

I have noted all the settings I used tonight, I will post them tomorrow. I was planning to try a DRFPMI lock if I was successful with the DRMI earlier tonight, but I'm calling it a night for now. But I think the DRMI locking is now back to a reliable level, and we can push ahead with the full IFO lock...

It remains to update the auto-configure scripts to restore the optimized settings from tonight, I am leaving this to tomorrow as well...

 

 

Attachment 1: 5hrs.png
5hrs.png
  12630   Mon Nov 21 14:02:32 2016 gautamUpdateLSCDRMI locked on 3f signals, arms held on ALS

Over the weekend, I was successful in locking the DRMI with the arms held on ALS. The locks were fairly robust, lasting order of minutes, and was able to reacquire by itself when it lost the lock in <1min. I had to tweak the demod phases and loop gains further compared to the 1f lock with no arms, but eventually I was able to run a sensing matrix measurement as well. A summary of the steps I had to follow:

  • Lock on 1f signals, no arms, and run sensing lines, adjust REFL33 and REFL 165 demod phases to align PRCL, MICH and SRCL as best as possible to REFL33I, REFL165Q and REFL165I respectively
  • I also set the offsets to the 'B' inputs at this stage
  • Lock arms on ALS, engage DRMI locking on 3f signals (the restore script resets some values like the 'B' channel offsets, so I modified the restore script to set the offsets I most recently measured)
  • I was able to achieve short locks on the settings from the locking with no arms - I set the loop gains using the UGF servos and ran some sensing lines to get an idea of what the final demod phases should be
  • Adjusted the demod phases, locked the DRMI again (with CARM offset = -4.0), and took another sensing matrix measurement (~2mins). The data was analyzed using the set of scripts EricQ has made for this purpose, here is the result from a lock yesterday evening (the radial axis is meant to be demod board output volts per meter but the calibration I used may be wrong)

I've updated the appropriate fields in the restore script. Now that the DRMI locking is somewhat stable again, I think the next step towards the full lock would be to zero the CARM offset and turning on the AO path.

On the downside, I noticed yesterday that ITMY UL shadow sensor readback was glitching again - for the locking yesterday, I simply held the output of that channel to the input matrix, which worked fine. I had already done some debugging on the Sat. Box with the help of the tester box, but unlike the PRM sat. box, I did not find anything obviously wrong with the ITMY one... I also ran into a CDS issue when I tried to run the script that sets the phase tracker UGF - the script reported that the channels it was supposed to read (the I and Q outputs of the ALS signal, e.g. C1:ALS-BEATX_FINE_I_OUT) did not exist. The same channels worked on dataviever though, so I am not sure what the problem was. Some time later, the script worked fine too. Something to look out for in the future I guess..

Attachment 1: DRMIArms_Nov20.pdf
DRMIArms_Nov20.pdf
  12638   Wed Nov 23 16:21:02 2016 gautamUpdateLSCITMY UL glitches are back

 

Quote:

As an aside, we have noticed in the last couple of months glitchy behaviour in the ITMY UL shadow sensor PD output - qualitatively, these were similar to what was seen in the PRM sat. box, and since I was able to get that working again, I did a similar analysis on the ITMY sat. box today with the help of Ben's tester box. However, I found nothing obviously wrong, as I did for the PRM sat. box. Looking back at the trend, the glitchy behaviour seems to have stopped some days ago, the UL channel has been well behaved over the last week. Not sure what has changed, but we should keep an eye on this...

I've noticed that the glitchy behaviour in ITMY UL shadow sensor readback is back - as mentioned above, I looked at the Sat. Box and could not find anything wrong with it, perhaps I'll plug the tester box in over the Thanksgiving weekend and see if the glitches persist...

  12644   Tue Nov 29 11:07:37 2016 SteveUpdateLSCITMY UL glitches are back

400 days plot. Satelite amp ITMY has been swapped with ETMY

Unlabeled sat.amps are labeled. This plot only makes sense if you know the Cuh-Razy sat amp locations.

Attachment 1: gliching400d.png
gliching400d.png
  12648   Wed Nov 30 01:47:56 2016 gautamUpdateLSCSuspension woes

Short summary:

  • Looks like Satellite boxes are not to blame for glitchy behaviour of shadow sensor PD readouts
  • Problem may lie at the PD whitening boards (D000210) or with the Contec binary output cards in c1sus
  • Today evening, similar glitchy behaviour was observed in all MC1 PD readout channels, leading to frequent IMC unlocking. Cause unknown, although I did work at 1X5, 1X6 today, and pulled out the PD whitening board for ITMY which sits in the same eurocrate as that for MC1. MC2/MC3 do not show any glitches.

Detailed story below...


Part 1: Satellite box swap

Yesterday, I switched the ITMY and ETMY satellite boxes, to see if the problems we have been seeing with ITMY UL move with the box to ETMY. It did not, while ITMY UL remained glitchy (based on data from approximately 10pm PDT on 28Nov - 10am PDT 29 Nov). Along with the tabletop diagnosis I did with the tester box, I concluded that the satellite box is not to blame.


Part 2: Tracing the signal chain (actually this was part 3 chronologically but this is how it should have been done...)

So if the problem isn't with the OSEMs themselves or the satellite box, what is wrong? I attempted to trace the signal chain from the satellite box into our CDS system as best as I could. The suspension wiring diagram on our wiki page is (I think) a past incarnation. Of course putting together a new diagram was a monumental task I wasn't prepared to undertake tonight, but in the long run this may be helpful. I will put up a diagram of the part I did trace out tomorrow, but the relevant links for this discussion are as follows (? indicates I am unsure):

  1. Sat box (?)--> D010069 via 64pin IDE connector --> D000210 via DB15 --> D990147 via 4pin LEMO connectors --> D080281 via DB25 --> ADC0 of c1sus
  2. D000210 backplane --> cross-connect (mis)labelled "ITMX white" via IDE connector
  3. c1sus CONTEC DO-32L-PE --> D080478 via DB37 --> BO0-1 --> cross-connect labelled "XY220 1Y4-33-16A" via IDE --> (?)  cross-connect (mis)labelled "ITMX white" via IDE connector

I have linked to the DCC page for the various parts where available. Unfortunately I can't locate (on new DCC or old or elog or wiki) drawings for D010069 (Satellite Amplifier Adapter Board), D080281 ("anti-aliasing interface)" or D080478 (which is the binary output breakout box). I have emailed Ben Abbott who may have access to some other archive - the diagrams would be useful as it is looking likely that the problem may lie with the binary output.

So presumably the first piece of electronics after the Satellite box is the PD whitening board. After placing tags on the 3 LEMOs and 1 DB15 cable plugged into this board, I pulled out the ITMY board to do some tabletop diagnosis in the afternoon around 2pm 29Nov.


Part 3: PD whitening board debugging

This particular board has been reported as problematic in the recent past. I started by inserting a tester board into the slot occupied by this board - the LEDs on the tester board suggested that power-supply from the backplane connectors were alright, confirmed with a DMM.

Looking at the board itself, C4 and C6 are tantalum capacitors, and I have faced problems with this type of capacitor in the past. In fact, on the corresponding MC3 board (which is the only one visible, I didn't want to pull out boards unnecessarily) have been replaced with electrolytic capacitors, which are presumably more reliable. In any case, these capacitors do not seem to be at any fault, the board receives +/-15 V as advertised.

The whitening switching is handled by the MAX333 - this is what I looked at next. This IC is essentially a quad SPDT switch, and a binary input supplied via the backplane connector serves to route the PD input either through a whitening filter, or bypass it via a unity gain buffer. The logic levels that effect the switching are +15V and 0V (and not the conventional 5V and 0V), but according to the MAX333 datasheet, this is fine. I looked at the supply voltage to all ICs on the board, DC levels seemed fine (as measured with a DMM) and I also looked at it on an oscilloscope, no glitches were seen in ~30sec viewing stretch. I did notice something peculiar in that with no input supplied to the MAX333 IC (i.e. the logic level should be 15V), the NO and NC terminals appear shorted when checked with a DMM. Zach has noticed something similar in the past, but Koji pointed out that the DMM can be fooled into thinking there is a short. Anyway, the real test was to pull the logic input of the MAX333 to 0, and look at the output, this is what I did next.

The schematic says the whitening filter has poles at 30,100Hz and a zero at 3 Hz. So I supplied as "PD input" a 12Hz 1Vpp sinewave - there should be a gain of ~x4 when this signal passes through the path with the whitening filter. I then applied a low frequency (0.1Hz) square wave (0-5V) to the "bypass" input, and looked at the output, and indeed saw the signal amplitude change by ~4x when the input to the switch was pulled low. This behaviour was confirmed on all five channels, there was no problem. I took transfer functions for all 5 channels (both at the "monitor" point on the backplane connector and on the front panel LEMOs), and they came out as expected (plot to be uploaded soon).

Next, I took the board back to the eurocrate. I first put in a tester box into the slot and measured the voltage levels on the backplane pins that are meant to trigger bypassing of the whitening stage, all the pins were at 0V. I am not sure if this is what is expected, I will have to look inside D080478 as there is no drawing for it. Note that these levels are set using a Contec binary output card. Then I attached the PD whitening board to the tester board, and measured the voltages at the "Input" pins of all the 5 SPDT switches used under 2 conditions - with the appropriate bit sent out via the Contec card set to 0 or 1 (using the button on the suspension MEDM screens). I confirmed using the BIO medm screen that the bit is indeed changing on the software side, but until I look at D080478, I am not sure how to verify the right voltage is being sent out, except to check at the pins on the MAX333. For this test, the UL channel was indeed anomalous - while the other 4 channels yielded 0V (whitening ON, bit=1) and 15V (whitening OFF, bit=0), the corresponding values for the UL channel were 12V and 10V.

I didn't really get any further than this tonight. But this still leaves unanswered questions - if the measured values are faithful, then the UL channel always bypasses the whitening stage. Can this explain the glitchy behaviour?


Part 4: MC1 troublesfrown

At approximately 8pm, the IMC started losing lock far too often - see the attached StripTool trace. There was a good ~2hour stretch before that when I realigned the IMC, and it held lock, but something changed abruptly around 8pm. Looking at the IMC mirror OSEM PD signals, all 5 MC1 channels are glitching frequently. Indeed, almost every IMC lockloss in the attached StripTool is because of the MC1 PD readouts glitching, and subsequently, the damping loops applying a macroscopic drive to the optic which the FSS can't keep up with. Why has this surfaced now? The IMC satellite boxes were not touched anytime recently as far as I am aware. The MC1 PD whitening board sits in the same eurocrate I pulled the ITMY board out of, but squishing cables/pushing board in did not do anything to alleviate the situation. Moreover, MC2 and MC3 look fine, even though their PD whitening boards also sit in the same eurocrate. Because I was out of ideas, I (soft) restarted c1sus and all the models (the thinking being if something was wrong with the Contec boards, a restart may fix it), but there was no improvement. The last longish lock stretch was with the MC1 watchdog turned off, but as soon as I turned it back on the IMC lost lock shortly after.

I am leaving the autolocker off for the night, hopefully there is an easy fix for all of this...

Attachment 1: IMCwoes.png
IMCwoes.png
  12652   Wed Nov 30 17:08:56 2016 gautamUpdateLSCBinary output breakout box removed

[ericq, gautam]

To diagnose the glitches in OSEM readouts, we have removed one of the PCIE BO D37 to IDE50 adaptor boxes from 1X5. All the watchdogs were turned off, and the power to the unit was cut before the cables on the front panel were removed. I am working on the diagnosis, I will update more later in the evening. Note that according to the c1sus model, the box we removed supplies backplane logic inputs that control whitening for ITMX, ITMY, BS and PRM (in case anyone is wondering/needs to restore damping to any of these optics). The whitening settings for the IMC mirrors resides on the other unit in 1X5, and should not be affected.

  12653   Thu Dec 1 02:19:13 2016 gautamUpdateLSCBinary output breakout box restored

As we suspected, the binary breakout board (D080478, no drawing available) is simply a bunch of tracks printed on the PCB to route the DB37 connector pins to two IDE50 connectors. There was no visible damage to any of the tracks (some photos uploaded to the 40m picasa). Further, I checked the continuity between pins that should be connected using a DMM.

I got a slightly better understanding of how the binary output signal chain is - the relevant pages are 44 and 48 in the CONTEC manual. The diagram on pg44 maps the pins on the DB37 connector, while the diagram on pg 48 maps how the switching actually occurs. The "load" in our case is the 4.99kohm resistor on the PD whitening board D000210. Following the logic in the diagram on pg48 is easy - setting a "high" bit in the software should pull the load resistor to 0V while setting a "low" bit keeps the load at 15V (so effectively the whole setup of CONTEC card + breakout board + pull-up resistor can be viewed as a simple NOT gate, with the software bit as the input, and the output connected to the "IN" pin of the MAX333).

Since I was satisfied with the physical condition of the BO breakout board, I re-installed the box on 1X5. Then, with the help of a breakout board, I diagnosed the situation further - I monitored the voltage to the pins on the backplane connector to the whitening boards while switching the MEDM switches to toggle the whitening state. For all channels except ITMY UL, the behaviour was as expected, in line with the preceeding paragraph - the voltage swings between ~0V and ~15V. As mentioned in my post yesterday, the ITMY UL channel remains dodgy, with voltages of 12.84V (bit=1) and 10.79V (bit=0). So unless I am missing something, this must point to a faulty CONTEC card? We do have spares, do we want to replace this? It also looks like this problem has been present since at least 2011...

In any case, why should this lead to ITMY UL glitching? According to the MAX333 datasheet, the switch wants "low"<0.8V and "high">2.4V - so even if the CONTEC card is malfunctioning and the output is toggling between these two states, the condition should be that the whitening stage is always bypassed for this channel. The bypassed route works just fine, I measured the transfer function and it is unity as expected.

So what could possibly be leading to the glitches? I doubt that replacing the BO card will solve this problem. One possibility that came up in today's meeting is that perhaps the +24V to the Sat. Box. (which is used to derive the OSEM LED drive current) may be glitching - of course we have no monitor for this, but given that all the Sat. Amp. Adaptor boards are on 1X5 near the Acromag, perhaps Lydia and Johannes can recommission the PSL diagnostic Aromag to a power supply monitoring Acromag?


What do these glitches look like anyway? Here is a few second snapshot from one of the many MC1 excursions from yesterday - the original glitch itself is very fast, and then that gives an impulse to the damping loop which eventually damps away.

And here is one from when there was a glitch when the tester box was plugged in to the ITMY signal chain (so we can rule out anything in the vacuum, and also the satellite box itself as the glitches seem to remain even when boxes are shuffled around, and don't migrate with the box). So even though the real glitch happens in the UL channel (note the y axes are very different for the channels), the UR, LR and LL channels also "feel" it. recall that this is with the tester box (so no damping loops involved), and the fact that the side channel is more immune to it than the others is hard to explain. Could this just be electrical cross-coupling?

Still beats me what in the signal chain could cause this problem.


Some good news - Koji was running some tests on the modified WFS demod board and locked the IMC for this. We noticed that MC1 seemed well behaved for extended periods of time unlike last night. I realigned the PMC and IMC, and we have been having lock streches of a few hours as we usually have. I looked at the MC1 OSEM PD readbacks during the couple of lock losses in the last few hours, and didn't notice anything dramatic laugh. So if things remain in this state, at least we can do other stuff with the IFO... I have plugged in the ITMY sat. box again, but have left the watchdog disabled, lets see what the glitching situation is overnight... The original ITMY sat. box has been plugged into the ETMY DAQ signal chain with a tester box. The 3 day trend supports the hypothesis the sat. box is not to blame. So I am plugging the ETMY suspension back in as well...

Attachment 4: ULcomparison.pdf
ULcomparison.pdf
  12654   Thu Dec 1 08:02:57 2016 SteveUpdateLSCglitching ITMY_UL_LL

 

 

Attachment 1: ITMY_UL_LL.png
ITMY_UL_LL.png
  12657   Fri Dec 2 11:56:42 2016 gautamUpdateLSCMC1 LEMO jiggled

I noticed 2 periods of frequent IMC locklosses on the StripTool trace, and so checked the MC1 PD readout channels to see if there were any coincident glitches. Turns out there wasnt yes BUT - the LR and UR signals had changed significantly over the last couple of days, which is when I've been working at 1X5. The fast LR readback was actually showing ~0, but the slow monitor channel had been steady so I suspected some cabling shenanigans.

Turns out, the problem was that the LEMO connector on the front of the MC1 whitening board had gotten jiggled ever so slightly - I re-jiggled it till the LR fast channel registered similar number of counts to the other channels. All looks good for now. For good measure, I checked the 3 day trend for the fast PD readback for all 8 SOS optics (40 channels in all, I didn't look at the ETMs as their whitening boards are at the ends), and everything looks okay... This while situation seems very precarious to me, perhaps we should have a more robust signal routing from the OSEMs to the DAQ that is more immune to cable touching etc...

  12664   Mon Dec 5 15:05:37 2016 gautamUpdateLSCMC1 glitches are back

For no apparent reason, the MC1 glitches are back. Nothing has been touched near the PD whitening chassis today, and the trend suggests the glitching started about 3 hours ago.. I had disabled the MC1 watchdog for a while to avoid the damping loop kicking the suspension around when these glitches occur, but have re-enabled it now. IMC is holding lock for some minutes... I was hoping to do another round of ringdowns tonight, but if this persists, its going to be difficult...

  12674   Thu Dec 8 10:13:43 2016 SteveUpdateLSCglitching ITMY_UL has a history

 

 

Attachment 1: glitching__ITMY-UL_2007.png
glitching__ITMY-UL_2007.png
  12860   Wed Mar 1 17:25:28 2017 SteveUpdateLSCMCREFL condition pictures

Gautam and Steve,

 

Our MCREFL rfpd C30642GH 2x2mm beeing investigated for burned spots.

Atm1,           unused -  brand new pd

Atm2,3,4       MCREFL in place was not moved

More pictures will be posted on 40m Picassa site later. 

 

Attachment 1: IMG_3646.JPG
IMG_3646.JPG
Attachment 2: mcRefl_1.jpg
mcRefl_1.jpg
Attachment 3: mcRefl_3.jpg
mcRefl_3.jpg
Attachment 4: mcRefl_5.jpg
mcRefl_5.jpg
  12891   Fri Mar 17 14:49:09 2017 gautamUpdateLSCMCREFL condition pictures

I did a quick measurement of the beam size on the MC REFL PD today morning. I disabled the MC autolocker while this measurement was in progress. The measurement set up was as follows:

This way I was able to get right up to the heat sink - so this is approximately 2cm away from the active area of the PD. I could also measure the beam size in both the horizontal and vertical directions.

The measured and fitted data are:

  

The beam size is ~0.4mm in diameter, while the active area of the photodiode is 2mm in diameter according to the datasheet. So the beam is ~5x smaller than the active area of the PD. I couldn't find anything in the datasheet about what the damage threshold is in terms of incident optical power, but there is ~100mW on th MC REFL PD when the MC is unlocked, which corresponds to a peak intensity of ~1.7 W / mm^2...

Even though no optics were intentionally touched for this measurement, I quickly verified that the spot is centered on the MC REFL PD by looking at the DC output of the PD, and then re-enabled the autolocker.

Attachment 2: MCREFL_X.pdf
MCREFL_X.pdf
Attachment 3: MCREFL_Y.pdf
MCREFL_Y.pdf
  12952   Thu Apr 27 16:41:13 2017 Eric GustafsonUpdateLSC Status of the 40 m PD Frequency Response Fiber System
There two reports in the DCC describing the state of the system as of October 2014 including: (1)  Alex Cole’s “T1300618 Automated photodiode Frequency Response Measurement System” and a Wiki  created by Alex Cole where there are some instructions on the Master Script at https://wiki.ligo.caltech.edu/ajw?AlexanderCole    

And (2)  P140021 “Final Report: Automated Photodiode Frequency Response Measurement System for 40m Lab” by Nichin Sreekantaswamy and also as part of Nichin’s report by there is an archive of data at   https://wiki-40m.ligo.caltech.edu/Electronics/PDFR%20system   

I made a visual inspection of the system and saw that the following fibers collimators are still mounted in alignment mounts and the fiber is attached and pointed at a photodetector but possibly not aligned. 

ASP Table

Photodetector Label                             Fiber Label

REFL11                                              REFL55 Fiber on mount        

REFL33                                              REFL33 Fiber on mount

REFL55                                              REFL11 Fiber on mount

REFL165                                            No Fiber

AS55                                                   AS55 Fiber on mount

MCREFPD                                         MCREFPD Fiber on mount

No PD                                                 Loose unlabeled Fiber No mount

 

ITMX Optics Table

Photodetector Label                             Fiber Label

POX11                                                POX11 on mount

Unlabeled PD                                      POP22/POP110 on mount

NO PD                                                 POP55 loose fiber No mount

 

The RF switch seems to be hooked up and there is a fiber running from the Diode Laser module to the fiber splitter module. So REFL 11 and REFL545 seem to be illuminated by the wrong fiber. I’ll try and run the software on Monday and check to see if I need to move the fibers or just relabel them.

  13022   Wed May 31 12:58:30 2017 Eric GustafsonUpdateLSCRunning the 40 m PD Frequency Response Fiber System; Hardware and Software

Overall Design

A schematic of the overall subsystem diagran in attachment.

RF and Optical Connections

Starting at the top left corner is the diode laser module.  This laser has an input which allows it to be amplitude modulated.  The output of the laser is coupled into an optical fiber which is connectorized with an FC/APC connector and is connected to the input port of a 1 by 16 Optical Fiber Splitter. The Splitter produces 16 optical fiber outputs dividing the input laser power into 16 roughly equal optical optical fiber outputs.  These optical fibers are routed to the Photodiode Receivers (PD) which are the devices under test. All of the PDs are illuminated simultaneously with amplitude modulated light. The Optical Fiber outputs each have a collimating fiber telescope which is used to focus the light onto the PDs. Optical Fiber CH1 is routed to a broadband flat response reference photodiode which is used to provide a reference to the HP-4395A Network Analyzer.  The other Channel outputs are connected to an RF switch which can be programmed to select one of 16 inputs as the output.  The selected outputs can then be sent into channel A of the RF Network Analyzer. 

 

RF Switch

The RF switch consists of two 8 by 1 Multiplexers (National Instruments PXI-254x) slotted into a PXI Chassis (National Instruments PXI-1033).  The Multiplexers have 8 RF inputs and one RF output and can be programmed through the PXI Chassis to select one and only one of the 8 inputs to be routed to the RF output.) The first 8 Channels are connected to the first 8 inputs of the first Multiplexer.  The first Multiplexer’s output is then connected to the Channel 1 input of the second Multiplexer. The remaining PD outputs are connected to the remaining inputs of the second Multiplexer. The output of the second Multiplexer is connected to the A channel of the RF Network Analyzer.  Thus it is possible to select any one of the PD RF outputs for analysis.

Software

Something on this tomorrow.

 

Attachment 1: Overall_schematic_D1300603-v2.pdf
Overall_schematic_D1300603-v2.pdf
  13248   Thu Aug 24 00:39:47 2017 gautamUpdateLSCDRMI locking attempt

Since the single arm locking and dither alignment seemed to work alright after the CDS overhaul, I decided to try some recycling cavity locking tonight.

  • First, I locked single arms, ran dither alignment servos, and centered all test mass Oplevs. Note: the X arm dither alignment doesn't seem to work if we use the High-Gain Thorlabs PD as the Transmission PD. The BS loops just seem to pick up large offsets and the alignment actually degrades over a couple of minutes. This needs to be investigated.
  • Next, to get good PRM alignment, I manually moved the EPICS sliders till the REFL spot became roughly centered on the CCD screen.
  • Then I tried locking PRMI on carrier using the usual C1IFOConfigure script - the lock was caught within ~30 seconds.
  • The PRCL and MICH dither servo scripts also ran fine.
    • Centered PRM Oplev.
  • Next, I tried enabling the PRC angular feedforward.
    • OAF model does not automatically revert to its safe.snap configuration on model reboot, so I first manually did this such that the correct filter banks were enabled.
    • I was able to turn on the angular feedforward without disturbing the PRMI carrier lock. The angular motion of the POP spot on the CCD monitor was visibly reduced.
  • At this point I decided to try DRMI locking.
    • I centered the beam on the AS PDs with the simple Michelson.
    • Centered the beam on the REFL PDs with PRM aligned and PRC flashing through resonances.
    • Restored SRM alignment by eye with EPICS sliders.
    • Cavity alignment seemed alright - so I tried to lock DRMI with the old settings (i.e. from DRMI 1f locking a couple of months ago). But I had no success.
    • The behaviour of REFL55 (used for SRCL control) has changed dramatically - the analog whitening gain for this PD used to be +18dB, but at this setting, there are frequent ADC overflows. I had to reduce the whitening gain to +6dB to stop the ADC overflows. I also checked to make sure that the whitening setting was "manual" and not triggered.

Why should this have changed? I was just on the AS table and did re-center the beam onto the REFL 55 RFPD, but I had also done this in April/May when I was last doing DRMI locking. But I can't explain the apparent factor of ~4 increase in light level. I think I have some measurements of the light levels at various PDs from April 2017, I will see how the present levels line up.

Of course dataviever won't cooperate when I am trying to monitor testpoints.

I may be missing something obvious, but I am quitting for tonight, will look into this more tomorrow.


Unrelated to this work: looking at the GTRY spot on the CCD monitor, there seems to be some excess angular motion. Not sure where this is coming from. In the past, this sort of problem has been symptomatic of something going wonky with the Oplev loops. But I took loop measurements for ITMY and ETMY PIT and YAW, they look normal. I will investigate further when I am doing some more ALS work.

  13250   Thu Aug 24 18:02:16 2017 GabrieleSummaryLSCFirst cavity length reconstruction with a neural network

1) Introduction

In brief, I trained a deep neural network (DNN) to recosntuct the cavity length, using as input only the transmitted power and the reflection PDH signals. The training was performed with simulated data, computed along 0.25s long trajectories sampled at 8kHz, with random ending point in the [-lambda/4, lambda/4] unique region and with random velocity.

The goal of thsi work is to validate the whole approach of length reconstruction witn DNN in the Fabry-Perot case, by comparing the DNN reconstruction with the ALS caivity lenght measurement. The final target is to deploy a system to lock PRMI and DRMI. Actually, the Fabry-Perot cavity problem is harder for a DNN: the cavity linewidth is quite narrow, forcing me to use very high sampling frequency (8kHz) to be able to capture a few samples at each resonance crossing. I'm using a recurrent neural network (RNN), in the input layers of the DNN, and this is traine using truncated backpropagation in time (TBPT): during training each layer of RNN is unrolled into as many copies as there are input time samples (8192 * 0.25 = 2048). So in practice I'm training a DNN with >2000 layers! The limit here is computational, mostly the GPU memory. That's why I'm not able to use longer data stretches.

But in brief, the DNN reconstruction is performing well for the first attempt.

2) Training simulation

In the results shown below, I'm using a pre-trained network with parameters that do not match very well the actual data, in particular for the distribution of mirror velocity and the sensing noises. I'm working on improving the training.

I used the following parameters for the Fabry-Perot cavity:

The uncertaint is assumed to be the 90% confidence level of a gaussian distribution. The DNN is trained on 100000 examples, each one a 0.25/8kHz long trajectory with random velocity between 0.1 and 5 um/s, and ending point distributed as follow: 33% uniform on the [-lambda/4, lambda/4] region, plus 33% gaussian distribution peaked at the center with 5 nm width. In addition there are 33% more static examples, distributed near the center. 

For each point along the trajectory, the signals TRA, POX11_I and POX11_Q are computed and used as input to the DNN.

3) Experimental data

Gautam collected about 10 minutes of data with the free swinging cavity, with ALS locked on the arm. Some more data were collected with the cavity driven, to increase the motion. I used the driven dataset in the analysis below.

3.1) ALS calibration

The ALS signal is calibrated in green Hz. After converting it to meters, I checked the calibration by measuring the distance between carrier peaks. It turned out that the ALS signal is undercalibrated by about 26%. After correcting for this, I found that there is a small non-linearity in the ALS response over multiple FSR. So I binned the ALS signal over the entire range and averaged the TRA power in each bin, to get the transmission signals as a function of ALS (in nm) below:

I used a peak detection algorithm to extract the carrier and 11 MHz sideband peaks, and compared them with the nominal positions. The difference between the expected and measured peak positions as a function of the ALS signal is shown below, with a quadratic fit that I used to improve the ALS calibration

The result is

z_initial = 1e9 * L*lamba/c *1.26. * ALS
z_corrected = 2.1e-06 z^2  -1.9e-02 z  -6.91e+02

The ALS calibrated z error from the peak position is of the order of 3 nm (one sigma)

3.2) Mirror velocity

Using the calibrated ALS signal, I computed the cavity length velocity. The histogram below shows that this is well described by a gaussian with width of about 3 um/s. In my DNN training I used a different velocity distribution, but this shouldn't have a big impact. I'm retraining with a different distirbution.

4) DNN results

The plot below shows a stretch of time domain DNN reconstruction, compared with the ALS calibrated signal. The DNN output is limited in the [-lambda/4, lambda/4] region, so the ALS signal is also wrapped in the same region. In general the DNN reconstruction follows reasonably well the real motion, mostly failing when the velocity is small and the cavity is simultanously out of resonance. This is a limitation that i see also in simulation, and it is due to the short training time of 0.25s.

I did not hand-pick a good period, this is representative of the average performance. To get a better understanding of the performance, here's a histogram of the error for 100 seconds of data:

The central peak was fitted with a gaussian, just to give a rough idea of its width, although the tails are much wider. A more interesting plot is the hisrogram below of the reconstructed position as a function of the ALS position, Ideally one would expect a perfect diagonal. The result isn't too far from the expectation:

The largest off diagonal peak is at (-27, 125) and marked with the red cross. Its origin is more clear in the plot below, which shows the mean, RMS and maximum error as a function of the cavity length. The second peak corresponds to where the 55 MHz sideband resonate. In my training model, there were no 55 MHz sidebands nor higher order modes. 

5) Conclusions and next steps

The DNN reconstruction performance is already quite good, considering that the DNN couldn't be trained optimally because of computation power limitations. This is a validation of the whole idea of training the DNN offline on a simulation and then deploy the system online.

I'm working to improve the results by

  • training on a more realistic distribution of velocity
  • adding the 55 MHz sidebands
  • maybe adding HOMs
  • tune the DNN architecture

However I won't spend too much time on this, since I think the idea has been already validated.

 

  13251   Thu Aug 24 18:51:57 2017 KojiSummaryLSCFirst cavity length reconstruction with a neural network

Phenomenal!

  13252   Fri Aug 25 01:20:52 2017 gautamUpdateLSCDRMI locking attempt

I tried some DRMI locking again tonight, but had no success. Here is the story.

  • I started out by going to the AS table and measuring the light level on the REFL55 photodiode (with PRM aligned and the PRC flashing, but LSC disabled).
    • The Ophir power meter reads 13mW
    • The DC output of the photodiode shows ~500mV on an oscilloscope.
    • Both of these numbers line up well with measurements I made in April/May.
  • Returned to the control room and aligned the IFO for DRMI locking - but LSC servos remained disabled.
    • At the nominal REFL55 whitening level of +18dB, the REFL 55 signals saturated the ADC (confirmed by looking at the traces on dataviewer).
    • But the signals still looked like PDH error signals.
    • Lowering the whitening gain to 6dB makes the PDH error signal horns peak around 20,000 counts.
    • Could this be indicative of problems with either the analog whitening gain switching or the LSC Demod Boards? To be investigated.
  • Tried enabling LSC servos with same settings with which I had success right up till a couple of months ago, but had no success.
    • If it is true that the REFL55 signal is getting amplified because of some gain stage not being switched correctly, I should still have been able to lock the SRC with a lowered loop gain - but even lowering the gain by a factor of 10 had no effect on the locking success rate.

Looks like I will have to embark on the REFL55 LSC electronics investigation. I was able to successfully lock the PRC on carrier and sideband, and the Michelson lock also seems to work fine, all of which seem to point to a hardware problem with the REFL55 signal chain.

I did a quick check by switching the output of the REFL55 demod board to the inputs normally used by AS55 signals on the whitening board. Setting the whitening gain to +18dB for these channels had the same effect - ADC overflow galore. So looks like the whitening board isn't to blame. I will have to check the demod board out.

 

ELOG V3.1.3-