40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 231 of 348 Not logged in
ID Date Author Type Category Subject
10841   Tue Dec 23 20:50:39 2014 rana, kojiUpdateIOOSeven transfer functions

Today we decided to continue to modify the TTFSS board.

The modified schematic can be found here: https://dcc.ligo.org/D1400426-v1 as part of the 40m electronics DCC Tree.

What we did

1) Modify input elliptic filter (L1, C3, C4, C5) to give zero and pole at 30 kHz and 300 kHz, respectively. L1 was replaced with a 1 kOhm resistor.  C3 was replaced with 5600 pF. C4 and C5 were removed. So the expected locations of the zero and pole were at 28.4 kHz and 256 kHz, respectively. This lead filter replaces the Pomona box, and does so without causing the terrible resonance around 1 MHz.

2) Removed the notch filters for the PC and fast path. This was done by removing L2, L3, and C52.

At this point we tested the MC locking and measured the transfer function. We successfully turned up the UGF to 170kHz and two super-boosts on.

3) Now a peak at 1.7MHz was visible and probably causing noise. We decided to revert L2 and adjusted C50 to tune the notch filter in the PC path to suppress this possible PC resonance. Again the TF was measured. We confirmed that the peak at 1.7MHz is at -7dB and not causing an oscillation. The suppression of the peak is limited by the Q of the notch. Since its in a weird feedback loop, we're not sure how to make it deeper at the moment.

4) The connection from the MC board output now goes in through the switchable Test1 input, rather than the fixed 'IN1'. The high frequency gain of this input is now ~4x higher than it was. I'm not sure that the AD829 in the MC board can drive such a small load (125 Ohms + the ~20 Ohms ON resistance of the MAX333A) very well, so perhaps we ought to up the output resistor to ~100-200 Ohms?

Also, we modified the MC Servo board: mainly changed the corner frequencies of the Super Boost stages and some random cleanup and photo taking. I lost the connecting cable from the CM to the AO input (unlabeled).

1.  The first two Super Boost stages were changed from 20k:1k to 10k:500 to give us back some phase margin and keep the same low freq gain. I don't really know what the gain requirement is for this servo here at the 40m. The poles and zeros were chosen for iLIGO so as to have the frequency noise be 10x less than the SRD at 7 kHz.
2. The third Super Boost (which we never used) was changed from 10k:500 to ~3k:150 (?) just in case we want a little more low freq gain.
3. There was some purple vestigial wiring on the back side of the board with a flying resistor; I think this was a way to put a DC offset in to the output of the board, but its not needed anymore so I removed it.

Attachment 1: MC_OLTF.pdf
Attachment 2: MC_OLTF2.pdf
Attachment 3: matlab.zip
1203   Wed Dec 24 10:33:24 2008 YoichiUpdateComputersSeveral fixes. Test point problem remains.
Yesterday, I fixed several remaining problems from the power failure.

I found a LEMO cable connecting the timing board to the Penteks was lose on the c1susvme1 crate.
After I pushed it in, the DMA error has not occured on c1susvme1.

I logged into op340m using a Null Modem Cable.
The computer was failing to boot because there were un-recoverable disk errors by the automatic fsck.
I run fsck manually and corrected some errors. After that, op340m booted normally and now it is working fine.
Here is the serial communication parameters I used to communicate with op340m:
>kermit      (I used kermit command for serial communication.)
>set modem type none
>set line /dev/ttyS0     (ttyS0 should be the device name of your serial port)
>set speed 9600
>set parity none
>set stop-bits 1
>set flow-control none
>connect


After fixing op340m, the MC locked.
Then I reset the HV amps. for the steering PZTs.
Somehow, the PZT1 PIT did not work. But after moving the slider back and forth several times, it started to work.

I reset the mechanical shutters around the lab.

I went ahead to align the mirrors. The X-arm locked but the alignment script did not improve
the arm power.
I found that test points are not available. (diag said test point management not available).
Looks like test point manager is not running. Called Rolf, but could not reach him.
I'm not even sure on which machine, the tp manager is supposed to be run.
Is it c0daqawg ?
17441   Wed Feb 1 16:53:55 2023 AlexSummaryGeneralShadowing Anchal on developing a change for the c1ioo CDS computer

