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.

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

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...

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.

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

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.

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. 

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). 

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. 

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. 

Summary:

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).

Details:

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...

I just turned off the PSL enclousure lights.
 

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.

Summary:

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

finesse = 401 +/- 11

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

Detail:

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. 

Note:

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.

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. 

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. 

Summary:

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

Details:

• 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   , and solving for . Attachment #2 shows a plot of the RHS of this equation as a function of  - 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. 

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

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.  

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.

Summary:

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)?

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.

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.

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. 

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. 

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...

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

PMC

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

IMC

- 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.

/opt/rtcds/caltech/c1/scripts/MC/MC2tickleON

amp=300
=>
amp=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).

TM SUS

- 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.

The ITMX OSEMS are oscillating.

The PMC is not happy and the ITMX UL OSEM is moving too much

Building:         San Pasqual walkway East to West

                  (Between Holliston & Wilson)         

Date:             Thursday 11-12-15 to Wednesday 11-18-15

Time:             Between 6:00 a.m. and 4:00 p.m. each day        

Notification:     Possible Noise Vibration

Contact:          Ken Lewis (626) 298-2037       

* Plumbing contractor will be inspecting and water jetting Storm drains

Type of interruption: (Some vehicle noise and small vibrations limited to close surrounding area)

Areas effected: San Pasqual walkway from Holliston Street to Wilson)

Potential effects: storm drain loss of use

Reason for interruption: Storm drain cleaning in preparation for rainy season

By looking at the oplev and Vmons before and after a step of 90 counts in SUS-ETMX_PIT_OFFSET, I observe:

• UL: +1.53mV / urad
• UR: -1.94mV / urad
• LR: -1.54mV / urad
• LL: +1.92mv / urad

The random error associated with these measurements is ~0.02mV

So, the ~7urad urad shift seen in my earlier post would mean a change of around 10mV in the Vmon signals, which isn't evident in the traces. So, this is possibly a piece of evidence in favor of a real mechanical shift, rather than an electronic glitch. 

We found the PSL laser switched off. Looking at the wall StripTool, it looks like this happened about 4 hours ago. Gautam was working at and around the PSL table, and I suspect he accidently ran into the Big Red Button. 

We turned the laser back on.

Are they oscillating or not ?

ETMX, ETMY and MC2 POS _biases are off. Why ?

The Epics MEDMs screens are going blank in  ~3-5 minutes reluctantly.

[yutaro, gautam]

Summary:

Having obtained a working FS725 Rubidium standard and syncing it to out GPS timing unit, I wanted to have one more pass at calibrating the phase tracker output, with the RF signal generator calibrated relative to an 'absolute' source. I also extended the range of frequencies swept over to 15MHz to 110MHz. We found that the phase tracker output appears linear over the entire range scanned, but taking a closer look at the residuals suggested some quadratic structure. Restricting the fitted range to [31MHz 89MHz] yields the following calibration constants for the X and Y arm respectively: 0.9904 +/- 0.0008 and 0.9984 +/- 0.0005. This suggests that out previous calibration was pretty accurate, and that it is valid over a wider range of frequencies, so we could plausibly fit in more FSRs in future scans if necessary. I have not updated these values on the EPICS screens (though judging by how close they are to 1, I wonder if this is even necessary)...

Details:

