Tl;dr: Tried to replace of XEND green PDH servo controller with Moku template IIR filter, designed to match PDH servo frequency response. The green laser did not catch lock with this filter.

Attachment 1 plots the measured TF of the PDH servo controller, with boost on and the gain knob set to 7.22 (the current lock configurations). It also plots an 8th order Chebyshev type II low-pass filter, with cutoff frequency and scale chosen to best match the data. (8 was the highest order filter that could be represented by 4 second-order-sections, the maximum allowed by the Moku.) I wanted to test if the XAUX PDH lock could be maintained using this filter as the controller.

The phase of the Chebyshev II filter does not seem to be a good fit to the data, but I wanted to see how far we could get using a template filter already designed for discrete time, and with a magnitude frequency response that approximates the servo. This would bypass having to perform a bilinear transform from the s-domain to the z-domain, which can raise more complications.

The PDH error signal (mixer output) was split and sent to the Moku (input 1) and to the PDH servo input. Closing the loop with the Moku filter output, the green laser was not able to catch lock. Attachment 2 shows the Moku:Go Digital Filter Box configurations, as well as the traces comparing output of the filter and the output of the PDH servo. The red trace is the output of Moku filter, and the blue trace is the output of the PDH servo (input 2) with the loop open (nothing feeding back to laser PZT). The input gain of the filter module was chosen to match the amplitudes of the two control signals. Qualitatively, the filter output contains higher frequency components and preserves the odd polarity of the PDH error signal, compared to the servo output. 

I then tried to directly fit the PDH servo TF data. I fit the (analog) poles and zeros of the TF using vectfit. In theory, using a bilinear transform can convert the analog zpk TF to digital zpk, with some frequency pre-warping required. However, vectfit did not return a "normal" transfer function, defined as having at least as many poles as zeros. This caused the bilinear transform to fail.

Next, I will need to use a different fitting package (perhaps IIRrational) to obtain a nicer TF fit, in normal form. Then I can attemp the bilinear transform, confirm it preserves the desired frequency response, and test it out with the Moku:Go.

[Mayank, Radhika]

I retook a transfer function measurement of the uPDH servo closed-loop (using the SR560 to simulate a cavity pole) [Attachment 1]. While some coherence is lost at low frequencies, the servo does not appear to be saturating. Moving forward this measurement is used to design a digital filter that can replicate the uPDH servo box response. *Note: for now the chosen sampling frequency for the discrete filters is 61.04 kHz, the lowest sampling frequency setting of the Moku:Go.

We performed a low-order fit of the TF using vectfit. Vectfit always seems to return 1 more zero than pole - this results in an "improper" transfer function that causes any transformation to the z-domain to fail. Mayank took the fitted zeros and poles from vectfit and manually removed one of the zeros. After transforming the zeros and poles to the z-domain (using control.matlab.c2d), we noticed multiple resonances around 100 kHz that reached 10-20 dB. We decided to estimate poles and zeros by eye instead of using vectfit. 

2 zeros and 2 poles were selected by eye to get an estimated fit in the s-domain. Using continous-to-discrete transforms (tried scipy.signal.bilinear and control.matlab.c2d) resulted in unstable controller responses. Attachment 2 shows the original TF measurement with the designed analog filter and the resulting digital filter. The orange 'x's and 'o's mark the poles and zeros used. The digital filter contains many high-frequencies resonances, the most significant at the sampling frequency, 61.04 kHz, reaching 20 dB. Next we tried to manually load the analog ZPK coefficients into Foton. This resulted in the same digital filter as the python s-domain to z-domain functions [Attachment 3].

**UPDATE** Now looking back it's clear that the high-frequency response is limited by the sampling rate. I will redo this for the highest Moku:Go sampling rate of 3.9 MHz.

XAUX laser locked with Moku:Go controller

The analog zeros and poles used to design this filter were:

Attachment 1 shows the resulting digital SOS filter (sampling rate: 3.9 MHz) compared to the measured uPDH servo transfer function (loop closed). The filter design was loaded on the Moku:Go.

Lock acquisition

I locked the AUX laser with the uPDH servo box and maximized its transmission to ~0.8. I then fed the Moku digital filter output to the PZT and the laser was able to catch lock. However, the max green transmission I could achieve using the Moku controller was 0.5. Attachment 2 is a screenshot of the green transmission ndscope during a lock sequence.

