40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 106 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  11753   Wed Nov 11 22:11:15 2015 KojiUpdateSUSPSL/IOO maintenance, TM SUS check up


- Before any of the following work, I went to the PSL table and aligned the PMC. In fact, it has not been misaligned.


- It was claimed in the meeting today that the IMC had not been happy thesedays. I checked out what's happening.

- I found the IMC was still well aligned. Autolocker frequently stuck on a weak higher-order mode and couldn't recover TEM00 locking without help.

- I modified /opt/rtcds/caltech/c1/scripts/MC/mcdown for easier relocking on TEM00.

The MC_REFL_GAIN and MC_VCO_GAIN for relocking was set to be 27 and -3, in stead of 0 and 10, respectively.
This means that REFL_GAIN is not changed before and after the locking. Only VCO_GAIN is lowered for lock acquisition.
The corresponding lines in mcdown are excerpted here.

#set servo and boost gains for re-acquisition
#${ewrite} C1:IOO-MC_REFL_GAIN 0 &
${ewrite} C1:IOO-MC_REFL_GAIN 27 &
#${ewrite} C1:IOO-MC_VCO_GAIN 10 &
${ewrite} C1:IOO-MC_VCO_GAIN -3 &

We still have some chance of locking on higher-order modes. If I jiggle the VCO gain slider from -31 to 0, eventually I find TEM00.
I don't know how to do it in the script yet. For now, I increased tickle amplitude from 300 to 500.




- IMC was locked and aligned with the WFS. The WFS feedback offsets were offloaded to the alignment slider (via the MEDM button as usual).


- I wanted to use ASS. => The OL damping and ASC inputs are enabled for ETMX. The filter bank output of the ASS servos are all turned on.
- The arms were locked and aligned with ASS. The ASS servo offsets were offloaded to the ASC offset sliders (as usual).

- I found the X arm spot positionis moving slowly in pitch. I wanted to know what is causing this.

- Turned off all the OPLEV dampings for the four test masses.
- Took the power spectra of the OSEM output (e.g. C1:SUS-ITMX_LLSEN_OUT)

See attachment 1 (The DTT XML file can be found as /users/koji/151111/TM_SUS.xml )

- It seems that something is wrong with ITMX UL OSEM
  The signal level seems to be identical with the others. However, the noise level is huge. We need to check if the cable connection is OK.

- ITMY LL shows remarkably higher bounce mode although I can't tell if this is normal or not.

- The OPLEV dampings have been restored.

Attachment 1: TM_SUS.pdf
Attachment 2: TM_SUS_SD.pdf
  11752   Wed Nov 11 14:06:09 2015 ranaUpdateSUSETMX oplev servo disabled

How many volts does it take to pitch the ETM by 5 urad?

  11751   Wed Nov 11 11:41:42 2015 gautamUpdateGeneralLong cable laid out for 1pps signal

In order to synchronise the FS725 Rb clock with our GPS timing signals, I laid out a longish cable running from 1X7 to the IOO rack via the overhead cable guide. There was a T-connector attached to the 1pps output of the GPS timing unit, with one of the outputs unused - I have connected one end of the cable I laid out to this output, with the other end going to the 1pps input of the FS725. I am now waiting for the FS725 to sync to the external reference, before running the calibration of the phase tracker once again using the same method detailed here, using the 10MHz output from the FS725 to serve as a reference for the Fluke RF signal generator...

  11750   Tue Nov 10 19:25:42 2015 gautamUpdateGeneralFS725 Rubidium reference

In the last few days, with Koji's help, I have recovered both the FS725 Rubidium references from W. Bridge, one from the ATF lab, and one from the CTN lab. Both are back at the 40m at the moment.

However, the one that was recovered from the ATF lab is no longer locking to the Rubidium reference frequency, although it was locked at the time we disconnected it from the ATF lab. I emailed the support staff at SRS, who seem to think that either the internal oscillator has drifted too far, or the Rb lamp is dead. Either ways, it needs to be repaired. They suggested that I run a check by issuing some serial commands to the unit to determine which of these is actually the problem, but I've been having some trouble setting up the serial link - I will try this again tomorrow. I'm also having trouble generating an RMA number that is needed to start the repair/maintenance process, but I've emailed SRS support again and hope to hear back from them soon. 

The other FS725, recovered from the CTN lab earlier today, seems to work fine and is locked to the Rb reference at the moment. I plan to redo the calibration of the phase tracker with an 'absolute' frequency reference with the help of the FS725 and out GPS timing unit tomorrow. Once that is done, the working unit can be returned to the CTN lab. 

  11749   Tue Nov 10 16:34:00 2015 yutaroUpdateLSCUpdated interpretation of peaks

What is the uncertainty of your RoC estimation?

The uncertainty came from the residual of linear fitting and based on my estimation,

ROC_ETMY = 59.3 +/- 0.1 m.


And I attach the updated figure of the fitting (with residual zoomed up).

Data points in the lower are (intentionally) slightly shifted horizontally to make it easy for us to see them.

It is hard, I think, to estimate the error of each data point, but I used 17 kHz for the errors of all data points; 17 kHz is the error of FSR estimation of this measurement, and since FSR is the distance between two carrier peaks we can consider that HOM distances, which are the distance between carrier peaks and HOM peaks, have similar order errors comared with that of FSR. 

Attachment 1: homfit2.png
  11748   Tue Nov 10 11:41:56 2015 KojiUpdateLSCUpdated interpretation of peaks

FYI: I've also reported the similar mod depths of

11M: 0.194
55M: 0.234

in ELOG11036 with a different kind of measurement method.

  11747   Tue Nov 10 11:40:03 2015 KojiUpdateLSCUpdated interpretation of peaks

What is the uncertainty of your RoC estimation?

One measurement of the ETMY ROC was 57.6m, but we trust another measured value of 60.26m than the other.
The value is always dependent on the spotposition on the mirror and how the ROC is calculated from the mirror phase map (e.g. spotsize, averaging method).
So I don't think this is a huge deviation from the spec.

  11746   Tue Nov 10 11:06:02 2015 yutaroUpdateLSCUpdated interpretation of peaks

- modulation depth = 0.390 +/- 0.062

There are two modulation frequencies that make it to the arm cavities, at ~11MHz and ~55MHz. Each of these will have their own modulation depth indepedent of each other. Bundling them together into one number doesn't tell us what's really going on. 


I'm sorry. I misunderstood two things when writing elog 11741: the number of modulation frequencies, and how to distinguish modulation peaks and HOM peaks.


