40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 322 of 335 Not logged in
ID Date Author Type Category Subject
9625   Tue Feb 11 22:17:06 2014 KojiUpdateGreen LockingALS X and Y arm restored

Nice restoration. We eventually want to make transition of the servo part from ALS to LSC model for the further handing off to the other signals.

9721   Tue Mar 11 19:38:26 2014 manasaUpdateGreen LockingALS Slow servo settings

 Quote: Nic, Jenne, EricQ, and Koji should describe the demonstartion of CESAR achieved tonight.

Q and I have started to use the ALS slow servo for the end aux lasers while locking the arms using ALS. The servo prevents us from hitting the limits of the PZT range for the end lasers and a better PDH locking.

But keeping the servo ON causes the slow output to drift away making it hard to find the beat note everytime the arm loses lock. The extensive beat note search following the unlock can be avoided by clearing history of the slow servo.

9727   Fri Mar 14 10:31:10 2014 jamieUpdateGreen LockingALS Slow servo settings

 Quote: Q and I have started to...

Ha!

11891   Thu Dec 17 16:44:03 2015 gautamUpdateCDSALS Slow control MEDM screen updated
 Quote: I've not updated the MEDM screens to reflect the two new paths yet, but will do so soon. It also remains to install appropriate filters for the servo path that takes the frequency readout as the input.

A few more related changes:

1. The couplers that used to sit on the green beat PDs on the PSL table have now been shifted to the IR broadband PDs in the FOL box so that I can get the IR beat frequency over to the frequency counters. The FOL box itself, along with the fibers that bring IR light to the PSL table, have been relocated to the corner of the PSL table where the green beat PDs sit because of cable length constraints.
2. I've updated the ALS slow control MEDM screen to allow for slow control of the beat frequency. The servo shape for now is essentially just an integrator with a zero at 1 Hz. The idea is to set an offset in the new filter module, which is the desired beat frequency, and let the integrator maintain this beat frequency. One thing I've not taken care of yet is automatically turning this loop off when the IMC loses lock. Screenshot of the modified MEDM screen is attached.
3. I checked the performance by using the temperature sliders to introduce an offset. The integrator is able to bring the beat frequency back to the setpoint in a few seconds, provided the step I introduced was not two big (~20 counts, but this is a pretty large shift in beat frequency, nearly 20MHz).

To do:

1. Figure out how to deal with the IMC losing lock. I guess this is important if we want to use the IR beatnote as a diagnostic for the state of the X AUX laser.
2. Optimize the servo gains a little - I still see some ringing when I introduce an offset, this could be avoided...
16161   Tue May 25 17:42:11 2021 Anchal, PacoSummaryALSALS Single Arm Noise Budget

Here is our first attempt at a single-arm noise budget for ALS.

Attachment 1 shows the loop diagram we used to calculate the contribution of different noises.

Attachment 2 shows the measured noise at C1:ALS-BEATX_PHASE_FINE_OUT_HZ when XARM was locked to the main laser and Xend Green laser was locked to XARM.

• The brown curve shows the measured noise.
• The black curve shows total estimated noise from various noise sources (some of these sources have not been plotted as their contribution falls off the plotting y-lims.)
• The residual frequency noise of Xend green laser (AUX) is measured by measuring the PDH error monitor spectrum from C1:ALS-X_ERR_MON_OUT_DQ. This measurement was converted into units of V by multiplying it by 6.285e-4 V/cts. This factor was measured by sending a 43 Hz 100 mV sine wave at the readout point and measuring the output in the channel.
• This error signal is referred to AUX_Freq input in the loop diagram (see attachment 1) and then injected from there.
• All measurements were taken to Res_Disp port in the 'Out-of-Loop Beat Note' block (see attachment 1).
• In this measurement, we did not DAC noise that gets added when ALS loop is closed.
• We added ADC noise from Kiwamu's ALS paper after referring it to DFD input. DFD noise is also taken from Kiwamu's ALS paper data.

### Inference:

• Something is wrong above 200 Hz for the inclusion of AUX residual displacement noise. It is coming off as higher than the direct measured residual noise, so something is wrong with our loop diagram. But I'm not sure what.
• There is a lot of unaccounted noise everywhere from 1 Hz to 200 Hz.
• Rana said noise budget below 1 Hz is level 9 stuff while we are at level 2, so I'll just assume the excess noise below 1 Hz is level 9 stuff.
• We did include seismic noise taken from 40m noise budget in 40m/pygwinc. But it seems to affect below the plotted ylims. I'm not sure if that is correct either.

### Unrelated questions:

• There is a slow servo feeding back to Green Laser's crystal temperature by integrating PZT out signal. This is OFF right now. Should we keep it on?
• The green laser lock is very unreliable and it unlocks soon after any signal is being fed back to the ETMX position.
• This means, keeping both IR and green light locked in XARM is hard and simultaneous oscillation does not last longer than 10s of seconds. Why is it like this?
• We notice that multiple higher-order modes from the green laser reach the arm cavity. The HOMs are powerful enough that PDH locks to them as well and we toggle the shutter to come to TEM00 mode. These HOMs must be degrading the PDH error signal. Should we consider installing PMCs at end tables too?
16164   Thu May 27 11:03:15 2021 Anchal, PacoSummaryALSALS Single Arm Noise Budget

Here's an updated X ARM ALS noise budget.

## Things to remember:

• Major mistake we were making earlier was that we were missing the step of clicking  'Set Phase UGF' before taking the measurement.
• Click the clear phase history just before taking measure.
• Make sure the IR beatnotes are less than 50 MHz (or the left half of HP8591E on water crate). The DFD is designed for this much beatnote frequency (from Gautum).
• We took this measurement with old IMC settings.
• We have saved a template file in users/Templates/ALS/ALS_outOfLoop_Ref_DQ.xml . This si same as ALS_outOfLoop_Ref.xml except we changed all channels to _DQ.

## Conclusions:

