40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 55 of 344 Not logged in
ID Date Author Type Category Subject
14574   Thu Apr 25 10:32:39 2019 JonUpdateVACVac interlocks updated

I slightly cleaned up Gautam's disabling of the UPS-predicated vac interlock and restarted the interlock service. This interlock is intended to protect the turbo pumps after a power outage, but it has proven disruptive to normal operations with too many false triggers. It will be reenabled once a new UPS has been installed. For now, as it has been since 2001, the vac pumps are unprotected against an extended power outage.

14573   Thu Apr 25 10:25:19 2019 gautamUpdateFrequency noise measurementHomodyne v Heterodyne

If I understand correctly, the Mach-Zehnder readout port power is only a function of the differential phase accumulated between the two interfering light beams. In the homodyne setup, this phase difference can come about because of either fiber length change OR laser frequency change. We cannot directly separate the two effects. Can you help me understand what advantage, if any, the heterodyne setup offers in this regard? Or is the point of going to heterodyne mainly for the feedback control, as there is presumably some easy way to combine the I and Q outputs of the heterodyne measurement to always produce an error signal that is a linear function of the differential phase, as opposed to the sin^2 in the free-running homodyne setup? What is the scheme for doing this operation in a high bandwidth way (i.e. what is supposed to happen to the demodulated outputs in Attachment #3 of your elog)? What is the advantage of the heterodyne scheme over applying temperature feedback to the NPRO with 0.5 Hz tracking bandwidth so that we always stay in the linear regime of the homodyne readout?

Also, what is the functional form of the curve labelled "Theory" in Attachment #2? How did you convert from voltage units in Attachment #1 to frequency units in Attachment #2? Does it make sense that you're apparently measuring laser frequency noise above 10 Hz? i.e. where do the "Dark Current Noise" and "Shot Noise" traces for the experiment lie relative to the blue curve in Attachment #2? Can you point to where the data is stored, and also add a photo of the setup?

14572   Thu Apr 25 10:13:15 2019 ChubUpdateGeneralAir Handler Out of Commission

The air handler on the roof of the 40M that supplies the electronics shop and computer room is out of operation until next week.  Adding insult to injury, there is a strong odor of Liquid Wrench oil (a creeping oil for loosening stuck bolts that has a solvent additive) in the building.  If you don't truly need to be in the 40M, you may want to wait until the environment is back to being cool and "unscented".  On a positive note, we should have a quieter environment soon!

14571   Thu Apr 25 03:32:25 2019 AnjaliUpdateFrequency noise measurementMZ interferometer ---> DAQ
• Attachment #1 shows the time domain output from this measurement. The contrast between the maximum and minimum is better in this case compared to the previous trials.
• We also tried to extract the frequency noise of the laser from this measurement. Attachment #2 shows the frequency noise spectrum. The experimental result is compared with the theoretical value of frequency noise. Above 10 Hz, the trend is comparable to the expected 1/f characteristics, but there are other peak also appearing. Similarly, below 10 Hz, the experimentally observed value is higher compared to the theory.
• One of the uncertainties in this result is because of the length fluctuation of the fiber. The phase fluctuation in the system could be either because of the frequency noise of the laser or because of the length fluctuation of the fiber.  So,one of the reasons for the discrepancy between the experimental result and theory could be because of  fiber length fluctuation. Also, there were no locking method been applied to operate the MZI in the linear range.
• The next step would be to do a heterodyne measurement. Attachment #3 shows the schematic for the heterodyne measurement. A free space AOM can be inserted in one of the arms to do the frequency shift. At the output of photodiode, a RF heterodyne method as shown in attachment #3 can be applied to separate the inphase and quadrature component. These components need to be saved with a deep memory system. Then the phase and thus the frequency noise can be extracted.
• Attachment #4 shows the noise budget prepared for the heterodyne setup. The length of the fiber considered is 60 m and the photodiode is PDA255. I also have to add the frequency noise of the RF driver and the intensity noise of the laser in the noise budget.
 Quote: Delay fiber was replaced with 5m (~30 nsec delay) The fringing of the MZ was way too large even with the free running NPRO (~3 fringes / sec) Since the V/Hz is proportional to the delay, I borrowed a 5m patch cable from Andrew/ATF lab, wrapped it around a spool, and hooked it up to the setup Much more satisfactory fringing rate (~1 wrap every 20 sec) was observed with no control to the NPRO MZ readout PDs hooked up to ALS channels To facilitate further quantitative study, I hooked up the two PDs monitoring the two ports of the MZ to the channels normally used for ALS X. ZHL3-A amps inputs were disconnected and were turned off. Then cables to their outputs were highjacked to pipe the DC PD signals to the 1Y3 rack Unfortunately there isn't a DQ-ed fast version of this data (would require a model restart of c1lsc which can be tricky), but we can already infer the low freq fringing rate from overnight EPICS data and also use short segments of 16k data downloaded "live" for the frequency noise measurement. Channels are C1:ALS-BEATX_FINE_I_IN1 and C1:ALS-BEATX_FINE_Q_IN1 for 16k data, and C1:ALS-BEATX_FINE_I_INMON and C1:ALS-BEATX_FINE_I_INMON for 16 Hz. At some point I'd like to reclaim this setup for ALS, but meantime, Anjali can work on characterization/noise budgeting. Since we have some CDS signals, we can even think of temperature control of the NPRO using pythonPID to keep the fringe in the linear regime for an extended period of time.
Attachment 1: Time_domain_output.pdf
Attachment 2: Frequency_noise.pdf
Attachment 3: schematic_heterodyne_setup.png
Attachment 4: Noise_budget_1_micron_in_Hz_per_rtHz.pdf
14570   Thu Apr 25 01:03:29 2019 gautamUpdatePSLMC trans is ~1000 cts (~7%) lower than usual

When dialing up the current, I went up to 2.01 A on the front panel display, which is what I remember it being. The label on the controller is from when the laser was still putting out 2W, and says the pump current should be 2.1 A. Anyhow, the MC transmission is ~7% lower now (14500 cts compared to the usual 15000-15500 cts), even after tweaking the PMC alignment to minimize PMC REFL. Potentially there is less power coming out of the NPRO. I will measure it at the window tomorrow with a power meter.

14569   Thu Apr 25 00:30:45 2019 gautamUpdateSUSETMY BR mode

We briefly talked about the bounce and roll modes of the SOS optic at the meeting today.

Attachment #1: BR modes for ETMY from my free-swinging run on 17 April. The LL coil has a very different behavior from the others.

Attachment #2: BR modes for ETMY from my free-swinging run on 18 April, which had a macroscopically different bias voltage for the PIT/YAW sliders. Here too, the LL coil has a very different behavior from the others.

Attachment #3: BR modes for ETMX from my free-swinging run on 27 Feb. There are many peaks in addition to the prominent ones visible here, compared to ITMY. The OSEM PD noise floor for UR and SIDE is mysteriously x2 lower than for the other 3 OSEMs???

In all three cases, a bounce mode around 16.4 Hz and a roll mode around 24.0 Hz are visible. The ratio between these is not sqrt(2), but is ~1.46, which is ~3% larger. But when I look at the database, I see that in the past, the bounce and roll modes were in fact at close to these frequencies.

In conclusion:

1. the evidence thus far says that ETMY has 5 resonant modes in the free-swinging data between 0.5 Hz and 25 Hz.
2. Either two modes are exactly degenerate, or there is a constraint in the system which removes 1 degree of freedom.
3. How likely is the latter? As any mechanical constraint that removes one degree of freedom would presumably also damp the Qs of the other modes more than what we are seeing.
4. Can some large piece of debris on the barrel change the PIT/YAW eigenvectors such that the eigenvalues became exactly degenerate?
5. Furthermore, the AC actuation vectors for PIT and YAW are not close to orthogonal, but are rotated ~45 degrees relative to each other.

Because of my negligence and rushing the closeout procedure, I don't have a great close-out picture of the magnet positions in the face OSEMs, the best I can find is Attachment #4. We tried to replicate the OSEM arrangement (orientation of leads from the OSEM body) from July 2018 as closely as possible.

I will investigate the side coil actuation strength tomorrow, but if anyone can think of more in-air tests we should do, please post your thoughts/poetry here.

Attachment 1: ETMY_sensorSpectra_BRmode.pdf
Attachment 2: ETMY_sensorSpectra_BRmode.pdf
Attachment 3: ETMX_sensorSpectra_BRmode.pdf
Attachment 4: IMG_5993.JPG
14568   Wed Apr 24 17:39:15 2019 YehonathanSummaryLoss MeasurementBasic analysis of loss measurement

Motivation

• Getting myself familiar with Python.
• Characterize statistical errors in the loss measurement.

Summary

​The precision of the measurement is excellent. We should move on to look for systematic errors.

In Detail

According to Johannes and Gautam (see T1700117_ReflectionLoss .pdf in Attachment 1), the loss in the cavity mirror is obtained by measuring the light reflected from the cavity when it is locked and when it is misaligned. From these two measurements and by using the known transmissions of the cavity mirrors, the roundtrip loss is extracted.

I write a Python notebook (AnalyzeLossData.ipynb in Attachment 1) extracting the raw data from the measurement file (data20190216.hdf5 in Attachment 1) analyzing the statistics of the measurement and its PSD.

Attachment 2 shows the raw data.

Attachment 3 shows the histogram of the measurement. It can be seen that the distribution is very close to being Gaussian.

The loss in the cavity pre roundtrip is measured to be 73.7+/-0.2 parts per million. The error is only due to the deviation in the PD measurement. Considering the uncertainty of the transmissions of the cavity mirrors should give a much bigger error.

Attachment 4 shows noise PSD of the PD readings. It can be seen that the noise spectrum is quite constant and there would be no big improvement by chopping the signal.

The situation might be different when the measurement is taken from the cavity lock PD where the signal is much weaker.

Attachment 1: LossMeasurementAnalysis.zip
Attachment 2: LossMeasurement_RawData.pdf
Attachment 3: LossMeasurement_Hist.pdf
Attachment 4: LossMeasurement_PSD.pdf
14567   Wed Apr 24 17:07:39 2019 gautamUpdateSUSc1susaux in-situ testing [and future of IFOtest]

[jon, gautam]

For the in-situ test, I decided that we will use the physical SRM to test the c1susaux Acromag replacement crate functionality for all 8 optics (PRM, BS, ITMX, ITMY, SRM, MC1, MC2, MC3). To facilitate this, I moved the backplane connector of the SRM SUS PD whitening board from the P1 connector to P2, per Koji's mods at ~5:10PM local time. Watchdog was shutdown, and the backplane connectors for the SRM coil driver board was also disconnected (this is interfaced now to the Acromag chassis).

I had to remove the backplane connector for the BS coil driver board in order to have access to the SRM backplane connector. Room in the back of these eurocrate boxes is tight in the existing config...

At ~6pm, I manually powered down c1susaux (as I did not know of any way to turn off the EPICS server run by the old VME crate in a software way). The point was to be able to easily interface with the MEDM screens. So the slow channels prefixed C1:SUS-* are now being served by the Supermicro called c1susaux2.

A critical wiring error was found. The channel mapping prepared by Johannes lists the watchdog enable BIO channels as "C1:SUS-<OPTIC>_<COIL>_ENABLE", which go to pins 23A-27A on the P1 connector, with returns on the corresponding C pins. However, we use the "TEST" inputs of the coil driver boards for sending in the FAST actuation signals. The correct BIO channels for switching this input is actually "C1:SUS-<OPTIC>_<COIL>_TEST", which go to pins 28A-32A on the P1 connector. For todays tests, I voted to fix this inside the Acromag crate for the SRM channels, and do our tests. Chub will unfortunately have to fix the remaining 7 optics, see Attachment #1 for the corrections required. I apportion 70% of the blame to Johannes for the wrong channel assignment, and accept 30% for not checking it myself.

The good news: the tests for the SRM channels all passed!

• Attachment #2: Output of Jon's testing code. My contribution is the colored logs courtesy of python's coloredlogs package, but this needs a bit more work - mainly the PASS mssage needs to be green. This test applies bias voltages to PIT/YAW, and looks for the response in the PDmon channels. It backs out the correct signs for the four PDs based on the PIT/YAW actuation matrix, and checks that the optic has moved "sufficiently" for the applied bias. You can also see that the PD signals move with consistent signs when PIT/YAW misalignment is applied. Additionally, the DC values of the PDMon channels reported by the Acromag system are close to what they were using the VME system. I propose calling the next iteration of IFOtest "Sherlock".
• Attachment #3: Confirmation (via spectra) that the SRM OSEM PD whitening can still be switched even after my move of the signals from the P1 connector to the P2 connector. I don't have an explanation right now for the shape of the SIDE coil spectrum.
• Attachment #4: Applied 100 cts (~ 100*10/2**15/2 ~ 15mV at the monitor point) offset at the bias input of the coil output filters on SRM (this is a fast channel). Looked for the response in the Coil Vmon channels (these are SLOW channels). The correct coil showed consistent response across all 5 channels.

Additionally, I confirmed that the watchdog tripped when the RMS OSEM PD voltage exceeded 200 counts. Ideally we'd have liked to test the stability of the EPICS server, but we have shut it down and brought the crate back out to the electronics bench for Chub to work on tomorrow.

I restarted the old VME c1susaux at 915pm local time as I didn't want to leave the watchdogs in an undefined state. Unsurprisingly, ITMY is stuck. Also, the BS (cable #22) and SRM (cable #40) coil drivers are physically disconnected at the front DB15 output because of the undefined backplane inputs. I also re-opened the PSL shutter.

Attachment 1: 2019-04-24_20-29.pdf
Attachment 2: Screenshot_from_2019-04-24_20-05-54.png
Attachment 3: SRM_OSEMPD_WHT_ACROMAG.pdf
Attachment 4: DCVmon.png
14566   Wed Apr 24 16:06:44 2019 gautamUpdatePSLInnolight NPRO shutoff

After discussing with Koji, I turned the NPRO back on again, at ~4PM local time. I first dialled the injection current down to 0A. Then powered the control unit state to "ON". Then I ramped up the power by turning the front panel dial. Lasing started at 0.5A, and I saw no abrupt swings in the power (I used PMC REFL as a monitor, there were some mode flashes which are the dips seen in the power, and the x-axis is in units of time not pump current). PMC was relocked and IMC autolocker locked the IMC almost immediately.

Now we wait and watch I guess.

Attachment 1: PMCrefl.png
14565   Wed Apr 24 11:22:59 2019 awadeBureaucracyEquipment loanBorrowed Zurich HF2LI Lock in Amplifer to QIL

Borrowed Zurich HF2LI Lock in Amplifer to QIL lab Wed Apr 24 11:25:11 2019.

14564   Tue Apr 23 19:31:45 2019 JonUpdateSUSWatchdog channels separated from autoBurt.req

For the new c1susaux, Gautam and I moved the watchdog channels from autoBurt.req to a new file named autoBurt_watchdogs.req. When the new modbus service starts, it loads the state contained in autoBurt.snap. We thought it best for the watchdogs to not be automatically enabled at this stage, but for an operator to manually have to do this. By moving the watchdog channels to a separate snap file, the entire SUS state can be loaded while leaving just the watchdogs disabled.

This same modification should be made to the ETMX and ETMY machines.

14563   Tue Apr 23 18:48:25 2019 JonUpdateSUSc1susaux bench testing completed

Today I tested the remaining Acromag channels and retested the non-functioning channels found yesterday, which Chub repaired this morning. We're still not quite ready for an in situ test. Here are the issues that remain.

Channel Issue
C1:SUS-MC2_URPDMon No response
C1:SUS-MC2_LRPDMon No response

I further diagnosed these channels by connecting a calibrated DC voltage source directly to the ADC terminals. The EPICS channels do sense this voltage, so the problem is isolated to the wiring between the ADC and DB37 feedthrough.

## Analog Output Channels

Channel Issue
C1:SUS-ITMX_ULBiasAdj No output signal
C1:SUS-ITMX_LLBiasAdj No output signal
C1:SUS-ITMX_URBiasAdj No output signal
C1:SUS-ITMX_LRBiasAdj No output signal
C1:SUS-ITMY_ULBiasAdj No output signal
C1:SUS-ITMY_LLBiasAdj No output signal
C1:SUS-ITMY_URBiasAdj No output signal
C1:SUS-ITMY_LRBiasAdj No output signal
C1:SUS-MC1_ULBiasAdj No output signal
C1:SUS-MC1_LLBiasAdj No output signal
C1:SUS-MC1_URBiasAdj No output signal
C1:SUS-MC1_LRBiasAdj No output signal

To further diagnose these channels, I connected a voltmeter directly to the DAC terminals and toggled each channel output. The DACs are outputting the correct voltage, so these problems are also isolated to the wiring between DAC and feedthrough.

In testing the DC bias channels, I did not check the sign of the output signal, but only that the output had the correct magnitude. As a result my bench test is insensitive to situations where either two degrees of freedom are crossed or there is a polarity reversal. However, my susPython scripting tests for exactly this, fetching and applying all the relevant signal gains between pitch/yaw input and coil bias output. It would be very time consuming to propagate all these gains by hand, so I've elected to wait for the automated in situ test.

## Digital Output Channels

Everything works.

14562   Mon Apr 22 22:43:15 2019 gautamUpdateSUSETMY sensor diagnosis

Here are the results from this test. The data for 17 April is with the DC bias for ETMY set to the nominal values (which gives good Y arm cavity alignment), while on 18 April, I changed the bias values until all four shadow sensors reported values that were at least 100 cts different from 17 April. The times are indicated in the plot titles in case anyone wants to pull the data (I'll point to the directory where they are downloaded and stored later).

There are 3 visible peaks. There was negligible shift in position (<5 mHz)  / change in Q of any of these with the applied Bias voltage. I didn't attempt to do any fitting as it was not possible to determine which peak corresponds to which DoF by looking at the complex TFs between coils (at each peak, different combinations of 3 OSEMs have the same phase, while the fourth has ~180 deg phase lead/lag). FTR, the wiki leads me to expect the following locations for the various DoFs, and I've included the closest peak in the current measured data in parentheses:

DoF Frequency [Hz]
POS 0.982 (0.947)
PIT 0.86 (0.886)
YAW 0.894 (0.886)
SIDE 1.016 (0.996)

However, this particular SOS was re-suspended in 2016, and this elog reports substantially different peak positions, in particular, for the YAW DoF (there were still 4). The Qs of the peaks from last week's measurements are in the range 250-350.

 Quote: Repeat the free-swinging ringdown with the ETMY bias voltage adjusted such that all the OSEM PDmons report ~100 um different position from the "nominal" position (i.e. when the Y arm cavity is aligned). Investigate whether the resulting eigenmode frequencies / Qs are radically different. I'm setting the optic free-swinging on my way out tonight. Optic kicked at 1239690286.
Attachment 1: ETMY_sensorSpectra_consolidated.pdf
14561   Mon Apr 22 21:33:17 2019 JonUpdateSUSBench testing of c1susaux replacement

Today I bench-tested most of the Acromag channels in the replacement c1susaux. I connected a DB37 breakout board to each chassis feedthrough connector in turn and tested channels using a multimeter and calibrated voltage source. Today I got through all the digital output channels and analog input channels. Still remaining are the analog output channels, which I will finish tomorrow.

There have been a few wiring issues found so far, which are noted below.

Channel Type Issue
C1:SUS2-PRM_URVMon Analog input No response
C1:SUS2-PRM_LRVMon Analog input No response
C1:SUS2-BS_UL_ENABLE Digital output Crossed with LR
C1:SUS2-BS_LL_ENABLE Digital output Crossed with UR
C1:SUS2-BS_UR_ENABLE Digital output Crossed with LL
C1:SUS2-BS_LR_ENABLE Digital output Crossed with UL
C1:SUS2-ITMY_SideVMon Analog input Polarity reversed
C1:SUS2-MC2_UR_ENABLE Digital output Crossed with LR
C1:SUS2-MC2_LR_ENABLE Digital output Crossed with UR

14560   Fri Apr 19 20:21:52 2019 gautamUpdatePSLInnolight NPRO shutoff

Happened again at ~730pm.

The NPRO diag channels don't really tell me what happened in a causal way, but the interlock channel seems suspicious. Why is the nominal value 0.04 V? From the manual, it looks like the TGUARD is an indication of deviations between the set temperature and actual diode laser temperature. Is it normal for it to be putting out 11V?

I'm not going to turn it on again right now while I ponder which of my hands I need to chop off.

 Quote: I'm restoring it now in the hope we can get some more info on what exactly happened if this is a recurring event.
Attachment 1: Screenshot_from_2019-04-19_20-27-04.png
14559   Fri Apr 19 19:22:15 2019 ranaUpdateSUSActuation matrix still not orthogonal

If thy left hand troubles thee

then let the mirror show the right

for if it troubles enough to cut it off

it would not offend thy sight

14558   Fri Apr 19 16:19:42 2019 gautamUpdateSUSActuation matrix still not orthogonal

I repeated the exercise from yesterday, this time driving the butterfly mode [+1 -1 -1 +1] and adding the tuned PIT and YAW vectors from yesterday to it to minimize appearance in the Oplev error signals.

The measured output matrix is $\begin{bmatrix} 0.98 & 0.64 & 1.5 & 1.037 \\ 0.96 & 1.12 & -0.5 & -0.998 \\ 1.04 & -1.12 & 0.5 & -1.002 \\ 1.02 & -0.64 & -1.5 & 0.963 \end{bmatrix}$, where rows are the coils in the order [UL,UR,LL,LR] and columns are the DOFs in the order [POS,PIT,YAW,Butterfly]. The conclusions from my previous elog still hold though - the orthogonality between PIT and YAW is poor, so this output matrix cannot be realized by a simple gain scaling of the coil output gains. The "adjustment matrix", i.e. the 4x4 matrix that we must multiply the "ideal" output matrix by to get the measured output matrix has a condition number of 134 (1 is a good condition number, signifies closeness to the identity matrix).

 Quote: let us have 3 by 4, nevermore so that the number of columns is no less and no more than the number of rows so that forevermore we live as 4 by 4
14557   Fri Apr 19 15:13:38 2019 ranaUpdateSUSNo consistent solution for output matrix

let us have 3 by 4, nevermore

so that the number of columns is no less

and no more

than the number of rows

so that forevermore we live as 4 by 4

 Quote: I'm struggling to think
14556   Fri Apr 19 14:06:36 2019 gautamUpdatePSLInnolight NPRO shutoff

When I got back from lunch just now, I noticed that the PMC TRANS and REFL cameras were showing no spots. I went onto the PSL table, and saw that the NPRO was in fact turned off. I turned it back on.

The laser was definitely ON when I left for lunch around 130pm, and this happend around 140pm. Anjali says no one was in the lab in between. None of the FEs are dead, suggesting there wasn't a labwide power outage, and the EX and EY NPROs were not affected. I had pulled out the diagnostics connector logged by Acromag, I'm restoring it now in the hope we can get some more info on what exactly happened if this is a recurring event. So FSS_RMTEMP isn't working from now on. Sooner we get the PSL Acromag crate together, the better...

Attachment 1: Screenshot_from_2019-04-19_14-06-11.png
14555   Fri Apr 19 12:06:31 2019 awadeBureaucracyElectronicsBorrowed Busby Box May 19th 2019

I've borrowed the Busby Box for a day or so.  Location: QIL lab at Bridge West.

Edit  Sat Apr 20 21:16:46 2019 (awade): returned.

14554   Fri Apr 19 11:36:23 2019 gautamUpdateSUSNo consistent solution for output matrix

Ther isn't a consistent set of OSEM coil gains that explains the best actuation vectors we determined yesterday. Here are the explicit matrices:

1. POS (tuned to minimize excitation at ~13.5 Hz in the Oplev PIT and YAW error signals): $\begin{bmatrix} \text{UL} & \text{UR} & \text{LL} & \text{LR} \end{bmatrix}\begin{bmatrix} 0.98 \\ 0.96 \\ 1.04 \\ 1.02 \\ \end{bmatrix}$
2. PIT (tuned to minimize cross coupled peak in the Oplev YAW error signal at ~10.5 Hz): ​$\begin{bmatrix} \text{UL} & \text{UR} & \text{LL} & \text{LR} \end{bmatrix}\begin{bmatrix} 0.64 \\ 1.12 \\ -1.12 \\ -0.64 \\ \end{bmatrix}$
3. YAW (tuned to minimize cross coupled peak in the Oplev PIT error signal at ~13.5 Hz): $\begin{bmatrix} \text{UL} & \text{UR} & \text{LL} & \text{LR} \end{bmatrix}\begin{bmatrix} 1.5 \\ -0.5 \\ 0.5 \\ -1.5 \\ \end{bmatrix}$

There isn't a solution to the matrix equation $\begin{bmatrix} \alpha_1 & \alpha_2 & \alpha_3 & \alpha_4 \end{bmatrix} \begin{bmatrix} 1 & 1 & 1 \\ 1 & 1 & -1 \\ 1 & -1 & 1 \\ 1 & -1 & -1 \end{bmatrix} =\begin{bmatrix} 0.98 & 0.64 & 1.5 \\ 0.96 & 1.12 & -0.5 \\ 1.04 & -1.12 & 0.5 \\ 1.02 & -0.64 & -1.5 \end{bmatrix}$, i.e. we cannot simply redistribute the actuation vectors we found as gains to the coils and preserve the naive actuation matrix. What this means is that in the OSEM coil basis, the actuation eigenvectors aren't the naive ones we would think for PIT and YAW and POS. Instead, we can put these custom eigenvectors into the output matrix, but I'm struggling to think of what the physical implication is. I.e. what does it mean for the actuation vectors for PIT, YAW and POS to not only be scaled, but also non-orthogonal (but still linearly independent) at ~10 Hz, which is well above the resonant frequencies of the pendulum? The PIT and YAW eigenvectors are the least orthogonal, with the angle between them ~40 degrees rather than the expected 90 degrees.

 Quote: So we now have matrices that minimize the cross coupling between these DoFs - the idea is to back out the actuation coefficients for the 4 OSEM coils that gives us the most diagonal actuation, at least at AC.
14553   Fri Apr 19 09:42:18 2019 KojiBureaucracyGeneralItem borrowing (40m->OMC)

Apr 16, 2019
Borrowed two laser goggles from the 40m. (Returned Apr 29, 2019)
Apr 19, 2019
Borrowed from the 40m:
- Universal camera mount
- 50mm CCD lens
- zoom CCD lens (Returned Apr 29, 2019)
- Olympus SP-570UZ (Returned Apr 29, 2019)
- Special Olympus USB Cable (Returned Apr 29, 2019)

14552   Thu Apr 18 23:10:12 2019 gautamUpdateLoss MeasurementX arm misaligned

Yehonathan wanted to take some measurements for loss determination. I misaligned the X arm completely and we installed a PD on the AS table so there is no light reaching the AS55 and AS110 PDs. Yehonathan will post the detailed elog.

14551   Thu Apr 18 22:35:23 2019 gautamUpdateSUSETMY actuator diagnosis

[rana, gautam]

Rana did a checkout of my story about oddness of the ETMY suspension. Today, we focused on the actuators - the goal was to find the correct coefficients on the 4 face coils that would result in diagonal actuation (i.e. if we actuate on PIT, it only truly moves the PIT DoF, as witnessed by the Oplev, and so on for the other DoFs). Here are the details:

1. Ramp times for filter modules:
• All the filter modules in the output matrix did not have ramp times set.
• We used python, cdsutils and ezca to script the writing of a 3 second ramp to all the elements of the 5x6 output matrix.
• The script lives at /opt/rtcds/caltech/c1/scripts/cds/addRampTimes.py, can be used to implement similar scripts to initialize large numbers of channels (limiters, ramp times etc).
2. Bounce mode checkout:
• ​The motivation here was to check if there is anomalously large coupling of the bounce mode to any of the other DoFs for ETMY relative to the other optics
• The ITMs have a different (~15.9 Hz) bounce mode frequency compared to the ETMs (~16.2 Hz).
• I hypothesize that this is because the ETMs were re-suspended in 2016 using new suspension wire.
• We should check out specs of the wires, look for either thickness differences or alloying composition variation (Steve has already documented some of this in the elog linked above). Possibly also check out the bounce mode for a 250g load on the table top.
3. Step responses for PIT and YAW
• With the Oplevs disabled (but other local damping loops engaged), we applied a step of 100 DAC counts to the PIT and YAW DoFs from the realtime system (one at a time)
• We saw significant cross-coupling of the YAW step coupling to PIT, at the level of 50%.
4. OSEM coil coefficient balancing
• I had done this a couple of months ago looking at the DC gain of the 1/f^2 pendulum response.
• Rana suggested an alternate methodology
• we used the lock-in amplifier infrastructure on the SUS screens to drive a sine wave
• Frequencies were chosen to be ~10.5 Hz and ~13.5 Hz, to be outside the Oplev loop bandwidth
• Tests were done with the Oplev loop engaged. The Oplev error signal was used as a diagnostic to investigate the PIT/YAW cross coupling.
• In the initial tests, we saw coupling at the 20% level. If the Oplev head is rotated by 0.05 rad relative to the "true" horizontal-vertical coordinate system, we'd expect 5% cross coupling. So this was already a red flag (i.e. it is hard to believe that Oplev QPD shenanigans are responsible for our observations). We decided to re-diagonalize the actuation.
• The output matrix elements for the lock-in-amplifier oscillator signals were adjusted by adding some amount of YAW to the PIT elements (script lives at /opt/rtcds/caltech/c1/scripts/SUS/stepOutMat.py), and vice versa, and we tried to reduce the height of the cross-coupled peaks (viewed on DTT using exponential weighting, 4 avgs, 0.1 Hz BW - note that the DTT cursor menu has a peak find option!). DTT Template saved at /users/Templates/SUS/ETMY-actDiag.xml
• This worked really well for minimizing PIT response while driving YAW, not as well for minimizing YAW in PIT.
• Next, we added some YAW to a POS drive to minimize the any signal at this drive frequency in the Oplev YAW error signal. Once that was done, we minimized the peak in the Oplev PIT error signal by adding some amount of PIT actuation.
• So we now have matrices that minimize the cross coupling between these DoFs - the idea is to back out the actuation coefficients for the 4 OSEM coils that gives us the most diagonal actuation, at least at AC.
5. Next steps:
• All of our tests tonight were at AC - once the coil balancing has been done at AC, we have to check the cross coupling at DC. If everything is working correctly, the response should also be fairly well decoupled at DC, but if not, we have to come up with a hypothesis as to why the AC and DC responses are different.
• Can we gain any additional info from driving the pringle mode and minimizing it in the Oplev error signals? Or is the problem overconstrained?
• After the output matrix diagonalization is done, drive the optic in POS, PIT and YAW, and construct the input matrix this way (i.e. transfer function), as an alternative to the usual free-swinging ringdown method. Look at what kind of an input matrix we get.
• Repeat the free-swinging ringdown with the ETMY bias voltage adjusted such that all the OSEM PDmons report ~100 um different position from the "nominal" position (i.e. when the Y arm cavity is aligned). Investigate whether the resulting eigenmode frequencies / Qs are radically different. I'm setting the optic free-swinging on my way out tonight. Optic kicked at 1239690286.
14550   Wed Apr 17 18:12:06 2019 gautamUpdateVACVac interlock tripped again

After getting the go ahead from Chub and Jon, I restored the Vacuum state to "Vacuum normal", see Attachment #1. Steps:

1. Interlock code modifications
• Backed up /opt/target/python/interlocks/interlock_conditions.yaml to /opt/target/python/interlocks/interlock_conditions_UPS.yaml
• The "power_loss" condition was removed for every valve and pump inside /opt/target/python/interlocks/interlock_conditions.yaml
• The interlock service was restarted using sudo systemctl restart interlock.service
• Looking at the status of the service, I saw that it was dying ~ every 1 second.
• Traced this down to a problem in/opt/target/python/interlocks/interlock_conditions.yaml  when the "pump_managers" are initialized - the way this is coded up, doesn't play nice if there are no conditions specified in the yaml file. For now, I just commented this part out. The git diff  below:
2. Restoring vacuum normal:
• Spun up TP1, TP2 and TP3
• Opened up foreline of TP1 to TP2, and then opened main volume to TP1
• Opened up annulus foreline to TP3, and then opened the individual annular volumes to TP3.
controls@c1vac:/opt/target/python/interlocksgit diff interlock.py diff --git a/python/interlocks/interlock.py b/python/interlocks/interlock.py index 28d3366..46a39fc 100755 --- a/python/interlocks/interlock.py +++ b/python/interlocks/interlock.py @@ -52,8 +52,8 @@ class Interlock(object): self.pumps = [] for pump in interlocks['pumps']: pm = PumpManager(pump['name']) - for condition in pump['conditions']: - pm.register_condition(*condition) + #for condition in pump['conditions']: + # pm.register_condition(*condition) self.pumps.append(pm) So far the pressure is coming down smoothly, see Attachment #2. I'll keep an eye on it. PSL shutter was opened at 645pm local time. IMC locked almost immediately. Update 11pm: The pressure has reached 8.5e-6 torr without hiccup. Attachment 1: Screenshot_from_2019-04-17_18-11-45.png Attachment 2: Screenshot_from_2019-04-17_18-21-30.png 14549 Wed Apr 17 11:01:49 2019 gautamUpdateALSLarge 2kHz peak (and harmonics) in ALS X no more EX green stayed locked to XARM length overnight without a problem. The spectrogram doesn't show any alarming time varying features around 2 kHz (or at any other frequency). Attachment 1: EX_PDH_specGram.pdf 14548 Wed Apr 17 00:50:17 2019 gautamUpdateALSLarge 2kHz peak (and harmonics) in ALS X no more I looked into this issue today. Initially, my thinking was that I'd somehow caused clipping in the beampath somewhere which was causing this 2kHz excitation. However, on looking at the spectrum of the in-loop error signal today (Attachment #1), I found no evidence of the peak anymore! Since the vacuum system is in a non-nominal state, and also because my IR ALS beat setup has been hijacked for the MZ interferometer, I don't have an ALS spectrum, but the next step is to try single arm locking using the ALS error signal. To investigate whether the 2kHz peak is a time-dependent feature, I left the EX green locked to the arm (with the SLOW temperature offloading servo ON), hopefully it stays locked overnight...  Quote: These weren't present last week. The peaks are present in the EX PDH error monitor signal, and so are presumably connected with the green locking system. My goal tonight was to see if the arm length control could be done using the ALS error signal as opposed to POX, but I was not successful. Attachment 1: EX_PDHnoise.pdf 14547 Wed Apr 17 00:43:38 2019 gautamUpdateFrequency noise measurementMZ interferometer ---> DAQ 1. Delay fiber was replaced with 5m (~30 nsec delay) • The fringing of the MZ was way too large even with the free running NPRO (~3 fringes / sec) • Since the V/Hz is proportional to the delay, I borrowed a 5m patch cable from Andrew/ATF lab, wrapped it around a spool, and hooked it up to the setup • Much more satisfactory fringing rate (~1 wrap every 20 sec) was observed with no control to the NPRO 2. MZ readout PDs hooked up to ALS channels • To facilitate further quantitative study, I hooked up the two PDs monitoring the two ports of the MZ to the channels normally used for ALS X. • ZHL3-A amps inputs were disconnected and were turned off. Then cables to their outputs were highjacked to pipe the DC PD signals to the 1Y3 rack • Unfortunately there isn't a DQ-ed fast version of this data (would require a model restart of c1lsc which can be tricky), but we can already infer the low freq fringing rate from overnight EPICS data and also use short segments of 16k data downloaded "live" for the frequency noise measurement. • Channels are C1:ALS-BEATX_FINE_I_IN1 and C1:ALS-BEATX_FINE_Q_IN1 for 16k data, and C1:ALS-BEATX_FINE_I_INMON and C1:ALS-BEATX_FINE_I_INMON for 16 Hz. At some point I'd like to reclaim this setup for ALS, but meantime, Anjali can work on characterization/noise budgeting. Since we have some CDS signals, we can even think of temperature control of the NPRO using pythonPID to keep the fringe in the linear regime for an extended period of time. 14546 Tue Apr 16 22:06:51 2019 gautamUpdateVACVac interlock tripped again This happened again, about 30,000 seconds (~2:06pm local time according to the logfile) ago. The cited error was the same - 2019-04-16 14:06:05,538 - C1:Vac-error_status => VA6 closed. AC power loss. Hard to believe there was any real power loss, nothing else in the lab seems to have been affected so I am inclined to suspect a buggy UPS communication channel. The PSL shutter was not closed - I believe the condition is for P1a to exceed 3 mtorr (it is at 1 mtorr right now), but perhaps this should be modified to close the PSL shutter in the event of any interlock tripping. Also, probably not a bad idea to send an email alert to the lab mailing list in the event of a vac interlock failure. For tonight, I only plan to work with the EX ALS system anyways so I'm closing the PSL shutter, I'll work with Chub to restore the vacuum if he deems it okay tomorrow. Attachment 1: Screenshot_from_2019-04-16_22-05-47.png Attachment 2: Screenshot_from_2019-04-16_22-06-02.png 14545 Mon Apr 15 22:55:34 2019 gautamFrogsThermal CompensationLab thermostat adjusted It is feeling cold in the office area. According to the digital wall clock near the coffee machine, it is 19C. Rana bumped the thermostat setpoint up by 2F (from 75F to 77F). We need to setup long-term monitoring. 14544 Mon Apr 15 22:39:10 2019 gautamUpdateFrequency noise measurementAlternate setup with PSL pickoff [anjali, gautam] just main points, anajli is going to fill out the details. To rule out mode-matching as the reason for non-ideal output from the MZ, I suggested using the setup I have on the NW side of the PSL enclosure for the measurement. This uses two identical fiber collimators, and the distance between collimator and recombination BS is approximately the same, so the spatial modes should be pretty well matched. The spooled fiber we found was not suitable for use as it had a wide key connector and I couldn't find any wide-key FC/PC to narrow-key FC/APC adaptors. So we decided to give the fiber going to the Y end and back (~90m estimated length) a shot. We connected the two fibers at the EY table using a fiber mating sleeve (so the fiber usually bringing the IR pickoff from EY to the PSL table was disconnected from its collimator). In summary, we cannot explain why the contrast of the MZ is <5%. Spatial mode-overlap is definitely not to blame. Power asymmetry in the two arms of the MZ is one possible explanation, could also be unstable polarization, even though we think the entire fiber chain is PM. Anjali is investigating. We saw today that the Thorlabs PM beam splitters (borrowed from Andrew until our AFW components arrive) do not treat the two special axes (fast and slow) of the fiber on equal footing. When we coupled light into the fast axis, we saw huge asymmetry between the two split arms of the beamsplitter (3:1 ratio in power instead of the expected 1:1 for a 50/50 BS). Looking at the patch cord with an IR viewer, we also saw light leaking through the core along it. Turns out this part is meant to be used with light coupled to the slow axis only. 14543 Mon Apr 15 18:29:07 2019 ranaSummaryComputersnew laptop setup: ASIA - yum issues had trouble using YUM to update. This turned out to be a config problem with our Martian router, not the new laptop. Since I've changed the WiFi pwd awhile ago for the martian access for the CDS laptops, you'll have to enter that in order to use the laptops. turned out to be some Access Control nonsense inside of the router. Even loggin in as admin with a cable gave some of the fields the greyed out color (had to hover over the link and then type the URL directly in the browser window). ASIA is now able to connect and use YUM + usual connections. Gautam and I have also moved the router a little to get easier view of its LED lights and not blockk its WiFi signal with the cable tray. We'll get a little shelf so that we can mount it ~1 foot off of the wall. still, this seems like a bad laptop choice: the Lenovo Ideapad 330 will not have its touchpad supported by SL7 without compiling a new version of the kernel 14542 Mon Apr 15 18:13:23 2019 ranaUpdateComputer Scripts / ProgramsAutomated suspension testing with susPython if this gonna be general for everybody, maybe it oughta be called IFOtest (like the last incarnation that was tried in Livingston) ? : ### In anticipation of needing to test hundreds of suspension signals after the c1susaux upgrade, I've started developing a Python package to automate these tests: susPython then the SUS tests could just be some smaller set of measurements. Using the same code base, but different params. 14541 Mon Apr 15 10:20:44 2019 gautamUpdateOptical LeversBS Oplev PIT was oscillating The AS spot on the camera was oscillating at ~3 Hz. Looking at the Oplevs, the culprit was the BS PIT DoF. Started about 12 hours ago, not sure what triggered it. I disabled Oplev damping, and waited for the angular motion to settle down a bit, and then re-enabled the servo - damps fine now... Attachment 1: BS_OL_oscillating.png 14540 Fri Apr 12 01:22:27 2019 AnjaliUpdateFrequency noise measurementFrequency noise measurement of 1 micron source The alignement was disturbed after the replcement of the beam splitter. We tried to get the alignment back . But we are not succeeded yet in getting good interfernce pattern. This is mainly because of poor mode matching of two beams. We will also try with the spooled fiber. Quote: • The experimental setup is then modified as shown in attachment #3. The thick beam spliiter is replaced with a thinner one. The mount is also changed such that the transmitted beam can be now coupled to an other photodiode (earlier the transmitted light was blocked by the mount). One more photodiode (PDA55) is introduced .So now the two photodiodes in the setup are PDA520 and PDA 55. 14539 Thu Apr 11 17:30:45 2019 JonUpdateSUSAutomated suspension testing with susPython ### Summary In anticipation of needing to test hundreds of suspension signals after the c1susaux upgrade, I've started developing a Python package to automate these tests: susPython https://git.ligo.org/40m/suspython The core of this package is not any particular test, but a general framework within which any scripted test can be "nested." Built into this framework is extensive signal trapping and exception handling, allowing actuation tests to be performed safely. Namely it protects against crashes of the test scripts that would otherwise leave the suspensions in an arbitrary state (e.g., might destroy alignment). ### Usage The package is designed to be used as a standalone from the command line. From within the root directory, it is executed with a single positional argument specifying the suspension to test:  python -m suspython ITMY

Currently the package requires Python 2 due to its dependence on the cdsutils package, which does not yet exist for Python 3.

### Scripted Tests

So far I've implemented a cross-consistency test between the DC-bias outputs to the coils and the shadow sensor readbacks. The suspension is actuated in pitch, then in yaw, and the changes in PDMon signals are measured. The expected sign of the change in each coil's PDMon is inferred from the output filter matrix coefficients. I believe this test is sensitive to two types of signal-routing errors: no change in PDMon response (actuator is not connected), incorrect sign in either pitch or yaw response, or in both (two actuators are cross-wired).

The next test I plan to implement is a test of the slow system using the fast system. My idea is to inject a 3-8 Hz excitation into the coil output filter modules (either bandlimited noise or a sine wave), with all coil outputs initially disabled. One coil at a time will be enabled and the change in all VMon signals monitored, to verify the correct coil readback senses the excitation. In this way, a signal injected from the independent and unchanged fast system provides an absolute reference for the slow system.

I'm also aware of ideas for more advanced tests, which go beyond testing the basic signal routing. These too can be added over time within the susPython framework.

14538   Thu Apr 11 12:57:48 2019 JonUpdateSUSStarting some scripted SUS tests on ITMY

Testing is finished.

 Quote: Will advise when I'm finished, will be by 1 pm for ALS work to begin.
14537   Thu Apr 11 12:21:01 2019 not KojiUpdatePSLPSL fan is noisy

I could probably install the new fan if we have one.  Can you do without the laser for a while?

 Quote: This thread: ELOG 10295 My interpretation of these ELOGs is that we did not have the replacement, and then I brought unknown fan from WB. At the same time, Steve ordered replacement fans which we found in the blue tower yesterday. The next action is to replace the internal fan, I believe.
14536   Thu Apr 11 12:04:43 2019 JonUpdateSUSStarting some scripted SUS tests on ITMY

Will advise when I'm finished, will be by 1 pm for ALS work to begin.

14535   Thu Apr 11 11:42:10 2019 KojiUpdatePSLPSL fan is noisy

This thread: ELOG 10295

My interpretation of these ELOGs is that we did not have the replacement, and then I brought unknown fan from WB. At the same time, Steve ordered replacement fans which we found in the blue tower yesterday.
The next action is to replace the internal fan, I believe.

14534   Thu Apr 11 09:05:06 2019 AnjaliUpdateIOOSpooled fiber
• Attchment #1,2,3 and 4 shows the results with frequency modulation of 32 Hz, 140 Hz , 300 Hz and without frequency modulation. I am trying to understand these results better.
• A lot of fringing is there even when no modulation is applied. We hope to improve this by spooling the fiber and then encasing it in a box.
• As mentioned by Gautam, we have got a 50 m spooled fiber. Attachment #5 shows the photo of the same
 Quote: Steve had showed me some stock of long fibers a while back - they are from Oz Optics, and are 50m long, and are already spooled - so barring objections, we will try the MZ setup with the spooled fiber and see if there is any improvement in the fringing rate of the MZ. Then we can evaluate what additional stabilization of the fiber length is required. Anjali will upload a photo of the spooled fiber.
Attachment 1: Frequecy_modulation_32_Hz.pdf
Attachment 2: Frequecy_modulation_140_Hz.pdf
Attachment 3: Frequecy_modulation_300_Hz.pdf
Attachment 4: Without_modulation.pdf
Attachment 5: New_fiber_spool.JPG
14533   Thu Apr 11 01:10:05 2019 gautamUpdateALSLarge 2kHz peak (and harmonics) in ALS X

These weren't present last week. The peaks are present in the EX PDH error monitor signal, and so are presumably connected with the green locking system. My goal tonight was to see if the arm length control could be done using the ALS error signal as opposed to POX, but I was not successful.

Attachment 1: EX_PDH_2kNoise.pdf
14532   Wed Apr 10 23:37:59 2019 gautamUpdatePSLPSL fan is noisy

Attached is my phone recording of what it sounds like right now in the PSL enclosure - not good for frequency noise measurement! The culprit is the little PC fan that is hacked onto the back of the Innolight controller.

1. Is this necessary?
2. If so, is it sufficient to replace this fan with one from our stock?
Attachment 1: New_Recording.m4a
14531   Wed Apr 10 22:59:22 2019 gautamUpdateIOOSpooled fiber

Steve had showed me some stock of long fibers a while back - they are from Oz Optics, and are 50m long, and are already spooled - so barring objections, we will try the MZ setup with the spooled fiber and see if there is any improvement in the fringing rate of the MZ. Then we can evaluate what additional stabilization of the fiber length is required. Anjali will upload a photo of the spooled fiber.

14530   Wed Apr 10 16:58:54 2019 ranaUpdateIOOfiber MZ for NPRO freq noise measurements

Can we get some panel mount FC/APC connectors and put them on a box?   Then we could have the whole setup inside of a box that is filled with foam and sits outside the PSL hut.

14529   Wed Apr 10 00:33:09 2019 AnjaliUpdateFrequency noise measurementFrequency noise measurement of 1 micron source
• Attachement #1 shows the input (ch4-green) modulation frequency and the photodiode output (ch1-yellow) when the modulation frequency is about 100 Hz
• Attachement #2 shows the input (ch4-green) modulation frequency and the photodiode output (ch1-yellow) when the modulation frequency is about 30 Hz
• The output frequency is varying in accordance with variation in modulation frequency. It is observed that, for a given modulation frequency also, the output frequency is fluctuating. There could be multiple reasons for this behaviour. One of the main reasons is the frequency noise of the laser itself. Also, there could be acoustic noise coupled to the system (eg, by change in length of the fiber).
• The experimental setup is then modified as shown in attachment #3. The thick beam spliiter is replaced with a thinner one. The mount is also changed such that the transmitted beam can be now coupled to an other photodiode (earlier  the transmitted light was blocked by the mount). One more photodiode (PDA55) is introduced .So now the two photodiodes in the setup are PDA520 and PDA 55.
• We then applied frequency modulation on the input laser and observed the output of the two photodiodes. But we didn't get the results as we expected and observed earlier (shown in attachment #1 &2). Looks like, the problem is poor mode matching between the two beams.
 Quote: The alignment of the output beam from the delayed path of MZI to the photodetector was disturbed when we did the polarisation characterisation yesterday. So, today we tried to align the output beam from the delayed path of MZI to the detector . We then observed the beat output from the detector on oscilloscope.We initialy observed a dc shift . We then applied a frequency modulation on the input laser and observed the output on oscilloscope. We expected to see variation in output frequency in accordance with variation of input frequency modulation. But we didnt observe this and we were not really getting the interference pattern.  We tried to make the alignment better. With a better alignment, we could see the interference pattern. We also observed that the output frequency was varying in accordance with variation in the input frequency modulation. We would expect a better result with proper mode matching of the two beams on the photodetector.
Attachment 1: Modulation_frequency_100Hz.jpg
Attachment 2: Modulation_frequency_30Hz.jpg
Attachment 3: Modified_setup.JPG
14528   Tue Apr 9 19:07:12 2019 gautamUpdateALSIR ALS noise budget

Updated the noise budget to include the unsuppressed frequency noise from the EX laser. It does not explain the noise between 10-100 Hz, although the 1-3 Hz noise is close.

Actually, I think the curve that should go on the budget is when the X arm length is locked to the PSL frequency, whereas this is when the X arm is just locally damped. I will update it later tonight.

Update 1010pm: I've uploaded the relevant plot as Attachment #2. Predictably, the unsuppressed frequency noise of the EX laser is now higher, because the MC length is a noisier frequency reference than the arm cavity. But still it is a factor of 10 below the measured ALS noise.

 Quote: Next noises to budget: In-loop X arm length noise In-lop EX laser frequency noise
Attachment 1: ALS_noiseBudget.pdf
Attachment 2: ALS_noiseBudget.pdf
14527   Tue Apr 9 18:44:00 2019 gautamUpdateALSEX Green PDH discriminant measurement

I decided to use the more direct method, of disconnecting feedback to the EX laser PZT, and then looking at the cavity flashes.

Attachment #1 shows the cavity swinging through two resonances (data collected via oscilloscope). Traces are for the demodulated PDH error signal (top) and the direct photodiode signal (bottom). The traces don't look very clean - I wonder if some saturation / slew rate effects are at play, because we are operating the PD in the 30 dB setting, where the bandwidth of the PD is spec-ed as 260 kHz, whereas the dominant frequency component of the light on the PD is 430 kHz.

The asymmetric horns corresponding to the sideband resonances were also puzzling. Doing the modeling, Attachment #2, I think this is due to the fact that the demodulation phase is poorly set. The PDH modulation frequency is only ~5x the cavity linewidth, so both the real and imaginary parts of the cavity reflectivity contribute to the error signal. If this calculation is correct, we can benefit (i.e. get a larger PDH discriminant) by changing the demod phase by 60 degrees. However, for 230 kHz, it is impractical to do this by just increasing cable length between the function generator and mixer.

Anyway, assuming that we are at the phi=30 degree situation (since the measurement shows all 3 horns going through roughly the same voltage swing), the PDH discriminant is ~40 uV/Hz. In lock, I estimate that there is ~60 uW of light incident on the PDH reflection photodiode. Using the PD response of 0.2 A/W, transimpedance of 47.5 kohm, and mixer conversion loss of 6dB, the shot-noise limited sensitivity is 0.5 mHz/rtHz. The photodiode dark noise contribution is a little lower - estimated to be 0.2 mHz/rtHz. The loop does not have enough gain to reach these levels.

 Quote: PDH discriminant (40 uV/Hz, see this elog)
Attachment 1: cavityFlashes.pdf
Attachment 2: modelPDH.pdf
14526   Tue Apr 9 00:18:19 2019 gautamUpdateALSEX Green PDH error monitor calibrated

wrong assumption - i checked the gain just now, it is G=10, and is running in the "low-noise" mode, so can only drive 4V. fixed elog, filter.

Note: While working at EX, I saw frequent saturations (red led blinking) on the SR560. Looking a the error mon signal on a scope, it had a pk-to-pk amplitude of ~200mV going into the SR560. Assuming the free-swinging cavity length changes by ~1 um at 1 Hz, the green frequency changes by ~15 MHz, which according to the PDH discriminant calibration of 40 uV/Hz should only make a 60 mV pk to pk signal. So perhaps the cavity length is changing by 4x as much, plausible during daytime with me stomping around the chamber I guess.. My point is that if the SR560 get's saturated (i.e. input > 13000 cts), the DQ-ed spectrum isn't trustworthy anymore. Should hook this up to some proper whitening electronics

 Quote: G=10 or G=100?
14525   Tue Apr 9 00:16:22 2019 ranaUpdateALSEX Green PDH error monitor calibrated

G=10 or G=100?

ELOG V3.1.3-