We want to startup the RT processes one by one on boot of FE machines.

Therefore /diskless/root/etc/rc.local on FB was modified as follows. The last sudo line was commented out.

for sys in $(/etc/rt.sh); do
    #sudo -u controls sh -c ". /opt/rtapps/rtapps-user-env.sh && /opt/rtcds/cal\
tech/c1/scripts/start${sys}"

    # NOTE: we need epics stuff AND iniChk.pl in PATH
    # we use -i here so that the .bashrc is sourced, which should also
    # source rtapps and rtcds user env (for epics and scripts paths)

    # commented out Nov 19, 2015, KA
    # see ELOG 11791 http://nodus.ligo.caltech.edu:8080/40m/11791
    # sudo -u controls -i /opt/rtcds/caltech/c1/scripts/start${sys}
done

I'm sorry. I will be careful about that. And I updated the plots in elog 11785.

 In this morning, Steve and I looked at the ETMY table and we found that the measurement you suggested might interfere with other optics or detectors because of space constraint. So, before doing this measurement, I roughly estimated the calibration factors for ETMY oplev by using the rough value of the arm length of the optical lever and the beam width of the light just before the QPD.

How I got the arm length and the beam width:

I measured the length of the optical path between ETMY and the QPD. Then I measured the beam width with an iris to screen the beam. To get the beam width from the decrease of the power of the beam detected by QPD, I used this formula: .

Then I got:   (arm length) = 1.8 +/-0.2 m,    w= 0.56 +/- 0.5 mm.

How I estimated the calibration factors from these:

The calibration factors (such as C1:SUS-ETMY_OL_PIT_CALIB; (real angle) / (normalized output of QPDXorY)) can be calculated with: . Then, I got

,