• Attachment 1 shows the updated noisebudget. The estimated and measured RMS noise are very close to eachother.
• However, there is significant excess noise between 4 Hz and 200 Hz. We're still thinking on what could be the source of these.
• From 200 Hz to about 3 kHz, the beatnote noise is dominated by AUX residual frequency noise. This can be verified with page 2 of Attachment 2 where coherence between AUX PDH Error signal and BEATX signal is high.
• One mystery is how the measured beatnote noise is below the residual green laser noise above 3 kHz. Could this be just because the phase tracker can't measure noise above 3kHz?
• We have used estimated open loop transfer function for AUX from poles/zeros for uPDH box used (this was done months ago by me when I was working on ALS noise budget from home). We should verify it with a fresh OLTF measurement of AUX PDH loop. That's next on our list.
15211   Thu Feb 13 21:30:55 2020 shrutiUpdateALSALS OOL noise with arms locked

[Meenakshi, Gautam, Shruti]

Summary:

- We initially aligned the arm cavities to get the green lasers locked to them. For the X arm cavity, we tweaked the ITMX and ETMX pitch and yaw and toggled the X green shutter until we saw something like a TEM00 mode on the monitor and a reasonable transmitted power.

- With the LSC servo enabled, the IR light also became resonant with the cavities.

- Then we measured the noise in different configurations. Attachment 1 shows the the ALS OOL (in the IR beat signal) noise with the arms locked inidividually via PDH.

The script for plotting the ALS beat frequency noise is:

users/Templates/ALS/ALS_outOfLoop_Ref.xml
15213   Fri Feb 14 14:02:13 2020 shrutiUpdateALSALS OOL noise with arms locked

[Meenakshi, Shruti]

Even though we were not able to lock the the IR beat (by enabling LSC) during the day possibly because of increased seismic activity, we tried to the measure the ALS beat frequency noise by changing the PDH side-band frequency to different values.

I tried choosing values that corresponded to the peaks in the PM/AM as found in elog:15206 but for some reason unknown to us the cavity did not lock between 700-800 kHz.

The three attachments have data for different sideband frequencies:

Attachment 1: 819.472 kHz (peak in PM/AM, measured around noon)

Attachment 2: 225.642 kHz (peak in PM/AM, measured earlier in the morning)

Attachment 3: 693.500 kHz (not a peak in PM/AM)

We don't think these plots mean much and will do the measurement at some quieter time more systematically.

While doing the experiment, the ITMY pitch actuation was changed from -2.302 to -2.3172V because it locked better.

The ITMX, ETMX alignment was also tweaked to try to lock with different sideband frequencies and then restored to the values that were found earlier in the morning.

15214   Fri Feb 14 14:52:41 2020 gautamUpdateALSALS OOL noise with arms locked

Unlikely, the alignment was probably just not good. I restored the alignment and now the arms can be locked to IR frequency.

 Quote: Even though we were not able to lock the the IR beat (by enabling LSC) during the day possibly because of increased seismic activity
15216   Tue Feb 18 18:14:59 2020 shrutiUpdateALSALS OOL noise with arms locked

We proceeded with the trying to measure the ALS out-of-loop noise of the X arm when the X arm cavity is green-locked using different PDH sideband frequencies.

Before doing the experiment, Koji helped us with getting the arm cavities locked in IR using LSC (length) and ASC (angular).

With the arms locked in IR and green, we repeated the same measurements as before at different sideband frequencies (Refer Attachment 1 - label in Hz). We did not optimize the phase nor did we look at the PDH error signal today which is possibvly why we did not see an improvement in the noise. We will look into this possibly tomorrow.

15217   Wed Feb 19 22:20:22 2020 ranaUpdateALSALS OOL noise with arms locked

Could you please put physical units on the Y-axis and also put labels in the legend which give a physical description of what each trace is?

It would also be good to a separate plot which has the IR locking signal and the green locking signal along with this out of loop noise, all in the same units so that w can see what the ratio is.

15220   Fri Feb 21 20:44:18 2020 shrutiUpdateALSALS OOL noise and PDH

[Meenakshi, Shruti]

In order to adjust the relative phase for PDH locking, we used the Siglent SDG 1032X function generator which has two outputs whose relative phase can be adjusted.

This Siglent function generator was borrowed from Yehonathan's setup near the PSL table and can be found at the X end disconnected from our setup after our use.

Initially, we used the Siglent at 231.250 kHz and 5 Vpp from each output with zero relative phase to lock the green arm cavity. By moving the phase at intervals of 5deg and looking at the PDH error signals when the cavity was unlocked we concluded that 0deg probably looked like it had the largest linear region (~1.9 V on the yaxis. Refer elog 15218 for more information) as expected.

Then we tried the same for 225.642 kHz, 5 Vpp, and found the optimal demod phase to be -55deg, with linear region of ~3 V (Ref. Attachment 2). A 'bad' frequency 180 kHz was optimized to 10deg and linear region of ~1.5 V.

The error signals at higher frequencies appeared to be quite low (not sure why at the moment) and tuning the phase did not seem to help this much.

For the noise measurement, the IFO arms were locked to IR and green, but even after optimizing the transmission with dither, we couldn't achieve best locking (green transmission was around ~0.2). Further, the IMC went out of lock during the experiment after which Koji helped us by adjusting the gains a locking point of the PMC servo. Attachment 1 contains some noise curves for the 3 frequencies with a reference from an earlier 'good' time.

15221   Sun Feb 23 18:15:22 2020 ranaUpdateALSALS OOL noise and PDH

to make the comparisons meaningfully

one needs to correct for the feedback changes

faithfully

14918   Mon Sep 30 18:20:26 2019 gautamUpdateALSALS OOL noise - a first look

Attachment #1 shows a first look at the IR ALS noise after my re-coupling of the IR light into the fiber at EY.

Measurement configuration:

• Each arm length was individually stabilized to the PSL frequency using POX/POY locking.
• The respective AUX laser frequencies were locked to the arm cavity length using the AUX PDH loops.
• GTRX ~0.3 (usually I can get ~0.5) and GTRY ~ 0.2 (the mode-matching to the arm cavities is pretty horrible as suggested by the multitude of bullseye modes seen when toggling the shutter).
• The control signal to the AUX PZT had the DC part offloaded by the slow temperature control servos to the AUX laser crystal temperature.

CDS model changes:

• The c1lsc model was modified to route the input signals to the Y phase tracker servo from ADC1_2 and ADC1_3 (originally, they were ADC0_20 and ADC0_21).
• This change was necessary because the DFD output is sent differentially to the ADC1 card in the c1lsc expansion chassis (bypassing the iLIGO whitening and AA electronics, for now just going through an aLIGO AA board with no whitening available yet).
• I chose to use the differential receiving (as opposed to using the front-panel single ended BNC connectors) as in principle, it is capable of delivering better noise performance.
• After making the model changes, I compiled and restarted the model. Apart from the missing path issue, the compile/restart went smoothly.

Next steps:

• Get the easy fixes done (better GTRX, GTRY).
• Test the noise with POX and POY as the OOL sensors, and the arms controlled using the ALS error signal - this is the relevant metric for how ALS will be used in locking.
• Noise budget. Need to double-check the DFD output calibration into Hz.
• For the general interferometer recovery, I think I will push ahead with trying to lock some other configurations like the PRMI (should be easy to recover), DRMI (potentially more difficult to find the right settings), and the FPMI (I'd like to use this config to get an estimate for how much contrast defect we have in the interferometer, but I think it'll be pretty challenging to lock in this configuration).
15157   Sun Jan 26 14:40:55 2020 gautamUpdateALSALS OOL noise

In preparation for resuming IFO locking activities, I measured the ALS noise with the arm lengths locked to IR, AUX laser frequencies locked to the arm lengths. Looks promising (y-axis units are Hz/rtHz).

13238   Tue Aug 22 02:19:11 2017 gautamUpdateALSALS OLTFs

Attachment #1 shows the results of my measurements tonight (SR785 data in Attachment #2). Both loops have a UGF of ~10kHz, with ~55 degrees of phase margin.

Excitation was injected via SR560 at the PDH error point, amplitude was 35mV. According to the LED indicators on these boxes, the low frequency boost stages were ON. Gain knob of the X end PDH box was at 6.5, that of the Y end PDH box was at 4.9. I need to check the schematics to interpret these numbers. GV Edit: According to this elog, these numbers mean that the overall gain of the X end PDH box is approx. 25dB, while that of the Y end PDH box is approx. 15dB. I believe the Y end Lightwave NPRO has an actuator discriminant ~5MHz/V, while the X end Innolight is more like 1MHz/V.

Not sure what to make of the X PDH loop measurement being so much noisier than the Y end, I need to think about this.

More detailed analysis to follow.

 Quote: I am now going to measure the OLTFs of both green PDH loops to check that the overall loop gain is okay, and also check the measurement against EricQ's LISO model of the (modified) AUX green PDH servos. Results to follow.

13244   Tue Aug 22 23:27:14 2017 ranaUpdateALSALS OLTFs

Didn't someone look at what the OLG req. should be for these servos at some point? I wonder if we can make a parallel digital path that we switch on after green lock. Then we could make this a simple 1/f box and just add in the digital path (take analog control signal into ADC, filter, and then sum into the control point further down the path to the laser) for the low frequency boost.

9283   Thu Oct 24 19:12:45 2013 MasayukiUpdateGreen LockingALS OFFSETTER calibration

I calibrated the ALS-OFFSETTER output.
I measured the FSR of cavity in unit of counts. That was 395 counts. Our cavity FSR is 3.8 MHz, so 1 count of the OFFSETTER output is 9.7 kHz.

9284   Thu Oct 24 21:46:18 2013 KojiUpdateGreen LockingALS OFFSETTER calibration

 Quote: I calibrated the ALS-OFFSETTER output. I measured the FSR of cavity in unit of counts. That was 395 counts. Our cavity FSR is 3.8 MHz, so 1 count of the OFFSETTER output is 9.7 kHz.

Really? What cavity length did you use in the calculation?

11046   Wed Feb 18 01:58:51 2015 ericqUpdateLSCALS Fool single arm performance

I'm playing around with the lastest ALS fool feedforward on the Yarm, and I like what I'm seeing.

First, I verified that I could reproduce the TF shapes in ELOG 11041, which I was able to do with a gain of +9.3 and FMs 5 and 6 in the FF module.

Then, I locked the arm on ALS with full bandwidth, and on POY with the settings currently used the MC module, and took their spectra as references. (I put an excitation on the arm at 443Hz to line them up to the same arbitrary units.)

Then, with ALS at its usual 100Hz UGF and boosts on, the Fool path on, and the MC FM set to trigger on/off at 0.8/0.5, I slowly brought ALS towards zero offset and saw it pop right into resonance.  I then manually triggered the PDH boosts.

Here are some spectra, showing that, with the Fool path on:

• POY unsurprisingly picks up the high frequency noise of the ALS. (Could be mitigated by judicious lowpassing?)
• The in-fool-loop POY noise is WAY more supressed at low frequencies, so the loops are definitely working together. RMS is about 2x smaller too.

Once the PDH loop is running, the ALS loop can be switched out at the CARM FM output without much of an effect beyond a small kick.

However, looking at the loop shapes, maybe I got lucky here. I took the usual injection TFs at the MC FM, the CARM FM, and at ETMY, to get the overall OLG; all of them have >0.9 coherence pretty much everywhere except the first two points.

As desired, the PDH loop looks pretty normal.

I have no intuition about how the fooled CARM loop should look, since this is even more complicated than a two-loop system.

I don't currently know what is causing the odd feature in the overall at ~50Hz, and it spooked me out when I saw the multiple UGF crossings. The only thing I could think of happening there is the pole in the ALS phase tracker boost. I turned it off, and remeasured; the feature persists...

To wrap it up, here's something I think is pretty cool. Here's what happens when I give ETMY a 1000 count position step impulse (no ramp). [Here, CARM is on ALS with G=12, but only FM5 on]

Although the arm was controlled with IR before the kick, ALS maintained control. As soon as ALS brought the arm back towards resonance, the PDH loop picked it right back up.

Coooool.

Some random notes:

• We should really DQ the output of the feedforward FM. I'll try to remember to do this tonight
• I was having problems with the zero crossing triggering, so I didn't end up using it, desipte trying to. Maybe we should implement the Schmitt-y style of "Am I below the threshold? Wait. Am I closer to zero now? Ok, Go!"
• The 1Hz pole in the FF FM rings, unsurprisingly, when the MC FM triggers on briefly, which can be a pain. I made a FM4 which is a Q=1 (instead of 7) pole pair for less ringy. This probably hurts the cancellation somewhat, but I was impatient.
• Alternatively, we could try to figure out how to force history clear when the MC filter is triggered off.

