40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 176 of 341  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  16834   Thu May 5 17:50:48 2022 YehonathanUpdateBHDBHD Readout simulation

I have made a Simulink diagram to use in the MICH modeling (attachment) for the homodyne angle detection scheme. The model will be used for each optic separately and the noises will be combined in quadrature.

I gathered some more bits of info to fill the Simulink boxes. This is what I have so far:

Noise sources

# Displacement noises from gwinc
# OSEM sensing noise from the null stream
# OpLev noise from SUM channel + Seismic motion

freq = np.logspace(1, 4, 100)
coil_driver_noise = 1*freq/freq # pA/sqrt(Hz), elog 15846 
RIN = 1e-2*freq/freq #1/sqrt(Hz), elog 16082  
freq_noise = (1e6/freq**2) #Hz/sqrt(Hz), elog 15431
dark_noise = 1e-8 #V/sqrt(Hz) https://wiki-40m.ligo.caltech.edu/Electronics/RFPD/AS55
ADC_noise = 1e-6 #V/sqrt(Hz)
DAC_noise = 1e-6 #V/sqrt(Hz), elog 13003

TFs and gains

#POS->BHD from Finesse
#RIN->BHD from Finesse
#Frequency noise->BHD from finesse
#Control filters from MEDM
#Whitening filters from https://wiki-40m.ligo.caltech.edu/Electronics/WhiteningFilters
#Dewhitening filters from elog 12983  

DAC_gain = 6.285e-4 #V/cts, elog 16161

coil_driver_gain = 31 # elog 15534

coil_driver_TF = 0.016 #N/A per coil, elog 15846 
coil_R = 20e3 #Ohm,, elog 15846 
SUS_TF = 1/(0.25*freq**2) #m/N, single pendulum
OSEM_TF = 2*16384*1e3 #cts/m, https://wiki-40m.ligo.caltech.edu/Calibration
ADC_TF = 1638.4 #cts/V 
DCPD_responsivity = 0.8 #A/W
DCPD_transimpedance = 1e3 #V/A

Attachment 1: BHD_controls_40m_MICH.pdf
  16858   Mon May 16 16:13:01 2022 YehonathanUpdateBHDInitial BHD modeling: Damped suspension model

I was finally able to set up a stable suspension model with the help of Yuta and I'm now ready to start doing some MICH noise budgeting with BHD readout. (Tip: turns out that in the zpk function in Matlab you should multiply the poles and zeros by -2*pi to match the zpk TFs in Foton)

I copied all the filters from the suspension MEDM screens into a Matlab. Those filters were concatenated with a single pendulum suspension TF with poles at [0.05e-1+1i, 0.05e-1-1i] and a gain of 4 N/kg.

I multiplied the OLTF with the real gains at the DAC/DAC/OSEMs/Coil Driver and Coils. I ignore whitening/dewhitening for now. The OLTF was calculated with no additional ad-hoc gain.

Attachment 1 shows the calculated open-loop transfer function.

Attachment 2 shows OLTF of ETMY measured last week.

Attachment 3 shows the step and impulse responses of the closed-loop system.



Attachment 1: Damped_SUS.png
Attachment 2: ETMY_SUSPOS_GOL.pdf
Attachment 3: SUS_Response.png
  16883   Tue May 31 17:30:01 2022 YehonathanUpdateBHDGreen shutters fixed

[Paco, Yehonathan]

We fixed the slow control over the green beam shutters.

At the Y arm the wrong BNC was connected to the shutter driver. We connected the correct BNC to the driver and switched the remote mode. The green Y shutter now works but in reverese, meaning that sending 1 to C1:AUX-GREEN_Y_Shutter closes the shutter and vice versa. This needs to be fixed.

At the X end the problem was a bit more complicated. Previously, the shutter was controlled by c1auxey. We figured that c1auxex has a lot of spare bio channels. We found an Acromag BNC front panel (with wires already soldered to the BNCs) lying around in the lab and installed it on the c1auxex Acromag chassie. We then connected the topmost BNC to channel 0 on XT1111A in the chassie. The BNC was connected to the green shutter driver on the X end.

EPIC channel was added to the c1auxex db file while it was commented out on the psl shutters db file. Modbus was restarted on c1auxex and c1psl. c1psl had to be burt restored to regain MC lock. Now the green X shutter works properly.

  16923   Thu Jun 16 17:40:15 2022 YehonathanUpdateBHDComparison of MICH OLTF model with measurement

I made some progress in modeling MICH loop.

Putting all the LSC and SUS filters together with the MICH Finesse model I constructed an OLTF model and plot it with the measurement done by Paco and Yuta in this elog (attachment 1).

There are 2 unknown numbers that I had to adjust in order to fit the model with the measurement:

1. The SUS damping loop gain (found to be ~ 2.22), which seems to vary wildly from SUS to SUS.

2. The coil driver gain (found to be 45), which I should measure.

I find coil_driver_gain*SUS_damping_filter_gain by increasing it until the SUS damping loop becomes unstable.

The coil driver gain I find by making the measurement and model overlap.

However, there is one outstanding discrepancy between the measurement and the model: Paco and Yuta measure the MICH calibration to be 1.3e9 cts/m while my model shows it to be 1.3e10 cts/m, an order of magnitude larger.


The model can be summarized with these lines of code (I assume that the product of the ADCs(DACs) and and whitening(dewhitening) filters is unity):

BS2AS55 = TFs["AS_f2"]["BS"]

PD_responsivity = 1e3*0.8 #V/W
ADC_TF = 3276.8 #cts/V
demod_gain = 6.77 #According to https://wiki-40m.ligo.caltech.edu/Electronics/LSC_demoddulators
whitening_gain = 10**(24/20) #24 dB
BS2MICH = BS2AS55*PD_responsivity*demod_gain*whitening_gain*ADC_TF

DAC_TF = 6.285e-4 #V/cts, elog 16161

coil_TF = 0.016 #Newton/Ampere per coil, elog 15846 

coil_R = 20e3 #Ohm

actuation_TF = DAC_TF*coil_TF/coil_R

OLTF = (BS2MICH*MICH_ctrl_cmplx*-6*0.5 + OSEM_filters_cmplx*OSEM_TF*2.22)*coil_filters_cmplx*actuation_TF*SUS_cmplx*45

  • BS2AS55 is the optical plant, calculated with Finesse
  • MICH_ctrl_cmplx is the MICH control filter with gain of -6
  • 0.5 factor comes from the LSC output matrix
  • OSEM_TF is the product of the OSEMs input filters and damping loop filters.
  • coil_filters_cmplx are the coil filters
  • SUS_cmplx is the suspension transfer function (w0 = 1Hz, Q=200)
