40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 217 of 329 Not logged in
ID Date Author Type Category Subject
3734   Mon Oct 18 11:22:13 2010 JenneUpdateComputersShame on people not elogging! FrameFiles backups not working.

On the one hand, SHAME ON ALL PEOPLE WHO DON'T ELOG THINGS, such as the moving of scripts directories (it was a pain to figure out that that's part of why the backup scripts are broken).  On the other hand, the moving of the scripts directories brought to light a critical problem in the backup scheme. None of the frame files have been backed up since Joe replaced fb40m with fb, on ~23 Sept (I think).

What went down:

The frame builder was replaced, and no backup script was started up on the new machine.  Sadface.  Crontab doesn't work yet on the new machine, and also the 'ssh-add' commands give an error:

controls@fb /cvs/cds/rtcds/caltech/c1/scripts/backup $ssh-add ~/.ssh/id_rsa No such file or directory controls@fb /cvs/cds/rtcds/caltech/c1/scripts/backup$ ssh-add ~/.ssh/backup2PB
No such file or directory



Thus, I know that the backup was never running on the new fb.  However, the check-er script runs on nodus, and looks at the logfile, and since there was no script running, it wasn't adding to the log file, so the last log was an "Okay, everything worked" entry.  So, the check-er script kept sending me daily emails saying that everything was okie-dokey.