DTT data is attached, in case it's useful to anyone!

11047   Wed Feb 18 17:51:40 2015 ericqUpdateLSCALS Fool impulse response

Koji raised a good question about the step response I wrote about. Namely, if the UGF of the ALS servo is around 100Hz, we would expect it to settle with a characteristic time on the order of tens of milliseconds, not seconds, as was seen in the plot I posted.

I claim that the reason for the slow response was the fact that the feedforward FM stayed on after the kick, despite the MC filter bank being triggered off. Since it has filters that look like a oscillator at 1Hz, the ringdown or exponential decay of this filter's output in response to the large impulsive output of the PDH control signal just before being triggered down would slowly push the ALS error signal around through the feedforward path.

Given this reasoning, this should be helped by adding output triggering to the FF filter that uses the MC trigger matrix row, as I wanted to do anyways. I have now added this into the LSC model (as well as DQ at 2kHz for the MC_CTRL_FF_OUT), and the impulse response is indeed much quicker.

In the following plot, I hit ETMY with a five sample, 5000 amplitude, impulse (rather than a step, as I did yesterday). The system comes back to PDH lock after ~40ms.

11048   Wed Feb 18 19:06:40 2015 KojiUpdateLSCALS Fool impulse response

11041   Tue Feb 17 00:24:47 2015 rana, jenneUpdateLSCALS Fool filter updated for more cancellation

## Today we measured the TFs again and then updated the filter in the POY -> ALS FF path so as to get 10x better cancellation.

The cancellation went from ~10 dB to ~30 dB. This seems good enough. The new filter 'Comp1' is just constructed by eye. We then had to tune the filter module gain to a few %. Seems good enough for now, but we should really try to understand what it is and why it is the way that it is. In the above plot, the ORANGE trace is the old cancellation and the GREEN one is the new one. The filter TF is attached below - its not special, we made it by presing buttons in FOTON until the TF matched the measured TF of ALSY/LSC-MC_CTRL_FF_OUT.

11484   Thu Aug 6 11:45:01 2015 JessicaUpdateGeneralALS Delay Line front panel testing

Koji had suggested that I sync up the two function generators to ensure that they have the same base frequency and so that crosstalk will actually appear at the expected frequency. After syncing up the two function generators, I drove the following frequencies through each cable:

Conductive SMAs:

X: 29.537 MHz           Y: 29.5372 MHz

Isolated SMAs:

X: 29.545 MHz           Y: 29.5452 MHz

Each time, the difference between the frequencies was 200 Hz, so if there was crosstalk, a spike should appear in the PSDs at 200 Hz when frequencies are being driven through both cables simulataneously, but not when just one is on. We very clearly see a spike at 200 Hz in both the X arm and the Y arm with the conductive SMAs, indicating crosstalk. For the front panel with isolated SMAs, we see a spike at 200 Hz when both frequencies are on, but it is much less pronounced than with the conductive SMAs. It seems as though there will be crosstalk using either panel, just less with the isolated SMAs.

11471   Thu Jul 30 18:58:36 2015 JessicaUpdateGeneralALS Delay Line Box Front Panel Testing

I tested both of the front panels (conductive and isolated SMAs) with the ALS Delay Line Box by driving extremely close frequencies through the cables. By doing this, we would expect that a spike would show up in the PSD if there was crosstalk between the cables.

In the plots below, for the conductive panel, the frequencies used were

X Arm:  22.329 MHz                        Y Arm: 22.3291 MHz

For the isolated panel, the frequencies were

X Arm: 22.294 MHz                         Y Arm: 22.2943 MHz

This gives a difference of 100 Hz for the conductive panel and 300 Hz for the isolated panel. Focusing on these areas of the PSD, it can be seen that in the Y Arm cable there is a very clear spike within 30 Hz of these differences when frequencies are being driven through both cables as opposed to the signal being in only the Y Arm. In the X Arms, the noise in general is higher when both cables are on, but there is no distinct spike at the expected frequencies. This indicates that some sort of crosstalk is probably happening due to the strong spikes in the Y Arm cables.

11440   Thu Jul 23 20:54:42 2015 JessicaUpdateGeneralALS Delay Line Box

The front panels for the ALS delay line box came in last week. Some of the holes for the screws were slightly misaligned, so I filed those and everything is now put together. I just need to test both front panels to determine if the SMAs should be isolated or not.

Koji had also suggested making the holes in the front and back panel conical recesses so that flat head screws could be used and would counteract the anodization of the panel and avoid the SMAs being isolated. I think if we did that then conductivity would be ensured throughout the panel and also through the rest of the box. I also think one way we could test this before drilling conical recesses would be to test both front panels now, as one has isolated SMAs and one has conductive SMAs. If the anodization of the panel isolated the SMA regardless, we could potentially figure this out by testing both panels. But, would it also be that it is possible that the isolation of the SMA itself does not matter and so this test would tell us nothing? Is there a better way to test if the SMAs are being isolated or not? Or would this be more time consuming than just drilling conical recesses as a preventative measure?

10396   Thu Aug 14 22:58:59 2014 rana, jenneSummaryGreen LockingALS DIFF tuning

We've been having trouble tuning the ALS DIFF matrix. Trying to see if the MC2 EXC can be cancelled in ALS DARM by adjusting the relative gains in ALSX and ALSY Phase Tracker outputs.

There's a bunch of intermittent behavior. Between different ALS locks, we get more or less cancellation. We were checking this by driving MC2 at ~100-400 Hz and checking the ALS response (with the ALS loops closed). We noticed that the X and Y readbacks were different by ~5-10 degrees and that we could not cancel this MC2 signal in DARM by more than a factor of 4-5 or so. In the middle of this, we had one lock loss and it came back up with 100x cancellation?

Attached is a PDF showing a swept sine measurement of the ALSX, ALSY, and DARM signals. You can see that there is some phase shift between the two repsonses leading to imperfect cancellation. Any ideas? Whitening filters? HOM resonance? Alignment?