Attachment 1: MICH_Model_Measurement_Comparison.pdf
  16927   Fri Jun 17 12:05:32 2022 YehonathanUpdateBHDComparison of MICH OLTF model with measurement

I should write down what I didn't include for completeness:

1. AA filters

2. AS55 input 60Hz comb filter

3. Violin filters

After discussing with Paco, we agreed that the discrepancy in the MICH calibration might come from the IQ mixing angle which for the IFO is not optimized, while in Finesse is set such that all the amplitude is in one quadrature.


I made some progress in modeling MICH loop.

Putting all the LSC and SUS filters together with the MICH Finesse model I constructed an OLTF model and plot it with the measurement done by Paco and Yuta in this elog (attachment 1).

There are 2 unknown numbers that I had to adjust in order to fit the model with the measurement:

1. The SUS damping loop gain (found to be ~ 2.22), which seems to vary wildly from SUS to SUS.

2. The coil driver gain (found to be 45), which I should measure.

I find coil_driver_gain*SUS_damping_filter_gain by increasing it until the SUS damping loop becomes unstable.

The coil driver gain I find by making the measurement and model overlap.

However, there is one outstanding discrepancy between the measurement and the model: Paco and Yuta measure the MICH calibration to be 1.3e9 cts/m while my model shows it to be 1.3e10 cts/m, an order of magnitude larger.

  16944   Fri Jun 24 13:29:37 2022 YehonathanUpdateGeneralOSEMs from KAGRA

The box was given to Juan Gamez (SURF)


I put the box containing the untested OSEMs from KAGRA near the south flow bench on the floor.


  16960   Tue Jun 28 22:27:11 2022 YehonathanUpdateBHDMeasurement of input and output electronics noise

{Yuta, Yehonathan}

For MICH noise budgeting we measure the input electronics noise which includes the AS55 RFPD, preamp, demod board, the whitening, and the AA filters, and the ADC noises. To do so we simply close the laser shutter and take the spectrum of C1:LSC-AS55_I_ERR_DQ and C1:LSC-AS55_Q_ERR_DQ shown in attachment 1.

Next, we measured the output electronics noise which includes the DAC, dewhitening and AI filters, and coil driver noises. We disabled the BS watchdog and went to 1X4 rack. We measured the spectrum of one of the lemo outputs on the BS coil driver module using an SR785. Attachment 2 shows the spectrum together with the SR785 dark noise.

Attachment 1: input_noise_spectrum.pdf
Attachment 2: output_noise_spectrum.pdf
  16961   Tue Jun 28 23:10:34 2022 YehonathanUpdateBHDMeasurement of AS55 demod board conversion factor

{Yuta, Yehonathan}

We measured the AS55 demod board conversion from the amplitude of a 55MHz signal to a demodulated signal. We hooked the unused REFL55 LO into the PD input port on the AS55 demod board.

The REFL55 LO was measured to be 1.84 Vpp. The IQ outputs were: I = 0.86 Vpp, Q = 2.03 Vpp giving an amplitude of 2.205 Vpp. The overall conversion factor is sqrt(0.86**2+2.03**2)/(1.82/2)=2.422.

We also set to measure the loss in the RF cable from AS55 PD to the demod board on 1Y2. REFL55 was connected with a long BNC cable to the input of the cable under test. REFL55 at the input was measured to be 1.466 Vpp and 1.28 Vpp at the output signifying a transmission of 87.6%.

  16996   Wed Jul 13 10:54:39 2022 YehonathanUpdateBHDMICH AS55 noise budget

I fixed some mistakes in the budget:

1. The BS pendulum resonance was corrected from 0.8Hz to 1Hz

2. Added missing X3 filter in the coil filters

3. Optical gain is now computed from MICH to AS55 instead of BS to AS55 and is calculated to be: 9.95e8 cts/m.

4. Coil driver gain is still unmeasured but it is found to be 1.333 to make the actuation calibration from BS to MICH match the measurement (see attachment 1).

Attachment 2 shows the resulting MICH OLTF.

Laser noise was added to the budget in a slightly ad-hoc fashion (will fix later): Yuta and I measured MC_F and computed MC_F*(Schnupp asymmetry)/(Laser frequency). Attachment 3 shows the updated noise budget.

Attachment 1: BS_MICH_ACtuation_Calibration.pdf
Attachment 2: MICH_AS55_Model_Measurement_Comparison.pdf
Attachment 3: MICH_AS55_Noise_Budget.pdf
  16999   Wed Jul 13 13:30:48 2022 YehonathanUpdateBHDadd Laser RIN to MICH budget

the main laser noise coupling for a Michelson is because of the RIN, not the frequency noise. You can measure the RIN, in MC trans or at the AS port by getting a single bounce beam from a single ITM.

  17013   Mon Jul 18 16:49:57 2022 YehonathanUpdateBHDadd Laser RIN to MICH budget

I measured the RIN by taking the spectrum of C1:MC_TRANS_SUMFILT_OUT and dividing it by the mean count on that channel (~13800 cts). Attachment 1 shows the result.

I updated the MICH AS55 noise budget but got a very low contribution (gold trace in attachment 2).

It seems too low I think. What could've gone wrong? Finesse calculates that the transfer function from laser amplitude modulation to AS55 is ~ 1.5e-9 at DC. If I turn off HOMs I get 1e-11 at DC, so this coupling is a result of some contrast defect. Should I include some RMS imbalances in the optics to account for this? Should I include it as a second-order effect due to MICH RMS deviation from zero crossing?


the main laser noise coupling for a Michelson is because of the RIN, not the frequency noise. You can measure the RIN, in MC trans or at the AS port by getting a single bounce beam from a single ITM.


Attachment 1: Laser_RIN.pdf
Attachment 2: MICH_AS55_Noise_Budget.pdf
  17042   Thu Jul 28 14:34:40 2022 YehonathanUpdateBHDLO beam power at BHD DCPDs is significantly lower than expected

{Yuta, Yehonathan}

We went to the BS table to check the POP beam power. We first notice that the POP beam has a nice gaussan profile on the viewing card. We traced it the beam to the viewing port and measured the power there. Before measuring the power we misalign ITMY/ITMX to get rid of interferences. We measure the beam to be 205uW in both cases.

The expected power is

950 mW * 0.9 (IMC transmission?) * 5.637%(PRM) * 97.8%(PR2) * 50%(BS) * 98.6%(ITM) * 50%(BS)  * 2.2%(PR2) = 260uW