I measured the OLTF of the loop by injecting an excitation at the error point. An SR560 was used to sum the error signal with the excitation. The Moku multi-instrument mode was configured with the Frequency Response Analyzer and Digital Filter Box; it was able to source the excitation and take a transfer function measurement of error signal / (error signal + excitation), while keeping the loop closed.

The OLTF measurement [Attachment 3] points to a loop UGF of ~4 kHz, and phase margin of ~70 deg. An optimal controller would be able to boost the gain around the UGF without changing the phase too much (lag compensator)?

[Reuben, Radhika]

Checked out the AUX PDH locking system at the XARM. Started by locking the AUX laser using the uPDH servo box and adjusting the test masses to maximize transmission (~0.6 achieved). There were some issues where the fundamental mode would be briefly visible and then lose lock. Higher order modes were also seen which could be removed by adjusting test masses. We also noticed the laser spot moving around a lot, as if the test masses were swaying. Finally after repeated tries we managed to lock and hold the laser to the cavity long enough to measure the open loop transfer function using the Moku:Go frequency response analyzer tool. Got an idea of the finicky and temperamental nature of the locking process.

Taking the transfer function data from the Moku:Go and using a Python script, found the UGF to be around 25.6 kHz and phase margin to be around 25.5 deg. My current goal is to keep reading up on control systems and related theory (I still feel like I lack understanding of the important principles needed), and parallelly making a small script that can take the transfer functions data and calculate some useful information (halfway done).

One issue I found with the script was that the Python control library was giving me a wrong value of Gain Margin (~0.26 where ~-5 was expected) while using the control.margin function. The other parameters phase margin and crossover frequencies agree with the data visually.

[Hiroki, Mayank, Ruben, Koji]

As we expected that the X-end PZT steerers takes more times to be recovered, we decided to align the X-end beam with the PZTs not energized.

Because of some green alignment effort by the cavity mirrors earlier today (no elog seen yet), the Xarm IR alignment was found to be completely off.
We had to start over with the IR alignment and it was unexpectedly painful because...
- The X-end didn't have the oplev beam on the oplev QPD
- The ITMY was partially stuck
- ASS for the Xarm did not converge at the maximum of the transmission.

Once the Xarm was aligned, we went to the X-end and steered the two PZT mounts manually. This eventually made the x-arm green transmission (C1:ALS-TRX_OUT) to be 0.95~1.0.
It seems that this is the limit we could do.

This should make the x-end green work possible.

Earlier in the morning I tried to align the green laser of the X-arm. It was an attempt to see if green transmission can be brought up to some level. Unfortunately as seen from Koji's post, this led the IR alignment to go off.

Thanks to Koji, Hiroki and Mayank who were able to remedy this and get the green beam aligned, I can now start working on the PDH controller and run some tests with the Moku:Go.

In the meantime, a model of the plant and controller was made in Python, using a mix of transfer functions of the components taking data from Gautam's thesis, as well as frequency response data collected earlier by Radhika of the PZT and the PDH Servo Box. The open loop transfer function was calculated using the model, then tweaked to fit the open loop transfer function of the actual system collected earlier using the Moku:Go. We now have a model on which new controllers can be tested.

(Tuesday, Jun 20, 2023)

While the X end hardware was being updated, I decided to take an open loop transfer function of the green laser locking system at the Y end. It was already set up to measure the frequency response using the SR785, and i just had to take the inputs to it and just directly plug it into the Moku:Go. I was trying to test the 'Dynamic amplitude' mode of the Moku:Go's frequency response analyser, which "Increases the measurment dynamic range by reducing output signal amplitude when stauration is detected at input". There was no noticeable difference from a normal measurment without that feature and from that of the X arm measurment taken earlier. I wanted to take measurments of individual components, but didnt as I did not want to disturb the setup at the Y too much. I carefully replugged the bnc cables back into the SR785 and returned it to the way it was.

I wrote a Python code to simulate the AUX laser stabilisation system. It takes the poles and zeroes of the individual components (cavity, pzt, summer, low pass filter, pdh controller) and combines them, and shows the stability margins and impulse responses. Now any PDH controller designed can be easily plugged into the code and the stability and perfomance of the loop can be tested.

Trying to make a tabletop simulation of the setup, using an SR560 preamplifier with a second order pole at 30kHz to model the arm cavity and other ocmponents. The Moku:Go will be the digital PDH controller, and transfer of the setup will be taken with another Moku:Pro (not enough Gos). The individial and combined OLTF of the setup is taken and compared to the similar data. 