During my time shadowing Anchal, we discussed the need for digital control systems on the suspension systems for the 40 meter optics. The controls and diagnostics system (CDS) allows us to develop our own feedback controls and filters for the suspension systems by taking in analog signals from the shadow sensors. The feedback control system developed in the CDS then utilizes the OSEM actuators to dampen harmonic motion and noise on the suspension lines. While improving these feedback loops is an ongoing challenge, it is a problem that is likely non-linear, meaning the system must be understood on a much higher level to make further improvements. This brings us to the new addition of a wavefront sensor in the 40m lab, which will allow for constant monitoring of the active wavefront in the interferometer. The wavefront will soon be used for gathering training data for a neural net that will help further analyze the non-linear effects within the suspension and damping system. What Anchal was working on today was an update within a CDS model for clioo to allow for the integration of the wavefront sensor such that he may use a switch to change between connections in the mode cleaner and the arm cavity. The CDS models may be edited and updated using Matlab/Simulink to arrange blocks and code in a robust and visual manner. The final system designed in Simulink can then be saved and compiled using the real-time code generator (RCG), which cross-compiles the Simulink file into C code that can be read by the CDS system to assign inputs, outputs, and various logic or algorithms for filtering.

5183   Thu Aug 11 06:45:14 2011 NicoleSummarySUSShaking Testing

Koji and I have finished shaking the table for the first round of measurements (horizontal shaking). We have cleaned up the lab space used.

The FFT Analyzer has been put back to its position at the back side of the rack (near the seismometers).

I will calibrate the photosensor for the suspension frame and piece together/analyze/produce graphs of the data today. If everything is fine (the measurements are fine) and if there is a chance, we hope to shake the TT suspension vertically.

17044   Thu Jul 28 16:51:55 2022 TegaUpdateBHDShaking test for LO beam AS beam to BHD DCPDs

[Yuta, Tega, Yehonathan]

To investigate the BHD power imbalance and clipping issues, we did some shaking test of the mirrors in the LO path and AS paths. The results suggests the following:

• The clipping is happening after the BHD BS in DCPD_A path, as opposed to our initial guess of BHD BS transmission clipping in elog 17040.
• The LO beam we are seeing is probably a ghost beam from PR2

We performed both PIT and YAW shaking of all mirrors and looked at the output at DCPD_A and DCPD_B, see table below for details. Since we only see the dithering signal in DCPD_A, it suggests that the clipping is ocurring after the BHD BS and is also confined to the path between BHD BS and DCPD_A. We also swapped the camera location from DCPD_A to DCPD_B on ITMY table and confirmed that the beam was clipped for DCPD_A but not for DCPD_B.

This result discounts the possiblity of clipping being responsible for the power imbalance and therefore suggests that the power imbalance may actually be due to BHD BS not being 50:50. From the measurement in elog 17040, the transmission of BHD BS is 44$\pm$0.3% and the reflectivity is 56$\pm$0.3%. Note that DCPD_A is the transmission of BHD BS for AS beam, whereas DCPD_B is the reflection of BHD BS for AS beam, elog 16932.

We expect the shaking of PR2 to give no signal in either DCPD_A or DCPD_B when the LO beam is purely in trasmission, however, we see a signal in DCPD_A sugesting that the LO beam transit path through PR2 may not be as expected, i.e. the beam might be exiting the side of PR2 instead of the AR coated surface.

Finally, we measured the coherence between the dithering dof and DCPD_A/B & POP, see attachment 2, where we noticed that both DCPD_A/B have high coherence in the 1Hz-10Hz frequency band whereas ther was no coherence in POP as expected. This suggests that there may also be some small clipping in DCPD_B path.

LO Beam Shaking (LO1, LO2, PR2):

 color OPTIC DOF Freq OSC Amp (cnts) comment Black 0 Reference Blue LO1 YAW 304.4 2000 Signal in DCPD_A & No signal in DCPD_B Orange LO1 PIT 304.4 2000 No signal Magenta LO2 YAW 312.2 10000 No signal Purple LO2 PIT 312.2 10000 Signal in DCPD_A & No signal in DCPD_B Green PR2 YAW 308.8 20000 Signal in DCPD_A & No signal in DCPD_B Red PR2 PIT 308.8 20000 Signal in DCPD_A & No signal in DCPD_B