which is reasonably close to what we measure which confirms that PR2 transmission is around what we think it is.

This strengthen our suspicion that LO beam gets clipped somewhere.


We also improved the clipping on the POP camera by one of the beamsplitters along the beam path and the alignment to the POPDC PD (~100 cts before, ~ 1000 cts after).


  17064   Fri Aug 5 17:03:31 2022 YehonathanSummaryGeneralTesting 950nm laser found in trash pile

I set out to test the actuation bandwidth of the 950nm laser. I hooked the laser to the output of the bias tee of PD testing setup. I connected the fiber coming out of the laser to the fiber port of 1611 REF PD.

The current source was connected to the DB9 input of the PD testing setup. I turned on the current source and set the current to 20mA. I measured with a fluke ~ 2V at the REF PD DC port.

I connected the AC port of the bias tee to the RF source of the network analyzer and the AC port of the REF PD to the B port of the network analyzer. Attachment 2 shows the setup.

I took a swept sine measurement (attachment) from 100kHz to 500MHz.

It seems like the bandwidth is ~ 1MHz which is weird considering the spec sheet says that the pulse rise time is 0.5ns. To make sure we are not limited by the bandwidth of the cables I looped the source and the input of the network analyzer using the cables used for the previous measurement and observed that the bandwidth is a few 100s of MHz.

Attachment 1: 20220805_164434.jpg
Attachment 2: LaserActuation_TF_Measurement.drawio.pdf
  17089   Thu Aug 18 14:49:35 2022 YehonathanSummaryLSCFPMI Sensitivity

{Yuta, Yehonathan}

We wrote a notebook found on Git/40m/measurements/LSC/FPMI/NoiseBudget/FPMISensitivity.ipynb for calculating the MICH, DARM (currently XARM), CARM (currently YARM) sensitivities in the FPMI lock which can be run daily.

The IN and OUT channels of each DOFs are measured at a certain GPS time and calibrated using the optical gains and actuation calibration measured in the previous post.

Attachment shows the results.

It seems like the UGFs for MICH and DARM (currently XARM) match the ones that were estimated previously (100Hz for MICH, 120Hz for DARM) except for CARM for which the UGF was estimated to be 250Hz and here seems to be > 1kHz.

Indeed one can also see that the picks in the CARM plot don't match that well. Calculation shows that at 250Hz OUT channel is 6 times more than the IN channel. Calibrations for CARM should be checked.

MICH sensitivity using REFL55 at high frequencies is not much better than what was measured with AS55.

DARM sensitivity at 10Hz is a factor of a few better than the single arm lock sensitivity.

Now it is time to do the budgeting.

Attachment 1: Sensitivity_Plot_1344133503.pdf
  17105   Thu Aug 25 16:05:51 2022 YehonathanUpdateSUSTrying to fix some SUS

I tried to lock the Y/X arms to take some noise budget. However, we noticed that TRX/Y were oscillating coherently together (by tens of percent), meaning some input optics, essentially PR2/3 are swinging. There was no way I could do noise budgeting in this situation.

I set out to debug these optics. First, I notice side motion of PR2 is very weakly damped .

The gain of the side damping loop (C1:SUS-PR2_SUSSIDE_GAIN) was increased from 10 to 150 which seem to have fixed the issue. Attachment 1 shows the current step response of  the PR2 DOFs. The residual Qs look good but there is still some cross-couplings, especially when kicking POS. Need to do some balancing there.

PR3 fixing was less successful in the beginning. I increased the following gains:

C1:SUS-PR3_SUSPOS_GAIN: 0.5 -> 30




But the residual Q was still > 10. Then I checked the input matrix and noticed that UL->PIT is -0.18 while UR->PIT is 0.39. I changed UL->PIT (C1:SUS-PR3_INMATRIX_2_1) to +0.18. Now the Q became 7. I continue optimizing the gains.

Was able to increase C1:SUS-PR3_SUSSIDE_GAIN: 50 -> 100.

Attachment 2 shows the step response of PR3. The change of the entry of the input matrix was very ad-hoc, it would probably be good to run a systematic tuning. I have to leave now, but the IFO is in a very misaligned state. PR3/2 should be moved to bring it back.

Attachment 1: PR2_Step_Response_Test_2022-08-25_16-23.pdf
PR2_Step_Response_Test_2022-08-25_16-23.pdf PR2_Step_Response_Test_2022-08-25_16-23.pdf PR2_Step_Response_Test_2022-08-25_16-23.pdf PR2_Step_Response_Test_2022-08-25_16-23.pdf
Attachment 2: PR3_Step_Response_Test_2022-08-25_18-37.pdf
PR3_Step_Response_Test_2022-08-25_18-37.pdf PR3_Step_Response_Test_2022-08-25_18-37.pdf PR3_Step_Response_Test_2022-08-25_18-37.pdf PR3_Step_Response_Test_2022-08-25_18-37.pdf
  17122   Wed Aug 31 11:39:48 2022 YehonathanUpdateLSCUpdated XARM noise budget

{Radhika, Paco, Yehonathan}

For educational purposes we update the XARM noise budget and add the POX11 calibrated dark noise contribution (attachment).

Attachment 1: Screenshot_2022-08-31_11-38-46.png
  17128   Fri Sep 2 15:26:42 2022 YehonathanUpdateGeneralSOS and other stuff in the clean room

{Paco, Yehonathan}

BHD Optics box was put into the x-arm last clean cabinet. (attachment 5)

OSEMs were double bagged in a labeled box on the x-arm wire racks. (attachment 1)

SOS Parts (wire clamps, winches, suspension blocks, etc.) were put in a box on the x-arm wire rack. (attachment 3)

2"->3" optic adapter parts were put in a box and stored on the xarm wire rack. (attachment 3)

Magnet gluing parts box was labeled and stored on the xarm rack. (attachment 2)

TT SUS with the optics were stored on the flow bench at the x end. Note: one of the TT SUS was found unsuspended. (attachment 4)

InVac parts were double bagged and stored in a labeled box on the x arm wire rack. (attachment 2)

Attachment 1: osem_sus.jpeg
Attachment 2: magnet_gluing.jpeg
Attachment 3: 2-3inch_adapter_parts.jpeg
Attachment 4: TTs.jpeg
Attachment 5: BHD_optics.jpeg
  17137   Thu Sep 8 16:03:25 2022 YehonathanUpdateLSCRealignment, arm locking, gains adjustments

{Anchal, Yehonathan}

We came this morning and the IMC was misaligned. The IMC was realigned and locked. This of course changed the input beam and sent us down to a long alignment journey.