I loaded the same digital filter into both the Moku:Pro and Moku:Go, to see if there was any difference. I used the multi instrument mode, with Digital Filter and Frequency Response analyser. To my surprise, every configuration else exactly same, the transfer function was different for both Go an Pro. I also ran the Filter on the Go, and took the frequency response using the Pro, the transfer function was identical to the Go taken internally.The Pro is giving the expected transfer function. Idk if i am missing something here.

I will be testing out the digital controller on the Xend AUX setup today, replacing the anlaogue PDH box with the Moku:Go fitted with, see if i can get a lock with the digital version, see any problems that might come up.

I was able to use the Moku:Go to implement a digital controller and substitute the analog pdh box to lock the green laser at x end. I took the RFPD IF OUT (the error signal) and Servo Input (Control signal) and passed them through the Moku:Go filter. The mixer of the analog box is still used. The controller implements a digital filter with the poles and zeroes fitted to that of the analog controller. Transmission was low (~ .2 - .4), but similar to that acheived with the analog controller at the time, probably due to misalignment of the cavity. Changing the filter on the fly using the Moku gui brings about a momentary dip in transmission, but immediatley rises back to normal most of the time. The smaller the change in filter parameter (eg. gain 1dB -> 1.1 dB) the shorter the dip period.

I will test out how feasible it is to switch filters on the fly and have some python scripts that will switch filters, and one to potentially take transmission/reflection data and figure out if lock is broken. Play around with gain and offsets and filter coefficients, see what happens..
 

Wanted to see if digital filter on the Moku:Go can be changed without breaking lock. Loading different filter files broke lock. Tried to set two identical filters and have an output matrix to switch between them, but the Moku:Go lacks the capability for that, so I switched to a Moku:Pro, which lets me configure an output matrix in multi instrument mode. Changing the output matrix in multi instrument mode on the Moku:Pro does not seem to break lock, but the transmission kept jumping erratically, I did not know if the low transmission was causing the instability.Maximum transmission was around ~0.6 when locked.

Yuta let me align the arm cavity, was able to get transmission upto ~0.9 while locking with the Moku:Pro. Lock held for aorund 5-7 seconds before breaking, it was not enough time to test if changing the output matrix is breaking lock. I was able to keep it locked to a higer mode, with ~0.2 transmission (not ideal) and changing the output matrix does not cause any erratic changes in transmission (dont know if this will translate to TEM00 mode). Will try again tomorrow to change output matrix while stably locked to TEM00. I realigned the arm cavity to it's original state and got main laser transmission back to ~0.9. I also noticed that it's easier to lock when input gain is attenuated (~ -5dB), the plan is to lock with a low gain filter, and switch to a more agrressive filter to hold lock stably.

Locked with Moku:Go

Locked with Moku:Pro

Too many cavity poles! It should be just a single pole. Please show us your OLG Bode plot on the same plot as each of the individual pieces of the loop, so we can see what contributes to the TF.

Here are the transfer functions of the individual components along with the OLTF.

RXA: please spend some time trying to make the plot more useful: grid lines, distinguishable colors, zoom into important range, some text descriptions of each trace, comments on differences between theory and reality, etc., etc., etc

While modelling the system, I had no way of knowing the gain of each individual component. The individual transfer function of the PDH box and overall open loop is known, so I combined the Cavity, PZT, Low Pass filter, and Photodiode into one block, and fitted its overall gain to match with the overall OLTF of the system. 

Using this setup, with the pole values taken from Gautam’s thesis, and the fitted PDH zpk values; I was able to get the OLTF of the model to agree with the OLTF experimentally taken. I now use the model as a base for the setup, to test controller designs, impulse response, and stability margins. There is some deviation from the experimental value (~10dB in magnitude in the low frequency range, ~20 deg phase). 

We can see that at lower frequencies, the PDH box influences the transfer function while at higher frequencies the other components contribute. This is a good sign as we primarily want to increase the stability and performance of the system in the 10Hz to 20kHz range (Which is where the AUX laser noise is suspected to dominate in the ALS beat note) and this can be easily adjusted by changing the PDH box parameters. 

 I tried to simulate this block using the SR560, I tested with both a single and double pole at 30kHz. The 2-pole setup seemed to be the closest to the combined cavity, pzt, photodiode, low pass filter and summer combo (plant).  