The principle change in the setup compared to that used to collect the data presented in elog 11738 was the addition of the FS725 rubidium standard. As detailed here, I synced the Rubidium standard to our GPS timing unit (this took a while - the manual suggests it should only take minutes, but it took about 10 hours - the two photos in Attachment #1 show the status of the front panel before and after it synced to the external 1PPS input). I then took 10 MHz outputs from the FS725, and ran one to the Fluke 6061A, and the other to the AG4395A. The Fluke 6061 A has a small switch at the back which has to be set to "EXT" in order for it to use the external reference (it has now been returned to the "INT" state). We then connected the output of the signal generator via a 3-way minicircuits splitter to the AG4395A, and the two beat channels. 

I cleared the phase history on the MEDM screen, and set the phase tracker UGF. We then swept through frequencies from 15MHz to 110MHz (using the AG4395 to verify the frequency at each step). I used the following command to record the average value (over 10 seconds) and the standard deviation: z avg 10 -s C1:ALS-BEATX_FINE_PHASE_OUT_HZ >> 20151113_PT_X.dat and so on.. The amplitude of the signal generated (i.e. before the splitter) was -18dBm (chosen such that the Q outputs of either phase tracker was between 1000 and 3000), while the gains were ~100 (X) and 50 (Y). I then downloaded the data and fitted it.

Fitting details:

The output of the phase tracker looks roughly linear over the entire range of frequencies scanned - but looking at the residuals, one could say there was some quadratic structure to it (see residual plots in Attachment #2). By looking at the shapes of the residuals, I judged that if we fit in the range [31MHz   89MHz] (for both X and Y), we should see negligible structure in the residuals. Attachment #3 contains the fits and residuals for these fits. One could argue that there is still some structure in the residuals, but is markedly less than over the entire range, and, I think, small enough to be neglected. The calibration constants quoted at the beginning of the elog are from the fits over this range. In principle, we could always break this down into smaller pieces and do a linear fit over that range. But this should allow us to scan through >5 FSRs.

Other remarks:

Since the beat signal also goes to the frequency counter via the couplers, I was also collecting the readouts of the frequency counter. Attachment #5 contains the data collected. It is interesting to note that the FCs fail at ~101 MHz (corresponding to ~6146 Hz after the dividers).

Also, we had taken another dataset last night, but found that there was an anomalous kink in the X phase tracker output at (coincidentally?) 89 MHz (I've attached the data in Attachment #6). I'm not sure why this happened, but this is what led me to take another dataset earlier today (Attachment #4).

Summary of Attachments:

1. Attachment #1: Photos showing the front panel of the FS725 before and after syncing to the external 1PPS input.
2. Attachment #2: Fits and residuals over the entire range scanned.
3. Attachment #3: Fits and residuals over restricted range [31 89] MHz
4. Attachment #4: Data used for phase tracker calibration.
5. Attachment #5: Frequency counter data.

Summary:

I followed a slightly different fitting approach to Yutaro's in an attempt to determine the g-factor of the Y arm cavity (details of which are below), from which I determined the FSR to be 3.932 +/- 0.005 MHz (which would mean the cavity length is 38.12 +/- 0.05 m) and the RoC of ETMY to be 60.5 +/- 0.2 m. This is roughly consistent (within 2 error bars) of the ATF measurement of the RoC of ETMY quoted here.

Details:

I set up the problem as follows: we have a bunch of peaks that have been identified as TEM00, TEM10... etc, and from the fitting, we have a bunch of central frequencies for the Lorentzian shapes. The equation governing the spacing of the HOM's from the TEM00 peaks is:

The main differences in my approach are the following:

1. I attempt to simultaneously find the optimal value of FSR, g1 and g2, by leaving all these as free parameters and defining an objective function that is the norm of the difference between the observed and expected values of  (code in Attachment #1). I then use fminsearch in MATLAB to obtain the optimal set of parameters.
2. I do not assume that the "unknown" peak alluded to in my previous elog is a TEM40 resonance - so I just use the TEM10, TEM20 and TEM30 peaks. I did so because in my calculations, the separation of these peaks from the TEM00 modes are not consistent with (m+n) = 4 in the above equation. As an aside, if I do impose that the "unknown" peak is a TEM40 peak, I get an RoC of 59.6 +/- 0.3 m.

Notes:

1. The error in the optimal set of parameters is just the error in the central positions of the peaks, which is in turn due to (i) error in the calibration of the frequency axis and (ii) error in the fit to each peak. The second of these are negligible, the error in my fits are on the order of Hz, while the peaks themselves are of order MHz, meaning the fractional uncertainty is a few ppm - so (i) dominates.
2. I am not sure if leaving the FSR as a free parameter like this is the best idea (?) - the FSR and arm length I obtain is substantially different from those reported in elog 9804 - by almost 30cm! However: the RoC estimate does not change appreciably if I do the fitting in a 2 step process: first find the FSR by fitting a line to to the 3 TEM00 peaks (I get FSR = 3.970 +/- 0.017 MHz) and then using this value in the above equation. The fminsearch approach then gives me an RoC of 60.7 +/- 0.3 m. 

[yutaro, ericq]

We made the beam spot on QPD for the oplev of ETMY centered by changing the orientation of the mirror just before the QPD.

Before doing this, we ran dithering for Y arm and froze the output of ASS for Y arm.
 

A Caltech maintenance staff dropped by at around noon today, and told me that he had seen a small puddle of water on the other side of the door along the Y-arm that is kept locked (about 10m from the end-table, on the south side of the arm). He suspected a leak in the lab. Koji and I went down to the said door and observed that there was indeed a small puddle of water accumulated there. There isn't any obvious source of a leak on our side of the door, although the walls tiles in the area suggest that there could be a leak in one of the pipes running through the wall/under the floor. In any case, the leak doesn't seem too dramatic, and we have decided to consult Steve as to what is to be done about this once he is back on Wednesday.

After running dither alignment for all mirrors, all oplevs were recentered. (Except ETMY, since we did that earlier today.)

Looking at Koji's template for OSEM signals, the ITMX UL sensor noise floor seems more in line with the LL sensor, though there continues to be more noise than in other mirrors. 

Trending the sensor signals over the past 7 days, Koji's measurement looks to have been taken during a time when the UL sensor voltage had jumped down. Did someone squish the satellite box cable? I have not done so. 

I think that the step right at the end is due to a new POS offset of -2k counts, which I think Koji put into place earlier today. 

According to the wiki, the Vmax/2 values and the current values are: 

The leak was found inside the wall. Fortunately the plumbers were able to access it from CES room 108

This has been leaking for sometimes. The damaged wall area is about 18 ft long and 1 ft high.

To test the effect on EPICS latency, I've restarted daqd with modified ini files which disable all frame writing of 16Hz channels. 

This happened at GPS:1131835955 aka Nov 17 2015 22:52:18 UTC

Last night, I started running a script written by Dave Barker that monitors a specified EPICS channel (in this case C1:IOO-MC_TRANS_SUM), to look for seconds in which it does not update the expected number of times. This is still running, so I will be able to compare the rate of EPICS slowdowns before and after this change. 

I will revert back to the nominal state of things in a few hours, or until someone asks me to. 

Although this noise is bad, we have always had these kind of humps around the bounce mode. Our interpretation in the past was that this was due to poor alignment of the OSEM in the frame, leading to a large vertical to horizontal coupling. Once you implement the BLRMS for the SUS channels, we'll be able to trend the noise over long periods of time.

Back to nominal FB configuration at 1131857782, aka Nov 18 2015 04:56:05 UTC.

Weirdly, during this time, the script watching MC_TRANS_SUM from pianosa saw tons of freezes, but another instance  watching LSC-TRY_OUT16 on optimus saw no freezes. 

Steve and I inadvertently discovered that the c1iscey IO chassis doesn't have brackets to secure the cards where the ADC/DAC cables are connected, making them very easy to knock loose. All other IO chassis have these brackets. Pictures of c1iscey and c1lsc IO chassis to compare:

I got linear relation between these. The results and method are below.

RESULTS

METHOD

I added offset (C1:ASS-YARM_ETM_PIT_L_DEMOD_I_OFFSET and C1:ASS-YARM_ETM_YAW_L_DEMOD_I_OFFSET) to shift the beam spot on ETMY. For each data point, I measured the difference in angle of ETMY with oplev before and after adding offset. The precedure for each measurement I employed is following:

-- run dither

-- wait until error signals of dithering settle down

-- freeze dither

-- measure angle (10s avg)

-- add offset

-- wait until error signals of dithering settle down

-- freeze dither

-- measure angle (10s avg)

The reason why I measured the angle without offset for each measurement is that the angle which oplev shows changed with time (~several tens of minutes or something). 

DISCUSSION

At the maximum values of offsets, the arm transmission power started to degrade, so the range where I can do this measurement is limited by these values as for now. However, we have to shift the beam spot more in order to make loss maps of sufficiently broad area on the mirror (the beam width (w) on ETM; w ~ 5 mm). Then, we have to find out how to shift the beam spot more.  

[yutaro, Koji]

We made the beam spot on QPD for the oplev of ITMY centered by changing the orientation of the mirror just before the QPD.

Before doing this, we ran dithering for Y arm and froze the output of ASS for Y arm.

controls@nodus|~ > df -h
Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/nodus2--vg-root  355G   69G  269G  21% /
udev                         5.9G  4.0K  5.9G   1% /dev
tmpfs                        1.2G  308K  1.2G   1% /run
none                         5.0M     0  5.0M   0% /run/lock
none                         5.9G     0  5.9G   0% /run/shm
/dev/sda1                    236M  210M   14M  94% /boot
chiara:/home/cds             2.0T  1.5T  459G  77% /cvs/cds
fb:/frames                    13T   11T  1.6T  88% /frames

Based on elog 1403, I calibrated the oplevs for ITMY/ETMY.

Summary of this method is following:

We lock an arm, and slightly misalign one mirror of the arm. Then, the transmission of the arm starts to decrease quadratically as the misalign angle of the mirror changes. Here, how much the transmission decreases in terms of the misalign angle is determined by geometry of optics, so we can see how much the angle really changes from this quadratic curve.

RESULTS  

These are the relationship between misalign angles measured by oplev (the units are based on the calibration for now) and transmission power.

(I updated following figures on Nov 19 2015. You can find the figures I attached once here in the zipped folder attached.) 

According to this measurement, ratio of the calibration factor derived with this measurement (NEW) and the calibration factor for now (OLD), i.e. NEW/OLD was:  

ETMY_PIT: 5.0265  --->> 5.3922 (without an outlier; the outlier I removed is shown in the figure in zipped folder attached.)

ETMY_YAW: 4.6205

ITMY_PIT: 1.5010

ITMY_YAW: 1.2970

This results show that calibration of oplevs for ITMY is kind of OK, but that for ETMY is so BAD and the calibration factors should be updated.

NOTE

The calibration factors of the oplevs for ETMY/ITMY are   NOT UPDATED YET.  I updated on Dec 11, 2015

If these results are reliable, I will update them tomorrow.   

The /boot partition was filling up with old kernels. Nodus has automatic security updates turned on, so new kernels roll in and the old ones don't get removed. 

I ran apt-get autoremove, which removed several old kernels. (apt is configured by default to keep two previous kernels around when autoremoving, so this isn't so risky)

Now: /dev/sda1                    236M   94M  130M  42% /boot

In principle, one should be able change a setting in /etc/apt/apt.conf.d/50unattended-upgrades that would do this cleanup automatically, but this mechanism has a bug whose fix hasn't propagated out yet (link). So, I've added a line to nodus' root crontab to autoremove once a week, Sunday morning. 

OMG. Please try to use larger fonts and PDF so that we can read the plots.

I'm not sure that these calibration measurements are reliable. I would feel better if Steve can confirm them using our low accuracy method of moving the QPD by 1 mm and doing trigonometry.

A new type of plot is now available for use in the summary pages, based on EricQ's 2D histogram plots (elog 11210). I have added an example of this to the SandBox tab (https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20151119/sandbox/). The usage is straighforwad: the name to be used in config files is histogram2d; the first channel corresponds to the x-axis and the second one to the y-axis; the options accepted are the same as numpy.histogram2d and pyploy.pcolormesh (besides plot limits, titles, etc.). The default colormap is inferno_r and the shading is flat.

[Steve, ericq]

Brackets for the c1iscey IO chassis cards have been installed. Now, I can't unseat the cards by wiggling the ADC or DAC cable.