We first use TTs to find beam on BHD DCPD/Camera since it is only single bounce on all optics.

Then, PR2/3 were used to find POP beam while keeping the BHD beam.

Unfortunately, that was not enough. TTs and PRs have some degeneracy which caused us to lose the REFL beam.

Realizing this we went to AS table to find the REFL beam. We found a ghost beam that decieved us for a while. Realizing it was a ghost beam, we moved TT2 in pitch, while keeping the POP DCPD high with PRs, until we saw a new beam on the viewing card.

We kept aligning TT1/2, PR2/3 to maximize the REFL DCPD while keeping the POP DCPD high. We tried to look at the REFL camera but soon realized that the REFL beam is too weak for the camera to see.

At that point we already had some flashing in the arms (we centered the OpLevs in the beginning).

Arms were aligned and locked. We had some issue with the X-ARM not catching lock. We increased the gain and it locked almost immediately. To fix the arms gains correctly we took OLTFs (Attachment) and adjusted the XARM gain to 0.027 to make the UGF at 200Hz.

Both arms locked with 200 Hz UGF from:

From GPS: 1346713049
    To GPS: 1346713300

From GPS: 1346713380
    To GPS: 1346714166

HEPA turned off:
From GPS: 1346714298
    To GPS: 1346714716


  17138   Tue Sep 13 14:12:03 2022 YehonathanUpdateBHDTrying LO phase locking again

[Paco, Yehonathan]

Summary:  We locked LO phase using the DC PD (A - B) error point without saturating the control point, i.e. not a "bang bang" control.

Some suspensions were improved so we figure we should go back to trying to lock the LO phase.

We misalign ETMs and lock MICH using AS55. We put a small MICH offset by putting C1:LSC-MICH_OFFSET = -80.

AS and LO beams were aligned to overlap by maximizing the BHD signal visibility.

BHD DCPDs were balanced by misaligning the AS beam and using the LO beam only.

We measure the transfer function between the DCPDs and find the coherence is 1 at 1 Hz (because of seismic motion) so we measure the ratio between them to be 0.3db.

AS beam is aligned again to overlap with the LO beam. For the work below, we use the largest MICH OFFSET we could impinge before losing the lock = +90. This has the effect of increasing our optical gain.

We started using the HPC LOCK IN screen to dither POS on the different BHD SUS. We first started with AS1 (freq = 137.137 Hz, gain = 1000). The sensing matrix element was chosen accordingly (from the demodulated output) and fed to the LO_PHASE; because this affected the AS port alignment this was of course not the best choice. We moved over to LO2 (freq = 318.75 Hz, gain = 1000) but for the longest time couldn't see the dither line at the error point (A-B).

After this we added comb60 notch filters at DCPD_A and DCPD_B input signals. We ended up just feeding the (A-B) error point to LO1, and trying to lock mid fringe, which suceeded without saturation. The gain of the LO_PHASE filter was set to 0.2 (previously 20; attributable to the newly unclipped LO beam intensity?), and again we only enabled FM4 and FM5 for this. After this a dither line at 318.75 Hz finally appeared in the A-B error point! To be continued...

Attachment 1: Screenshot_2022-09-13_17-41-33.png
  17141   Thu Sep 15 16:19:33 2022 YehonathanUpdateLSCPOX-POY noise budget

Doing POX-POY noise measurement as a poor man's FPMI for diagnostic purposes. (Notebook in /opt/rtcds/caltech/c1/Git/40m/measurements/LSC/POX-POY/Noise_Budget.ipynb)

The arms were locked individually using POX11 and POY11. The optical gain was estimated to be by looking at the PDH signal of each arm: the slope was computed by taking the negative peak to positive peak counts and assuming that the arm length change between those peaks is lambda/(2*Finesse), where lambda = 1um and the arm finesse is taken to be 450.

Xarm peak-to-peak counts is ~ 850 while Yarm's is ~ 1100. This gives optical gains of 3.8e11 cts/m and 4.95e11 cts/m respectively.

Next, ETMX actuation TF is measured (attachments 1,2) by exciting C1:LSC-ETMX/Y_EXC and measuring at C1:LSC-X/YARM_IN1_DQ and calibrating with the optical gain.

Using these calibrations I plot the POX-POY (attachment 3) and POX+POY (attachment 4) total noise measurements using two methods:

1. Plotting the calibrated IN and OUT channels of XARM-YARM (blue and orange). Those two curves should cross at the UGF (200Hz in this case).

2. Plotting the calibrated XARM-YARM IN channels times 1-OLTF (black).

The UGF bump can be clearly seen above the true noise in those plots.

However, POX+POY OUT channel looks too high for some reason making the crossing frequency between IN and OUT channels to be ~ 300Hz. Not sure what was going on with this.

Next, I will budget this noise with the individual noise contributions.

Attachment 1: XARM_Actuation_Plot.pdf
Attachment 2: YARM_Actuation_Plot.pdf
Attachment 3: Sensitivity_Plot_1347315385.pdf
  17149   Wed Sep 21 10:10:22 2022 YehonathanUpdateCDSC1SU2 crashed

{Yehonathan, Anchal}

Came this morning to find that all the BHD optics watchdogs tripped. Watchdogs were restored but the all ADCs were stuck.

We realized that the C1SU2 model crashed.

We run /scripts/cds/restartAllModels.sh to reboot all machines. All the machines rebooted and burt restored to yesterday around 5 PM.

The optics seem to have returned to good alignment and are damped.

  16092   Wed Apr 28 18:56:57 2021 Yehonathan, JonUpdateCDSUpdated c1auxey wiring plan

We took a Supermicro from the lab (along with a keyboard, a mouse, and a screen taken from a table on the Y arm) and placed it near the Acromag chassis.

We installed Debian 10 on the machine. I followed the steps on the slow machine wiki for setting up the host machine. Some steps had to be updated. Most importantly, in the new Debian, the network interfaces are given random names like enp3s0 and enp4s0 instead of eth0 and eth1. I updated the wiki accordingly.

To operate the chassis using one 15V source I disconnected the +24V cable from the Acromag units and jumpered the +15V wire into the power input instead. I started up the Acromags. They draw 0.7A. I connected an Ethernet cable to the front interface. I checked that all the Acromags are connected to the local network of the host machine by pinging them one by one.


  16107   Fri Apr 30 19:18:51 2021 Yehonathan, JonUpdateCDSUpdated c1auxey wiring plan

We finished the installation procedure on the c1auxey1 host machine. There were some adjustments that had to be made for Debian 10. The slow machine wiki page has been updated.