9872   Mon Apr 28 23:05:03 2014 JenneUpdateLSCALS CARM and DARM settings

[Jenne, Koji]

The IFO is being uncooperative tonight, and I have an early morning meeting, so I'm calling it a night.

Koji's filter module changes have been propagated from the Xarm to the Yarm, to CARM and to DARM.  (Actually, Q overwrote the changes to Xarm on Sunday accidentally, so first he reverted those for us, and then we propagated the changes).

Today, with careful measuring, we find that for X and Y arms individually locked with the ALS, we want the gains to be +17 for the Yarm, and -17 for the Xarm (with the beatnote up-is-up convention).  This puts the UGFs at 150 Hz.

We then switched over to CARM and DARM locking.  We guessed that the gains should be a factor of 2 lower since we're pushing on both ETMs for DARM, and the MC2 actuator is roughly the same strength as the sum of the ETMs.  In the end, after measuring the CARM and DARM loops, we find that the gains should be +7.5 for CARM, and +8.0 for DARM to set the UGFs at 150 Hz.  The servo is a little bit delicate, so having too low of gain is not okay.

For some reason, we seem to be utilizing more actuator range with the new setup, so the limiters in the filter banks have been set to 11,000 (previously were 8,000), and the ALS watch script (ALSdown.py) threshold has been increased to 10,000 (previously 7,000).

When finding the IR resonances with the new scheme, we are having trouble holding lock throughout the scan.  I have set the tramp for the coarse part of the scan to be 0.05 seconds (previously 0.01 seconds), which is an increase of a factor of 5 in the ramp time.  This helps, but may still not be enough, since we don't always hold lock until both IR resonances are found.

Probably the most annoying thing from tonight is the fact that ETMY keeps drifting off, particularly in yaw, when locked.  I don't have an explanation of why this is happening, but you can watch it happen sometimes, and the lock will be lost shortly thereafter.  Definitely when we lose lock and the ETM gets kicked, it is far enough away in yaw alignment that I have to completely redo the Yarm alignment.  This happens whether or not the ETMY oplevs are on.

To summarize, 3 scripts have been modified:

(1) ALSdown - threshold increased  (Modification from last week - turns off the slow temp servos for the end lasers, clears histories)

(2) ALSfindIRresonance - increase ramp time

(3) Lock_ALS_CARMandDARM - final gain values set to 7.5 for CARM and 8 for DARM, no filters come on until gains all the way up, turns on new set of Koji filters. (Modification from last week - turns on the slow temperature servos for the end lasers)

9702   Fri Mar 7 00:43:34 2014 manasaUpdateLSCALS C&D locked (on MC2 and ETMs) and IR resonance obtained

[EricQ, Manasa]

ALS common locked by actuating on MC2 and ALS Differential locked by actuating on ETMX and ETMY (Stable lock acquired for over an hour).

Common and Differential offsets were swept to obtain IR resonance in both the arms (arms stayed on resonance for over 15 minutes).

Procedure:

1. Configured LSC settings to allow locking using ALS error signals.

2. Locked common and differential using ALS error signals

Aux matrix
ALSX    ALSY
------------------------------
XARM    1            -1
YARM    1              1
-----------------------------
X arm servo settings:
FIlters: FM1, FM5, FM6, FM7, FM9
Gain = -8.0

Y arm servo settings:
Filters: FM1, FM5, FM6, FM7, FM9
Gain = +8.0

Out matrix
XARM    YARM
------------------------
ETMX    1    0
ETMY    0    1
------------------------

3. Transitioned CARM control output to actuate on MC2 instead of ETMX

SUS-MC2_LSC servo gain = 1.0
The transition was done in very small steps : actuating on MC2 in -0.01 steps at the outmatrix upto -1.0 while reducing the ETMX actuation to 0 simultaneously.

DARM still stayed locked only with actuation on ETMY.

4. Transitioned DARM control to ETMX and ETMY.

Used ezcastep to step up DARM control (Y arm output) actuation on ETMX and step down the actuation on ETMY.

Final output matrix
Xarm    Yarm
-----------------------
ETMX      0    -0.5
ETMY      0     0.5
MC2    -1.0      0
-----------------------

Noise plot in attachment.

5. Finding arm resonance

Used ezcastep to gradually build up offsets in CARM (LSC-XARM_OFS) to find IR resoance in one arm (Y arm).
Introducing a small (order of 0.5) DARM offset (LSC-YARM_OFS) shifted the Y arm off-resonance.
Used CARM offset to get back the Y arm to resonance.
Changing CARM and DARM offsets alternately while tracking the Y arm resonance got us to a point where we had both the arms resonating for IR.

6. At this point the MC decided to give up and we lost lock.

Notes:
1. We found that the WFS2 YAW output filterbank had the output switched OFF (probably accidentally by one of us). This was reenabled. Please be careful while manually turning ON and OFF the MC WFS servos.

16333   Wed Sep 15 23:38:32 2021 KojiUpdateALSALS ASX PZT HV was off -> restored

It was known that the Y end ALS PZTs are not working. But Anchal reported in the meeting that the X end PZTs are not working too.

We went down to the X arm in the afternoon and checked the status. The HV (KEPCO) was off from the mechanical switch. I don't know this KEPCO has the function to shutdown the switch at the power glitch or not.
But anyway the power switch was engaged. We also saw a large amount of misalignment of the X end green. The alignment was manually adjusted. Anchal was able to reach ~0.4 Green TRX, but no more. He claimed that it was ~0.8.

We tried to tweak the SHG temp from 36.4. We found that the TRX had the (local) maximum of ~0.48 at 37.1 degC. This is the new setpoint right now.

9123   Wed Sep 11 23:34:37 2013 MasayukiSummaryGreen LockingALS locking in both arms

[manasa, masayuki]

We locked the XARM and YARM with using ALS control loop and we succeeded to lock stably both arms. The performance of the ALS was tested with a measurement of the calibrated error signal. (attachment 1)

- red and blue : the in-loop noise of ALS of each arm.

- green and purple:Stability of the beat-note frequency with the MC and the arm freely running.

Discussion