AS Beam Shaking (AS1 and AS4)

 color OPTIC DOF Freq OSC Amp (cnts) comment Black 0 Reference Blue AS1 YAW 305.5 2000 Signal in DCPD_A & No signal in DCPD_B Orange AS1 PIT 305.5 2000 Signal in DCPD_A & No signal in DCPD_B Magenta AS4 YAW 313.3 2000 Signal in DCPD_A & No signal in DCPD_B Purple AS4 PIT 313.3 2000 No signal

Attachment 1: Screenshot_2022-07-28_16-58-34_LOandASShaking.png
Attachment 2: Screenshot_2022-07-28_18-08-55_DCPDPOPSuspensionCoherence.png
17045   Thu Jul 28 20:16:26 2022 AnchalUpdateBHDShaking test for LO beam AS beam to BHD DCPDs

Some insights from the inside vacuum situation:

• The beam is an incident near normal on PR2 close to the center of the optic. It wasn't hard to align this part, I'm very confident that we aligned it to the center of PR2. So I do not think the LO beam is ghost beam from PR2.
• The place that is most susceptible to clipping is POP_SM5 mirror in front of LO1. The LO beam has little clearance from the edge of the mirror.
• Another possibility of clipping in LO beam is through the cage of LO2. LO2 is a 45-degree incidence mirror, so it is possible we are clipping off the cage or seeing a ghost beam mixed in LO beam here.
• The fact that moving PR2 is affecting LO beam is weird but doesn't necessarily mean it is a ghost from PR2.
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
16884   Wed Jun 1 11:56:28 2022 yutaUpdateALSShutter driver for GRY replaced

[JC, Yuta]

We replaced a shutter driver for GRY since it stopped working this morning.
We replaced it with a free driver which was sitting on the ITMY table.
The reverse polarity issue of C1:AUX-GREEN_Y_Shutter was fixed by switching one of the switches of the driver from N.O. to N.C.

Also, "Toggle" button was added to IFO_ALIGN.adl so that we can toggle shutters easily to find TEM00. It runs /home/controls/Git/40m/scripts/ALS/ShutterToggler.py.

 Quote: The green Y shutter now works but in reverese, meaning that sending 1 to C1:AUX-GREEN_Y_Shutter closes the shutter and vice versa. This needs to be fixed.

Attachment 1: Screenshot_2022-06-01_12-01-53.png
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)
10. Shadow Sensors have 2V/mm readout gain and whitening filters before being digitized by the SimADC.

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.

16718   Wed Mar 9 11:52:18 2022 YehonathanUpdateBHDSimplified BHD readout sketch on ITMY table

I have made an editable draw.io diagram of the planned simplified BHD setup on the ITMY table (see attached).  10 pts = 1 inch.

This is very sketchy but easily adjustable since we are removing everything but the ITMY Oplev from that table.

Attachment 1: ITMY_Table_Sketch.drawio.pdf
16719   Wed Mar 9 12:57:52 2022 KojiUpdateBHDSimplified BHD readout sketch on ITMY table

- BHD beams were already mixed in the chamber. So we don't need a BS on the table. (Probably there is no BS already)

- We don't need to split each BHD beam. One PD per BHD beam is OK for now.

- Check if the BHD paths have reasonable angles from the windows so that the beams do not hit the chamber wall.

- We need the POY path. POY indeed goes to the BS table

16755   Mon Apr 4 15:49:06 2022 TegaUpdateOptical LeversSimplified sketch on BS table

I have updated the BS table using feedback from Koji and Paco and the attached pdf document is the latest iteration.

Attachment 1: BS_Table.drawio.pdf
16751   Fri Apr 1 14:26:50 2022 TegaUpdateOptical LeversSimplified sketch on MC table

Here is an early sketch of the MC table.

 Quote: I have made an editable draw.io diagram of the planned simplified BHD setup on the ITMY table (see attached).  10 pts = 1 inch. This is very sketchy but easily adjustable since we are removing everything but the ITMY Oplev from that table.

Attachment 1: MC_Table.drawio.pdf
16752   Fri Apr 1 17:02:02 2022 KojiUpdateOptical LeversSimplified sketch on MC table

We are supposed to have BS Oplev Beams. We don't like the shallow angle reflections (i.e. AOI>45deg).