A test database file was made were all the channel names were changed from C1 to C2 in order to not interfere with the existing channels.

We starting testing the channels one by one to check the wiring and the EPICs software. We found some misswirings and fixed them.

Channel Name Type EPICs Test Acromag windows software test
C2:SUS-ETMY_SideVMon AI Pass Pass

Its getting late. I'll continue with the rest of the channels on Monday.

Notice that for all the AI channels the RTN was disconnected while testing.







  16114   Mon May 3 20:36:46 2021 Yehonathan, JonUpdateCDSUpdated c1auxey wiring plan

It seemed like the BIO channels were not working, both the inputs and the outputs. The inputs were working on the windows machine though. That is, when we shorted the BIO channel to the return, or put 0V on it, we could see the LED turn on on the I/O testing screen and when we ramped up the voltage above 3 the LED turned off. This is the expected behavior from a sinking digital input. However, the EPICs caget didn't show any change. All the channels were stuck on Disabled.

We checked the digital outputs by connecting the channels to a fluke. Initially, the fluke showed 13V. We tried to toggle the digital output channels with caput and that didn't work. We checked the outputs with the windows software. For that, we needed to stop the Modbus. To our surprise, the windows software was not able to flip the channels either. We realized that this BIO Acromag unit is probably defective. We replaced it with a different unit and put a warning sticker on the defective unit. Now, the digital outputs were working as expected. When we turned them on the voltage output dropped to 0V. We checked the channels with the EPICs software. We realized that these channels were locked with the closed loop definition. We turned on the channels tied to these output channels (watchdog and toggles) and it worked. The output channels can be flipped with the EPICs software. We checked all the digital output channels and fixed some wiring issues along the way.

The digital input channels were still not working. This is a software issue that we will have to deal with later.

(Yehonathan) Rana noticed that the BNC leads on the chassis front panel didn't have isolation on them so I redid them with shrinking tubes.

  12564   Fri Oct 14 19:59:09 2016 YinziUpdateGreen LockingContinuing work with the TC 200

Oct. 15, 2016

Another attempt (following elog 8755) to extract the oven transfer function from time series data using Matlab’s system identification functionalities.

The same time series data from elog 8755 was used in Matlab’s system identification toolbox to try to find a transfer function model of the system.

From elog 8755: H(s) is known from current PID gains: H(s) = 250 + 60/s +25s, and from the approximation G(s)=K/(1+Ts), we can expect the transfer function of the system to have 3 poles and 2 zeros.

I tried fitting a continuous-time and a discrete time transfer function with 3 poles and 2 zeros, as well as using the "quick start" option. Trying to fit a discrete time transfer function model with 3 poles and 2 zeros gave the least inaccurate results, but it’s still really far off (13.4% fit to the data).


1. Obtain more time domain data with some modulation of the input signal (also gives a way to characterize nonlinearities like passive cooling). This can be done with some minor modifications to the existing code on the raspberry pi. This should hopefully lead to a better system ID.

2. Try iterative tuning approach (sample gains above and below current gains?) so that a tune can be obtained without having to characterize the exact behavior of the heater.

Oct. 16, 2016

-Found the raspberry pi but it didn’t have an SD card

-Modified code to run directly on a computer connected to the TC 200. Communication seems to be happening, but a UnicodeDecodeError is thrown saying that the received data can’t be decoded.