In the high frequency region, YARM has larger noise than XARM, and these noises were not there in previous measurements by Koji and Manasa (elog8865). You can see that in both of in-loop noise and free running noise. These noises may be caused by the Green PDH servo or hte phase tracker servo or any other electrical staff. We will start noise budget of these servo.

At higher frequency than UGF of ASL control loop, the loop does not suppress the noises at all, but the inloop and free running noise are not equivalent. I have no idea about that so far.

9124   Wed Sep 11 23:43:10 2013 KojiSummaryGreen LockingALS locking in both arms

What was the beat freq for each arm?
The HF noise level depends on the frequency of the beat note.
As the BBPD has the freq dependent noise level. (See this entry)

9125   Thu Sep 12 00:07:26 2013 MasayukiSummaryGreen LockingALS locking in both arms

 Quote: What was the beat freq for each arm? The HF noise level depends on the frequency of the beat note. As the BBPD has the freq dependent noise level. (See this entry)

I'm not sure about the actual number of the beat frequency, but the beat frequency was almost same in both arms. And I took this measurement sometimes with slightly different beat frequency but the noise level didn't change so much.

16614   Mon Jan 24 12:33:41 2022 ranaConfigurationWikiAIC Wiki: txz files allowed

I updated the mime.local.conf file for the AIC Wiki so as to allow attachments with the .txz format. THis should be persistent over upgrades, since its a local file.

14227   Wed Oct 3 18:15:34 2018 yukiConfigurationASCAI board improvement

[ Yuki, Gautam ]

I improved Anti-Imaging board (D000186-Rev.D), which will be put between DAC port and PZT driver board.

It had notches at f = 16.6 kHz and 32.7 kHz, you can see them in the plot attached. So I replaced some resistors as follows:

• R6 and R7 replaced with 511 ohm (1206 thin film resistor)
• R8 replaced with 255 ohm (1206 thin film resistor)
• R14 and R15 replaced with 549 ohm (1206 thin film resistor)
• R16 replaced with 274 ohm (1206 thin film resistor)

Then the notch moved to 65.9 kHz (> sampling frequency of DAC = 64 kHz, good!).
(The plot enlarged around the notch frequency and the plot of all channels will be posted later.)

All electronics and optics seem to be ready.

Reference, elog:40m/8857
Diagram, D000186-D.pdf

14228   Thu Oct 4 00:44:50 2018 yukiConfigurationASCAI board improvement

[ Yuki, Gautam ]

I made a cable which connects DAC port (40 pins) and AI board (25 pins). I will check if it works.

Tomorrow I will change setup for improvement of AUX Y-end green locking. Any optics for IR will not be moved in my design, so this work doesn't affect Y-arm locking with main beam.
While doing this work, I will do:

• check if the cable works
• make another cable which connects AI board (10 pins) and PZT driver (10 pins).
• check if eurocate in Y-rack (IY4?) applies +/-5V, +/-15V and +/-24V. It will be done using an expansion card.
• improve alignment servo for X-end.
• setup alignment servo for Y-end.
7173   Tue Aug 14 11:33:14 2012 Jamie Alex DenUpdateCDSAI and AA filters

When signals are transmitted between the models running at different rates, no AI or AA filters are automatically applied. We need to fix our models.

8857   Tue Jul 16 14:51:09 2013 gautamConfigurationendtable upgradeAI Board-D000186-Modified notches

I tried shifting the notch frequencies on the D000186-revision D board given to me by Koji. The existing notches were at ~16 kHz and ~32 kHz. I shifted these to notches at ~64 kHz and ~128 kHz by effecting the following changes (see schematic for component numbering) on Channel 8 of the board-I decided to check things out on one channel before implementing changes en masse:

• R6 and R7 replaced with 511 ohm smts
• R8 replaced with 255 ohm smt
• R14 and R15 replaced with 549 ohm smts
• R16 replaced with 274 ohm smt

=> New notches should be at 66.3 kHz and 131.7 kHz.

I then measured the frequency response of the modified channel using the SR785, and compared it to the response I had measured before switching out the resistors. The SR785 only goes up to 102 kHz, so I cannot verify the 128 kHz notch at this point. The position of the 64 kHz notch looks alright though. I think I will go ahead and switch out the remaining resistors in the evening.

Note 1: These plots are just raw data from the SR785, I have not tried to do any sort of fitting to poles and zeros. I will do this at some point.

Note 2: All these smts were taken from Downs. Todd helped me locate the non-standard value resistors. I also got a plastic 25-pin D-sub backshells (the spares are in the rack), with which I have fashioned the required custom ribbon cables (40 pin IDC to 25 pin D-sub with twisted ribbon wire, and a short, 10pin IDC to 10pin IDC with straight ribbon wire).

8875   Thu Jul 18 21:12:58 2013 gautamConfigurationendtable upgradeAI Board-D000186-All channels modified

I carried some further modifications and tests to the AI Board. Details and observations here:

• I switched out the resistors for all the remaining 7 channels, using the same substitutions as detailed here
• I then verified that the modified transfer function for all 8 channels using the SR785. I did not collect data for all the channels as netgpib was taking ages, but I did use the cursor on the screen to verify the position of the first notch at ~64 kHz. I noticed that all the channels did not have the lowest point of the notch at the same frequency. Rather, (at least on the screen), this varied between 63kHz and 67kHz. I would put this down to component tolerance. Assuming 5% tolerance shifts the theoretical notch frequency from 66268 Hz to 63112 Hz.
• After verifying the transfer functions, I went to 1Y4 and plugged the AI board into the eurocrate. I then connected the input of the AI board to the DAC output using my custom ribbon cable. Next, I used the excitation points set up earlier to send a 1 kHz, 32000 counts amplitude sine wave through the channels one at a time. I monitored the output using an oscilloscope and the LEMO monitor channels on the front panel of the board.
• I found that the single-ended output of the AI board swings between -10 V and 10 V (w.r.t ground, oscilloscope trace attached). This is good because this is the range of input voltage to the PZT driver boards required to realize the full actuation range of the PZTs.
• I also verified that the connections on the custom ribbon cable are correct (channel map was right) and that there were no accidental shorts (I checked other channels' output monitor while driving one channel).

I think the board is okay to be used now.

We checked back in time to see how the BS and PRM OSEM slow channels are zero. It was clear that they became zero when we worked on this issue on June 17th, Thursday. So we simply went back and power cycled the c1susaux acromag chassis. After that, we had to log in to c1susaux computer and run

sudo /sbin/ifdown eth1
sudo /sbin/ifup eth1

This restarted the ethernet port acromag chassis is connected to. This solved this issue and we were able to see all the slow channels in BS and PRM.

But then, we noticed that the OPLEV of ITMX is unable to read the position of the beam on the QPD at all. No light was reaching the QPD. We went in, opened the ITMX table cover and confirmed that the return OPLEV beam is way off and is not even hitting one of the steering mirrors that brings it to the QPD. We switched off the OPLEV contribution to the damping.

We did burt restore to 16th June morning using
burtwb -f /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2021/Jun/16/06:19/c1susaux.snap -l /tmp/controls_1210622_095432_0.write.log -o /tmp/controls_1210622_095432_0.nowrite.snap -v

This did not solve the issue.

Then we noticed that the OSEM signals from ITMX were saturated in opposite directions for Left and Right OSEMs. The Left OSEM fast channels are saturated to 1.918 um for UL and 1.399 um for LL, while both right OSEM channels are bottomed to 0 um. On the other hand, the acromag slow PD monitors are showing 0 on the right channels but 1097 cts on UL PDMon and 802 cts in LL PD Mon. We actually went in and checked the DC voltages from the PD input monitor LEMO ports on the ITMX dewhitening board D000210-A1 and measured non-zero voltages across all the channels. Following is a summary:

C1-SUS-ITMX_XXSEN_OUT
C1-SUS-ITMX_xxPDMon
(Slow Acromag Monitors) (cts)
Multimeter measurements at input to Dewhitening Boards
(V)
UL 1.918 1097 0.901
LL 1.399 802 0.998
UR 0 0 0.856
LR 0 0 0.792
SD 0.035 20 0.883

We even took out the 4-pin LEMO outputs from the dewhitening boards that go to the anti-aliasing chassis and checked the voltages. They are same as the input voltages as expected. So the dewhitening board is doing its job fine and the OSEMs are doing their jobs fine.

It is weird that both the ADC and the acromags are reading these values wrong. We believe this is causing a big yaw offset in the ITMX control signal causing the ITMX to turn enough make OPLEV go out of range. We checked the CDS FE status (attachment 1). Other than c1rfm showing a yellow bar (bit 2 = GE FANUC RFM card 0) in RT Net Status, nothing else seems wrong in c1sus computer. c1sus FE model is running fine. c1x02 (the lower level model) does show a red bar in TIM which suggests some timing issue. This is present in c1x04 too.

### Bottomline:

Currently, the ITMX coil outputs are disabled as we can't trust the OSEM channels. We're investigating more why any of this is happening. Any input is welcome.

After sliding the alignment bias around and browsing through elog while searching for "stuck" we concluded the ITMX osems needed to be freed. To do this, the procedure is to slide the alignment bias back and forth ("shaking") and then as the OSEMs start to vary, enable the damping. We did just this, and then restored the alignment bias sliders slowly into their original positions. Attachment 1 shows the ITMX OSEM sensor input monitors throughout this procedure.

At the end, since MC has trouble catching lock after opening PSL shutter, I tried running burt restore the ioo to 2021/Jun/17/06:19/c1iooepics.snap but the problem persists

13661   Wed Feb 28 19:13:25 2018 gautamUpdateALSADC test for differential receiving in c1lsc

[koji, gautam]

we did a bunch of tests to figure out the feasibility of the plan I outlined last night. Bottom line is: we appear to have a working 64 channel ADC (but with differential receiving that means 32 channels). But we need an aLIGO ADC adaptor card (I'm not sure of the DCC number but I think it is D0902006). See attached screenshot where we managed to add an ADC block to the IOP model on c1lsc, and it recognizes the additional ADC. The firmware on the (newly installed) working card is much newer than that on the existing card inside the expansion chassis (see Attachment #1).

Details:

• Watchdogged all optics because we expected messing around with c1lsc to take down all the vertex FEs. Actually, only c1sus was killed, c1ioo survived.
• Closed PSL shutter. Shut down c1lsc FE machine.
• Started out by checking the functionality of the two ADC cards I found.
• Turns out the one Jamie and I removed from c1ioo ~6months ago is indeed broken in some way, as we couldn't get it to work.
• Took us a while to figure out that we require the adaptor board and a working ADC card to get the realtime model to run properly. A useful document in understanding the IO expansion chassis is this one.
• Another subtlety is that the ADC card we installed today (photo in previous elog) is somewhat different from the ones installed in c1sus and c1lsc expansion chassis. But a similar one is installed at the Y-end at least. Point is, this ADC card seems to need an external power supply via a 4-pin Molex connector to work properly.
• We borrowed an adapter card from c1iscey expansion chassis (after first shutting down the machine).
• It seems like a RED GPIO0 LED on these ADC cards isn't indicative of a fault.
• We were able to see sensible numbers (i.e. ~0 since there is no input to the ADC) on these readback channels.
• To restore everything, we first shutdown c1lsc, then restored the adaptor card back to c1iscey, and then rebooted c1iscey, c1lsc and c1sus. Recompiled c1x04 with the added ADC block removed as it would otherwise complain due to the absence of an adapter board.
• Did rtcds restart <model> on all machines to bring back all models that were killed. This went smoothly.
• IMC and Yarm locked smooth.

Note that we have left the working ADC card inside the c1lsc expansion chassis. Plan is to give Rolf the faulty ADC card and at the same time ask him for a working adapter board.

Unrelated to this work: we have also scavenged 4 pcs of v2 of the differential receiving AA board from WB EE shop, along with a 1U chassis for the same. These are under my desk at the 40m for the moment. We will need to re-stuff these with appropriate OpAmps (and also maybe change some Rs and Cs) to make this board the same as v6, which is the version currently in use.

14194   Thu Sep 6 14:21:26 2018 gautamUpdateCDSADC replacement in c1lsc expansion chassis

Todd E. came by this morning and gave us (i) 1x new ADC card and (ii) 1x roll of 100m (2017 vintage) PCIe fiber. This afternoon, I replaced the old ADC card in the c1lsc expansion chassis, and have returned the old card to Todd. The PCIe fiber replacement is a more involved project (Steve is acquiring some protective tubing to route it from the FE in 1X6 to the expansion chassis in 1Y3), but hopefully the problem was the ADC card with red indicator light, and replacing it has solved the issue. CDS is back to what is now the nominal state (Attachment #1) and Yarm is locked for Jon to work on his IFOcoupling study. We will monitor the stability in the coming days.

 Quote: (i) to replace the old generation ADC card in the expansion chassis which has a red indicator light always on and (ii) to replace the PCIe fiber (2010 make) running from the c1lsc front-end machine in 1X6 to the expansion chassis in 1Y3, as the manufacturer has suggested that pre-2012 versions of the fiber are prone to failure. We will do these opportunistically and see if there is any improvement in the situation.
14195   Fri Sep 7 12:35:14 2018 gautamUpdateCDSADC replacement in c1lsc expansion chassis

Looks like the ADC was not to blame, same symptoms persist.

 Quote: The PCIe fiber replacement is a more involved project (Steve is acquiring some protective tubing to route it from the FE in 1X6 to the expansion chassis in 1Y3), but hopefully the problem was the ADC card with red indicator light, and replacing it has solved the issue.
14196   Mon Sep 10 12:44:48 2018 JonUpdateCDSADC replacement in c1lsc expansion chassis

Gautam and I restarted the models on c1lsc, c1ioo, and c1sus. The LSC system is functioning again. We found that only restarting c1lsc as Rolf had recommended did actually kill the models running on the other two machines. We simply reverted the rebootC1LSC.sh script to its previous form, since that does work. I'll keep using that as required until the ongoing investigations find the source of the problem.

Quote:

Looks like the ADC was not to blame, same symptoms persist.

 Quote: The PCIe fiber replacement is a more involved project (Steve is acquiring some protective tubing to route it from the FE in 1X6 to the expansion chassis in 1Y3), but hopefully the problem was the ADC card with red indicator light, and replacing it has solved the issue.

1918   Mon Aug 17 07:01:09 2009 ClaraUpdatePEMADC noiseness

I shorted the inputs on three channels and the outputs on three channels of the Guralp box, and I did similar things with the accelerometers. I was going to move the instruments themselves back, but I didn't have time, so they are still in the box in the corner. If the setup could stay as-is for at least a few hours, that would be awesome.

13419   Wed Nov 8 16:39:24 2017 KiraUpdatePEMADC noise measurement

Gautam and I measured the noise of the ADC for channels 17, 18, and 19. We plan to use those channels for measuring the noise of the temperature sensors, and we need to figure out whether or not we will need whitening and if so, how much. The figure below shows the actual measurements (red, green and blue lines), and a rough fit. I used Gautam's elog here and used the same function, $\sqrt{a^{2}(\frac{b}{f^{2}})+c^{2}}$ (with units of nV/sqrt(Hz)) to fit our results. I used a = 1, b = 1e6, c = 2000. Since we are interested in measuring at lower frequencies, we must whiten the signal from the temperature sensors enough to have the ADC noise be negligible.

We want to be able to measure to $\inline 1mK/\sqrt{Hz}$ accuracy at 1Hz, which translates to about $\inline 1nA/\sqrt{Hz}$ current from the AD590 (because it gives $\inline 1\mu A/K$). Since we have a 10K resistor and V=IR, the voltage accuracy we want to measure will be $\inline 10^{-5}V/\sqrt{Hz}$. We would need whitening for lower frequencies to see such fluctuations.

To do the measurements, we put a $\inline 50\Omega$ BNC end cap on the channels we wanted to measure, then took measurements from 0-900Hz with a bandwidth of 0.001Hz. This setup is shown in the last two attachments. We used the ADC in 1X7.

13676   Fri Mar 9 12:59:53 2018 KiraUpdatePEMADC noise measurement

[Kira, Gautam]

I ceated a simple circuit that takes in 15V and outputs precisely 5V by using a 12V voltage regulator LM7812 and an AD586 that takes the output of the voltage regulator and outputs 5V (attachment 1). We plugged this into the slow channel and will leave it running for a few hours to see if we still have the fluctuations we observed earlier and also fit the noise curve. We'll also test the fast channel later as well. Attachment 2 shows the setup we have in the lab, with the red and white cable plugged into the +15V power supply and the red and black cable connected to the slow channel.

6821   Fri Jun 15 13:33:39 2012 yutaUpdateGreen LockingADC noise contribution to ALS

ADC noise is not a limiting noise source in a current ALS setup.

Below is the calibrated spectrum of C1:ALS-COARSE_I_ERR when
Y arm swinging with just damping (red; taken last night)
terminated before AA (green)
blocked PSL green beam (blue)

Blue and green curve tells us that noise from the beat PD to ADC is not contributing to the Y arm length sensing noise.

13794   Thu Apr 26 20:22:21 2018 KevinUpdatePEMADC common mode rejection with new seismometer connections

Yesterday I wired the outputs from the seismometers directly to the ADC input bypassing the old AA board circuit as is described in this elog. The old circuit converted the single-ended output from the seismometers to a differential signal. Today I looked at whether 60 Hz noise is worse going directly into the ADC due to the loss of the common mode rejection previously provided by the conversion to differential signals.

I split the output from the BS Z seismometer to the new board and to an SR785. On the SR785 I measured the difference between the inner and outer conductors of the seismometer output, i.e. A-B with A the center conductor and B the outer conductor, with grounded input. At the same time I took a DTT spectrum of C1:PEM-SEIS_BS_Z_IN1. Both spectra were taken with 1 Hz bandwidth and 25 averages. The setup is shown in attachment 1.

The spectra are shown in attachment 2. The DTT spectrum was converted from counts to volts by multiplying by 2 * 10 V/32768 cts where the extra factor of 2 is from converting from single-ended to differential input. If there was common 60 Hz noise that the ADC was picking up we would expect to see less noise at 60 Hz in the SR785 spectrum measured directly at the output from the seismometer since that was a differential measurement. Since both spectra have the same 60 Hz noise, this noise is differential.

ELOG V3.1.3-