The laser is too big but I suspect the other components are too small. So it'd be check the actual size of the components including the optical mounts that are missing on the figure so far.

16753   Fri Apr 1 22:22:29 2022 KojiUpdateOptical LeversSimplified sketch on MC table

Possibility to swap BS and ITMX tables:
BS table, which Tega said MC table, is 2ft x 4ft. The ITMX table is 3ft x 5ft and only the central 2ft x 4ft area is used. The area around the BS table is the narrowest for the east arm. We need at least (2+delta) ft of the hallway width so that we can move the instrument. I'm not yet sure if the ITMX table can be placed there without precise investigation.

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.

16948   Sat Jun 25 22:18:41 2022 TomislavUpdateASCSimulation and reality comparisons

In the attachment please find plots comparing controller output, local damping output, and error signals.

Input noises of the simulation are seismic noise, osem noise, input power fluctuations, sensing noises of WFSs and QPD, and air turbulence noise for WFSs. There is also optical torque noise (radiation pressure effect).

The procedure to get optical gains and sensing noises:
Having the actuator response A rad/cnts @ 3 Hz. I was shaking MC1/2/3 in pitch with B cnts @ 3 Hz and getting WFS1/2 QPD signals of C cnts @ 3 Hz, which means WFS1/2 QPD optical gain is D cnts/rad = C / (A * B) cnts/rad. So, if WFS1/2 QPD IN1 has a noise spectrum (at higher freqs) of E cnts/rtHz, that corresponds to E/D rad/rtHz of sensing noise for WFS1/2 QPD.

Actuator response [rad/cts] I was getting shaking mirrors at 3 Hz and measuring amplitudes of OSEM output (knowing the geometry of the mirror). I scaled it to DC. From here I was getting ct2tau_mc (knowing the mirror's moment of inertia, Q, and natural pitch frequencies). OSEM calibration factors [cts/rad] I was getting from the input matrix and geometry of the mirror.

The flat noise at higher frequencies from the local damping and controller output channels is presumably quantization/loss of digits/numerical precision noise which I don't include in simulations for now?!

Regarding air turbulence, in KAGRA it has been reported that air turbulence introduces phase fluctuations in laser fields that propagate in air. According to Kolmogorov’s theory, the PSD of phase fluctuations caused by air turbulence scales as ∝ L*V^(5/3)*f^(−8/3). Here, L is the optical path length and V is a constant wind speed. Since it is not obvious how can one estimate typical V in the beam paths I was taking this excess noise from the error signals data between 10 Hz and 50 Hz, extrapolated it taking into account ∝ f^(−8/3) (not for frequencies below 2 Hz, where I just put constant, since it would go too high). I expect that I won't be able to get a parameterized model that also predicts the absolute value. The slope is all I can hope to match, and this I already know. QPD chamber is much smaller (and better isolated?) and there is no this excess noise.

Regarding other things in simulations (very briefly): beam-spots are calculated from angular motions, length change is calculated from beam-spots and angular motion, cavity power depends on length change and input power, and torque on the mirrors depends on beam-spots and cavity power. From other things, local-sensor basis conversion (and vice versa) is worth noting.

Attachment 1: sens_output_comparison_23_6_new.png
Attachment 2: contr_out_comparison_23_6_new.png
Attachment 3: local_damp_out_comp_23_6_new.png
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.

16934   Tue Jun 21 18:41:46 2022 TomislavUpdateASCSimulation plot

In the attachment please find a comparison of error signals of simulation and reality. For C1:IOO-WFS1/2_PIT_IN1 excess signal ('belly') between a few Hz up to 70-80 Hz might be caused by air turbulence (which is not included in the simulation).

Attachment 1: sens_output_comparison.png
16930   Mon Jun 20 19:46:04 2022 TomislavUpdateASCSimulation plots

In the attachment please find IMC ASC simulation plots. Let me know what you think, if you want some other plots, and if you need any clarification.

Attachment 1: pit_mot_cl_MCs.png
Attachment 2: loc_damp_cl_MCs.png
Attachment 3: contr_output_cl_MCs.png
Attachment 4: sens_output_cl_MCs.png
Attachment 5: BS_motion_cl_MCs.png
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/

ELOG V3.1.3-