-Some troubleshooting: tried utf-8 and utf-16 but neither worked. The raw data coming in is just strings of K’s, [‘s, and ?’s

-Will investigate possible reasons (update to Mac OS or a difference in Python version?), but it might be easier to just find an SD card for the raspberry pi which is known to work. In the meantime, modify code to obtain more time series data with variable input signals.

  12567   Tue Oct 18 17:11:42 2016 YinziUpdateGreen LockingMore serial port troubleshooting

I connected to the serial port using screen (through Terminal) and using Arduino's serial monitor and basically received the same strings that were received through python, so it's not a python issue. Checked the other TC 200 module and was also receiving nonsense, but it was all question marks instead of mostly K's and ['s.

This rules out a few possible reasons for the weird data. Next steps are to set up and configure the Raspberry Pi (which has been interfaced before) and see if the problem continues.

  526   Mon Jun 9 17:32:14 2008 YoichiConfigurationPSLPMC transmittance
I checked the current PMC transmissivity at a low power.
The input laser power to the PMC was reduced to 75mW by rotating the HWP in front of the PBS.
In this configuration, the output power from the PMC was 50mW. So the transmittance is about 66%.
The reading of C1:PSL-PMC_PMCTRANSPD is now 0.1 whereas it was 2.7 before turning the power down.

I will check the transmittance at a higher power when I get the cable for the 35W calorie meter, which is missing now.
  527   Mon Jun 9 17:57:59 2008 YoichiConfigurationPSLPMC input power backed to the original
I rotated back the HWP before the PBS to restore the input laser power to the PMC.
Now the reading of PSL-PMC_PMCTRANSPD is 2.7.
  534   Fri Jun 13 11:17:25 2008 YoichiUpdatePSLPMC transmittance at high power
We received a new cable for the Scientech calorimeter. So I measured the transmittance of the PMC at higher power.

Input power = 2.298W
Output power = 1.364W
Transmittance = 59%

The input power to the PMC was measured between the two mode matching lenses by the calorimeter.
2.298W looks a bit too low. Actually, the calibrated monitor PD on the MEDM screen shows about 3W output from MOPA.
So we (me and Steve) measured the power right after the PBS after the periscope from MOPA with the HWP set to maximize the transmission of the PBS.
It was 2.77W. According to Steve's previous measurement, the first mirror of the periscope transmits about 200mW of the incoming light to the monitor PD. So the actual output of the MOPA is about 2.97W, which is consistent with the monitor PD reading.
The aperture of the EOM for the PMC control is glowing a lot. We suspect this is the main cause of the loss (from 2.77W to 2.298W).
We may want to re-align the EOM.

The output light from the PMC was picked off by a glass slide. The reflectance of the glass slide was measured first at a lower power (input 98mW, reflected power 1.58mW). Assuming that the reflectance is the same for the higher power, I turned up the input power to the PMC. This time, the picked off power was 22.45mW. This means the actual output power is 98/1.58*22.45=1364mW. The glass slide was kept at the same angle through out the measurement.
The measurement of the output power was done by the Ophir power meter. So calibration difference between the Ophir and the calorimeter may introduce some error.
  540   Wed Jun 18 18:20:10 2008 YoichiUpdatePSLInvestigation on the NPRO temperature stabilization glitches
As Rob pointed out in http://dziban.ligo.caltech.edu:40/40m/537 the MOPA NPRO has been showing some glitchiness in the LTEC loop.
Following Rana's suggestion, Steve and I opened the MOPA and directed a heat gun for a minute to the NPRO hoping that we can see something in the LTEC loop.
The first attachment shows the behavior of LTMP and LTECH along with DTMP and DTECH at the time of the heat gun attack.
T=0 is the time when Steve directed the heat gun to the NPRO. There is no response neither in LTMP nor LTECH.
DTMP and DTECH look like responding.
Around the center, there is a dip in LTMP. This might be caused by removing the heat gun. But we are not sure. This kind of small glitches can be found in LTMP everywhere (see the attachment 2).
It looks like the LTMP sensor is not working, or the LTECH loop is actually working but the LTECH reading is broken.
However, the scan of the slow actuator (temperature) shows the LTECH loop is actually working. So it is a bit confusing.
More investigation is necessary.
See the next entry by me.
Attachment 1: LTEC-loop-HeatGun-Response.pdf
Attachment 2: LTMP-glitches.pdf
  541   Wed Jun 18 18:26:19 2008 YoichiUpdatePSLFinding the optimal operation temperature for the NPRO by the slow act scan
Being suspicious of the temperature stabilization of the NPRO crystal, I ran the slow scan script written by Rana to find the suitable operation temperature.
The procedure is the same as the one explained in the entry below:
The attached plots show the results. By looking at C1:PSL-126MOPA_126MON, I set the slow slider voltage to 0.
This time, it looks like the temperature control of the NPRO crystal is working fine.
Obviously, PMC picks up many higher order modes. I will try to mode match/align the PMC later.
Attachment 1: FSS-slow-scan.pdf
  548   Fri Jun 20 02:20:33 2008 YoichiUpdate PMC transmittance degradation
The PMC transmitted light power has been degrading constantly for last two weeks (see the attachment 1).
I went down to 2.55V.
The output of the MOPA is constant during this period. More strangely, the reflected power from the PMC is also constant.
One possible explanation is the contamination of the PMC mirrors. But I don't know why it started two weeks ago.

I tweaked the alignment of PMC and was able to recover the transmitted power to above 2.7V (attachment 2).
I will keep eye on this issue.
Attachment 1: pmc_trans_long_trend.pdf
Attachment 2: pmc_trans_improvement.pdf
  569   Wed Jun 25 18:03:21 2008 YoichiConfigurationPSLFSS Input Offset slider problem
While working on the PMC scanning, I noticed that the FSS input offset slider is doing nothing.
I traced the signal flow and checked the cables/boards.
The slider changes the output voltage from a VMIVME4116 DAC in the PSL rack. This output voltage is confirmed to be correct at the FLKM64 connector. The signal is connected to the FSS servo interface box (D040423) trough a ribbon cable. However, the output from the interface box is always -27V regardless of the slider position.
Therefore, either the interface box (D040423) or the ribbon cable has a problem.
I will debug the interface box using an extension card when no one is working on the interferometer.
  575   Thu Jun 26 18:24:28 2008 YoichiUpdatePSLFSS input ofset slider problem - fixed
I checked the FSS servo interface board and found that a LT1125CSW used to differentialize offset channel was broken (no virtual short).
So I replaced it. Now the slider is working.
The op-amp was hitting the rail. So it seems like we had been applying the maximum offset to the FSS input all the time.
The reason why the FSS loop still worked with the large offset is that the applied offset (~14V) is attenuated by a factor of 500 at the summing point.
  607   Mon Jun 30 18:36:01 2008 YoichiUpdatePSLMZ alignment again
John, Yoichi

We re-adjusted the MZ alignment. The reason behind this is to make sure that the MZ dark port is not falling at a strange fringe, where it is only dark at the dark port PD. It can happen when the two beams poorly overlap.
We tried both the minimization of the MZ dark PD and the maximization of the MZ transmission at the same time.
We also placed another PD in the MZ dark port at a different distance from the original dark PD and tried to minimize this too.
If the MZ dark port is at a strange fringe, one of the dark PD can be dark where the other one is still bright.
If both of the dark PD get dark, the overlap between the beams should be ok.
We tweaked only the two mirrors of the MZ after the EOMs (mainly the one with a PZT).

Right now, the MZ dark power is 0.432.
BTW, we should change the name of the MZ dark port on the medm screen (it is now MZ reflection, where it is not a reflection).
I will try to change it later.

We wanted to put the beam position on the IOO-QPD_POS_* back to the original (before John tweaked the MZ alignment earlier).
However, the trends of IOO-QPD_POS_* show a lot of fluctuation and jumps, of which we don't know the cause. So we could not find reasonable original values.
We suspect a circuit problem in IOO-QPD_POS, especially because the jumps are very strange.
We will do this investigation later too.
  610   Tue Jul 1 11:53:38 2008 YoichiUpdateComputersRFM network back
I took a tour of the FE machines and power cycled all of them.
After executing the software restart procedures of those computers, the RFM network got back to the normal state.
For some reason, the computers requiring startup.cmd (like c1lsc) halt after running this command. Actually the computer is running ok, but the command freezes. Basically, what it does is simply to load a kernel module. I don't know what is wrong.
Anyway, I just closed the terminal after running startup.cmd and it seems fine for now.
  611   Tue Jul 1 11:57:24 2008 YoichiConfigurationPSLMZ servo switch problem again
C1:PSL-MZ_BLANK switch (to turn on/off the servo) is not working again. The switch is always off regardless of the epics state.
I pushed the cables into the xycom card, but it did not fix the problem.
  639   Mon Jul 7 13:49:27 2008 YoichiHowToPSLMZ offset, gain tips
John, Yoichi

This morning John found that MZ servo is not working.
We were able to bring the MZ back by changing the output offset a bit. But we were not sure what was actually wrong.
So we pulled out the MZ board and checked several TPs to understand the behavior.
Here is the summary of what we learned this morning.

The MZ control board has the following stages:

[Mixer] -(error signal)-> [Sum amp for input offset] -(error + offset)-> [Variable Gain Amp] -> [Filter (x100 DC gain)] -(FB signal)-> [High Voltage Amp] -> output
(The HV amp also works as the sum amp for the output offset)

(1) We noticed that the Sum amp for the input offset has an output of -0.14V even when the offset input is 0V. This can be canceled by the input offset slider.
So for the moment, it is fine. But we might want to change the op-amp because the weird offset implies there might be something wrong with the chip.
The procedure to null the -0.14V offset is the following:
a) Enable Test 1 input on the MZ MEDM screen.
b) Move the input offset slider until the mixer monitor becomes 0V. Currently the input offset slider is at -7.5V to cancel the -0.14V offset.