though the calibration factors, C1:SUS-ETMY_OL_PIT_CALIB C1:SUS-ETMY_OL_YAW_CALIB, right now are 26.0 and 31.0, respectively. (If I express this in the same way as elog 11785, 5.0 and 4.2 for ETMY_PIT and ETMY_YAW, respectively. they are consistent with yesterday's results.) 

I believe that the calibration factors I estimated today are not different from the true values by a factor of 2 or something, so this estimation indicates that the oplev calibration measurements I did yesterday are reliable, at least for the oplev for ETMY. 

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

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.

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.

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. 

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.   

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

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

Summary

The PMC servo was analysed. OLTF was measured and modeled by ZPK (Attachment 1). The error and actuator signals were calibrated in m/rtHz (Attachment 2)

Measurement methods

OLTF:

- The PMC servo board does not have dedicated summing/monitor points for the OLTF measurement. Moreover the PZT HV output voltage is monitored with 1/49.6 attenuation.
  Therefore we need a bit of consideration.

- The noise injection can be done at EXT DC.
- Quantity (A): Transfer function between HV OUT MON and MIX OUT MON with the injection.
  We can measure the transfer function between the HV OUT (virtual) and the MIX OUT. (HV OUT->MIX OUT). In reality, HV OUT is attenuated by factor of 49.6.
  i.e. A = (HV_OUT->MIX_OUT)*49.6
- Quantity (B): Transfer function between HV OUT MON and MIX OUT MON without the injection.
  This is related to the transfer function between the MIX OUT and HV OUT. In reality, HV OUT is attenuated. 
  i.e. B = 1/((MIX_OUT->HV_OUT)/49.6)

- What we want to know is HV_OUT->MIX_OUT->HV_OUT. i.e. A/B = (HV_OUT->MIX_OUT*49.6)*((MIX_OUT->HV_OUT)/49.6) = HV_OUT->MIX_OUT->HV_OUT

PSD:

- The MIX OUT and HV OUT spectra have been measured. The MIX OUT was calibrated with the calibration factor in the previous entry. This is the inloop stability estimation.
  From the calibrated MIX OUT and HV OUT, the free running stability of the cavity was estimated, by mutiplying with |1-OLTF| and |1-1/(1-OLTF)|, respectively, in order to recover
  the free running motion.

OLTF Modeling

Here is the model function for the open loop TF. The first line comes from the circuit diagram. The overall factor was determined by eye-fit.
The second and third lines are to reproduce the peak/notch feature at 12kHz. The fourth line is to reproduce 28kHz feature.
The LPF right after the mixer was analyzed by a circuit simulation (Circuit Lab). It can be approximated as 150kHz LPF as the second pole
seems to come at 1.5MHz.

The sixth line comes from the LPF formed by the output resistance and the PZT capacitance.

The seventh line is to reproduce the limit by the GBW product of OP27. As the gain is 101 in one of the stages,
it yields the pole freq of ~80kHz. But it is not enough to explain the phase delay at low frequency. Therefore this
discrepancy was compensated by empirical LPF at 30kHz.

function cmpOLTFc = PMC_OLTF_model(freqOLTFc)

cmpOLTFc = -7e5*pole1(freqOLTFc,0.162).*zero1(freqOLTFc,491)... % from the circuit diagram
    .*zero2(freqOLTFc,12.5e3,100)... % eye-fit
    .*pole2(freqOLTFc,12.2e3,6)... % eye-fit
    .*pole2(freqOLTFc,27.8e3, 12)... % eye-fit
    .*pole1(freqOLTFc,150e3)... % Mixer LPF estimated from Circuit Lab Simulation
    .*pole1(freqOLTFc,11.3)... % Output Impedance + PZT LPF
    .*pole1(freqOLTFc,8e6/101)... % GBW OP27
    .*pole1(freqOLTFc,3e4); % Unknown

end

Result

Attachment 1:

The nominal OLTF (Nov 17 data) shows the nominal UGF is ~1.7kHz and the phase margin of ~60deg.

The measured OLTF was compared with the modelled OLTF. In the end they show very sufficient agreement for further calibration.
The servo is about to be instable at 28kHz due to unknown series resonance. Later in the same day, the gain of the PMC loop had to be
reduced from 7dB to 3dB to mitigate servo oscillation. It is likely that this peak caused the oscillation. The notch frequency was measured
next day and it showed no sign of frequncy drift. That's good.

We still have some phase to reduce the high freq peaks by an LPF in order to increase the over all gain.

Attachment 2:

The red curve shows the residual floor displacement of 2~10x10^-15 m/rtHz. Below 4Hz there is a big peak. I suspect that I forgot to close
the PSL shutter and the IMC was locked during the measurement. Then does this mean the measured noise corresponds to the residual laser
freq noise or the PMC cavity displacement? This is interesting to see.

The estimated free running motion from the error and actuation signals agrees very well. This ensures the precision of the caibration in the precious entries.
 

The PMC PZT capacitance was measured.
- Turn off the HV supplies. Disconnect HV OUT cable.
- Make sure the cable is discharged.
- Measure the capacity at the cable end with an impedance meter.
=> The PMC PZT capacitance at the cable end was measured to be 222nF
Combined with the output impedance of 63.3kOhm, the LPF pole is at 11.3Hz

Summary

The PMC servo error (MIX OUT MON on the panel) and actuation (HV OUT MON) have been calibrated using the swept cavity.

Error signal slope in round-trip displacement: 2.93e9 +/- 0.05e9 [V/m]
HV OUT calibration (round-trip displacement): 5.36e-7 +/- 0.17e-7 [m/V]
PZT calibration (round-trip displacement): 10.8 +/- 0.3 [nm/V] => corresponds to ~2.5 fringes for 0~250V full range => not crazy

Measurement condition

The transmission level: 0.743V (on the PMC MEDM screen)
LO level: ~13dBm (after 3dB attenuation)
Phase setting: 5.7
PMC Servo gain: 7dB during the measurement (nominal 3dB)

Method

- Chose PMC actuation "BLANK" to disable servo
- Connect DS345 function generator to EXT DC input on the panel
- Monitor "MIX OUT MON" and "HV OUT MON" with an oscilloscope
- Inject a triangular wave with ~1Vpp@1 or 2Hz with appropriate offset to see the cavity resonance at about the middle of the sweep.
  The frequency of the sweep was decided considering the LPF corner freq formed by the output impedance and the capacitance of the PZT. (i.e. 11.3Hz, see next entry)

Result

- 4 sweep was taken (one 2Hz seep, three 1Hz sweep)
- The example of the sweep is shown in the attachment.
- The input triangular wave and the PDH slopes were fitted by linear lines.
- Spacing between the sideband zero crossing corresponds to twice of the modulation frequency (2x35.5MHz = 71MHz)
- The error signal slope was calibrated as V/MHz
- FSR of the PMC is given by google https://www.google.com/search?q=LIGO+pmc.m
  => Cavity round trip length is 0.4095m, FSR is 732.2MHz
- Convert frequency into round-trip displacement

- Convert HV OUT MON signal into displacement in the same way.
- The voltage applied to the PZT element is obtained considering the ratio of 49.6 between the actual HV and the HV OUT MON voltage.

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.  

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:

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. 

In preparation for the measurement of loss maps of arm cavities, I measured the relationship between:

the offset just after the demodulation of dithering loop (C1:ASS-YARM_ETM_PIT_L_DEMOD_I_OFFSET and C1:ASS-YARM_ETM_YAW_L_DEMOD_I_OFFSET)

and

the angle of ETMY measured with oplev (C1:SUS-ETMY_OL_PIT_INMONC1:SUS-ETMY_OL_PIT_INMON and C1:SUS-ETMY_OL_PIT_INMONC1:SUS-ETMY_OL_PIT_INMON)

while the dithering script is running. With the angle of ETMY, we can calculate the beam spot on the ETMY assuming that the beam spot on the ITMY is not changed thanks to the dithering. What we have to do is to check the calbration of oplev with another way to measure the angle, to see if the results are reliable or not.

I will report the results later.

I'm still analyzing the open loop TF data. Here I report some nominal settings of the PMC servo

Nominal phase setting: 5.7
Nominal gain setting: 3dB

After the tuning of the notch frequency, I thought I could increase the gain from 5dB to 9dB.
However, after several hours of the modification, the PMC servo gradually started to have oscillation.
This seemed to be mitigated by reducing the gain down to 4dB. This may mean that the notch freq got drifted away
due to themperature rise in the module. PA85 produce significant amount of heat.
(The notch frequency did not change. Just the 22kHz peak was causing the oscillation.)

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.

/opt/rtcds/caltech/c1/scripts/MC/AutoLockMC.csh  was modified last night.

1. Autolocker sometimes forget to turn off the MC2Tickle. I added the following lines to make sure to turn it off.

    echo autolockMCmain: MC locked, nothing for me to do >> ${lfnam}
    echo just in case turn off MC2 tickle >> ${lfnam}
    ${SCRIPTS}/MC/MC2tickleOFF

2. During the lock acquisition, Autolocker frequently stuck on a weak mode. So the following lines were added
so that the Autolocker toggles the servo switch while waiting for the lock.

    echo autolockMCmain: Mon=$mclockstatus, Waiting for MC to lock .. >> ${lfnam}
    # Turn off MC Servo Input button
    ezcawrite C1:IOO-MC_SW1 1
    date >> ${lfnam}
    sleep 0.5;
    # Turn on MC Servo Input button
    ezcawrite C1:IOO-MC_SW1 0
    sleep 0.5;

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. 

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.

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 result of the precise inspection for the PMC servo board for the 40m was done.

The record, including the photo of the board, can be found at https://dcc.ligo.org/D1400221-v2

- I found some ceramic 1uF caps are used in the signal path. They have been replaced with film caps by WIMA.

- In later measurements with the openloop TF measurement, it was found that the notch frequency (14.6kHz) was off from the a sharp PZT resonance at 12.2kHz.
I replaced the combined caps of 1220pF to 1742pF. This resulted nice agreement of the notch freq with the PZT resonant freq.

Past related elogs:

SRA-3MH mixer installed in 2009: http://nodus.ligo.caltech.edu:8080/40m/1502

R20 increased for more LO Mon gain: http://nodus.ligo.caltech.edu:8080/40m/10172

PMC follow up measurements have been done. The servo circuit was reviewed.

Now the PMC, IMC, X/Y arms are locked and aligned waiting for the IFO work although I still think something is moving (ITMX?)
as the FPMI fringe is quite fast.

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.

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

I think the IMC locking was somewhat improved. Still it is not solid as long time before.

Before the PMC fix (attachment 1)
After the PMC fix (attachment 2)

To do
- PMC loop inspection / phase check / spectral measurements
- PMC / IMC interaction
- IMC loop check
 

[Yutaro, Koji]

Recently "EPICS Freeze" is so frequent and the normal work on the MEDM screen became almost impossible.

As a part of the investigation, all 19 realtime processes were stopped in order to see any effect on the probem.

IN FACT, when the realtime processes were absent (still slow machines were running), frequency of EPICS Freeze
became much less. This might mean that the issue is related to the data collection of the slow channels. We need more investigation.

After the testing, all the processes were restored although it was not so straghtforward. Particularly, c1sus DAC had an error which was
not visible from the CDS Status screen. We noticed it as suspension damping was not effective on any of the vertex suspensions.
This has been solved by restarting c1x02 process.

[Yutaro, Koji]

We found that the PMC LO level was fluctuating in a strage way (it was not stable but had many clitches like an exponential decay), we suspected the infamous PMC LO level decay. In fact, in June 2014 when Rana recalibrated the LO level,  the number on the medm screen (C1:PSL-PMC_LO_CALC) was about 11dBm. However, today it was about 6dBm. So we decided to jump in to the 1X1 rack.

The LO and PC outputs of the PMC Crystal module (D980353) were measured to be 6.2dBm and 13.3dBm. Rana reported in ELOG 10160 that it was measured to be 11.5dBm. So apparently the LO level decayed. Unfortunately, there was no record of the PC output level. In any case, we decided to pull the module for the replacement of ERA-5 chips.

Once we opened the box we found that the board was covered by some greasy material. The ERA-5 chip on the LO chain seemed unreasonably brittle. It was destryed during desoldering. We also replaced the ERA-5 chip in the PC chain, just in case. The board was cleaned by the defluxing liquids.

Taking an advatage of this chance, the SMA  cables around the PMC were checked. By removing some of the heat shrinks, suspicious broken shields of the connectors were found. We provided additional solder to repair them.

After the repair, the LO and PC output levels became icreased to 17.0dBm(!) and 13.8dBm, respectively. (Victory)
This LO level is way too much compared to Rana's value. The MEDM LO power adj has little effect and the adj range was 16dBm~17dBm. Therefore we moved the slider to 10, which yields 16dBm out, and added a 5dB attenuator. The measured LO level after the attenuator was measured to be 11.2dBm.

Locking of the PMC was tried and immediately acquired the lock. However, we noticed that the nomoinal gain of 10dB cause the oscillation of the servo. As we already adjusted the LO level to recover the nominal value, we suspeced that the modulation depth could be larger than before. We left the gain at 0dB that doesn't cause the oscillation. It should be noted that the demodulation phase and the openloop gain were optimized. This should be done in the day time as soon as possible.

When the PMC LO repair was completed, the transmission of the PMC got decreased to 0.700V. The input alignment has been adjusted and the transmission level of 0.739V has been recovered.

The IMC lock stretch is not stable as before yet. Therefore, there would still be the issue somewhere else.

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

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.

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.

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. 

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

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

The ITMX OSEMS are oscillating.

I was gazing at the log file for Autolocker script (/opt/rtcds/caltech/c1/scripts/MC/logs/AutoLocker.log )
and found quite old time stamps. e.g.

Old : C1:IOO-MC_VCO_GAIN             1991-08-08 14:36:28.889032 -3
New : C1:IOO-MC_VCO_GAIN             1991-08-08 14:36:36.705699 18
Old : C1:PSL-FSS_FASTGAIN            1991-08-09 19:05:39.972376 14
New : C1:PSL-FSS_FASTGAIN            1991-08-09 19:05:44.939043 18

It was found that the date/time setting of some of the slow machines (at least c1psl and c1iool0) is not correct.
I could not figure out how to fix it.

Question: Is this anything critical?

Another thing: While I was in c1iool0 I frequently saw the message like

c1iool0 > 0xc461f0 (CA event): Events lost, discard count was 514

Is this anything related to EPICS Freeze?

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.

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

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

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. 

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. 

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.

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.

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

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.  

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

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.