With two poles at 30kHz and the fitted PDH controller implemented on the Moku: Go, I took an OLTF, and it was deviating ~20 dB from the model (in hindsight, I could've increased the gain in sr560 (but I dismantled the setup to use the SR560 to take OLTF at with digital controller at XEND) will take another reading if I get time, but still the phase is way off).  

I have moved onto implementing the digital PDH box on the actual system, I have not been able to design an optimal controller, but using the fitted values, and increasing gain on the Moku, I was able to achieve similar (not necessarily better in terms of open loop characteristics as that of the original PDH box. I will get some more data and post the comparisons of OLTFs and noises when locked.
 

The OLTFS of AUX locking system when locked with the PDH box, and Moku:Go and Moku:Pro running a similar filter as that of the PDH box. The Moku:Go for some reason seems to have a very low UGF (~10.8kHz) compared to the Moku:Pro  (~21.4kHz), which is a bit lower than than the original UGF of the PDH box (~24.2kHz). With a better, optimal digital controller, it could be possible to get higher low frequency gain and bandwidth. Unfortunately due to time constraints and the interferometer not being available to work on for enough time, I was not able to start testing optimal controllers. 

Today, I managed to completely substitute the analog PDH box with the Moku:Pro. Earlier, I was just taking the error signal demodulated by the PDH box only. Now i can show that the Moku can source the oscillator, and using the mixer and low pass filter retrieve the error signal using the lock in amplifier instrument, and oass it onto the digitial filter instrument to lock the box. This could mean the entire PDH box can be replaced with a Moku:Pro/Moku:Go, which allows for easy modification and upgrades, with optimal controller design. Still, the lock was brief, lasted 10-15 secs, and the transmission was noisier. I could not get a noise reading yet because getting it to maintain lock  out of the box was a bit finicky,  might have to tweak some paramters of the lock in amplifier and pdh box... 
(I also tried the same with a Moku:Go, but the transmission was even more noisier.)

(Moku Pro transmission and setup)

(Moku:Go transmission)

Wow, this is awesome. Can you plot the comparison between the measured and expected OLTFs for both (or either) Moku cases?
At low freq, the measurement of OLTFs gets difficult due to high loop suppression and the estimation will give us an idea of how the loop can be improved.

Here is the OLTF from the model of the system I made in Python. https://github.com/CaltechExperimentalGravity/LaserStabilization/blob/main/code/PlantSim/plant_model.py

With this model, I should be able to plug in potential optimal controllers and see how the OLTF might improve. The green line shows the OLTF of the model with the PDH box zpk values inputted into the Mokus, which in turn was eyeball fitted to the analog uPDH box frequuncy response. 

In hindsight I realise I have made a mistake that could explain the discrepancy in data between the Mokus. I forgot to account for the difference in sampling rate of either Mokus while making the SOS filter file. I used the same file, one that had the Moku:Gos sampling rate for both devices. Using the correct sampling rate could solve the large delta in phase, and minor changes made to the model for better estimation of the Mokus response.

I just wanted to take the same time series data I took back in 2012 (40m/6874).
ALS noise look much better than 2012, but MICH contrast during both arms hold on IR resonance with ALS looks pretty bad compared with 2012, which indicate unbalance of the arms.

[Paco, Yuta]

Attachment #1 shows tonights OOL ALS noises with the PSL hepa OFF, and arm cavities locked using POX/POY.

This evening during an FPMI lock stretch we took transfer functions from C1:LSC-DARM_IN2 to C1:ALS-BEATXY_FINE_PHASE_OUT (the individual ALS beat sensing points) to reproduce the measurement described by Anchal in (40m/17562) and also reported in his thesis. The diaggui template for this measurement was saved under /users/Templates/ALS/BEATXY_DARM_TF.xml

Anyways the residual frequency dependence shown in Attachment #2 and seems less dramatic as previously described, amounting to <10% over the DFD + phase tracker bandwidth (2kHz) and with a low excitation SNR (~ 2). According to our previous estimate there was > 100% across the same frequency band.

Wait, what?

Recently, we straightened DW switching on ETMY (40m/17875) so the DARM actuation is definitely homogeneous because both ETMY and ETMX are in the same (acquisition) mode. Before ETMY had a weird mix of DW switches. Another possibility is that the previous measurement excited only the YARM length (actuating on ETMY) thus creating a CARM as well as DARM signal which was seen by the ALS beat. This seems like a perfect recipe for confusion.

Hence I will  focus on high bandwidth CARM locking in the context of PRFPMI locking for BHD, and stop this Hi-BW CARM for calibration witch hunt.

         f_fsr
dfmn =   ----- * (m+n) * acos(sqrt(g1*g2))
           pi

I pushed the "closed loop" button on PZT2 YAW around 3:40 pm today, then roughly recentered it using the DC Offset knob on the PiezoJena controller and the IP ANG QPD readbacks.  There was a large DC shift.    We'll watch and see how much it drifts in this state.

 Here's the trend.

The transient at ~22:40 is Rob switching to 'Open Loop' on the Piezo Jena PZTs. I don't see any qualitative change in the drift after this event.

At 05:55 UTC, I removed an iris that was blocking the IP POS beam (the sum goes up from 2 to 6.5) without disturbing the mirrors who's oplev beam are on that table. Steve has conceded one sugar Napoleon after betting against my ninja-like iris skills.

We should recenter the beam on IP POS now that its unclipped - I'll let it sit this way overnight just to get more drift data.

I wanted to see how long our IP POS beam has been badly clipped - turns out its since April 1, 2007.

Steve's April Fool's joke is chronicled then. The attached trend shows that the drop in IP POS is coincident with that event.

In trying to align IPPOS, I noticed that someone has placed a ND2.0 filter (factor of 100 attenuation) in front of it. This is kind of a waste - I have removed IPPOS to fix its resistors and avoid this bad optic. Also the beam coming onto the table is too big for the 1" diameter optics being used; we need to replace it with a 2" diamter optic (Y1-2037-45P).

IP ANG dropped by a factor of 2 back in early August of '08.

We need this guy on the investigation:

Tonight I aligned the IFO by running the scripts one by one.

SRC was far off and I had to align SRM by hand before the script could work. SPOB is still low when DRM is aligned.

I'm restoring the full IFO now that I'm taking off.

I have resurrected the MC WFS on Friday night.
I have uncommented the WFS part of the MC autolocker.
The WFS total gain was empirically set to 0.1 such that the loops have no instability.

The loops somewhat worked through the weekend although they seemed to have the drift of the operating points
in accordance with the WFS spot.

According to c1scy.mdl, OL signals should be connected to adc_0_24 to adc_0_27 but they were connected to adc_0_16 to adc_0_19 which are assigned to QPD signals.

Actually cable connections were messed up. One ribbon cable was connected from QPD driver and ADC ports assigned for OL, and another ribbon cable was connected from the board combining the signals of oplev and QPD to ADC port assigned for QPD.

Now ETMY oplev is working well and aligned to center.

I found that the ADC channels for IP_ANG had been assigned to a wrong machine.

IP_ANG is supposed to be acquired at c1auxey (east end), but actually it had been at c1auxex (south end).

This is the reason why we couldn't see any signals from IP_ANG.

So I fixed it by editing the db files (i.e. ETMXaux.db and ETMYaux.db). Now it seems working fine.

This mistake obviously came from the X-Y name swapping business. Something else might be still wrong.

It turns out there are no reasonable signal from the segment 1 on the IP_ANG QPD.

For right now I can still use it as a funny QPD, but I absolutely need somebody to check and fix it in a daytime.

Rana and I found that the QPD for the optical lever at X end are showing small signals.

At this moment each of the segments exhibits approximately 200 counts when the oplev beam is centered.

These small numbers may be due to the coating of ETMX, but we are not sure.

Probably we have to increase the gain of the QPD depending on situations.

So a set of the tomorrow's daytime task is:

   1. check the trend data of the QPD outputs to see how much signals were there in the past.

   2. check the whitening filters to make sure if it's on or off.

   3. If it's necessary, increase the gain of the QPD to have reasonable readouts.

I am going to ask somebody to do this task.

I tried aligning the IR beam axis for the X arm to have good beam centering on ITMX and ETMX.

As a first attempt, I started translating the beam upward by steering PZT1 and PZT2, since the pitch was quite off from the center on ITMX.

As a result I could decrease the pitch off-centering down to about 0.5 mm on ITMY, but on the other hand TRX decreased a lot (by a factor of 4).

I am worrying if something in the central part of IFO might be clipping the beam.

(notes)

When I was touching PZT1 and PZT2, I payed attention on IP_ANG so that I don't lose a beam spot on IP_ANG.

As long as the beam is on the IP_ANG QPD, the angle of the beam should not be so much different.

Each time after I touched the PZTs, I realigned ITMX and ETMX to maximize the transmitted light.

In this way I proceeded the alignment by changing the PZT offsets little by little while keeping the X arm locked always.

At the beginning, all the PZT offsets were zero. And at the end of this work they became:

 C1:LSC-PZT1_Y = 1.880

 C1:LSC-PZT2_Y = -1.699

But during this alignment work TRX gradually decreased eventually down to 0.25, which had been 1 at the beginning (TRX is calibrated by dividing it by its maximum power).

Along with this TRX reduction, I found that the optical gain also decreased by a factor of about 5.

This fact has been confirmed by intentionally increasing the filter gain such that the servo oscillates at the UGF.
 

[Valery, kiwamu, Jenne, Suresh]

    I first interchanged the two QPD's on the Y end table to see if the problem QPD related.  Exchanging the units did not make any difference.  The problem therefore had to be in the cables or the circuit boards in 1X4

    We traced the signals pertaining to the IP_ANG QPD ( "Initial Pointing Beam") using  Jay's wiring diagram (pages 2 and 5 of 7).  We noted that while the signals were available on all Segments till the Monitors (Lemo) on 1X4-2-2A card, two of the lines did not reach the output of the cross connect 1X4-B8.  We checked card to make sure that the signals were indeed reaching the back plane of the 1X4-2 chassis using a D990612 extension board.  The card was found to be okay.  We therefore suspected that the cable (CAB_1X4_?) going from the card to the cross connect 1X4-B8 was faulty.  Indeed visual inspection showed that the crimping of the connector was poor and weight of the cable had put further strain on the crimping.  

   I changed the 64-pin connector on the 1X3-2-2A side of the cable. 

When I connected everything back together the problems persisted. Namely the lines P1-1A  (Segment 1 high) and P1-2C (Segment 2 Low) were floating They were not reaching points 2T and 3T respectively on the output of the cross connect.

   I therefore replaced 1X4-B8 with a similar unit which I found in one of the shelves along the East (Y) arm. 

I then checked with the StripTool to make sure that all the quadrants are showing similar response to a flashlight on the QPD.   All Segments are working fine now. Currently the IR Initial Pointing beam reaches the QPD but is not centered on it. 

I did not attempt to center it since the beam appeared to be clipped and may anyway require repositioning.

JD: We need to meditate on where this beam could be getting clipped.  Suresh and I checked that it's not on the viewport on the beam's way out of the ETMY chamber by seeing that the beam is far away from the edges of the viewport, and also far away from the edges of the black beamtube between the viewport and the table.  Suresh mentioned that the clipping nature of the IP_ANG beam sometimes goes away.  I don't know if this is the same clipping that Kiwamu might be seeing with the main beam, or if this is separate clipping just with the IP beam, after it's been picked off.  I suspect it's the same as what Kiwamu is seeing....maybe when we move PZT1, we clip on one of the MMT mirrors or PZT2??  If this is true, it's a total pain since we might have to vent if we can't steer around it.

[Jenne and Kiwamu]

 This time we aligned the vertical angle (not the translation) of the IR beam so that the transmitted light from BS shoots the center of ETMY.

The idea is to use ETMY as a beam pointing reference instead using IP_ANG, assuming the translation is not so bad.

As a result it looks like we are wining. A quick A2L test on ITMX_PITCH showed a small off-centering at sub-milimeter level.

 We are concluding that the initial beam after PZT2 had been pointing downward somehow.

Before doing this whole job, we checked the spot shape on IP_POS to see if the beam is clipped or not. It was a round shape, which means no clipping around MMT.

But on the other hand, the spot on IP_ANG had been clipped more than half of its bottom as Suresh reported on his elog (see here).

I found that this clipping is able to be fixed by moving the beam angle upward. I guess the clipping happened at one of the steering mirror in the ETMY chamber.

According to these information, we imagined that the beam was somehow pointing downward after PZT2.

So we started aligning the beam by touching only PZT2 for vertical direction. Then we found a beam spot on ETMY's suspension frame, and brought it to the center.

Then we aligned BS and X arm for this new beam axis. The it resulted a small off-centering on pitch.

Once the MC fully gets back, we will examine the TRX degradation with this configuration.

 I made several scripts to handle the mcass configuration and sensing measurements:

- The scripts and data are in the scripts/ASS directory

- The mcassUp script restores the settings for the digital lockins: oscillator gains, phases, and filters. The MC mirrors are modulated in pitch at 10, 11, 12 Hz and in yaw at 10.5, 11.5, and 12.5 Hz. The attached plot shows the comb of modulation frequencies in the MCL spectrum.

- The mcassOn and mcassOff scripts turn on and off the dither lines by ramping up and down the SUS-MC1_ASCPIT etc gains

- The senseMCdecenter script measures the response of the MCL demodulated signals to the decentering of the beam on the optics by imbalancing the coil gains by 10% which corresponds to the shift of the optic rotation point relative to the beam by 2.65 mm (75mm diameter optic) and allows calibration of the demodulated signals in mm of decentering. The order of the steps was MC1,2,3 pitch and MC1,2,3 yaw. The output of the script can be redirected to the file and analyzed in matlab. The attached plot shows the results. The plot was made using the sensemcass.m script in the same directory.

- The senseMCmirror script measures the response of the MCL demodulated signals to the mirror offsets (SUS-MC1_ASCPIT etc filter banks). The result is shown below (the sensemcass.m script makes this plot as well). There is some coupling between pitch and yaw drives so the MC coils can use some balancing - currently all gains are unity.

- The senseMCdofs scripts measures the response to the DOF excitation but I have not got to it yet.

- The next step is to invert the sensing matrix and try to center the beams on the mirrors by feeding back to optics. Note that the MC1/MC3 pitch differential and yaw common dofs are expected to have much smaller response than the other two dofs due to geometry of this tree mirror cavity. We should try to build this into the inversion.

The alignment of the interferometer goes basically step by step.

Tuesday will be an alignment day.

  0. MC beam centering (it's done)

  1. F2P to balance the coils on every optics including BS, PRM, SRM, ITMs and ETMs (Kiwamu).

  2. A2L and then change the DC bias of ITMY and ETMY to get a perfect eigen axis (VF/Jamie).

  3. align input PZT mirrors (PZT1 and 2) to maximize the Y arm transmission (VF/Jamie).

  4. do the same things for X arm but using BS instead of the PZTs.

  5. Alignment of the central part.

  6. Make a script to automatically get those things done. 

[Jamie / Valera / Kiwamu]

 The incident beam pointing was improved a lot by using C1ASS realtime code.

Some more details will be posted later. The below is the list of the highlights today.

 - The Y arm cavity was aligned to have good beam centering on the mirrors.

 - The input PZTs were also aligned to the aligned Y arm by hand.

 - Automation of the  Y arm alignment using C1ASS_LOCKIN got partially functional with two loops closed. C1ASS correctly servos the centering on ETMY

 - The amount of the off-centering on ITMY and ETMY look roughly within 1 mm.

 - As a result the intracavity power got bigger by a factor of about 3.5

I closed all 8 dither loops for the Y arm initial alignment: 2x2 centering servo (this worked before) and 2x2 input beam servo for both pitch and yaw.

So far it looks pretty good - the error points go to zero and the arm power goes up to 1.

The offloading to the alignment biases and the PZTs is not yet automated.

Today the PMC, MC, and Y arm were very cooperative and a pleasure to work with.

WFS1 Transimpedance

The attached plots show the location of the ~29.5 MHz pole and the 59 MHz notch for each quadrant of the WFS1 Sensor head.

As may be seen from the above table, these frequencies will need to be adjusted in some cases.

From the plots we can see that, when there is no attenuation set on the attenuator AT65-0263 (ref D990249-A),  the MAX4107  oscillations are seen in Q2,Q3,Q4 quadrants at around 200 MHz.  

Rana suggested, from his previous encounter with this circuit, that the solution is to remove the second MAX4106 and the attenuator on the RF line to avoid this oscillation.

A look at the circuit board shows that some of the inductors have not been mounted.  That explains the presence of only one notch though the schematic shows two. 

Last night I aligned the incident beam axis and the Yarm by touching the PZT mirrors and the suspensions.

I didn't estimate how good they were aligned, but I guess the Y arm is now ready for the Y green light.

 Next : Y green alignment and the MC spots measurement / alignment.

 ++ Motivation ++

Prior to the coming vent we want to have the Y arm, incident beam axis and Y green light aligned so that we can align some necessary optics in the chamber.

Also alignment of the incident beam will allow us to re-position the incident beam alignment monitor (i.e. IPPOS and IPANG).

Our plan was to first align the Y arm using the ASS system and then align the Y green light to the Y arm.

++ what I failed ++

First I was trying to measure the spot positions on the MC mirrors to make me sure the beam axis has/hasn't changed.

Also I was going to align the MC suspensions to have nice spot position on each suspension using the MCASS system

because this will help us checking the beam clearance in the Faraday and perhaps re-positioning of the Faraday during the coming vent.

But essentially I failed and eventually gave up because MCASS didn't work. It seems that MCASS needs some modifications in the scripts.

Then, to make me feel better I moved on to the Y arm and beam axis alignment.

++ what I did ++

I tried using C1ASS to align the incident beam and suspensions on the Y arm, but it didn't work.

However the drive signals from ASS and its demodulated signals looked fine. Only the feedback did not work correctly.

Every time I enabled the feedback paths, the arm just lost the lock. Something is wrong in the feedback paths.

Then I started to align the cavity by my hands while looking at the demodulated signal from each LOCKIN module.

I aligned the things until each demodulated signal fluctuates around zero.

At the end the beam spots on the ETMY and ITMY camera looked well-aligned and the transmitted light became larger by a factor of 2ish.

The servos of C1ASS for the Y arm and the beam axis alignments were fixed.

Now we can correctly run the Y arm ASS from the C1IFO_CONFIGURE window as usual.

The sign of some control gains had been flipped for some reasons, so I changed them to the correct signs.

Next : Health-check for the X arm ASS, the loss measurements.

Since we will measure (and hopefully adjust) the spot positions on the MC suspensions prior to the vent, MCASS is necessary for it.

#######################

Here is the MCASS status so far:

  + Valera worked on MCASS on the last February, and basically no progress after he left.

  + The MCASS model had been completed in C1IOO.mdl.

  + He made some useful scripts, including mcassup, mcassOn/Off, senseMCdecenter, senseMCmirrro and senseMCdofs.

       Summary of those scripts can be found in his entry #4355.

  + We haven't closed the MCASS loops.

  + The control filters are still blank.

  + We haven't put any elements on the input and output matrices.

  + Some parameters for the dithering oscillators and demodulation systems were properly set.

     So we can get the demodulated signals by simply running mcassUp and mcassOn. (This essentially corresponds to the A2L measurement.)

  + The PIT motions are driven at 10, 11 and 12 Hz for MC1, 2 and 3 respectively. For YAW, the frequencies were chosen to be 11.5, 12.5 and 13.5 Hz.

  + Some medm windows were prepared but not as refined as that of ASS.

  + Valera performed a measurement of the spot positions by using MCASS. The results are summarized in #4660.

  + We made an estimation about the beam clearance on the Faraday based on the measured spot positions (#4674)

#########################

So, it seems we should be able to at least measure the spot positions soon by using his scripts.

The X arm ASS was also fixed. So both X and Y arm ASS are now back to normal.

Now we can align the arms any time from the buttons on the C1IFO_CONFIGURE window.

(notes)

The reason why the servo didn't work was that the sign of some control gains had been flipped.

This was exactly the same situation as that in the Y arm ASS (#5067).

SUS-ETMY_QPD is not responding. It is reading zero in dataviewer and 4,400 counts on QPD MEDM screen.......must be wrong cable connected

IP-POS is sick. Last time alive 7-19-2011

IP-ANG beam is clipping on pick-up mirror at ETMY chamber. This will have to be fixed at the vent. The qpd itself is responding to light.

The interferometer was coarsely aligned.

Now spatially overwrapped DRMI and FP arm fringes are visible on the AS camera although the incident beam alignment was done only with PZT2.

All the DC biases were saved so that we can go back to this condition any time.

/***** some health checks *******/

 [FINE] IPPOS : it looks okay but the spot on the QPD is a little bit too low by a few mm.

 [NOT GOOD] IPANG : maybe hitting a post or something because the spot is vertically split into two. The spot is too low.

 [FINE] POX/POY/POP : they all are coming out. POP is visible with an IR viewer.

 [FINE] REFL :  no clipping but the beam looks a little bit too low relative to the CCD camera.

 [FINE] AS : no clipping and the spot position on the AS camera looks fine.

 [FINE] Green beams : both X and Y beams are successfully landing onto the PST table without no clipping.

 [FINE] Suspensions : all of them are reasonably quiet without the oplevs, which is good.

The output matrix in the C1ASS servo were coarsely readjusted and the servos seemed working.

However it is difficult to say the servo is very good or so-so,

because the ETMY suspension moves a lot and hence the cavity eigen axis moves a lot too.

(to do)

(Background)