(2) Because the gain of the Variable Gain Amp and the Filter combined is large, the Filter can be easily saturated if the output offset is not right.
This was the cause of the MZ problem this morning. The output offset slider was at a wrong position making the error signal slightly off centered from zero.
This residual DC error signal was amplified by the large gain chain and saturated the filter amp.
Our experience is that the output offset cannot go below -3V. We set it at 0V for now.
  641   Mon Jul 7 14:02:05 2008 YoichiUpdateComputersSVN conversion progress
So far /cvs/cds/caltech/medm, /cvs/cds/caltech/chans and /cvs/cds/caltech/scripts have been converted to svn working copies.
Now /cvs/cds/caltech/target is being converted.
  649   Tue Jul 8 21:46:38 2008 YoichiConfigurationPSLGC650M moved to the PMC transmission
I moved a GC650M, which was monitoring the light coming out of the PSL, to the transmission port of the PMC to see the transmitted mode shape.
It will stay there unless someone find other use of it.

Just FYI, you can see the picture from the control computers by the following procedure:

ssh -X mafalda
cd /cvs/cds/caltech/target/Prosilica/40mCode

Chose 02-2210A-06223 and click on the Live View icon.
  654   Thu Jul 10 13:47:12 2008 YoichiHowToComputerssvn access via https
Now you can access to the svn repository on nodus by https.
To perform a checkout, you can use the following command

svn co --username svn40m https://nodus.ligo.caltech.edu:30889/svn/trunk/chans

This will check out "chans" directory.
The password for svn40m is written in the usual place.
You can also access the URL by a web browser to see the repository in a very primitive way.
A nice web interface for browsing the repository is planed but not yet implemented.
  692   Thu Jul 17 20:13:34 2008 YoichiUpdatePSLPMC alignment/mode matching effort
I'm working to improve the mode matching of PMC.
Because I noticed that the beam was hitting the aperture of the EOM for PMC, I moved the EOM a little bit to maximize the transmission.
This did not change the alignment to the reference cavity but changed the alignment of the PMC a lot.
So I adjusted it back.
The alignment of the PMC can be easily optimized but the Hermite 02 mode still remains. This means the mode matching is bad.
Moving the lenses by a small amount (a few mm) did not change the height of 02 mode.
I'm planning to move the lenses by a large amount tomorrow. But it will destroy the alignment to the PMC.
So I installed two irises in the beam path after the lenses to remember the alignment roughly.
Right now the PMC transmission is slightly worse than before because the lens positions are not good.
  699   Fri Jul 18 19:41:09 2008 YoichiUpdatePSLPMC PZT investigation
I measured the HV coming to the PMC PZT by plugging it off from the PZT and hooking it up to a DVM.
The reading of DVM is pretty much consistent with the reading on EPICS. I got 287V on the DVM when the EPICS says 290V.

Then I used a T to monitor the same voltage while it is connected to the PZT. I attached a plot of the actual voltage measured by the DVM vs the EPICS reading.
It shows a hysteresis.
Also the actual voltage drops by more than a half when the PZT is connected. The output impedance of the HV amp is 64k (according to the schematic). If I believe this number, the impedance of the PZT should also be 64k. The current flowing the PZT is 1.6mA at 200V EPICS reading.
The impedance of the PZT directly measured by the DVM is 1.5M ohm, which is significantly different from the value expected above. I will check the actual output impedance of the HV amp later.
The capacitance of the PZT measured by the DVM is 300nF. I don't know if I can believe the DVM's ability to measure C.

I noticed that when a high voltage is applied, the actual voltage across the PZT shows a decay.
The second plot shows the step response of the actual voltage.
The voltage coming to the PZT was T-ed and reduced by a factor of 30 using a high impedance voltage divider to be recorded by an ADC.
The PMCTRANSPD channel is temporarily used to monitor this signal.
After the voltage applied to the PZT was increased abruptly (to ~230V), the actual voltage starts to exponentially decrease.
When the HV was reduced to ~30V, the actual voltage goes up. This behavior explains the weird exponential motion of the PZT feedback signal when the PMC is locked.
The cause of the actual voltage drop is not understood yet.
From the above measurements, we can almost certainly conclude that the problem of the PMC is in the PZT, not in the HV amp nor the read back.
Attachment 1: Hysteresis.png
Attachment 2: StepResponse.png
  700   Fri Jul 18 19:43:55 2008 YoichiDAQComputersPSL fast channels cannot be read by dataviewer
At this moment only the PSL fast channels have trouble.
Rob restarted fb40m, c1IOVME, but no effect.
  703   Sat Jul 19 19:41:56 2008 YoichiAoGPSLThe author of the entry 702 is Yoichi not Rob
I made a mistake.
  717   Tue Jul 22 22:11:58 2008 YoichiUpdateLSCX-arm g factor measurement
Alberto, Yoichi

We measured the g factor of the X-arm by slightly shifting the 166MHz sideband frequency:

We first locked the X-arm to TEM00 mode. Then misaligned the ETMX in yaw a little bit until the transmitted power is a half of the normal value.
In this way, we can expect that TEM01 mode will be resonated in the arm if a sideband with a suitable frequency is introduced.
To add such a sideband, we used the 166MHz EOM. According to John's calculation (ELog entry 690), the TEM01 mode of the 166MHz upper sideband is only about 100kHz away from the resonance. So by changing the 166MHz modulation frequency, we should be able to see the 166MHz upper sideband resonating in the X-arm.
We used the 166MHz PD at the AS to find the resonance.
When we modulated the 166MHz RF frequency by +/- 100kHz, we could see spikes in the AS166_I signal.
Then we fine tuned the RF frequency slowly by hand to find the exact resonant frequency. At that time, the X-arm PDH servo was oscillating at ~480Hz.
So the resonance was determined by maximizing this signal in the AS166_I.
The 166MHz signal was originally at 165.977195 MHz. I found the resonance around 165.985MHz. It is surprisingly close to the original modulation frequency (only 7.3kHz away). This number yields the g factor of 0.626 and the transverse mode interval of 0.285*FSR. I used the arm length of 38.5750m in this calculation. Because of the 480Hz oscillation, it was difficult to precisely determine the resonant frequency. We will try this again tomorrow after mitigating the oscillation.
Although the resonance of the 166MHz upper sideband is located at a lower frequency in John's prediction, we found a resonance at a higher frequency.
This can be interpreted as the discrepancy between the actual g-factor and the designed g-factor.