Now, I report about interpretation of the peaks marked in grey in Attachment #1 in elog 11745.


The peaks marked in grey are interpreted as 3rd and 4th HOM resonance, if we assume that the radius of curvature of ETMY is slightly different from measured value. (measured: 57.6 m --> assumed: 59.3 m)


What I have done:

I plotted the differences in frequency between HOM peaks and 00 mode peaks (see Attachment #1) vs. expected orders of modes. The plot is shown in Attachement #2.

By fitting these data points, I calculated most likely value of gradient of this plot. This value corresponds: g_ITMYg_ETMY=0.3781. However, measured data of the radii of curvature suggests that g_ITMYg_ETMY=0.358. Assuming that this disagreement comes from the difference between measured and real values of ROC of ETMY (ITM is almost flat so that change of ROC of ITM doesn't have significant effect on g_ITMg_ETM), ROC of ETMY should be 59.3 m, different from measured value 57.6 m.


What I'd like to know:

-- Is such disagreement of ROC usual? Could it happen?

-- Are there any other possible explanations for this disagreement (or interpretations of the peaks marked in grey)?

Attachment 1: HOMlocation.png
Attachment 2: homfit.png
  11745   Tue Nov 10 02:34:28 2015 gautamUpdateLSCUpdated interpretation of peaks

After thinking about the interpretation of the various peaks seen in the scan through 2 FSRs, I have revised the information presented in the previous elog. Yutaro pointed out that the modulation frequency isn't exactly 11MHz, but according to this elog, is 11.066209 MHz. So instead of using mod(11e6,FSR), I really should have been using mod(11.066209,FSR) and mod(5*11.066209,FSR) to locate the positions of the 11MHz and 55MHz sidebands relative to the carrier resonances. With this correction, the 'unknown' peaks identified in Attachment #1 in elog 11743 are in fact the 55MHz sideband resonances. 

However, this means that the peaks which were previously identified as 55MHz sideband resonances have to be interpreted now - I'm having trouble identifying these. If we assume that the types of peaks present in the scan are 11 MHz sideband, 55MHz sideband, and the TEM00, TEM10, TEM20, TEM30, and TEM40 mode resonances, then the peaks marked in grey in Attachment #1 to this elog can be interpreted as TEM30 (right of a carrier resonance) and TEM40 (left of a carrier resonance) mode resonances - however, the fitted center frequencies differ from the expected center frequencies (determined using the same method as elog 469) by ~3% (for TEM30) and ~20% (for TEM40) - therefore I am skeptical about these peaks, particularly the 4th HOM resonances. In any case, they are the smallest of all the peaks, and any correction due to them will be small. 

The updated modulation depths are as follows (computed using the same method as described in elog 11743, the updated plot showing the ratio of bessel functions as a function of the modulation depth is Attachment #2 in this elog):

@11.066209 MHz ---- 0.179

@5*11.066209 MHz --- 0.226

These numbers are now reasonably consistent with those reported in elog10211.

As for the mode-matching efficiency, the overall number is almost unchanged if I assume the TEM30 peaks are accurately interpreted: 92.11%. But the dominant HOM contribution comes from the first HOM resonance: (TEM00 = 1, TEM20 = 0.0325, TEM10 = 0.0475, TEM30 =  0.0056). These numbers may change slightly if the 4th HOM resonances are also correctly identified.

ETMx is still not well behaved and the mode cleaner isnt too happy either, so I think we will save the measurement of the round trip arm loss for daytime tomorrow.  

Attachment 1: Y_scan.pdf
Attachment 2: modDepth.pdf
  11744   Mon Nov 9 23:22:18 2015 ericqUpdateSUSETMX oplev servo disabled

During a ETMX kick that just occured, with only local damping on, the slow VMon channels didn't show any noticable change. 

  11743   Mon Nov 9 16:58:59 2015 gautamUpdateLSCFSR and linewidth measurements with phase tracker

There are two modulation frequencies that make it to the arm cavities, at ~11MHz and ~55MHz. Each of these will have their own modulation depth indepedent of each other. Bundling them together into one number doesn't tell us what's really going on. 


As an update to Yutaro's earlier post - I've done an independent study of this data, doing the fitting with MATLAB, and trying to estimate (i) the FSR, (ii) the mode matching efficienct, and (iii) the modulation depths at 11MHz and 55MHz.

The values I've obtained are as follows:

FSR = 3.9704 MHz +/- 17 kHz 

Mode matching efficiency = 92.59 % (TEM00 = 1, TEM10 = 0.0325, TEM20 = 0.0475)

Modulation depth at 11MHz = 0.179

Modulation depth at 55MHz = 0.131


  • To approximately locate the TEM10 and TEM20 resonances, I followed the methodology listed here (though confining myself to (m+n) = 1,2). 
  • To approximately locate the 11 MHz and 55 MHz sidebands, I used the mod command in MATLAB to locate approximately how far they should be from a carrier resonance. 
  • The results of these first two steps are demonstrated pictorially in Attachment #1. Red = carrier resonance, grey = 55MHz sideband resonance, cyan = 11MHz sideband resonance, green = TEM20 resonance, and yellow = TEM10 resonance
  • The FSR was calculated by fitting the center frequencies of fits to the three carrier resonances with a lorentzian shape, vs their index. The quoted error is the 95% C.I.s generated by MATLAB
  • The mode-matching efficiency was calculated by taking the fitted height of Lorentzian shapes to the TEM00, TEM10 and TEM20 shapes. The ratio of the peak heights was taken as a measure of the fraction of total power coupled into the TEM10 and TEM20 modes relative to TEM00. In calculating the final value, I took the average of the 3 available values for each peak to calculate the ratios.
  • The modulation depth was calculated by approximating that the ratio   \sqrt\frac{P_c}{P_s} = \frac{J_0(\beta)}{J_1(\beta)}, and solving for \beta. Attachment #2 shows a plot of the RHS of this equation as a function of \beta - the two datatips mark the location of the ratios on the LHS of the equation - both P_c and P_s were averaged over the 3 and 6 values available, respectively. The values I have obtained are different from those cited here - not sure why? The real red flag I guess is that I get the modulation depth at 11MHz to be larger than at 55MHz, whereas elog10211 reports the reverse... Do we expect a resonance for a 44MHz sideband as well? If so, it could be that the two peaks close to the carrier resonance is in fact the 55.30 MHz sideband resonance, and the peaks I've identified as 55MHz sideband resonances are in fact 44MHz sidebands.. If this were true, I would recover the modulation depth for 55.30 MHz sidebands to be approximately 0.22...

Misc Remarks and Conclusions:

  • The y-scale in Attachment #1 is log(transmission) - the semilogy command in MATLAB messed up the rendering of the overlaid semi-transparent rectangles, hence the need for adopting this scale...
  • I've attached the code used to split the entire scan into smaller datasets centered around each peak, and the actual fitting routine, in Attachment #3. I've not done the error analysis for the mode matching efficiency and the modulation depths, I will update this entry with those numbers as soon as I do. 
  • In my earlier elog11738, I had mislabelled some peaks as being sideband peaks - attachment #1 in this entry is (I think) a correct interpretation of the various peaks. 
  • There are two peaks on either side of every carrier resonance, spaced, on average, about 177kHz away from the resonance on either side. I am not sure what the interpretation of this peak should be - are they the 55.30 MHz resonances? 
  • These values should allow us to carry out alternative measurements of the round trip arm loss as estimating this from the cavity finesse seems to not be the best way to go about this. 



Attachment 1: Y_scan.pdf
Attachment 2: modDepth.pdf
Attachment 3: Matlab_code.zip
  11742   Mon Nov 9 15:59:06 2015 ericqUpdateLSCFSR and linewidth measurements with phase tracker

- modulation depth = 0.390 +/- 0.062

There are two modulation frequencies that make it to the arm cavities, at ~11MHz and ~55MHz. Each of these will have their own modulation depth indepedent of each other. Bundling them together into one number doesn't tell us what's really going on. 

  11741   Mon Nov 9 14:24:36 2015 yutaroUpdateLSCFSR and linewidth measurements with phase tracker

I'd like to add a few calculation results, mode matching ratio for Y arm and modulation depth.

Here I assumed peaks marked in the bottom figure shown in elog 11738 as resonances of carrier and modulated sidebands and others as resonances of HOM. 


- mode matching ratio = 94.92 +/- 0.19 % WRONG

How I calculated: for each peak of carrier, you can find 6 peaks of HOM resonaces. Then I calculated the sum of the hight of 6 peaks divided by the hight of carrier resonance peak, and took average of this values for 3 resonance peaks of carrier.


- modulation depth = 0.390 +/- 0.062 WRONG

How I calculated: I took average of the hight of 6 peaks of modulated sideband resonance, and normalized it with the hight of peaks of carrier resonance. Using the relation 'normalized hight' = (J_1(m)/J_0(m))^2, I got modulation depth, m. 



  11740   Mon Nov 9 11:34:51 2015 yutaroUpdateLSCFSR and linewidth measurements with phase tracker

I fitted the data obtained with the FSR and linewidth measurements and I've got FSR and finesse of y-arm by fitting.

The fitted data and the fitting results are attached.



FSR = 3.9704 MHz (ave. of two FSRs, 3.9727 MHz and 3.9681 MHz)

finesse = 401 +/- 11

estimated loss = 1812 (+456 / - 431) ppm



I found peaks from the data and fitted each peak by Lorentzian, automatically with Python (the sourse code I used is attached).

3 parameters of Lorentzian for each peak and their fitting errors are attached.

Then, using 3 peaks of carrier resonance, I calculated FSR, finesse, and loss.

The error of finesse came from that of linewidth.

When calculating the loss, I used the value of 1.384 % for transmission of ITMY. 



Since the finesse is mostly determined by the transmission of ITM, the relative error of loss estimation is larger (about 25 % ) though the relative error of finesse is about 3 %. Therefor we have to find the reason why each estimated linewidth varies that largely, and measure finesse more accurately.


Attachment 1: plt.png
Attachment 2: fitresult_and_code.zip
  11739   Mon Nov 9 09:27:44 2015 SteveUpdatePSLMC is not happy

I just turned off the PSL enclousure lights.

Attachment 1: ioo8d.png
  11738   Fri Nov 6 15:56:00 2015 gautamUpdateLSCFSR and linewidth measurements with phase tracker


I performed a preliminary calibration of the X and Y phase trackers, and found that the slopes of a linear fit of phase tracker output as a function of driven frequency (as measured with digital frequency counter) are 0.7886 +/- 0.0016 and 0.9630 +/- 0.0012 respectively (see Attachments #1 and #2). Based on this, the EPICS calibration constants have been updated. The data used for calibration has also been uploaded (Attachment #4).


I found that by adopting the approach I suggested as a fix in elog 11736, and setting a gate time of 1second, I could eliminate the systematic bias in measured frequency I had been seeing, the origin of which is also discussed in elog 11736. This was verified by using a digital oscillator to supply the input to the frequency counting block, and verifying that I could recover the driving frequency without any systematic bias. Therefore, I used this as a measure of the driving frequency independent of the front panel display of the Fluke 6061A. 

The actual calibration was done as follows:

  1. Close PSL green and end green shutters. Turned off the power to the green transmission PDs on the PSL table and disconnected the couplers from their outputs.
  2. Connected the output of the Fluke 6061A RF signal generator to a splitter, and to the inputs of the couplers for the X and Y signal chains.
  3. Adjusted the amplitude of the RF signal output until the Q readout of the rotated X and Y outputs were between 1000 and 3000. The final value used was -17dBm. As a qualitative check, I also looked at the beat signal on the spectrum analyzer in the control room and judged the peak height to be roughly the same as that seen when a real beat note was being measured. The phase tracker gains after setting the UGF were ~83 and 40 for the X and Y arms respectively.
  4. Step through the frequency from 20MHz to 70MHz in steps of 1MHz, and record the outputs of (i) Digital frequency counter readout, and (ii) Phase tracker phase readout for the X and Y arms. I used the z avg -s utility to take an average for 10 seconds, and the standard deviation thus obtained correspond to the errorbars plotted. 
  5. Restore the connections to the green beat PDs and power them on again.

Y-arm transmission scan

I used the information from Attachment #2 to calibrate the X-axis of the Y-arm transmission data I collected on Wednesday evening. Looking at the beat frequency on the analyzer in the control room, between 24 and 47 MHz (green beat frequency, within the range the calibration was done over), we saw three IR resonances. I've marked these peaks, and also the 11MHz sideband resonances, in Attachment #3. It remains to fit the various peaks. I did a quick calculation of the FSR, and the number I got using these 3 peaks is 3.9703 +/- 0.0049 MHz. This value is ~23 kHz greater than that reported in elog 9804, but the error is also ~4 times greater (6 IR resonances were scanned in elog 9804) so I think these measurements are consistent.

Rubidium clock

I had brought an FS725 Rubidium clock back from W Bridge - the idea was to hook this up to the GPS 1PPS output, and use the 10MHz output from the FS725 as the reference for the fluke 6061A. However, the FS725 has not locked to the Rb frequency even though it has been left powered on for ~2days now. Do I have to do something else to get it to lock? The manual says that it should lock within 7 minutes of being powered on. Once this is locked, I can repeat the calibration with an 'absolute' frequency source...

Attachment 1: Xcalib.pdf
Attachment 2: Ycalib.pdf
Attachment 3: Y_scan_log.pdf
Attachment 4: 2015-11-05_phase_tracker_calib.dat.zip
Attachment 5: 2015-11-04_y_arm_scan.dat.zip
  11737   Thu Nov 5 10:48:21 2015 yutaroUpdateElectronicsoffset voltage vs. gain of common mode servo

I report the results of the measurement to know how offset voltage of common mode servo changes when the gain is changed.


- Motivation: If discontinuous change of the offset happens when we change the gain, it could cause saturation somewhere and so make the length control down. So, we want to estimate effect of such discontinuous change.


- Method: In 1 (or In 2) was terminated with 50 ohm, and the output voltage at Out 2 was measured with a multimeter (D040180-B).


- Results are shown below. Acquired data are attached in .zip.

The upper shows input equiv. offset. The lower shows offset measured at Out 2.

As for both In1 and In2, strange behaviors can be seen between -17 dB and -16 dB.

This is because 5 amplifiers (or attenuators) are simultaneously enabled/disabled here. Similar situation occurs every change of 8 dB gain. 

Attachment 2: offsets.zip
  11736   Thu Nov 5 03:04:13 2015 gautamUpdateCDSFrequency counting - systematics and further changes

I've made a few more changes to the frequency counting code - these are mostly details and the algorithm is essentially unchanged.

  • The C-code block in the simulink model now outputs the number of clock cycles (=1/16384 seconds) rather than the frequency itself. I've kept converting this period to frequency step by taking the reciprocal as the last step of the signal chain, i.e. after the LP filter.
  • In the current version of the FC library block, I've disabled the moving average in the custom C code - I've left the functionality in the code, but the window length at the moment is set to 1, which in effect means that there is no moving average. I found that comparable jitters in the output are obtained by using no moving average, and having two 2-pole IIR low-pass filters in series (at 4Hz and 2Hz) as by doing a moving average over 4096 clock cycles and then passing that through a 2Hz IIR lowpass filter (as is to be expected).

Systematic error

The other thing that came up in the meeting last week was this issue of the systematic errors in the measured frequency, and how it was always over-estimating the 'actual' frequency. I've been investigating the origin of this over the last few days, and think I've found an explanation. But first, Attachment #1 shows why there is a systematic error in the first place - because we are counting the period of the input signal in terms of clock cycles, which can only take on discrete, integer values, we expect this number to fluctuate between the two integers bounding the 'true value'. So, if I'm trying to measure an input signal of 3000Hz, I would measure its period as either 5 or 6 clock cycles, while the "true"  value should be 5.4613 clock cycles. In attachment #1, I've plotted the actual measured frequency and the measured frequency if we always undercounted/overcounted to the nearest integer clock cycles, as functions of the requested frequency. So the observed systematic error is consistent with what is to be expected.

The reason why this doesn't average out to zero is shown in Attachment #2. In order to investigate this further, I recorded some additional diagnostic variables. If I were to average the period (in terms of clock cycles - i.e. I look for the peaks in the blue cuve, add them up, and divide by the number of peaks), I find that I can recover the expected period in terms of clock cycles pretty accurately. However, the way the code is set up at the moment, the c code block outputs a value every 1/16384 seconds (red curve) - but this is only updated each time I detect a zero crossing - and as a result, if I average this, I am in effect performing some sort of weighted average that distorts the true ratio of the number of times each integer clock-cycle-period is observed. This is the origin on the systematic error, and is a function of the relative frequency each of the two integer values of the clock-cycle-period occurs, which explains why the systematic error was a function of the requested frequency as seen in Attachment #1, and not a constant offset. 

At the frequencies I investigated (10-70MHz in 5MHz steps), the maximum systematic error was ~1%.

Is there a fix?

I've been reading up a bit on the two approaches to frequency counting - direct and reciprocal. My algorithm is the latter, which is generally regarded as the more precise of the two. However, in both these approaches, there is a parameter known as the 'gate-time': this is effectively how long a frequency counter measures for before outputting a value. In the current approach, the gate time is effectively 1/16384 seconds. I would think that it is perhaps possible to eliminate the systematic error by setting the gate time to something like 0.25 seconds, and within the gate time, do an average of the total number of periods measured. Something like 0.25 seconds should be long enough that if, within the window, we do the averaging, and between windows, we hold the averaged value, the systematic error could be eliminated. I will give this a try tomorrow. This would be different from the moving average approach already explored in that within the gate-time, I would perform the average only using those datapoints where the 'running counter variable' shown in Attachment #2 is reset to zero - this way, I avoid the artificial weighting that is an artefact of spitting out a value every clock cycle. 

Attachment 1: Systematic_error.pdf
Attachment 2: systematics_origin.pdf
  11735   Thu Nov 5 02:18:32 2015 gautamUpdateLSCFSR and linewidth measurements with phase tracker

While the ETMx issues are being investigated - with Eric's help, I took some data from arm scans of the Y arm through ~2FSRs using ALS. I've also collected the data from the frequency counter readout during these scans but since they were done rather fast (over 60seconds), I am not sure how accurate this data will be. The idea however is to use the frequency readout from the phase tracker - this has to be linearized though, which I will do during the daytime tomorrow. The plan is to use our GPS timing unit to synchronize the following chain :

GPS timing unit 1PPS out --> FS725 Rb Clock 1PPS in (I recovered one which was borrowed from the 40m some time ago from the ATF lab yesterday evening, waiting for it to lock to the Rb clock now)

FS725 Rb Clock 10 MHz out --> Fluke 6061A 10MHz reference in

FS725 Rb Clock 10 MHz out-->agilent network analyzer 10MHz reference in (for measurement of the frequency of the signal output from the Fluke RF signal generator independent of its front panel display)

Then I plan to look at the phase tracker output as a function of the driving frequency (which will also be measured, offline, using the digital frequency counter setup) over a range of 20 MHz - 50 MHz in steps of 1 MHz. Results to follow.

Earlier tonight, Eric and I tweaked the PMC alignment (the mode cleaner was not staying locked for more than a couple of minutes, for almost an hour). 

  11733   Wed Nov 4 22:42:02 2015 ericqUpdateSUSETMX oplev servo disabled

During this time period, it looks like there was maybe one excursion. Here are the individual OSEM signals, which I think to be calibrated to microns. 

When I'm doing other things, I'm going to intentionally leave the watchdog tripped, and see if anything happens. 

  11732   Wed Nov 4 20:16:58 2015 yutaroUpdateElectronicsoffset voltage vs. gain of common mode servo

At 1Y2 rack, I measured offset voltage of the common mode servo (D040180-B) with the gain of it varied.

For now, all signal cables that come into or go out of the common mode servo are not plugged.


I will upload the data I took and report the result later.

  11731   Wed Nov 4 16:12:07 2015 ericqUpdateCDSOPTIMUS

There is a new machine on the martian network: 32 cores and 128GB of RAM. Probably this is more useful for intensive number crunching in MATLAB or whatever as opposed to IFO control. I've set up some of the LIGO analysis tools on it as well. 

A successor to Megatron, I dub it: OPTIMUS

  11730   Wed Nov 4 15:48:58 2015 SteveUpdatePEMETMX wirestadoff vs EQ

ETMX was not much effected by this 8.3 M Chilian earthquake. It was kicked up and it was kicking for hours after it. This is a sign of instability but it maintaind it's position.

The 24 hours plot follows the tempeerature.


Attachment 1: 8.3mChili.png
  11729   Wed Nov 4 14:44:00 2015 ericqUpdateSUSETMX oplev servo disabled

I've turned the ETMX oplev servos off for the time being. (At the input side, so that no scripts will accidently turn it on).

Thus, only the local damping is being applied, let's see if we see any kicks...

  11728   Wed Nov 4 08:04:53 2015 SteveUpdatesafetysafety training

Yutaro Enamoto, visiting graduate student of Seiji received 40m specific basic safety training.


Attachment 1: Yutaro.jpg
  11727   Tue Nov 3 18:49:41 2015 gautamUpdateSUSETMX kicked up

I was trying to take a few more IR transmission scans with ALS when the ETMX got kicked again. I'm not sure how to fix this, so for the time being, I'm leaving the Oplev servo and the LSC turned off. The oplev spot looks really far off center especially in yaw, the yaw error is ~ -80.


The oplev and  the LSC are off.


  11726   Tue Nov 3 03:12:46 2015 ericqUpdateLSCDRFPMI work

Tonight was kind of a wash. 

We spent some time retaking single arm scans with Gautam's frequency counting code to confirm the linewidths he measured before his most recent round of code improvements. During this, ETMX was being its old fussy self, costing us gentle realignment time. For the time being, we started actuating on ITMX for single arm locks. Also, out of superstition, I changed the static position offset that had been at +1k for the last N months to -1k. 

ETMX broke us out of a few DRFPMI lock trials as well, as did poor SRM alignment. I finally set up dither alignement settings for SRM in DRMI though, which helped (even in the arms-held-off-resonance situation). I still prefer doing the PRM/BS dither alignment in a carrier PRMI lock, because I think the SNR should be better than DRMI. 

We know that the ETMX excursions can happen without length drive exciting them, but also that length drives certainly can excite them. For future locks, I'm going to try out avoiding ETMX drive altogether; the sites use a single ETM for their DARM actuation and let the CARM loop take care of the resultant cross coupling, so hopefully we can do the same without angering the mode cleaner.

Anyways, we didn't really ever make it far enough to do anything interested with the DRFPMI tonight frown

  11725   Mon Nov 2 17:39:01 2015 KojiFrogsGeneralDRFPMI celebration


Attachment 1: yatta.jpg
  11724   Fri Oct 30 17:49:27 2015 SteveUpdateSUSETMX kicked up

The oplev and  the LSC are off.

Attachment 1: ETMXkicking.png
Attachment 2: ETMXkickedbyOpPerror.png
Attachment 3: ETMXstillKicking.png
Attachment 4: ETMXkickingCond.png
Attachment 5: 7hrsETMX-Y.png
  11723   Fri Oct 30 16:56:04 2015 gautamUpdateCDSis there a problem with the SCHMITTTRIGGER CDS library part?

Over the course of my investigations into the systematic errors in the frequency readout using digital frequency counting, I noticed that my counter variable that keeps track of the number of clock cycles between successive zero crossings was NOT oscillating between 2 values as I would have expected (because of there being a +/- 1 clock cycle difference between successive zero crossings due to the fixed sampling time of 1/16384 seconds), but that there were occassional excursions to values that were +/- 3 clock cycles away. I then checked the output of the SCHMITTTRIGGER CDS library part (which I was using to provide some noise immunity), and noticed that it wasn't triggering on every zero crossing at higher frequencies. I tested this by hooking up a digital oscillator to the SCHMITTTRIGGER part, and looked at its output for different frequencies. The parameters used were as follows:

CLKGAIN: 10000

SCHMITTTRIGGER lower threshold: -1.0

SCHMITTTRIGGER upper threshold: +1.0

I am attaching plots for two frequencies, 3000Hz and 4628Hz (Attachments #1 and #2) . I would have expected a flip in the state of the output of the schmitt trigger between every pair of horizontal red lines in this plot, but at 4628 Hz, it looks like the schmitt trigger isn't catching some of the zero crossings? Come to think of it, I am not even sure why the output of the schmitt trigger takes on any values other than 0 or 1 (could this be an artefact of some sort of interpolation in the visualization of these plots? But this would not affect the conclusion about the schmitt trigger missing some of the zero crossings?)

As an interim measure, I implemented a Schmitt trigger in my C code block - it was just a couple of extra lines anyways - I have designated the schmitt trigger output as a static variable that should hold its value in successive execution cycles, unless it is updated by comparing the input value to the thresholds (code attached for reference). Attachments #3 and #4 show the output of this implementation of a Schmitt trigger at the same two frequencies, and I am seeing the expected flip in the state between successive zero crossings as expected (though I'm still not sure why it takes on values other than 0 and 1?). Anyways this warrants further investigation. An elog regarding the implications of this on the systematic error in the frequency counter readout to follow.

Attachment 1: 3000Hz.pdf
Attachment 2: 4628Hz.pdf
Attachment 3: 3000Hz_software_SCHMITT.pdf
Attachment 4: 4628Hz_software_SCHMITT.pdf
  11722   Thu Oct 29 03:25:49 2015 ericqUpdateLSCDRFPMI work

[ericq, Gautam]

The length of DRFPMI lock did not increase much tonight, but we got a ~80 second sensing matrix measurement, and got the CARM bandwidth up to 10k with two boosts on. 

NB: I did not measure the CARM loop gain at its excitation frequency, so the plotted sensing element is supressed by the CARM loop. However, this is still useful for gauging the size of the PRCL signal vs. the residual CARM fluctuations. The excitations are fairly closely spaced between 309 and 316 Hz. 

For comparison, I'm also re-plotting the DRMI sensing measurement from a few weeks back taken at CARM offset of -4. We can see some change in the PRCL sensing, likely due to the CARM-coupled path. MICH/PRCL sadly looks pretty degenerate, but REFL55 looks more reasonable. 


I think the main limitation tonight was SRC stability. Even before bringing CARM to zero offset, we would see occasional sharp dives in AS110 power. One lockloss happened soon after such an occurance, but I checked the values, and it was not sufficient to trigger the Schmitt trigger down; instead it may have been a real optical loss of signal. The SRCL OLTF looks sensible. 

Random notes:

  • Aux X laser was glitching yet again, twiddled laser current to 1.90A from the 1.95A that I twiddled it to on Monday from the nominal 2.0A. 
  • When aligning the PRMI, I saw both ITMs' oplevs shift by a few urad in both pitch and yaw when engaing/breaking the lock, but this was not repeatable.
  • I reduced the AS110 whitening gain by 9dB, since the DC values were a few thousands, and I wanted to make sure there were no stray ADC saturations. This didn't change lock stability though. 
Attachment 1: DRFPMI.pdf
Attachment 2: DRMIarms.pdf
  11721   Wed Oct 28 17:06:30 2015 ericqUpdateASCNew PRC Angular FF filters installed

I've installed new filters for the T240 -> PRM static online angular feedforward that were trained after some of the recent changes to the signal chain of the relevant signals (i.e. the counts->velocity calibration that Rana did for the seismometers, and fixing the improper dewhitening of the POP QPD channels used as the Wiener target.)

Quickly trying them out now shows about the same level of performance as the previous ones, but the real performance I care about is during after-hours locking-time, so I'll take more measurements tonight to be posted here. 

  11720   Wed Oct 28 14:07:44 2015 KojiUpdateIOOMC WFS Offsets update

MC WFS offsets were updated to have a better operating point.

  11719   Tue Oct 27 10:08:12 2015 SteveUpdateVAC CC vacuum gauges

CC1 and CC2 are working again. Why did they start working  again ?


Attachment 1: gauges_5y_vs_8d.png
Attachment 2: 13.9yCC1&4.png
  11718   Tue Oct 27 03:56:52 2015 ericqUpdateLSCDRFPMI work

A handful of DRFPMI locks tonight, longest one was ~7 minutes. 

EPICS/network latency has been a huge pain tonight. The locking script may hang between commands at an unstable place, or fail to execute commands altogether because it can't find the EPICS channel. This prevented or broke a number of locks. 

I made some CARM OLG and crossover measurements, and found the AO gain for the right crossover freq (~100Hz) to be ~8dB different than what's in the PRFPMI script, which is weird. Right now, the CARM bandwidth / ability to turn on boosts is limited by the gain peaking in the IMC CLG due to the high-ish PC/PZT crossover frequency we're using. 

Gautam turned on some sensing excitations during the last couple of locks, but they weren't on for very long before the lock loss. Hopefully I can pull out at least some angles from the data. 

I'm also more convinced that the PRC angular FF needs retuning; there is more residual motion on the cameras than I'm used to seeing. I've taken more data that I'll use to recalculate a wiener filter tomorrow. 

The PMC, ALSX beat and ITMX oplev all needed a reasonable pitch realignment tonight. 

  11716   Tue Oct 27 03:46:26 2015 ericqUpdateSUSMC2 F2P mis-tuned

D'oh. Good point.

Reverted for now; I'm thinking about doing laser pointer->MC2 QPD...

  11715   Mon Oct 26 19:10:59 2015 gautamUpdateGreen LockingAUX PDH loop characterization

I began my attempts to characterize the PDH loops at the X end today. My goal was to make the following measurements:

  • Dark noise and shot noise of the PD
  • Mixer noise
  • Servo electronics noise 

which I can then put into my simulink noise-budget scheme for the proposed IR beat setup.

I've made an Optickle model of a simple FP cavity and intend to match the measured PDH error signal from the X end to the simulated error signal to get the Hz/V calibration. I'll put the plots up for these shortly.

With regards to the other measurements, I was slowed down by remote data-acquisition from the SR785 - I've only managed to collect the analyzer noise floor data, and I plan to continue these measurements during the day tomorrow. 

  11714   Mon Oct 26 18:59:25 2015 gautamUpdateLSCGreen beatnote couplers installed

I found (an old) 10 dB coupler in the RF component shelves near MC2 - it has BNC connectors and not SMA connectors, but I thought it would be worth it to switch out the 20dB coupler currently on the X green beat PD on the PSL table with it. I used some BNC to SMA adaptors for this purpose. It appears that the coupler works, because I am now able to register an input signal on the X arm channel of the digital frequency counter (i.e. the coupled output from the green beat PD). I thought it may be useful to have this in place and do an IR transmissions arm scan using ALS for the X arm as well, in order to compare the results with those discussed here. However, the beat note amplitude on the analyzer in the control room looks noticeably lower - I am not sure if the coupler is responsible for this or if it has to do with the problems we have been having with the X end laser (the green transmission doesn't look glitchy on striptool though, and the transmission itself is ~0.45). In any case, we could always remove the coupler if this is hindering locking efforts tonight. 

  11713   Mon Oct 26 18:10:38 2015 IgnacioUpdateIOOLast Wiener MCL subtractions

As per Eric's request, here is the code and TF measurement that was used to calculate the MC2 FF filter that is loaded in FM5. This filter module has the filter with the best subtraction performance that was achieved for MCL.


Attachment 1: code_TF.zip
  11712   Sat Oct 24 12:34:43 2015 gautamUpdateCDSFrequency counting - workable setup prepared

Sorry for the confusion - I did mean Green beat frequency, and I had neglected the factor of 2 in my earlier calculations. However, the fit parameter "c" in my fit was actually the half-width at half maximum and not the full width at half maximum. After correcting for both these errors (new fit is Attachment #1, where I have now accounted for the factor of 2, and the X axis is the IR beat frequency), I don't think the numbers change too much. It could be that the frequency counter wasn't reading out the frequency correctly, but looking at a time series plot of the frequency counter readout (Attachment #2), and my earlier trials, I don't think this is the case (38 MHz is a frequency at which I don't expect much systematic error - also, the offset was stepped from -3 to 3 over 45 seconds). 

The revised numbers:

Fitted linewidth = 2*c = 10.884 kHz +/- 2 Hz (95% C.I.)

FSR of Y arm (from elog 9804) = 3.9468 MHz +/- 1.1 kHz

=> Y arm Finesse = FSR/fitted linewidth =  362.6 +/- 0.5

Total round trip loss = 2*pi/Finesse = 0.0173


Attachment 1: Yscan.pdf
Attachment 2: Frequency_readout.pdf
  11711   Fri Oct 23 21:58:10 2015 ranaUpdateSUSMC2 F2P mis-tuned

The OSEMs cannot be used for coil balancing above ~10 Hz. The main coupling path from OSEM drive to sensor is not through the mirror motion, but instead direct electrical coupling of the drive wires to the sensing wires.sad

I put this in the elog every ~1-2 years since people keep trying it, but it keeps coming back like a zombie.crying

Better to use the MC angular sensors for L2A decoupling. Not perfect, but better than OSEMs. For the TMs we can use the OLs.

  11710   Fri Oct 23 19:27:19 2015 KojiUpdateCDSFrequency counting - workable setup prepared

It is a nice scan. I'm still thinking about the equivalence of the moving average and the FIR low pass that I have mentioned in the meeting.


I'm confused by the plot. The bottom axis says "green beat frequency".
If you scan the IR laser frequency by df, you get 2*df shift of the green beatnote. You need to have this factor of two somewhere.
If you are looking at the IR beat freq, just the label is not correct. (I believe this is the case.)

Accepting the rather-too-low finesse of 363 (nominally 450), the total round trip loss is said to be 0.0173.
If we subtract the front transmission of 1.38% (and ignoring the transmission loss from the ETM),
the round trip loss is 3500ppm. Is this compatible with the following elog?
In fact, I'm afraid that the loss number in the above elog 11111 was not correct by a factor of 10.
Then, if so, can we believe this high loss number? (Nominally we expect ~100ppm loss per round trip...)

  11709   Fri Oct 23 18:36:48 2015 gautamUpdateCDSFrequency counting - workable setup prepared

I've made quite a few changes in the software as well as the hardware of the digital frequency counting setup.

  • The main change on the software side is that the custom C code that counts intervals between successive zero crossings and updates the frequency output now has a moving average capability - the window size is readily changable (by a macro in the first line of the code, which resides at /opt/rtcds/userapps/release/cds/c1/src/countZeroCrossingWindowed.c - however, changing the window size requires that the model be recompiled and restarted), and is currently set to 4096 because based on some empirical trials I did, this seemed to give me the frequency output with the least jitter, and also smaller systematic errors than in my earlier trials described here.
  • The filter modules for both the X and Y channels now have 2 pole butterworth low pass filters with poles at 64Hz, 32Hz, 16Hz, 8Hz, 4Hz, 2Hz and 1Hz loaded. Again, based on my empirical trials, a combination of a moving average filter in the C code and the IIR filters after that worked best in terms of reducing the jitter in the frequency readout. I think the fact that the moving average 'spreads' the impulse caused by a glitch in the counting algorithm improves the response of the combination as compared to having only the IIR filters in place. 
  • The Frequency Counting SIMULINK block has been cleaned up a little - I have removed unnecessary test points I had set up for debugging, and is now a library part called "FC".
  • After the experience of having C1ALS crash as noted here, I was doing all my testing in the C1TST model. Having made all the changes above, I reverted to the C1ALS model, which compiled and ran successfully this time.
  • On the hardware side, I interchanged the couplers mentioned here - so the 20dB coupler now sits on the X green beat PD, while the 10dB coupler sits on the Y green beat PD. This change was motivated by wanting to test out the digital frequency counting setup by performing an arm scan through an IR resonance using ALS, and we found that the PSL+Y green beat frequency was better behaved than the X+PSL combination.

Arm scan

Eric helped me test the new setup by doing an arm scan through an IR resonance by ramping the ALS offset from -3 to +3 with a ramp time of 45 seconds. The data was acquired with the window size of the moving average set to 4096 clock cycles, and a 2 Hz low pass IIR filter before the frequency readout. Attachment 1 shows a plot of the data, and a fit with a function of the form trans = a/(1+((x-b)/c)^2), where a = normalization, b = center of lorentzian, and c = linewidth (FWHM) of the peak (the fitted parameter values, along with 95% confidence bounds are also quoted on the plot). In terms of the data acquisition, comparing this dataset to one from an earlier scan Eric did (elog11111) suggests that the frequency counting setup is working reasonably well - at any rate, I think the data is a lot cleaner than before implementing the moving average and having a 20Hz lowpass IIR filter. In any case, we plan to repeat this measurement sometime next week during a nighttime locking session. It remains to calculate the arm loss from these numbers analogous to what was done earlier for the X arm.

Calculation of loss:

Fitted linewidth = 10.884 kHz +/- 11Hz (95% C.I.)

FSR of Y arm (from elog 9804) = 3.9468 MHz +/- 1.1 kHz

=> Y arm Finesse = FSR/fitted linewidth =  362.6 +/- 0.5

Total round trip loss = 2*pi/Finesse = 0.0173





Attachment 1: Yscan.pdf
  11708   Fri Oct 23 09:55:50 2015 SteveUpdateLSCstable days
Attachment 1: stable4days.png
  11707   Thu Oct 22 08:52:04 2015 SteveUpdateVACclean RGA scan after sweaty Maglev

Clean comparable scan at vacuum normal. There was no backstreaming.

Attachment 1: clean_scan.png
  11706   Wed Oct 21 15:42:56 2015 SteveUpdateVACvacuum gauge check

Convectron gauge check:

Brand new 10 years old convectron gauge at atm was swapped into the place of existing gauges to see if they read close to 760 Torrs

They did reasonable well at the low end. I tried to imitate calibration and bring down the high end with little success.

( P1 and P2  were reading 7e-4 to ~660 Torr  The correction of the upper end pushed up the lower end too. I will correct this later

P3 and P4 high ends are way off )

The point is that they work.  Convectron gauges will be replaced and calibrated at the next vent.

Interlocks were not triggered during this test. I was expected to close the PSL shutter when P1 was reading 760 Torr

This hide some problem or  not understanding.

It was good to see CC1 and CC4 working at the moment


Somehow I succeded opening VM1 and closed VM2 = vacuum normal

I just hope it stays open overnight to get comparable RGA scan.


Attachment 1: Gauges.png
  11705   Wed Oct 21 10:03:15 2015 SteveUpdateVACafter running out of N2



[ericq, Gautam, Steve]

Following roughly the same procedure as ELOG 11354, c1vac1 and c1vac2 were rebooted. The symptoms were identical to the situation in that ELOG; c1vac1 could be pinged and telneted to, but c1vac2 was totally unresponsive. 

The only change in the linked procedure was that we did not shut down the maglev. Since I unwittingly had it running for days without V4 open while Steve was away, we now know that it can handle shorter periods of time than that...

Upon reboot, many channels were readable again, unfortunately the channels for TP2 and TP3 are still blank. We were able to return to "Vacuum normal state," but because of unknowned communication problems with VM1's interlock, we can't open VM1 for the RGA. Instead we opened VM2 to expose the RGA to the main IFO volumn, but this isn't part of the "Normal" state definite, so things currently read "Undefined state".


1, Pressure gauges had no communication ( NO COMM ) with c1vac2


2, Lost N2 supply on Oct 9 This triggered a normal all valve closed condition. At this point you replace N2 cylinders and manually swich valves to recreate VAC NORMAL configuration in the correct sequential order.

   The very last thing you do is open V1 gate valve.

   a, check TP2 that is the forepump of the Maglev. Foreline pressure to drypump  ~ 10- 100 mTorr, rotation speed 50 Krpm

   b, open V4 if P2 <1Torr

   c, check Maglev rotating at 560 Hz

   d, open V1 if P1 <500 mTorr

   e, check TP3 foreline, rotation speed and open V5 if P3 <1 Torr with VA6 closed

   f, open VA6 if PAN <1 Torr

  g, open annulos valves one by one , like VASE if PASE <1 Torr and so on...........Now the Current State: should read Vac Normal


3, Maglev run for 7 days with V4 closed. This encreased its foreline pressure to estimated few Torrs  and its body temp rose ~30C on the outside.

   So it was sweating and it may be back streamed.

The present RGA data is indicating that it had to be very mild.

The RGA will have better sensitivity with VM1 open and VM2 closed.

The PSL output shutter stayed open during these period is pointing  to IFO pressure stayed P1 <3 mTorr

PROBLEM: P1 and P2 plot should show nothing where there is no communication.http://nodus.ligo.caltech.edu:8080/40m/151016_182003/oct16Fpm2015.png

                   How do we check if pressure based software interlocks are working in this no communication condition?

Attachment 1: 1d_after_reboot.png
  11704   Tue Oct 20 17:36:01 2015 gautamUpdateCDSFrequency counting with moving average

I'm working on setting up a moving-average in the custom C code block that counts the zero crossings to see if this approach is able to mitigate the glitchy frequency readout due to mis-counting by one clock cycle between successive zero crossings. I'm storing an array the size of the moving average window of frequency readouts at each clock cycle, and then taking the arithmetic mean over the window. By keeping a summing variable that updates itself each clock cycle, the actual moving average process isnt very intensive in terms of computational time. The array does take up some memory, but even if I perform the moving average over 1 second with 16384 double precision numbers stored in the array, its still only 130 kB so I don't think it is a concern. Some tests I've been doing while tuning the code suggest that with a moving average over 16384 samples (i.e. 1 second), I can eliminate glitches at the 1Hz level in the frequency readout for frequencies up to 5 kHz (generated digitally using an oscillator block). Some tuning still needs to be done, and the window could possibly be shortened. I also need to take a look at the systematic errors in this revised counting scheme, preferably with an analog source, but this is overall, I think, an improvement.

On a side note, I noticed some strange behaviour while running the cds average command - even though my signal had zero fluctuations, using z avg 10 -s C1:TST-FC_FREQUENCY_OUT gave me a standard deviation of ~1 kHz. I'm not sure what the problem is here, but all the calibration data I took in earlier trials were obtained using this so it would be useful to perform the calibration again. 

  11703   Tue Oct 20 16:27:04 2015 ericqUpdateVACvacuum VME machines rebooted

[ericq, Gautam, Steve]

Following roughly the same procedure as ELOG 11354, c1vac1 and c1vac2 were rebooted. The symptoms were identical to the situation in that ELOG; c1vac1 could be pinged and telneted to, but c1vac2 was totally unresponsive. 

The only change in the linked procedure was that we did not shut down the maglev. Since I unwittingly had it running for days without V4 open while Steve was away, we now know that it can handle shorter periods of time than that...

Upon reboot, many channels were readable again, unfortunately the channels for TP2 and TP3 are still blank. We were able to return to "Vacuum normal state," but because of unknowned communication problems with VM1's interlock, we can't open VM1 for the RGA. Instead we opened VM2 to expose the RGA to the main IFO volumn, but this isn't part of the "Normal" state definite, so things currently read "Undefined state".

  11702   Tue Oct 20 15:51:44 2015 ericqUpdateSUSMC2 F2P tuned

Using a modified version of Hang's deMod_deCoup scripts, I tuned the MC2 coil output matrix to minimize the appearance of POS drive in the SUSPIT signal at 28Hz. Up until now, there was no F2P compensation. This reduced the force to pitch coupling at 28Hz by 8dByes

Old: POS -> 1 x UL, 1 x UR, 1 x LL, 1x LR

New: POS -> 1.1054 x UL, 1.1054 x UR, 0.8946 x LL, 0.8946 LR

I checked the MCL spectrum before and after this change with OAF on, this did not spoil the feedforward length subtraction in any noticible way. 

The script lives in userapps/release/isc/c1/scripts/decoup, but I've symlinked it to /opt/rtcds/caltech/c1/scripts/decoup.

The script modification I made had to do with how the I and Q data is collected. Before, it was sporadically probing the I and Q FM output monitor EPICS values; I changed it to use the avg function of cdsutils, which calculates the mean and std from the 16kHz data and have seen it improve results by 1dB or so. I've been in touch with Jenne to propagate this to the sites. 

ELOG V3.1.3-