Since all of the scripts were moved (Joe said this happened on Friday, although there's no elog about it), the check-er script, and all of the rest of the backup scripts point to the wrong places (the old scripts/backup directory), so I didn't receive any emails about the backup either way (usually it at least sends a "Hey, I'm broken" email).  This clued me in that we need to check things out, and I discovered that it's all gone to hell.

Since I can't add the ssh clients to the new fb, I can't actually log in to the backup computers over in Powell-Booth to check when the last legitimately successful backup was. But I suspect it was just before the fb was replaced.

So, we need to get Crontab up and running on the new Frame Builder machine so that we can run cron jobs, and we also need to figure out this backup hullabaloo.  I think I'll email / call Dan Kozak over in downs, who was talking about upgrading our backup scheme anyway.

13906   Thu May 31 22:59:27 2018 KojiConfigurationComputersShorewall on nodus

[Jonathan Koji]

Shorewall (http://shorewall.net/), a tool to configure iptables, was installed on nodus.
The description about shorewall setting on nodus can be found here: https://wiki-40m.ligo.caltech.edu/NodusShorewallSetting

NDS (31200) on megatoron is not enabled outside of the firewall yet.

3084   Thu Jun 17 17:09:44 2010 AlbertoUpdateLSCShort Cavity Length Adjustments

I calculated the phase shifts that the sidebands would pick up in the arms in the case we changed the arm length to 38.4m as proposed. I obtained the following values (in degrees):

phi(-f2) = 0.66; phi(-f1) = -0.71; phi(f1) = 0.71; phi(+f2) = -0.66

These are the plots with the results as I obtained from an Optickle simulation (the second zooms in around 38.4m).

These values agree with what Koji had already estimated (see elog entry 3023).

Since we can't make the arm longer than that, to increase the distance from the resonance, we would like to adjust the length of the short cavities to compensate for that.  For f2 (=55MHz), 0.7 degrees correspond to about 5cm. That is about the length change that we expect to make to the design.

I simulated with Optickle the effect of changing the length of either the SRC or the PRC. The best way I found to do that, was to measure the cavity circulating power when the macroscopic lengths change.

The following plots show the effect of changing either the PRC or SRC length (left or right figure), on the circulating power of both cavities at the same time (top and bottom plots).

You can compare these with the case of perfect antiresonance as in the following plots:

It seems that the design length for the short cavities are not too bad. f1 is not optimized in the PRC, but changing the length of the cavity wold just make f2 worse in SRC.

These simulations seem to support the choice of not changing the design cavity lengths for PRC and SRC.

Of course these are only an "open loop" simulations. At the moment we don't know what would be the effect of closing the control loops. That is something I'm going to do later. It'll be part of my studies on the effects of cavity absolute length on the whole IFO.

3086   Fri Jun 18 13:47:20 2010 KojiUpdateLSCShort Cavity Length Adjustments

You should have been in my lecture yesterday!
Power in the cavity is not a good index (=error signal) to judge the optimal length.
You should look at the phases of the length signals. (i.e. demodulation phase which gives you the maximum amplitude for CARM, PRC, SRC, etc)

You must move the SRC and PRC lengths at the same time.
The resonance of f1 (mostly) depends on the PRC length, but that of f2 depends on both the PRC and SRC lengths.

3087   Fri Jun 18 15:07:26 2010 AlbertoUpdateLSCShort Cavity Length Adjustments

 Quote: You should have been in my lecture yesterday! Power in the cavity is not a good index (=error signal) to judge the optimal length. You should look at the phases of the length signals. (i.e. demodulation phase which gives you the maximum amplitude for CARM, PRC, SRC, etc) You must move the SRC and PRC lengths at the same time. The resonance of f1 (mostly) depends on the PRC length, but that of f2 depends on both the PRC and SRC lengths.

Right. Ultimately the phase gain inside the cavity is what we look at. Calculating that for the SBs inside PRC and SRC is actually the first thing I did.

But I kept getting very small angles. Too small, I thought. Maybe there was some problem in the way I calculated it.

Then I made a power analysis to check if the SBs were getting affected at all by that 0.7degree phase shift they're picking up in the arms.

I wanted to show the point where I am, before leaving. But, I keep working on it.

1089   Fri Oct 24 21:49:15 2008 JenneConfigurationPEMShort Seismometer Cable
Bad news regarding the cable that goes between the Guralp seismometer and the box that I've been working on: it's too short by about a factor of 2. Dang it. I've placed the seismometer underneath the Beam Splitter Chamber (where it needs to go), and started running the cable toward the ADC rack where box was planned to go, and as Rana guessed earlier tonight, the cable isn't nearly long enough. We have some options: the seismometer can go back into the half-height rack near the BS, SRM, PRM oplev's optical table where I think it used to be, or it can go into the rack with the Kepco high voltage power supplies and the laser's supply. The cable won't reach any farther than that.

I think that we can just add BNC extensions onto the octopus cable that Bob made for the Guralp box, so all we need to figure out after we decide on a rack is the power for the box.
2219   Mon Nov 9 16:32:36 2009 AlbertoFrogsEnvironmentShot of the white board yesterday before erasing

Yesterday Rana and I needed some room on the white board in the Control Room. We had to erase some of the stuff present on the board despite the bif warning "Do Not Erase".

This is how it looked like before erasing.

Attachment 1: DSC_0980.JPG
11386   Wed Jul 1 09:33:31 2015 KojiUpdateGeneralShutters closed, watch dogs disabled for the RCG upgrade

I closed the PSL/GREEN shutters and shut off the LSC feedback/SUS watch dogs at 9AM PDT, to allow Jamie to start his disruptive work.

4837   Mon Jun 20 09:28:19 2011 JamieUpdateCDSShutting down low-voltage DC power in 1X1/1X2 racks

In order to install the BO module in 1X2, I need to shut down all DC power to the 1X1 and 1X2 racks.

11073   Thu Feb 26 01:51:39 2015 ericqUpdateLSCSideband HOMs

So, my previous post suggested that 44*11 products might be the dominating signals in our "nominal" setup. I suppose that this could be not so bad, since it's not too unlike -11*22; the 11MHz field couples into the PRC and reflects with a rapidly changing phase around PRC resonance, and 44MHz is antiresonant, so it is a good local oscillator for REFL33.

However, it then occured to me that my previous HOM analysis only looked at the 11MHz and 55MHz sidebands.

When extending this to all of the sidebands within 55MHz, I discovered a troubling fact:

With the IFO parameters I have, the second spatial order +22MHz and fourth spatial order +44MHz fields almost exactly coresonate with the carrier in the PRFPMI! (DR, too)

If this is true, then any REFL33 signal seems to be in danger if we have an appreciable amount of these modes from, say, imperfect modematching.

On the other hand, we've been able to hold the PRMI with REFL33 when ALS is "on resonance," so I'm not sure what to think. (As a reminder, this analysis is done with analytic formulae for the complex reflectivities of the arm cavities and coupled recycling cavities as a function of CARM, spatial order and field frequency. Source is attached.)

It seems the Y arm geometry is to blame for this.

Maybe we should try to measure/confirm the Y arm g-factor...

Attachment 1: C1_HOMcurves_PR.png
Attachment 2: C1_HOMcurves_Y.png
Attachment 3: C1_HOMcurves_X.png
Attachment 4: C1_HOMlist.zip
12234   Thu Jun 30 16:21:32 2016 gautamUpdateCOCSideband HOMs resonating in arms

[EricQ, gautam]

Last night, we set about trying to see if we could measure and verify the predictions of the simulations, and if there are indeed HOM sidebands co-resonating with the carrier. Koji pointed out that if we clip the transmitted beam from the arm incident on a PD, then the power of the higher order HG modes no longer integrate to 0 (i.e. the orthogonality is broken), and so if there are indeed some co-resonating modes, we should be able to see the beat between them on a spectrum analyzer. The procedure we followed was:

1. Choose a suitable PD to measure the beat. We chose to use the Thorlabs PDA10CF because it has ~150MHz bandwidth, and also the responsivity is reasonable at 1064nm.
2. We started our measurements at the Y-end. There was a sufficiently fast lens in the beam path between the transmon QPD and the high gain PD at the Y end, so we went ahead and simply switched out the high gain thorlabs PDA520 for the PDA10CF. To power the PDA10CF, we borrowed the power cable from the green REFL PD temporarily.
3. We maximized the DC power of the photodiode signal using an oscilloscope. Then to introduce the above-mentioned clipping and orthogonality-breaking, we misaligned the beam on the PD until the DC power was ~2/3 the maximum value.
4. We then hooked up the PD output to the Agilent network analizyer (with a DC block).
5. We measured the spectrum of the PD signal around 11.066MHz (with 100kHz span) and higher harmonics up to 55MHz and used a narrow bandwidth (100Hz) and long integration time (64 averages) to see if we could find any peaks. More details in the results section.
6. Having satisfied ourselves with the Y-end measurements, we
• restored the power cable to the green beat PD
• re-installed the thorlabs PDA520
• verified that both IR and green could be locked to the arm

We then repeated the above steps at the X-end (but here, an additional lens had to be installed to focus the IR beam onto the PDA10CF - there was, however, sufficient space on the table so we didn't need to remove the PDA520 for this measurement).

Results:

Y-end: DC power on the photodiode at optimal alignment ~ 200mV => spectra taken by deliberately misaligning the beam incident on the PD till the DC power was ~120mV (see remarks about these values).

RF sideband (Y-arm) Peak height (uV) Beat power (nW) RF sideband (X-arm) Peak height (uV) Beat Power (nW)
11 1.55 0.52 11 1.2 0.4
22 10.6 3.53 22 none seen N.A.
33 none seen N.A. 33 none seen N.A.
44 22.0 7.33 44 7 2.33
55 8.6 2.97 55 5 1.67

I converted the peak heights seen on the spectrum analyzer in volts to power by dividing by transimpedance (=5*10^3 V/A into a 50ohm load) * responsivity at 1064nm (~0.6A/W for PDA10CF).

Remarks:

1. This effect flagged by the simulations seems to be real. Unfortunately I can't get a more quantitative picture because we can't quantify the mode-overlap between the carrier 00 mode and any higher order mode on the beat PD (as we know nothing about the profile of these modes), but the simulations did suggets that the 2nd order 22MHz and 4th order 44MHz HOMs are the ones closest to the carrier 00 resonance (see Attachments #2 and #3), which is kind of borne out by these results.
2. I disbelieve the conversions into power that I have done above, but have just put them in for now, because a DC power of 200mW at the Y-end suggests that there is >160uW of light transmitted from the arm, which is at least twice what we expect from a simple FP cavity calculation with the best-known parameters. If I've missed out something obvious in doing this conversion, please let me know!
3. For the Y-arm, the region around 55MHz had a peak (presumably from the sideband HOM beating with the carrier) but also a bunch of other weird sub-structures. I'm attaching a photo of the analyzer screen. Not sure what to make of this...
Attachment 1: image.jpeg
Attachment 2: C1_HOMcurves_Y.pdf
Attachment 3: C1_HOMcurves_X.pdf
3360   Wed Aug 4 16:52:59 2010 Razib, AidanUpdatePhase CameraSideband power measurement (updated)

Aidan and I made some attempt to measure the power of the sidebands so that we can calculate our expected signal strength.

Our setup looks like the following:

As light from the laser is split into two at BS1, the transmitted beam has higher power as our BS1 is only coated for 1064nm. We get two reflected beams from BS1, one reflected of the front surface and the other from the back surface. We took the stronger back reflected beam to the EOM driven at 40 MHz (also at 25 MHz at  a later time). The AOM produced a reference beam with 40 .000 005 MHz offset which we recombined with the sidebands obtained from the EOM. The beat produced is sent off to PDA 10CF connected to 4395A spectrum analyzer.

The plots for 40MHz sidebands and 25 MHz sidebands looks like this:

From the above spectra, at 40 MHz sideband regime:

Power of the carrier @ 40 MHz = -39.72 dBm

Power of the sideband @ 80 MHz = -60.39 dBm

At 25 MHz sideband regime,

Power of the carrier @ 40 MHz = -40.22 dBm

Power of the upper sideband @ 65 MHz = -61.72 dBm

Power of the lower sideband @ 15 MHz = -60.99 dBm

Power Measurement:

We made some necessary power measurement using a PD connected to a voltmeter after the EOM and the AOM when the EOM is driven at 40 MHz:

___________________________________________________________

Dark :  0.025 V

AOM on: 4.10 V    (EOM blocked)

EOM : 2.425 V      (AOM blocked)

___________________________________________________________

From the earlier calculation (ref: Elog entry July 28) the power that we expect to see at the PD is,

P= A_c ^2 + A_r^2 + A_(-sb)^2+ A_sb ^2 +2* A_r* A_sb * cos ( w_(r,sb) t ) ,                         where A_c= carrier;   A_r= reference beam;     A_sb=Upper sideband;    A_(-sb)= Lower sideband,     w_(r,sb) = w_r - w_sb

P = A_c ^2 + A_r^2 + A_(-sb)^2+ A_sb ^2 +2* A_r* A_sb  , letting cos (w_(r,sb) go to 1) is order to approximate the maximum signal

So the signal that we expect to see relative to the DC ( i.e    A_c ^2 + A_r^2 + A_(-sb)^2+ A_sb ^2,    the first four terms of the power equation) is,

Sig = 2* A_r* A_sb    / { A_c ^2 + A_r^2 + A_(-sb)^2+ A_sb ^2 },

Since the modulation index is small, the power in the sideband is very small compared to carrier and the reference beam. So we can ignore the sideband power for the signal expression.

So,

Sig = 2* A_r* A_sb  /  ( A_c ^2 + A_r^2 )

So if we want to maximize this signal w.r.t the reference then,

d (sig)/ d(A_r) = 2 { ( A_c ^2  - A_r^2) *A_sb } / {( A_c^2 + A_r^2)} ^2

Thus, the signal is maximized when,

A_r^2 = A_c^2

We adjusted the AOM to be driven at + 7.7 dBM so that the new power at the AOM matched the EOM power, which is 2.397 in the voltmeter.

So the power at both the AOM and the EOM are:

P_AOM = ( V_AOM - V_dark) / (PD responsitivity * Transimpedance gain)

= ( 2.397 - 0.025 ) / ( 0.45  * 1.5 x 10 ^5 )

= 3.51 x 10 ^ - 5  W

P_EOM = (V_EOM - V _dark) / (PD responsitivity * Transimpedance gain)

= ( 2. 425 - .0.025) / ( 0.45 * 1.5 x 10 ^5 )

= 3.55 x 10^ - 5  W

From the spectra of the 40 MHz sideband above, the ratio of the carrier and the sideband amplitude is:  A_c / A_sb = 10.8 .

P_EOM = A_c ^2 + 2 A_sb ^2

Therefore, A_sb = sqrt ( P_EOM / 118.64) = 5.47 x 10^ - 4   V/m

Thus,     A_c = 5.908 x 10^ -3   V/m

and    A_r = sqrt ( P_AOM) = 5.92 x 10 -3    V/m.

This measurement can be used to calculate the signal to contrast ratio (SCR) that we expect to see:

SCR = 2 A_r * A_sb  / ( A_c^2  + A_r^2 )  = 0.09

Our next step is to measure the actual signal to constrast ratio as seen by the camera. Details of that will be posted soon.

3411   Thu Aug 12 16:52:02 2010 RazibUpdatePhase CameraSideband power measurement (updated)

I made some measurement of the SCR (signal to contrast ratio) from the signal from the EOM and the AOM.

The recipe for that was:

1. Trigger the camera at 20 Hz (from function generator).

2. Take a series of 20 images.

3. Do FFT to take out the DC component.

4. Extract the beat signal out of the FFT'd data.

5. Block the EOM.

6. Take another set of images of the AOM beam.

7. Take more(!) images, but this time of the background (blocking both EOM and AOM).

So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry.

The plot for that is:

After measuring the SCR, I also measured the amplitude of the sideband and made an amplitude profile of the 40 MHz sideband.

The amplitude measurement is done as follows:

We know that the our 5 Hz signal consists of,

Sig = A_r * A_sb    where A_r = amplitude of the reference beam, A_sb= amplitude of the sideband

So, A_sb = Sig / A_r .

But,  A_r = sqrt ( P_AOM - Background),

Thus  A_sb = Sig / sqrt( P_AOM - Background) .

So the amplitude profile is done by taking the 5 Hz beat signal and dividing by the square root of the AOM beam minus the background light.

The plots looks like this:

The solo sideband profile looks like this:

Next we plan to trigger the camera with a 1 KHz signal and take snaps at n* T/4 (where n=0,1,2,3) of the period of the beat signal. So the plan is to trigger the camera at the point where the red dots appear in following cartoon.

Some more details of this setup will be posted later.

 Quote:

Attachment 4: sine_trig.jpg
3412   Thu Aug 12 17:10:07 2010 KojiUpdatePhase CameraSideband power measurement (updated)

This sounds very relieving although this could be a lower bound of the number.
Why didn't you use the output on the PD which just give us the direct observation of your so-called SCR.

Ed: I meant time series of the PD output

 Quote: So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry.

3413   Thu Aug 12 17:28:28 2010 RazibUpdatePhase CameraSideband power measurement (updated)

Quote:

This sounds very relieving although this could be a lower bound of the number.
Why didn't you use the output on the PD which just give us the direct observation of your so-called SCR.

 Quote: So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry.

The SCR was at first measured using the output of the PD. That was exactly from where we got our 0.09 (previous elog entry). The second measurement was from the CCD.

6167   Wed Jan 4 05:02:58 2012 kiwamuUpdateLSCSidebands measurement at POP
Just a quick report:
I did the first attempt to measure the recycling gains of the sidebands in the DRMI configuration (sidebands resonant condition)
by looking at the output of the POP22/110 RFPD.
Because this time what I measured is some absolute values of the sidebands power,
it doesn't tell us anything quantitatively until we calibrate it or compare it with similar data.
So I need to measure the same things in some different configurations (e.g. PRMI, SRMI, etc.)
in order to extract some useful information from the measurement.

The attached picture is the display of a power spectrum analyzer looking at the output of the POP22/110 broadband RFPD
while the DRMI (in the sideband resonant condition) was kept locked.
You can see that 111 MHz (twice of 55 MHz) is prominent. Also there are several peaks at 11, 22, 44 and 66 MHz.
1297   Thu Feb 12 14:39:07 2009 ranaSummaryGeneralSilicon Beam Dump test
Yesterday evening, Ken Mailand and I tested the reflectivity of a piece of polished Silicon. Since Silicon has such a high thermalconductivity (compared to stainless and fused silica) and can take much more heat than black glass and should have a very good BRDF and should absorb most of the 1064 nm light if we hit it at Brewster's angle, we want to try it out in the first version high power, low scatterbeam dump. This dump will be a 'V' style dump like what Steve has tested nearly a year ago, but the incoming beam will first hit this piece of Silicon.

The pictures of the setup and the Silicon with the beam hitting it are here.

Brewster's angle for p-pol at 1064 nm is 74.2 deg (n = 3.53 @ 1064 nm). We set up a cube polarizer on the output of the ~1064 nm CrystaLaser. 144 mW got to the Si; the reflected beam was ~1.9-2.0 mW after tuning the angle for minimum power. Via eyeball and protractor it seems that we're at ~74 deg. So the reflectivity is < 1.5-2%. This is good enough; the reflected power will be < 1 W in all cases for eLIGO and that can be absorbed by the rest of the stainless V dump. The 35 W of heat in the silicon will be mostly gotten rid of through conduction into the attached heat sink fins.

This kind of dump would go into places like the PMC-REFL, MC-REFL, & IFO-REFL, where we occasionally need to take high power, but also are sensitive to backscatter.
2752   Thu Apr 1 16:34:29 2010 HartmutUpdateGreen LockingSilicon PDs

just a few infos on Silicon PDs I looked up.

If you want to go beyond the 100MHz achievable with the device I worked on,

the one thing to improve is the opamp, where Steve is trying to find OPA657.

This is a FET with 1.6GHz BWP, minimum stable gain of 7, and 4.8nV/rt(Hz) noise.

Should be ok with 750-1000 Ohm transimpedance.

The other thing you might want to change is the PD

(although it might be the 1cm PD with high bias is as fast as smaller ones with lower bias).

There are two types of other Si diodes at the 40m right now (~3mm):

-Rana and I found a Centronic OSD 15-5T in the old equipment

-Frank gave me a Hamamatsu S1223-01 on a Thorlabs pre-amp device (could be taken out).

The Centronic OSD 15-5T has up to 80pF with 12 V bias according to the datasheet.

The Hamamatsu S1223-01 is stated with 20pF only, but stated to have a max. frequency resp. of 20MHz ('-3db point').

I dont know what this means, as the corner freq. of 10pF into 50Ohm is still 160MHz.

In any case there are faster 3mm types to start with, as for example Hamamatsu S3399 (~ 90\$),

which is stated to have the corner at 100MHz with 50 Ohm load.

For this type the stated capacity (20pF) looks consistent with ~100MHz corner into 50 Ohm.

So probably you can get higher BW with this one using much smaller load, as in transimpedance stage.

7181   Tue Aug 14 16:33:51 2012 SashaUpdateComputer Scripts / ProgramsSimPlant indicator added

I added an indicator to the watch dog screen so that a little "SP" icon appears whenever the SimPlant is on. Since we only have one simplant (ETMX), only ETMX has the simPlant indicator. However, since assymetry is ugly, I moved all of the OL icons over so that they're in a line and so that there is room for future SP icons.

I also fixed the link to the Watchdogs on the main SUS screens (it was dead, but now it is ALIVE).

4394   Thu Mar 10 01:28:47 2011 joe, jamie, rana, chrisSummaryCDSSimSuspension !

Today was a banner day for Simulated Plants.

Joe and Jamie have been working to get it all happening and this afternoon we started stuffing filters into the plant to make it act like the:

We put in the following features so far:

1. Anti-Imaging filters (these are hacked to be approximate since the real ones are 7570 Hz LP filters and the SimAI only can have filters up to 8192 Hz).
2. Dewhitening filters (copied from the SimDW in the SUS-ETMY screens)
3. Coil Driver transimpedance (1 / 200 Ohms)
4. Magnet-coil force constant (0.016 N/A)
5. Conversion from Coil to DOF Basis
6. All DOFs of the mechanical model are represented as simple harmonic oscillators with Q~100 and f ~ measured free swinging peaks.
7. Signals/Noise can be injected either as force noise on the test mass or as displacement noise at the suspension point.
8. Conversion from DOF to Shadow Sensor basis.
9. Optical Levers (with whitening)

We have also changed the switching logic for the SUS and SimETMs for the shadow sensor whitening. It used to be that either the hardware OR the software whitening was on. Now we have made it like all of the other whitening/antiwhitening in LIGO and the whitening/antiwhitening come on together. Joe and Jamie are going to propagate this to the other SUS. The hardware filter is a 30,100:3 (poles:zeros) whitening filter. The digital filter used to also be 30,100:3 with a DC gain = 1. I've changed the FM1 filter in the XXSEN filter banks into a 3:30 for the ETMY so that it now comes on and just compensates the hardware filter. This change should be propagated to all other SUS and the MEDM screens updated to show the new situation.

After this change, we decided to calibrate the {UL,UR,LL,LR,SD}SEN channels into units of microns. To do this we have made an FM6 filter called 'cts2um' that accounts for the OSEM gain and the ADC conversion factors. These channels are now in units of microns without applying any calibration in the DTT or Dataviewer. The plot below shows the OSEM shadow sensor time series with all damping loops ON and a very rough version of seismic noise being injected in all 6 DOFs (note that the y-axis is microns and the x-axis is seconds).

Next, Jamie is adding the angular calibrations (so that SUSPIT and SUSYAW are in rads) and Chris is making vectift quality seismic noise injectors.

We also need to add coating thermal noise, suspension thermal noise, substrate thermal noise, ADC/DAC noise and a lot of MEDM screen indicators of what state we're in. I myself can't tell from the OSEM time series if its real or Sim.

7151   Sat Aug 11 01:10:26 2012 SashaUpdateSimulationsSim_Plant Working!

Sim_Plant going okay. Adding seismic noise tomorrow - we'll see what happens. The gain is still semi-off, but I know how to fix it - its just nice to have it gained up while I play with noise.

P.S. JAMIE DO YOU NOTICE HOW PRETTY MY GRAPH IS?

Attachment 1: Plant_sen.jpg
7152   Sat Aug 11 18:05:49 2012 SashaUpdateSimulationsSim_Plant Working!

 Quote: Sim_Plant going okay. Adding seismic noise tomorrow - we'll see what happens. The gain is still semi-off, but I know how to fix it - its just nice to have it gained up while I play with noise. P.S. JAMIE DO YOU NOTICE HOW PRETTY MY GRAPH IS?

Developed some seismic noise. I adapted the seismic noise filters we used for the MC model way back when.  They looked questionable to begin with, but I added some poles/zeroes to make it more accurate (see Attached).

Attachment 1: seismic_noise1.jpg
7167   Mon Aug 13 23:06:08 2012 JenneUpdateSUSSimplant left on

Simplant for ETMX was left on, so I didn't have control of ETMX.  Not cool.  The IFO should be left in it's 'regular' state (all optics restored to saved alignments, no simplant, LSC/ALS/ASS loops off) if you're not actively working on it.

What this did point out, however, is that we need a big ol' indicator on the IFO_ALIGN / LSC / Watchdog / Overview screens to indicate that simplant is on for a particular optic, or whatever simplant might be controlling that takes away 'regular' control.  I probably would have continued being frustrated and confused for a lot longer if Eric didn't mention that simplant could have been left on.  Thanks Eric!

Symptoms, which perhaps would have eventually pointed me to simplant, were that there was some weird moving beam on the AS camera that was flashing fabry-perot fringes, and the POX signal looked like junk. After some looking around, I noticed that ETMX, while it claimed to have all the damping loops on, and the oplev on, was swinging a lot (rms levels of 4 - 7, rather than the usual < 2 ).  I said something out loud, and Eric suggested looking at Simplant.  After putting Simplant back to Reality, things are back to normal.

3276   Fri Jul 23 14:26:01 2010 GopalUpdateOptic StacksSimple Frequency Response Measurements in COMSOL

Over the past couple days, I discovered a simple, direct method for calculating frequency responses with a combination of COMSOL and any plotter such as Excel or MatLab. The simple case of rectangular prism of steel was analyzed using this method; details will be posted shortly on the COMSOL Wiki page. The frequency response matched theoretical reasoning: the bar acts as a simple mechanical low-pass filter, rapidly attenuating driving frequencies at the base beyond the first eigenmode.

It therefore shouldn't be too difficult to extend this analysis to the MC1/MC3 stack. The many eigenfrequencies will produce a more complicated transfer function, and so more data points will be taken.

The major shortcoming of this method involves dealing with the imaginary components of the eigenfrequencies. As of now, I haven't found a way of measuring the phase lag between the drive and the response. I also haven't found a way of changing the damping constants and therefore playing with phase components.

4388   Tue Mar 8 16:59:47 2011 josephbUpdateCDSSimulated Plant Work

The screens for the simplified c1spx model have been updated.  I re-introduced the suspension point information into the sensor output matrix so we can take into account the fact that as the entire supporting structure moves, the osems moves relative to the optic.

Master screens for the noise filters (i.e. 60 Hz, suspension point motion, and optic noise) have been created.

I have currently set the matrix values of the c1spx model to handle just longitudinal motion.  I.e. Coils drive only in the POS degree of freedom and sensor read outs are also only in the POS degree of freedom.  I've turned off all the noise inputs.

I added a simple double pole at 1 Hz in the C1:SUP_ETMX_PL_F2P_0_0 filter bank.

14667   Wed Jun 12 22:02:04 2019 MilindUpdateCamerasSimulation enhancements

Today, Rana asked me to work on improving simulations based on the ideas we discussed last week. As of the previous elog the simulation accomodated only

1. Simulation of Gaussian beam spot.
2. Arbitrary motion.

Today, I added the simulation of point scatterers.

What?

The image on the sensor (camera) is produced in roughly the following steps.

1. Motion of the Gaussian beam on the optic (X,Y coordinates) which is what has been simulated so far.
2. Reflection from the surface of the optic which can be modeled using knowledge of the BRDF has not been included as of this elog as I wish to do a little more reading before doing so.
3. Reflection from point scatterers (dust particles burnt into the optic surface by the laser and so forth) which are characterised as peaks (impulses) in the TIS vs position plot. The laser beam is incident nearly normally on the optic and this behaviour is independent of the angle of observation. This is what has been added to the simulation.

How?

1. Increased the frame resolution to 720 x 480.
2. Defined an array of the same size and set values of at most "num_scatter" number of points at random positions to values determined randomly between 1 and "scatter_amp" + 1 where scatter_amp is non-negative.
3. Multiplied the resulting array by the resulting Gaussian beam. The motivation was to imitate the bright specks obtained on various camera feeds in the lab. Physically, this also implies normal incidence and normal observation which is not the real case at all. I shall add these features in a day or two.

Herewith, in attachments #1, #2, #3 I am attaching videos obtained by varying scattering amplitude and number of scattering points in a vain attempt to reproduce this data. I shall work more on this simulation on Friday.

Scripting stuff:

1. Previous elogs detail how to take gige images at various exposure times. I am still waiting on Kruthi to use the script.
2. Tomorrow I shall work on the scripting software to interact with the GigE and take video for a fixed duration etc. I shall also begin working on a script to autolock the PMC based on what Rana showed me on Monday. I will also take a look at the the contents of this elog and try to pick up from there. I hope to make significant progress by the next lab meeting.

Neural network stuff:

GANs for simulation:

1. Other than putting the physics into simulation i.e the first portion of this elog, GANs can be trained to generate images similar to the original data. I am unfamiliar with training GANs and the various tricks that are used specifically for them. I will do a bit of reading and make an update by Friday. As of now, the data I plan to use is this and I will train it using the GTX 1060 on my machine.

Networks for beam tracking:

1. I will use the architectures suggested in this work with a few modifications. I will use MSE loss function, Adam optimizer and my local GPU for training.
Attachment 1: simulated_motion0.mp4
Attachment 2: simulated_motion0.mp4
Attachment 3: simulated_motion0.mp4
14698   Tue Jun 25 23:52:37 2019 MilindUpdateCamerasSimulation enhancements

Yesterday, Rana asked me to look at Hiro Yamamoto's docs on the DCC to improve the simulation. I'm performing a first pass (=> Just skimming through to see if they're relevant, I will go through them more carefully soon!) and putting up stuff here for future reference. @Kruthi's help much appreciated!

14714   Mon Jul 1 20:11:34 2019 MilindUpdateCamerasSimulation enhancements

Today, I read a lot more about BRDF and modelling but could not make much headway regarding the implementation in the simulation. I've stopped for now and I'll take a crack at it tomorrow again.

 Quote: Yesterday, Rana asked me to look at Hiro Yamamoto's docs on the DCC to improve the simulation. I'm performing a first pass (=> Just skimming through to see if they're relevant, I will go through them more carefully soon!) and putting up stuff here for future reference. @Kruthi's help much appreciated!
14635   Thu May 23 15:37:30 2019 MilindUpdateCamerasSimulation enhancements and performance of contour detection
1. Implemented image level noise for simulation. Added only uniform random noise.
2. Implemented addition of uniform random noise to any sinusoidal motion of beam spot.
3. Implemented motion along y axis according to data in "power_spectrum" file.
4. Impelemented simulation of random motion of beam spot in both x and y directions (done previously by Pooja, but a cleaner version).
5. Created a video file for 10s with motion of beam spot along the y direction as given by Attachment #1. This was created by mixing four sinusoids at different amplitudes (frequencies (0.1, 0.2, 0.4, 0.8) Hz Amplitudes as fractions of N = 64 (0.1 0.09 0.08 0.09). FPS = 10. Total number of frames = 100 for the sake of convenience.  See Attachment #5.
6. Following this, I used the thresholding (threshold = 127, chosen arbitrarily), contour detection and centroid computation sequence (see Attachment #6 for results) to obtain the plot in Attachment 2 for the predicted motion of the y coordinate. As is evident, the centering and scale of values obtained are off and I still haven't figured out how to precisely convert from one to another.
7. Consequently, as a workaround, I simply normalised the values corresponding to each plot by subtracting the mean in each case and dividing the resulting series of values by their maximum. This resulted in the plots in Attachments 3 and 4 which show the normalised values of y coordinate variation and the error between the actual and predicted values between 0 and 1 respectively.

Things yet to be done:

Simulation:

1. I will implement the mean square error function to compute the relativer performance as conditions change.
2. I will add noise both to the image and to the motion (meaning introduce some randomness in the motion) to see how the performance, determined by both the curves such as the ones below and the mean square error, changes.
3. Following this, I will vary the standard deviation of the beam spot along X and Y directions and try to obtain beam spot motion similar to the video in Attachment #2 of elog post 14632.
4. Currently, I have made no effort to carefully tune the parameters associated with contour detection and threshold and have simply used the popular defaults. While this has worked admirably in the case of the simple simulated videos, I suspect much more tweaking will be needed before I can use this on real data.
5. It is an easy step to determine the performance of the algorithm for random, circular and other motions of the beam spot. However, I will defer this till later as I do not see any immediate value in this.
6. Determine noise threshold. In simulation or with real data: obtain a video where the beam spot is ideally motionless (easy to do with simulated data) and then apply the above approach to the video and study the resulting predicted motion. In simulation, I expect the predictions for a motionless beam spot video (without noise) to be constant. Therefore, I shall add some noise to the video and study the prediction of the algorithm.
7. NOTE: the above approach relies on some previous knowledge of what the video data will look like. This is useful in determining which contours to ignore, if any like the four bright regions at the corners in this video.

Real data:

1. Obtaining real data and evaluate if the algorithm is succesful in determining contours which can be used to track the beam spot.
2. Once the kind of video feed this will be used on is decided, use the data generated from such a feed to determine what the best settings of hyperparameters are and detect the beam spot motion.
3. Synchronization of data stream regarding beam spot motion and video.
4. Determine the calibration: anglular motion of the optic to beam spot motion on the camera sensor to video to pixel mapping in the frames being processed.

Other approaches:

1. Review work done by Gabriele with CNNs, implement it and then compare performance with the above method.
Attachment 1: actual_motion.pdf
Attachment 2: predicted_motion.pdf
Attachment 3: normalised_comparison.pdf
Attachment 4: residue_normalised.pdf
Attachment 5: simulated_motion1.mp4
Attachment 6: elog_22may_contours.mp4
14638   Sat May 25 20:29:08 2019 MilindUpdateCamerasSimulation enhancements and performance of contour detection
1. I used the same motion as defined in the previous elog. I gradually added noise to the images. Noise added was uniform random noise - a 2 dimensinoal array of random numbers between 0 and a predetermined maximum (noise_amp). The previous elog provides the variation of the y coordinate. In this, I am also uploading the effect of noise on the error in the prediction of the x coordinate. As a reminder, the motion of the beam spot center was purely vertical. Attachement #1  is the error for noise_amp = 0, #2 for noise_amp = 20 and #3  for noise_amp = 40. While Attachment #3 does provide the impression of there being a large error, this is not really the case as without normalization, each peak corresponds to a deviation of one pixel about the central value, see Attachement #4 for reference.
2. While the error does increase marginally, adding noise has no significant effect on the prediction of the y coordinate of the centroid as Attachment #5 shows at noise_amp = 40.
3. I am currently running an experiment to obtain the variation of mean square error with different noise amplitudes and will put up the plots soon. Further, I shall vary the resolution of the image frames and the the standard deviation of the Gaussain beam with time and try to obtain simulations very close to the real data available and then determine the performance of the algorithm.
4. The following videos will serve as a quick reference for what the videos and detection look like at
1. noise_amp = 20
2. noise_amp = 40
5. I also performed a quick experiment to see how low the amplitude of motion could be before the algorithm falied to detect the motion and found it to occur at 2 orders of magnitude below the values used in the previous post. This is a line of thought I intend to pursue more carefully and I am looking into how opencv and python handle images with floats as coordinates and will provide more details about the previous trial soon. This should give us an idea of what the smallest motion of the beam spot that can be resolved is.
 Quote: Implemented image level noise for simulation. Added only uniform random noise. Implemented addition of uniform random noise to any sinusoidal motion of beam spot. Implemented motion along y axis according to data in "power_spectrum" file. Impelemented simulation of random motion of beam spot in both x and y directions (done previously by Pooja, but a cleaner version). Created a video file for 10s with motion of beam spot along the y direction as given by Attachment #1. This was created by mixing four sinusoids at different amplitudes (frequencies (0.1, 0.2, 0.4, 0.8) Hz Amplitudes as fractions of N = 64 (0.1 0.09 0.08 0.09). FPS = 10. Total number of frames = 100 for the sake of convenience.  See Attachment #5. Following this, I used the thresholding (threshold = 127, chosen arbitrarily), contour detection and centroid computation sequence (see Attachment #6 for results) to obtain the plot in Attachment 2 for the predicted motion of the y coordinate. As is evident, the centering and scale of values obtained are off and I still haven't figured out how to precisely convert from one to another. Consequently, as a workaround, I simply normalised the values corresponding to each plot by subtracting the mean in each case and dividing the resulting series of values by their maximum. This resulted in the plots in Attachments 3 and 4 which show the normalised values of y coordinate variation and the error between the actual and predicted values between 0 and 1 respectively. Things yet to be done: Simulation: I will implement the mean square error function to compute the relativer performance as conditions change. I will add noise both to the image and to the motion (meaning introduce some randomness in the motion) to see how the performance, determined by both the curves such as the ones below and the mean square error, changes. Following this, I will vary the standard deviation of the beam spot along X and Y directions and try to obtain beam spot motion similar to the video in Attachment #2 of elog post 14632. Currently, I have made no effort to carefully tune the parameters associated with contour detection and threshold and have simply used the popular defaults. While this has worked admirably in the case of the simple simulated videos, I suspect much more tweaking will be needed before I can use this on real data. It is an easy step to determine the performance of the algorithm for random, circular and other motions of the beam spot. However, I will defer this till later as I do not see any immediate value in this. Determine noise threshold. In simulation or with real data: obtain a video where the beam spot is ideally motionless (easy to do with simulated data) and then apply the above approach to the video and study the resulting predicted motion. In simulation, I expect the predictions for a motionless beam spot video (without noise) to be constant. Therefore, I shall add some noise to the video and study the prediction of the algorithm. NOTE: the above approach relies on some previous knowledge of what the video data will look like. This is useful in determining which contours to ignore, if any like the four bright regions at the corners in this video. Real data: Obtaining real data and evaluate if the algorithm is succesful in determining contours which can be used to track the beam spot. Once the kind of video feed this will be used on is decided, use the data generated from such a feed to determine what the best settings of hyperparameters are and detect the beam spot motion. Synchronization of data stream regarding beam spot motion and video. Determine the calibration: anglular motion of the optic to beam spot motion on the camera sensor to video to pixel mapping in the frames being processed. Other approaches: Review work done by Gabriele with CNNs, implement it and then compare performance with the above method.

Attachment 1: residue_normalised_x.pdf
Attachment 2: residue_normalised_x.pdf
Attachment 3: residue_normalised_x.pdf
Attachment 4: predicted_motion_x.pdf
Attachment 5: normalised_comparison_y.pdf
9326   Fri Nov 1 17:01:46 2013 GabrieleSummaryLSCSimulation of REFL_3f signal when the arms come in

I simulated how the 3f signal is affected by the resonance condition of the arms.

To keep it simple, I only simulated a double cavity. The attached plot shows the result. In x there is the arm cavity detuning from resonance (in log scale to show what happens close to the 0 value). In the y axis there is the PRC detuning. So every vertical slice of the upper plot gives a PDH signal for a given arm detuning. The bottom plot shows the power build up inside the arm, which is dominated by the carrier.

The 3f signal is not perturbed in any significant way by the arm resonance condition. This is good and what we expected.

However, in this simulation I had to ensure that the 1f sidebands are not perfectly anti-resonant inside the arms. They are indeed quite far away from resonance. If the modulation frequency is chosen in order to make the 1f sidebands exactly ant-resonant, the 2f will be resonant. This screws up the signal: REFL_3f is made of two contributions of equal amplitude, one on the PRC sidebands resonance and the other on the PRC carrier resonance. When the arm tuning goes to zero, these two cancels out and there is no more PDH...

However, this is a limit case, since the frequency show match perfectly. If the modulation frequency is few arm line widths away from perfect anti-resonance, we have no problem.

9327   Fri Nov 1 17:44:06 2013 KojiSummaryLSCSimulation of REFL_3f signal when the arms come in

Yes, the resonance of the 2nd-order sidebands to the IFO screws up the 3f scheme.

2f (~22MHz) and 10f (~110MHz) are at x 5.6 and x 27.9 FSR from the carrier, so that's not the case.

Could we also see how much gain fluctuation of the 3f signals we would experience when the arm comes into the resonance?

9337   Mon Nov 4 14:11:23 2013 GabrieleSummaryLSCSimulation of REFL_3f signal when the arms come in

 Quote: Yes, the resonance of the 2nd-order sidebands to the IFO screws up the 3f scheme. 2f (~22MHz) and 10f (~110MHz) are at x 5.6 and x 27.9 FSR from the carrier, so that's not the case. Could we also see how much gain fluctuation of the 3f signals we would experience when the arm comes into the resonance?

From the simulation there is no visible change in the gain.

11564   Thu Sep 3 02:12:08 2015 ranaUpdateCDSSimulink Webview updated

Back in 2011, JoeB wrote some entries on how to automatically update the Simulink webview stuff.

Somehow, the cron broke down over the years. I reran the matlab file by hand today and it worked fine, so now you can see the up to date models using the internet.

https://nodus.ligo.caltech.edu:30889/FE/

11567   Thu Sep 3 13:25:40 2015 ranaUpdateCDSSimulink Webview updated

added the cron script for this to megatron to run at 8:44 AM each morning. Here's the new MegaCron attached :-()-

** it takes ~13 minutes to complete on megatron

Attachment 1: crontab_150903.rtf
MAILTO=ericq@caltech.edu

# m h  dom mon dow   command
#0 */1 * * * bash /home/controls/public_html/summary/bin/c1_summary_page.sh > /dev/null 2>&1
#15 5 * * * /ligo/apps/nds2/nds2-megatron/test-restart

# MEDM Screen caps for the webpage
2,13,25,37,49 * * * * /cvs/cds/project/statScreen/bin/cronjob.sh

# op340m transplants -ericq

... 18 more lines ...
12727   Tue Jan 17 20:47:23 2017 ranaUpdateCDSSimulink Webview updated

Seems like this stops working every ~2 years. Its been busted since early 2016 according to cron, so I fixed up the paths and restored some missing files and committed things to the SVN (with comments!) and now its working and grabbing the Web viewable versions of the front end models. Just need to restore its viewability and then the world can watch our models any time.

 Quote: Back in 2011, JoeB wrote some entries on how to automatically update the Simulink webview stuff. Somehow, the cron broke down over the years. I reran the matlab file by hand today and it worked fine, so now you can see the up to date models using the internet. https://nodus.ligo.caltech.edu:30889/FE/

8299   Fri Mar 15 02:14:27 2013 JenneUpdateCDSSimulink linking to wrong library part

Jamie and I discovered a problem with Matlab/Simulink earlier today.

In the end suspension models, there is a subblock (with top_names) for ALS stuff.  Inside there, we use a library part called "ALS_END".  When the model was created, it included the part ...../userapps/release/isc/c1/models/ALS_END.mdl .  However, if you open up the c1scy diagram and look in the ALS block for this part, you see the part that is in ..../userapps/release/isc/common/models/ALS_END.mdl .  Note the difference - the one we want is in the c1 directory, while the one that was created (by Jamie) for the LHO One Arm Test is in the common directory.

If you compile the c1scy model, the RCG is using the correct library part, so the information regarding which part we want is still in there.

However, if you delete the ALS_END part from the model, put the correct one in, save, close, then reopen the model, it once again displays the wrong model.  The right click "go to library part" option brings you to the library part that is displayed, which is currently the wrong one.  THIS IS BAD, since we could start modifying the wrong things.  You do get a warning by Matlab about the file being "shadowed", so we should take heed when we see that warning, and make sure we are getting the file we want.

We are currently running Matlab version 7.11.0.584, which is r2010b.  Step 1 will be to update Matlab to the latest version, in hopes that this fixes things.  We also should change the name of our c1 part, so that it does not have the same name as the one for the sites.  This is not a great solution since we can't guarantee that we will never choose the same names as other sites, but it will at least fix this one case.  Again, if you see the warning about "shadowed" filenames, pay attention.

16168   Fri May 28 17:32:48 2021 AnchalSummaryALSSingle Arm Actuation Calibration with IR ALS Beat

I attempted a single arm actuation calibration using IR beatnote (in the directions of soCal idea for DARM calibration)

## Measurement and Inferences:

• I sent 4 excitation signals at C1:SUS-ITM_LSC_EXC wit 30cts at 31Hz, 200cts at 197Hz, 600cts at 619Hz and 1000cts at 1069 Hz.
• These were sent simultaneously using compose function in python awg.
• The XARM was locked to mai laser and alignment was optimized with ASS.
• The Xend Green laser was locked to XARM and alignment was optimized.
• Sidenote: GTRX is now normalized to give 1 at near maximum power.
• Green lasers can be locked with script instead of toggling.
• Script can be called from sitemap->ALS->! Toggle Shutters->Lock X Green
• Script is present at scripts/ALS/lockGreen.py.
• C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ was measured for 60s.
• Also, measured C1:LSC-XARM_OUT_DQ and C1:SUS-ITMX_LSC_OUT_DQ.
• Attachment 1 shows the measured beatnote spectrum with excitations on in units of m/rtHz.
• It also shows resdiual displacement contribution PSD of (output referred) XARM_OUT and ITMX_LSC_OUT to the same point in the state space model.
• Note: that XARM_OUT and ITMX_LSC_OUT (excitation signal) get coherently added in reality and hence the beatnote spectrum at each excitation frequency is lower than both of them.
• The remaining task is to figure out how to calculate the calibration constant for ITMX actuation from this information.
• I need more time to understand the mixture of XARM_OUT and ITMX_LSC_OUT in the XARM length node in control loop.
• Beatnote signal tells us the actual motion of the arm length, not how much ITMX would have actuated if the arm was not locked.
• Attachment 2 has the A,B,C,D matrices for the full state space model used. These were fed to python controls package to get transfer functions from one point to another in this MIMO.
• Note, that here I used the calibration of XARM_OUT we measured earlies in 16127.
• On second thought, maybe I should first send excitation in ETMX_LSC_EXC. Then, I can just measure ETMX_LSC_OUT which includes XARM_OUT due to the lock and use that to get calibration of ETMX actuation directly.

Attachment 1: SingleArmActCalwithIRALSBeat.pdf
Attachment 2: stateSpaceModel.zip
16171   Tue Jun 1 16:55:32 2021 Anchal, PacoSummaryALSSingle Arm Actuation Calibration with IR ALS Beat

Rana suggested in today's meeting to put in a notch filter in the XARM IR PDH loop to avoid suppressing the excitation line. We tried this today first with just one notch at 1069 Hz and then with an additional notch at 619 Hz and sent two simultaneous excitations.

## Measurement and Analysis:

• We added notch filters with Q=10, depth=50dB, freq=619 Hz and 1069 Hz using foton in SUS-ETMX_LSC filter bank at FM10.
• We sent excitation signals with amplitudes 600cts and 1000 cts for 619 Hz and 1069 Hz signals respectively.
• We measured time series data of C1:SUS-ITMX_LSC_OUT_DQ and C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ for 60s.
• Then, spectrum of both signals is measured with Hanning window using scipy.welch function with scaling set to  'spectrum', binwidth=1Hz.
• The beatnote signal was converted into length units by multiplying it by 1064nm * 37.79m / c.
• The ratio of the two spectrums at teh excitation frequency multiplies by excitation frequency squared gives us teh calibration constant in units of nm Hz^2/cts.
• At 619 Hz, we got $\frac{5.01}{f^2}$nm/cts
• At 1069 Hz, we got $\frac{5.64}{f^2}$nm/cts.
• The calibration factor in use is from $\frac{7.32}{f^2}$ nm/cts from 13984.
• So, the calibration factor from this methos is about 23% smaller than measured using freeswinging MICH in 13984.
• One possiblity is that our notch filter is not as effective in avoiding suppresion of excitation.
• We tried increasing the notch filter depths to 100 dB but got the same result within 2%.
• We tried changing the position of notch filters. We put them in POX filter banks. Again the result did not change more than 2%.
• The open loop gain of green PDH at 619 Hz and 1069 Hz must be large enough for our assumption of green laser perfectly following length motion to be true. The UGF of green laser is near 11 kHz.
• The discrepancy could be due to outdated freeswinging MICH measurement that was done 3 years ago. Maybe we should learn how to do the ITMX calibration using this method and compare our own two measurements.
Attachment 1: SingleArmActCalwithIRALSBeat-1306624785.pdf
16192   Tue Jun 8 11:40:53 2021 Anchal, PacoSummaryALSSingle Arm Actuation Calibration with IR ALS Beat

We attempted to simulate "oscillator based realtime calibration noise monitoring" in offline analysis with python. This helped us in finding about a factor of sqrt(2) that we were missing earlier in 16171. we measured C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ when X-ARM was locked to main laser and Xend green laser was locked to XARM. An excitation signal of amplitude 600 was setn at 619 hz at C1:ITMX_LSC_EXC.

## Signal analysis flow:

• The C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ is calibrated to give value of beatntoe frequency in Hz. But we are interested in the fluctuations of this value at the excitation frequency. So the beatnote signal is first high passed with 50 hz cut-off. This value can be reduced a lot more in realtime system. We only took 60s of data and had to remove first 2 seconds for removing transients so we didn't reduce this cut-off further.
• The I and Q demodulated beatntoe signal is combined to get a complex beatnote signal amplitude at excitation frequency.
• This signal is divided by cts amplitude of excitation and multiplied by square of excitation frequency to get calibration factor for ITMX in units of nm/cts/Hz^2.
• The noise spectrum of absolute value of  the calibration factor is plotted in attachment 1, along with its RMS. The calibration factor was detrended linearly so the the DC value was removed before taking the spectrum.
• So Attachment 1 is the spectrum of noise in calibration factor when measured with this method. The shaded region is 15.865% - 84.135% percentile region around the solid median curves.

We got a value of $\frac{7.3 \pm 3.9}{f^2}\, \frac{nm}{cts}$.  The calibration factor in use is from $\frac{7.32}{f^2}$ nm/cts from 13984.

Next steps could be to budget this noise while we setup some way of having this calibration factor generated in realitime using oscillators on a FE model. Calibrating actuation of a single optic in a single arm is easy, so this is a good test setup for getting a noise budget of this calibration method.

Attachment 1: ITMX_Cal_Noise_Spectrum_1307143423.pdf
16242   Fri Jul 9 15:39:08 2021 AnchalSummaryALSSingle Arm Actuation Calibration with IR ALS Beat [Correction]

I did this analysis again by just doing demodulation go 5s time segments of the 60s excitation signal. The major difference is that I was not summing up the sine-cosine multiplied signals, so the error associated was a lot more. If I simply multpy the whole beatnote signal with digital LO created at excitation frequency, divide it up in 12 segments of 5 s each, sum them up individually, then take the mean and standard deviation, I get the answer as:
$\frac{6.88 \pm 0.05}{f^2} nm/cts$as opposed to $\frac{7.32 \pm 0.03}{f^2} nm/cts$that was calculated using MICH signal earlier by gautum in 13984.

Attachment 1 shows the scatter plot for the complex calibration factors found for the 12 segments.

My aim in the previous post was however to get a time series of the complex calibration factor from which I can take a noise spectral density measurement of the calibration. I'll still look into how I can do that. I'll have to add a low pass filter to integrate the signal. Then the noise spectrum up to the low pass pole frequency would be available. But what would this noise spectrum really mean? I still have to think a bit about it. I'll put another post soon.

Quote:

We attempted to simulate "oscillator based realtime calibration noise monitoring" in offline analysis with python. This helped us in finding about a factor of sqrt(2) that we were missing earlier in 16171. we measured C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ when X-ARM was locked to main laser and Xend green laser was locked to XARM. An excitation signal of amplitude 600 was setn at 619 hz at C1:ITMX_LSC_EXC.

## Signal analysis flow:

• The C1:ALS-BEATX_FINE_PHASE_OUT_HZ_DQ is calibrated to give value of beatntoe frequency in Hz. But we are interested in the fluctuations of this value at the excitation frequency. So the beatnote signal is first high passed with 50 hz cut-off. This value can be reduced a lot more in realtime system. We only took 60s of data and had to remove first 2 seconds for removing transients so we didn't reduce this cut-off further.
• The I and Q demodulated beatntoe signal is combined to get a complex beatnote signal amplitude at excitation frequency.
• This signal is divided by cts amplitude of excitation and multiplied by square of excitation frequency to get calibration factor for ITMX in units of nm/cts/Hz^2.
• The noise spectrum of absolute value of  the calibration factor is plotted in attachment 1, along with its RMS. The calibration factor was detrended linearly so the the DC value was removed before taking the spectrum.
• So Attachment 1 is the spectrum of noise in calibration factor when measured with this method. The shaded region is 15.865% - 84.135% percentile region around the solid median curves.

We got a value of $\frac{7.3 \pm 3.9}{f^2}\, \frac{nm}{cts}$.  The calibration factor in use is from $\frac{7.32}{f^2}$ nm/cts from 13984.

Next steps could be to budget this noise while we setup some way of having this calibration factor generated in realitime using oscillators on a FE model. Calibrating actuation of a single optic in a single arm is easy, so this is a good test setup for getting a noise budget of this calibration method.

Attachment 1: ITMX_calibration_With_ALS_Beat.pdf
1757   Thu Jul 16 10:52:58 2009 ClaraUpdatePEMSingle Channel TRS-RNC Cable

I made and tested a female-to-female TRS(audio)-RNC cable. It only has a single channel, so it won't work for stereo speakers or anything, but I should only need one speaker for testing the microphones. The tip of the plug is the signal, the sleeve is ground, and the ring is null.

1432   Thu Mar 26 04:09:38 2009 YoichiUpdateIOOSingle X arm lock spectra with different MC lock schemes
The attached plots show MC_F, FSS_FAST_F and XARM IN/OUT spectra with different MC locking modes.
The conventional locking means the FSS is used. The direct frequency lock is the new way.
You can see that at low frequencies, the frequency actuator is working hard to suppress the MC pendulum motions.
The X-arm also sees a lot of frequency noise at low frequencies because of this.
The transmitted power of the X-arm fluctuates a lot making it difficult to align the mirrors.

The zoomed plots show that the structures in the kHz band are also present in the case of the direct frequency lock, although the frequencies are somewhat different.
Attachment 1: XarmSpectra.pdf
Attachment 2: XarmSpectraZoom.pdf
11061   Tue Feb 24 18:54:26 2015 ericqUpdateASCSingle arm QPD ASC stability

I've lowered the UGFs for the transmission QPD servos to ~1-2Hz, and made it just an integrator. I left the arms locked with the QPD servos on for a few hours during the daytime today, and they succesfully prevented the Y arm from losing power from alignment drift for ~4 hours. Turning the servo off caused TRY to drop to ~0.6 or so.

The X arm was only held for 2 hours or so, because after some unlock/drift event the power was below the servo trigger threshold. However, after gently nudging ETMX to get the transmission above the threshold, the servo kicked in, and brought it right back to TRX=1.0

Unfortunately, daqd was dead for much of the day, so I don't have much data to show; the trend was inferred from the wall striptool.

It is not proven that there aren't further issues that prevent this from working with higher / more dynamic arm powers, but this is at least a point in favor of it working.

EDIT: Here's a screenshot of the wall StripTool. Brown is TRY, blue is TRX. The downturn at the very end is me deactivating the servos.

There is no scientific justifcation for the 0.9 threshold. Really, I should look at the noise/SNR again, now that there is some ND filtering on the QPDs.

Attachment 1: trend.png
15611   Mon Oct 5 00:37:19 2020 gautamUpdateBHDSingle bounce interferometer locked

Summary:

The simple interferometer, composed of a single bounce reflection from ITMY and the LO beam deilvered via fiber to the AS table, can be locked - i.e. the phase of the LO beam can be controlled such that the DC light level on the DCPDs after the two beams are interfered can be stabilized. This test allows us to confirm that various parts of the sensing and actuation chain (e.g. PI PZT for homodyne phase control, Trek amplifier etc etc) are working.

I will post more quantitative analysis tomorrow.

Optical configuration:

• LO beam is a pickoff of the main PSL beam from just before it goes into the vacuum. The optical power arriving on each DCPD after the various beamsplitters, coupling loss etc is ~200 uW.
• IFO beam is the single bounce reflection from ITMY. For this test, ETMY, ITMX and ETMY are misaligned. Optical power arriving on each DCPD is ~80uW.
• The two beams are interfered on a 50-50 beamsplitter. The mode-matching efficiency was estimated to be ~50% which isn't stellar, but should be fine for this test.
• So, at half-fringe, we expect the signal on each DCPD to be linearly proportional to the phase difference between the two fields, and so we can use that as an error signal.

Servo topology:

Attachment #2 shows the servo topology.

• For a first attempt to close the feedback loop, we can consider the two blocks labelled "Sensing Chain" and "Actuation chain" to have a flat frequency response. While this isn't true, for a taget loop with ~100 Hz UGF, I think the approximation is reasonable.
• From the peak-to-peak value (160 cts) of the DCPD signals when the homodyne phase is uncontrolled, I estimate a sensing response (at half-fringe) of approximately 0.3 ct/nm, since this corresponds to 532nm of relative phase between the two beams.
• An inverting summing amplifier is used to map the +/- 2^15 ct DAC range to 0-125V on the PI PZT. Assuming the full stroke of the PZT is 10um per the datasheet, and that this voltage range drives half of the full stroke (this is just a guess since all the old PI PZT circuits were designed to work at 0-250 V), we get an actuation coefficient of 0.075 nm/ct.
• Using these two numbers, we can then design a digital feedback loop that gives an open loop transfer function with ~100 Hz UGF, and sufficient stability margin.
• From the earlier measurements, we have an estimate for the amount of phase fluctuations caused by (i) seismic disturbances and (ii) fiber phase noise. This is the quantity we wish to suppress, and the suppression factor will be 1/(1+L), where L is the open loop gain.
• I didn't do this in any systematic way, but the loop in Attachment #3 seemed like a reasonable shape that would suppress the error signal RMS by ~10x, as shown in Attachment #4. So I decided to try this out.

Other notes:

1. The idea of offloading the DC control voltage to the ITMY suspension seemed to work fine.
2. It also seems like the relative phase between the two beams doesn't drift by so large an amount in short time scales, at least at night/quiet seismic conditions. So it is possible to maintain the lock for several seconds without having to offload the DC signal to the suspensions.
3. I didn't bother adapting the FSS Slow PID script to do this offloading in an automated way, seemed like more trouble than was just doing it by hand. But we may want to automate this in the future.
4. I couldn't make a clean measurement of the loop transfer function using the usual IN1/IN2 method. Introducing a step offset at the error point, the servo is able to track it (I didn't fit the step response time, but it's not as if the loop bandwidth is <1 Hz or something). I have to compare the measured in-loop error signal ASD to the free-running one to get a feel for what the UGF is, I guess, to rule out a weird loop.
5. Update 1100 Oct 6 2020: I have now added measured, in-loop, error point spectra to Attachment #4. Looks like there might be significant sensing noise re-injection.
• Initially, I forgot to turn the HEPA on the PSL down for the measurement. So I have the two traces to compare. Looks like with the HEPA turned up to full, there is more noise in the 50-200 Hz range.
• The trace marked "highGain" was taken with an overall loop gain that was 3dB higher than the nominal value - I could see some oscillations start to appear, and in the spectrum, maybe the feature at ~150 Hz is evidence of some gain peaking?

Conclusions:

1. The PI PZT seems to work just fine.
2. Need to look into the loop shape. I guess it's not reasonable to expect a UGF much higher than 100-200 Hz, because of the various delays in the system, but maybe the low frequency suppression can be made better.
3. What are the next steps?? What does this mean for the RF44 sensing scheme?
Attachment 1: simpleHomodyne.png
Attachment 2: singleBounceIFO.pdf
Attachment 3: proposedController.pdf
Attachment 4: freeRunningSuppressed.pdf
15612   Mon Oct 5 00:53:16 2020 KojiUpdateBHDSingle bounce interferometer locked

🤘🤘🤘

15290   Wed Apr 1 00:51:41 2020 gautamUpdateWienerSlightly improved MCL FF

Summary:

Retraining the MCL filters resulted in a slight improvement in the performance. Compared to no FF, the RMS in the 0.5-5 Hz range is reduced by approximately a factor of 3

Details:

Attachment #1 shows my re-measurement of the MC2 position drive to MCL transfer function.

• The measurement was made using DTT swept sine, with the amplitude enveloped appropriately to avoid knocking the IMC out of lock.
• Coherence was >0.97 for all datapoints.
• Fitting was done using Lee's IIRrational, with the weighting being the coherence. I think there are some features of the fitting I don't fully understand, but I wanted to try and do everything in python and for this simple fit, it came out nicely I think.

Attachment #2 shows the IIR fits to the FIR filters calculated here

• Again, IIRrational was used.
• In the frequency band where subtraction is possible, the fit is good.
• But there is definitely room for improvement in the way this is done, for now, I did quite a bit "by eye" and tweaked the order of the filter and the minimum number of excess poles relative to zeros to get the AC coupling, but it'd be nice to make all of this iterative and quantitative (e.g. by minimizing a cost function).
• One nice feature of IIRrational is that it directly gives me a formatted string I can paste into foton. The order of these fits were 22, so I split them into two 19+3 order filters to be compatible with the realtime system before loading the coefficients (the overall gain was allocated to a single filter arbitrarily, with the other filter in the pair set to have unity gain in the zpk representation).

Attachment #3 shows several MCL spectra.

• Blue trace is the unsubtracted test dataset.
• Red is the performance of the calculated FIR filter, but the filtering is done offline.
• Gold is the performance of the IIR fit to the FIR filter, as shown in Attachment #2, applied offline to the test dataset.
• Green is the calculated ASD of MCL from a ~1 hour stretch from earlier tonight, when I left the feedforward loop on. So this is an actual measurement of the online performacne of the filter.
• Grey is the performance of the old filter loaded in the CDS system - the filtering is done using scipy, and the sos coefficients from the C1OAF.txt file.

Conclusions + next steps

1. Retraining the filters has resulted in a slight improvement, especially at ~3 Hz.
2. More tests need to be done to confirm that noise isn't being reinjected in the frequency bands where subtraction isn't possible (e.g. using arm cavities as OOL sensors).
3. The online filter isn't quite as good as what we would expect from calculations (green trace is noisier than gold). Need to think about why this is.
4. Why can't we get more subtraction at 1 Hz?
5. Now that I have the infrastructure ready, I will attempt to revive the PRC angular FF loops, which was the whole point of this exercise.
Attachment 1: MC2_act_calib.pdf
Attachment 2: IIR_fit_to_FIR.pdf
Attachment 3: FIRvIIR.pdf
12290   Tue Jul 12 09:18:12 2016 ericqUpdateGeneralSlippery substance mystery

I found a note on Steve's desk that R. Abbott left yesterday afternoon about an unidentified slippery substance being present on the floor by cabinet S12, along the X arm. (Steve is away this week)

Just now, I found no trace of the substance in the vicinity of that cabinent (which is one of the cabinets for clean objects). Maybe the janitor cleaned it already?

12291   Tue Jul 12 09:35:51 2016 JohannesUpdateGeneralSlippery substance mystery

I've noticed the spot that Rich means before, too. I think you only notice this when you're wearing the shoe covers, not sneakers or crocs. I didn't see any 'substance', it seems more like the floor finish (wax?) seems to be more slippery in that area than others.

 Quote: I found a note on Steve's desk that R. Abbott left yesterday afternoon about an unidentified slippery substance being present on the floor by cabinet S12, along the X arm. (Steve is away this week) Just now, I found no trace of the substance in the vicinity of that cabinent (which is one of the cabinets for clean objects). Maybe the janitor cleaned it already?

13443   Wed Nov 22 00:54:18 2017 johannesOmnistructureComputersSlow DAQ replacement computer progress

I got the the SuperMicro 1U server box from Larry W on Monday and set it up in the CryoLab for initial testing.

The processor is an Intel D525 dual core atom processor with 1.8 GHz (i386 architecture, no 64-bit support). The unit has a 250GB SSD and 4GB RAM.

I installed Debian Jessie on it without any problems and compiled the most recent stable versions of EPICS base (3.15.5), asyn drivers (4-32), and modbus module (2-10-1). EPICS and asyn each took about 10 minutes, and modbus about 1 minute.

I copied the database files and port driver definitions for the cryolab from cryoaux, whose modbus services I suspended, and initialized the EPICS modbus IOC on the SuperMicro machine instead. It's working flawlessly so far, but admittedly the box is not under heavy load in the cryolab, as the framebuilder there is logging only the 16 analog channels.

I have recently worked out some kinks in the port driver and channel definitions, most importantly:

• mosbus IOC initialization is performed automatically by systemd on reboot
• If the IOC crashes or a system reboot is required the Acromag units freeze in their last current state. When the IOC is started a single read operation of all A/D registers is performed and the result taken as the initial value of the corresponding channel, causing no discontinuity in generated voltage EVER (except of course for the rare case when the Acromags themselves have to be restarted)

Aaron and I set 12/4 as a tentative date when we will be ready to attempt a swap. Until then the cabling needs to be finished and a channel database file needs to be prepared.

ELOG V3.1.3-