To confirm what we saw was really an arm cavity resonance, we will try to do the same thing with the arm cavities all mis-aligned.
(We expect no signal in this configuration.)

Appendix: the expected signal from AS166 port when the 166MHz upper sideband passes by a resonance of the arm cavity.
Since the carrier is resonating in the cavity and kept there by the PDH feedback using 33MHz sideband, its phase is virtually fixed at the AS166 port. The lower sideband's phase also does not change much because it is off resonance. The upper sideband get a large phase change when approaching to the resonance. This effectively rotates the modulation angle of the 166MHz sidebands, which was orthogonal to the carrier when off resonance (i.e. phase modulation), to create 166MHz amplitude modulation. Because the sideband axis is rotated, the signal should appear both in I and Q phases.
  728   Wed Jul 23 22:34:07 2008 YoichiUpdateLSCArm cavity g-factor measurement
I tried the same thing as the X-arm to the Y-arm.
I'm puzzled. I found exactly the same behavior as the X-arm in the AS166 demodulated signals, whereas I expected different resonance frequency because of the arm length difference.

Here is more detailed account of the measurement today.

I locked the Y-arm and mis-aligned the end mirror in Yaw until the transmission power gets half.
Then I injected a 30Hz sinusoid into the error point of the Y-arm servo to shake the ETMY.
I observed AS166_I and AS166_Q as I changed the 166MHz frequency.

At 165.977MHz, both AS166_I and AS166_Q showed the 30Hz signal (15cnt p-p).
At 165.981MHz, Only I phase showed the 30Hz signal (40cnt p-p). No signal in Q.
At 165.984MHz, I and Q became the same amplitude again (20cnt p-p).
At 165.987MHz, Only Q phase showed the 30Hz signal (40cnt p-p). No signal in I.

Outside the above range, the signal decreases as the frequency go away. I think this is (at least partly) because the 166MHz sidebands no longer go through the MC at those frequencies.

I then locked the X-arm to the TEM01 mode. I saw exactly the same behavior as described above. This could be the resonance of TEM02 mode. I was expecting to see the resonance of TEM00 mode at the opposite side, but nothing there.

I unlocked the arm cavities and tried the same frequency scan of the 166MHz with one of the end mirrors shaken at 30Hz. I saw no signal at the AS166 port.
I also tried locking Y-arm and shaking the ETMX. No signal.
So it has to be something to do with the cavity resonance.

Since the MC transmission curve for 166MHz is folded in the measurement, it makes the interpretation of the results harder.
  733   Thu Jul 24 08:09:26 2008 YoichiUpdateLSCArm cavity g-factor measurement


A-ha! Do you always expect the 30Hz signal, don't you?
Because this is the PDH technique.

Yes you are right. I realized this when I was thinking about it in the bed Smile
The 30Hz signal should always be present because the carrier is phase shifted at 30Hz by the cavity length change.
I think the change in the signal ratio between I and Q happened because as the 166MHz sidebands get phase change when they move around the MC transmission peak due to the cavity pole of the MC. It changes the optimal demodulation phase for the 166MHz PDH signal at the AS port.


We should be able to see 166MHz sideband resonances using the double demodulated photodetectors. With these, the 33MHz sidebands will be acting as LO when the 166MHz sideband (or mode) resonates. Some modeling may be necessary to determine if the SNR will be good enough to make this worthwhile, however.

I will try, but at 100kHz away from the MC FSR (the number predicted by John's calculation), the transmission of the 166MHz sidebands is very weak. I did not see any signal when I swept it +/- 500kHz. Unfortunately, the Marconi's output level is almost at its maximum. So we don't have much room for increasing the sideband power.
  735   Thu Jul 24 19:29:26 2008 YoichiConfigurationPSLC1:PSL-STAT_FSS_NOM_C_GAIN is changed from 30 to -0.7
Koji, Yoichi

Since the light power going to the ref. cavity is now significantly increased (see Janne's elog later),
is changed from 30 to -0.7.
Otherwise, the MC did not lock.
  758   Tue Jul 29 19:41:38 2008 YoichiUpdatePSLFSS loop transfer functions
Last night I measured a bunch of transfer functions on the FSS loop.
All the loop gains were measured with the common gain = 30db and the fast gain = 18dB.

(1) The first attachment is the overall open loop transfer function of the FSS loop. I put a signal from the Test IN2 and observed signals from IN1 and IN2.
The UGF is about 180kHz.
By increasing the RF amplitude going to the EOM (i.e. increasing the sideband power), I can further increase the gain of the servo.
However, it made the PC drive immediately crazy. Probably it was some oscillation.

(2) Then I locked the ref. cav. with only the PZT actuator. I did so by simply unplugging the cable going to the PC.
Surprisingly, the cavity locked with the *same* gain setting as before. The second attachment shows the open loop transfer function measured in this configuration. It seems wrong, I mean, it should be unstable. But the cavity locked. A mystery.

(3) The third plot is the measured TF from the Test IN1 of the FSS board to the fast out (output to the PZT).

(4) By dividing the TF measured in (2) with the TF of (3), I got the response of the PZT times the cavity response. This is shown in the attachment 4.

(5) We can guess the open loop TF of the PC path by subtracting the TF in (2) from (1). It is shown in the attachment 5.

(6) The filter shape of the PC path is measured by injecting signal from the Test IN1 of the FSS board and observing it at the PC output. Since it is a high voltage output, I reduced the common gain to -8.5dB during the measurement. The attachment 6 is the measured filter shape. The gain is corrected to show what it should look like when the common gain = 30dB.

(7) By dividing (5) with (6), I plotted the response of the PC times the cavity response in the attachment 7. Since the 1/f cavity pole and the response of the PC, which is proportional to f, should cancel out, we expect a flat response above the cavity pole frequency (38kHz). You could say it is a sort of flat, if you have obscured eyes.

The measurement of the PZT open loop TF is very suspicious. According to this, the PC path has a very large gain even at very low frequencies (there is no cross over above 1kHz). This cannot be true. Maybe the cavity's optical gain was low when it was locked with only the PZT. I will re-measure it.
The plot (4) is also strange becaues it does not show the low pass feature expected from the cavity pole.
Attachment 1: OverallOPLTF.eps
Attachment 2: OpltfPZTOnly.eps
Attachment 3: PZTFilter.eps
Attachment 4: PZTxCavityPole.eps
Attachment 5: OpltfPCOnly.eps
Attachment 6: PCFilter.eps
Attachment 7: PCxCavityPole.eps
ELOG V3.1.3-