40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 190 of 339 Not logged in
ID Date Author Type Category Subject
14801   Tue Jul 23 21:59:08 2019 JonUpdateCamerasPlan for GigE cameras

This afternoon Gautam and I assessed what to do about restoring the GigE camera software. Here's what I propose:

• Set up one of the new rackmount Supermicros as a dedicated camera feed server
• All GigE cameras on a local subnet connected to the second network interface (these Supermicros have two)
• Put the SnapPy, pypylon, and pylon5 binaries on the shared network drive. These all have to be built from source.
• All other dependencies can be gotten through the package managers, so create requirements files for yum and pip to automatically install these locally.

I've started resolving the many dependencies of this code on rossa. The idea is to get a working environment on one workstation, then generate requirements files that can be used to set up the rest of the machines. I believe the dependencies have all been installed. However, many of the packages are newer versions than before, and this seems to have broken SnapPy. I'll continue debugging this tomorrow.

4548   Wed Apr 20 22:29:07 2011 sureshUpdateRF SystemPlan for LSC rack

The suggested layout of the 1Y2 Rack is shown below.

To simplify the wiring, I have largely kept demod boards with the same same LO frequency close to each other.

The Heliax cables land on the top and bottom of the of subracks.  These are currently flexible plastic sheets.  Steve has agreed to replace them with something more rigid.  It would be good to have eight N-type connectors on the top and eight  at the bottom.  As  demod boards occur in sets of eight per subrack.  So it would be convenient if the 11 and 55 Mhz Heliax cables land on the top and the rest at the bottom.  In the layout I have shown the current situation.

The LO signals to the boards come from the RF Distribution box and this is kept in the middle so that cables to both the subracks can be kept short.

The outputs of the AA filter boards from both subracks  have to be connected to the SCSI Interface board with a twisted pair ribbon cable.

15654   Mon Nov 2 16:46:06 2020 gautamUpdateGeneralPlan for OMC chamber

To be a bit more clear about what we are going to do in the OMC chamber, I marked-up some photos, see Attachments #1 and #2.

1. OM5 will be rotated to bring the IFO AS beam straight out without any splitting to the OMC.
2. OMMT, OMC, DCPD, DCPD transimpedance amp, and all peripheral optics associated with these components, will be removed. Many of these components are mounted on a breadboard and so removing that breadboard will take care of it. These are marked with pink Xs.

I anticipate that after this work, the only components on the table will be

1. IM1, to send the PSL beam to the IMC.
2. OMs 5 and 6 to bring the IFO AS beam out onto the AP table (in principle, we could try and eliminate both these optics, if the AS beam happens to exit through one of the viewports cleanly, we will not have any intervening objects in the way once the OMC and peripherals are removed).
3. MMT2 for mode-matching the IMC transmission to the interferometer mode.

Are we in agreement with this plan?

See #15656 for the updated photo

Attachment 1: IMG_2318.JPG
Attachment 2: IMG_2332.JPG
15655   Mon Nov 2 17:13:19 2020 KojiUpdateGeneralPlan for OMC chamber

I believe the mirror next to IM1 is for the green beams to be delivered to the PSL table. I think we still want to keep it. Otherwise, the plan looks fine.

15656   Mon Nov 2 17:32:05 2020 gautamUpdateGeneralPlan for OMC chamber

Good point - looking back, I also see that I already removed the mirror at the SW corner of the table in 2016. Revised photo in Attachment #1. There is an optic on the east edge of this table whose purpose I'm not sure of, but I'm pretty sure it isn't essential to the main functionality and so can be removed.

 Quote: I believe the mirror next to IM1 is for the green beams to be delivered to the PSL table. I think we still want to keep it. Otherwise, the plan looks fine.
Attachment 1: IMG_2317.JPG
3576   Wed Sep 15 14:34:57 2010 josephbSummaryCDSPlan for RFM switch over

Steps for RFM switch over:

1) Ensure the new frame builder code is working properly:

A) Get Alex to finish compiling the frame builder and test on Megatron.

B) Test the new frame builder code on fb40m (which is running Solaris) in a reversible way.  Change directory structure away from Data1, Data2, to use actual times.

C) Confirm new frame builder code still records slow channels (c1dcuepics).

2) Ensure awg, tpman, and diagnostic codes (dtt) are working with the new front end code.

3) Physically move RFM cables from old front ends to the new front ends.  Remove excess connections from the network.

4) Merge the megatron/c1sus/c1iscex/c1ioo network with the main network.

A) Update all the network settings on the machines as well as Linux1

B) Remove the network switch separating the networks.

4) Start the new frame builder code on fb40m.

16031   Wed Apr 14 17:53:38 2021 AnchalUpdateSUSPlan for calculating filter banks for output matrix aka F2A aka F2P

Plan of action

• Get the transfer functions of the suspension plant from actuated DOF to sensed DOF. We'll verify Bhavini's state-space model and get these transfer functions. Use the model TFs, not measured.
• For each of POS->POS, PIT->PIT, and YAW->YAW, we'll get the resonant frequency and Q of the resonance from these models. No, forget about the Q.
• We can correct the resonant frequencies from the measured ones in our free swinging data.
• Now, we'll repeat the following for each column of output matrix filters (inspired from scripts/SUS/F2Pcalc.py, but not fully understood how/why):
• Select col (eg. POS)
• Set f0 to the resonant frequency.
• Calculate $\large f_{UL} = f_0 * \sqrt{G_{UL}}$ where GUL is the corrected DC gain we got after output matrix optimization earlier. (Not sure how, why?). No, use the SS model.
• Calculate fUR, fLL, and fLR like above.
• Set $\large Q_{UL} = \sqrt{G_{UL}}$   (This just seems like a way of keeping some approximately low Q, ideally we should keep this same to what we got above but that might cause saturation issues like Rana mentioned in the meeting)
• Then, set the following filter in the output matrix element for UL:
$\dpi{200} G_{UL}\frac{1 + i\frac{f}{f_{UL}Q_{UL}} - \frac{f^2}{f_{UL}^2}}{1 + i\frac{f}{f_{0}} - \frac{f^2}{f_{0}^2}}$
which is in zpk form equivalent to:
$\dpi{150} z: \frac{f_0}{2 Q_{UL}} +/- i f_0 \sqrt{1 - \frac{1}{4Q_{UL}}} \quad, \quad p: \frac{f_0}{2} +/- i f_0 \frac{\sqrt{3}}{2} \quad, \quad k: G_{UL}$
• Repeat the above for UR, LL, LR.
• Note that this filter function takes values GUL at DC and at high frequencies while it would dip at the resonant frequency for POS with depth and narrowness directly proportional to QUL. No, the DC gain is different from the AC gain.
• However, the F2P filter plots we found in several places on elog look a bit different. Like here: 40m/4719. One important difference is that the filter magnitude always become 1 after the resonance at higher frequencies. Yes, this is  what we want, since you already did the balancing at high frequencies.
• A preliminary plot of the above calculation for the 1,1 output matrix filter bank (POS -> UL) is attached in Attachment 1.

Discussion:

• We can make 12 such filters for the 12 numbers we got for the optimized output matrix. Is that the aim or should we do it only for the POS column as has been done in past?
• We are not sure how the choice of Q is made in setting the above filter function. We'll think more about it to understand this.
• We are also not sure how the choice of fUL is made above. It looks like depending on the correction gain, we want to slide the zero positions with respect to the pole positions which are fixed at the resonant frequency as expected. This seems to have some complex explanation.
• Please let us know if we are planning this right before we dive into these calculations/script writing. Thanks.

Edit Thu Apr 15 08:32:58 2021 :

Corrected the plot in the attachment. It shows the correct behavior at high frequencies now.

Attachment 1: MC2propF2A_UL.pdf
4076   Mon Dec 20 10:47:29 2010 KojiUpdateIOOPlan for closing the vacuum chambers

Monday

• Place the bars on the in-vac tables to mark the positions of the test mass suspensions. (ITMX/ITMY/ETMX/ETMY)
• Check the table leveling again (ITMX/ITMY/ETMX/ETMY/BSC)
• Align the whole interferometer.
• Check the OPLEV spots by either QPDs or apertures
• Check the OSEM values (MC1/2/3, BS, PRM, SRM, ITMX, ITMY, ETMX, ETMY)
• Energize OMC PZTs.
• We have removed the cards at the back of the HV driver.
• Insert the card and check the connection.
• Adjust the DC values at the middle of the range.
-> They have an internal bias circuit to provide +75V at the outputs. (D060287).
The actual voltages confirmed.
• Adjust the physical knobs of the PZTs such that we can see the spots at the OMCR cam
• If everything is fine, attach the access connector.
• If still everythig is fine, put the BS heavy door.

Tuesday

- Do the following list for all of the testmass chambers.

• Check if the OSEMs and the OPLEV are still fine.
• Inspect the surface of the mirror with a laser pointer or a fiber coupled halogen light.
• Blow the mirrors by the ionization gun.
• Inspect the mirror surface again.
• Move the suspension tower close to the door.
• Make a single drag-wipe with iso
• Move the SOS tower at the original place.
• Check the OSEMs and the OPLEVs. Adjust the alignment.
• Put the heavy door.

- Start slow pumping

4078   Mon Dec 20 22:56:20 2010 JenneUpdateIOOPlan for closing the vacuum chambers

Tuesday

• If still everythig is fine, put the BS heavy door.

- Do the following list for all of the testmass chambers.

• Check if the OSEMs and the OPLEV are still fine. (ITMX and ITMY were not done on Monday, so need extra care.)
• Inspect the surface of the mirror with a laser pointer or a fiber coupled halogen light.
• Blow the mirrors by the ionization gun.
• Inspect the mirror surface again.
• Move the suspension tower close to the door.
• Make a single drag-wipe with iso
• Move the SOS tower at the original place.
• Check the OSEMs and the OPLEVs. Adjust the alignment.
• Put the heavy door.

- Start slow pumping

5278   Mon Aug 22 20:37:43 2011 AnamariaConfigurationRF SystemPlan for install of 3f PDs

I made a quick sketch of how to include two more RF PDs on the REFL beam, given the space we have on the table. We want to install REFL33 and REFL165, 3f signals for the the two modulation frequencies we are using. The point is to make the distance from first beam splitter the same to all PDs so that we can use only one lens before this BS to make the beam the right size. Currently there are 2 PDs on the refl beam, REFL11 and REFL55, predictably. So the drawing shows 4 PDs. Drawing is to scale but is a bit coarse. Hopefully we'll take pictures once we're done.

Reference from current BS splitting beam to the existing PDs.

Attachment 1: 40m3fReflPdLayout.pdf
5425   Thu Sep 15 20:30:52 2011 MirkoUpdateLSCPlan for long term optical spec. analyzer setup

Just to give some heads up on how the setup on the PSL table does / will look. We start out with one of the two reflections of a window. Power about 2mW.

5550   Mon Sep 26 18:59:11 2011 JenneUpdateAdaptive FilteringPlan for making MC_F

 Quote: For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

[Jenne, Den]

Suresh tells us that he already has this channel physically plugged in.  Probably as a result of Valera's MCASS work.  Neat.  We just have to make the channel.  Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.

We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things.  So.  Tomorrow.  In the morning:

We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F".  We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC.  Then we will compile all the things.  Or at least all the things that we touched.  This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway.  Neat.

Things to compile tomorrow:  c1ioo and c1rfm, because of channel routing.  c1oaf because of all the new stuff.  That should be all.

5555   Tue Sep 27 09:47:52 2011 SureshUpdateAdaptive FilteringPlan for making MC_F

Quote:

 Quote: For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

[Jenne, Den]

Suresh tells us that he already has this channel physically plugged in.  Probably as a result of Valera's MCASS work.  Neat.  We just have to make the channel.  Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.

We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things.  So.  Tomorrow.  In the morning:

We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F".  We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC.  Then we will compile all the things.  Or at least all the things that we touched.  This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway.  Neat.

Things to compile tomorrow:  c1ioo and c1rfm, because of channel routing.  c1oaf because of all the new stuff.  That should be all.

Is it okay to have two names for the same signal?  We would have both MCS_MCL and MC_F referring to MC length signal.  This signal is picked up from the MC-Servo (analog) and brought into the CDS through the adc_0_0 channel in C1IOO.   Then this signal is sent from C1IOO to C1MCS model without going through the c1rfm model.  This seems to break the current protocol that signals passed between machines have to go through the c1rfm model.  It should be sufficient to send this signal to c1rfm once and from there redirect to MCS and OAF from there, with an appropriate name.

5557   Tue Sep 27 11:52:33 2011 JenneUpdateAdaptive FilteringPlan for making MC_F

Quote:

Quote:

 Quote: For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

[Jenne, Den]

Suresh tells us that he already has this channel physically plugged in.  Probably as a result of Valera's MCASS work.  Neat.  We just have to make the channel.  Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.

We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things.  So.  Tomorrow.  In the morning:

We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F".  We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC.  Then we will compile all the things.  Or at least all the things that we touched.  This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway.  Neat.

Things to compile tomorrow:  c1ioo and c1rfm, because of channel routing.  c1oaf because of all the new stuff.  That should be all.

Is it okay to have two names for the same signal?  We would have both MCS_MCL and MC_F referring to MC length signal.  This signal is picked up from the MC-Servo (analog) and brought into the CDS through the adc_0_0 channel in C1IOO.   Then this signal is sent from C1IOO to C1MCS model without going through the c1rfm model.  This seems to break the current protocol that signals passed between machines have to go through the c1rfm model.  It should be sufficient to send this signal to c1rfm once and from there redirect to MCS and OAF from there, with an appropriate name.

Suresh makes a fine point.  I think the channel between c1ioo and c1mcs should always have had to go through the c1rfm model.  I don't know why it wasn't.  Anyhow, I have changed things so that there is one signal passing from c1ioo to c1rfm, and that signal is split in two, and goes to both c1oaf and c1mcs.  The naming convention I used last night is the one I kept:  C1:IOO-RFM_MCL goes from c1ioo to c1rfm, and then C1:RFM-OAF_MCL goes from c1rfm to c1oaf, and C1:RFM-MCS_MCL goes from c1rfm to c1mcs.

We can't compile until Mirko and I figure out what to do with the OAF model though.  Mirko, Den and I were looking at the c1oaf model, to make sure it is ready to compile, and I'm not sure that it is.  And we need everything with common channel names to be compiled at the same time, so I can't compile any of the models today, until we get this figured out.

The problem is thus:  The old TOP_XFCODE that mevans wrote back in 2008 takes in a certain number of inputs, calculates the new filter coefficients, and spits out the filtered signals.  Back in those days, we only ever gave the adaptive system one control (target) signal at a time.  Now, we want to be able to do multiple, if we so desire.  I don't know exactly how to do this yet.  Either we need to modify the code to make it a super-code, or we can have one copy of the code for each control signal (MC_F, XARM, YARM, DARM, MICH, etc...).  Do we want to have one code adapt everything at once, and have a giant MIMO system, or do we want to have many SISO-like systems in parallel (SISO-like, because each one would take in one control signal, and many seismometer signals, and output many filtered seis signals, but it wouldn't be combining control signals together)?

Either one of these options could be waaay to computationally tough for the computer.  The old computer was basically railed when we had one adaptive block, with one control signal and 7 seismometers.  7 was the max number of auxiliary channels we could use.  So, how much faster are the new computers?? Do we need to have one OAF per DoF that we want to filter?

14367   Wed Dec 19 14:19:15 2018 KojiSummaryVACPlan for pumpoing down test

We still need elaborated test procedure posted

12/29 Wed

• Jon continues to work on valve actuator tests.
• Chub continues to work on wiring / fixing wiring.
• At the end of the day Jon is going to send out a notification email of "GO"/"NO GO" for pumping.

12/30 Thu

• 9AM: Start closing two doors unless Jon gives us NO GO sign.
• 10AM: Start pumping down
• Test roughing pump capability via new control system
• (Independently) Test turbo rotating procedure. This time we will not open the gate valve between the TP1 and the main volume. This is because we want to take care of the backing turbo loads while we gradually open the gate valve. This will take more hours to be done and we will not be able to finish this test by the end of Thu.
• At the end of the procedure, we isolate the main volume, stop all the pumps, and vent the roghing pumps to save them from the oil backstream.

gautam: Koji and I were just staring at the vacuum screen, and realized that the drypumps, which are the backing pumps for TP2 and TP3, are not reflected on the MEDM screen. This should be rectified.

Steve also mentioned that the new small turbo controller does not directly interface with the drypump. So we need some system to delay the starting of the turbo itself, once the drypump has been engaged. Does this system exist?

Attachment 1: Screenshot_from_2018-12-19_14-49-34.png
5455   Mon Sep 19 02:33:34 2011 kiwamuHowToGeneralPlan for this week

GOAL1:  Stable lock of DRMI

GOAL2:  Measurement of the LSC input matrix in the DRMI configuration

/- - Daytime works - - /

+ Measurement of the arm lengths (Jenne / Kiwamu / volunteers)

+ Optimization of the oplev control loops (Paul)

+ Inversion and installation of the SUS input matrices (Jenne)

+ Tuning of the SUS damping gains (Steve)

+ Measurement of the modulation depths (Mirko)

+ Preparation of the green broadband PD (Katrin)

+ Fixing the Y arm green lock servo (Katrin / Kiwamu)

+ Installation of RFPDs (Anamaria)

+ Minimization of the AM sidebands (Anamaria / Keiko)

+ Preparation of a script for measuring the LSC input matrix (Keiko)

+ MC WFS (Suresh)

+ Online adaptive filtering (Mirko / Jenne)

+ Modification of C1ASS (Kiwamu)

+ Fixing IPPOS (volunteers)

+ Auto alignment of PRCL and SRCL (volunteers)

+ Loss measurement of the arm cavities (volunteers)

+ Fixing the ETMX SIDE slow monitor (volunteers)

/- - Nighttime works - - /

+ Locking of DRMI

+ Characterization of DRMI and complete the wiki page

5456   Mon Sep 19 11:49:32 2011 JenneHowToGeneralPlan for this week: SUS inversion

 Quote: + Inversion and installation of the SUS input matrices (Jenne)

It turns out that this is complicated, since there are so many people working with the IFO this week.  What I would like to do is put in the new input matricies, and then do a free swinging test, to see if the suspensions are really diagonalized in the way that we want them to be.  I can't do this during the day, since it will interfere with Paul's OpLev work.  And at "night", I can't, since we'll be doing locking.  So, this may be a late-night task.  I'll write a script this afternoon that will put in all of the new input matricies, and then run the freeswing and the restore watchdogs scripts.  Whomever is the last one to leave for the night can run the combo script.

EDIT:  As of this time (~11:45am), ITMY has its new input matrix.

5492   Tue Sep 20 23:59:53 2011 KojiSummaryLSCPlan to update the LSC code for multiple lock-ins

DRMI team needs to use at least three lockins on LSC

• Increase the number of the lockin matrix  done
• Duplicate lockin modules in the LSC code  done
• modify the main LSC screen done
• modify the lockin screen done
• modify the lockin matrix screen done
8850   Mon Jul 15 16:51:37 2013 AlexConfiguration Planned AS Table addition

[Eric, Alex]

We are planning to add our reference PD to the southern third of the AS Table as pictured in the attachment. The power supply will go under the table.

15683   Sun Nov 22 21:09:37 2020 gautamUpdateASCPlanned mods for WFS head

Attachment #1 - Proposed mods for 40m RF freqs.

• I followed Rich's suggestion of choosing an inductor that has Z~100 ohms at the frequency of interest.
• The capacitor is then chosen to have the correct resonant frequency.
• Voltronix trim caps are used for fine tuning the resonances. 2 variants are used, one with a range of 4-20 pF, and a Q of 500 per spec, while the other has range of 8-40 pF, and a Q of 200 per spec.
• In the table, the first capacitance is the fixed one, and the second is the variable one. We're not close to the rail for the variable caps.
• For the first trials, I think we can try by not populating all of the notches - just the 2f notch. We can then add notches if deemed necessary. Probably these notches are more important for a REFL/POP port WFS.
• One thing I noticed is that the aLIGO WFS use ceramic capacitors for the LC reactances. i haven't checked if there is any penalty we are paying in terms of Q of the capacitor. anyways, i'm not going to redesign the PCB and maybe ceramic is the only option in the 0805 package size?

Attachment #2 - Modelled TFs for the case where all the notches are stuffed, and where only the 2f notch is stuffed.

• The model uses realistic composite models for the inductors from coilcraft, but the capacitors are idealized parts.
• I also found the library part for LMH6624, so this should be a bit closer to the actual circuit than Rich's models which subbed in the MAX4107 in place.
• The dashed vertical lines indicate some frequencies of interest.
• Approx 1 kohm transimpedance is realized at 55 MHz. I don't have the W/rad number for the sensitivity at the AS port, but my guess is this will be just fine.
• If the 44 MHz and 66 MHz notches are stuffed, then there is some interaction with the 55 MHz notch, which lowers the transimpedance gain somewhat. So if we decide to stuff those notches, we should do a mroe careful investigation into whether this is problematic.

Attachment #3 - Modelled TFs for the case where all the notches are stuffed, and where only the 2f notch is stuffed.

• Initially, I found the (modelled) noise level to be rather higher than expected. It persisted despite making the resistors in the model noiseless. Turns out there is some leakage from the "Test Input" path. Some documents in the DCC suggest that there should be an "RF Relay" that allows one to isolate this path, but afaik, the aLIGO WFS does not have this feature. So maybe what we should do is to remove C9 once we're done tuning the resonances. Better yet, just tune the resonance with the Jenne laser and not this current-injection path.
• Horizontal dashed lines indicate shot noise for the indicated DC photocurrent levels. It is unlikely we will have even 1 mW of light on a single quadrant at the AS port, so the AS port WFS will not be shot noise limited. But I think that's okay for initial trials.
• The noise level of ~20 pA/rtHz input referred is in agreement what I would expect using Eq 3 of the LMH6624 datasheet. The preamp has a gain of 10, so the source impedance seen by it is ~100 ohms (since the overall gain is 1kohm). The corresponding noise level per Eq 3 is ~2 nV/rtHz, or 20 pA/rtHz current noise referred to the photocurrent 👍 .
• The LMH6624 datasheet claims that the OpAmp is stable for CLG >= 10. For reasons that aren't obvious to me, Koji states here that the CLG needs to be even higher, 15-20 for stability. Do the aLIGO WFS see some instability? Should I raise R14 to 900 ohms?

Any other red flags anyone sees before I finish stuffing the board?

 Quote: WFS head and housing. Need to finalize the RF transimpedance gain (i.e. the LC resonant part), and also decide which notches we want to stuff.
Attachment 1: aLIGO_wfs_v5_40m.pdf
Attachment 2: TFs.pdf
Attachment 3: noise.pdf
15689   Wed Nov 25 18:18:41 2020 gautamUpdateASCPlanned mods for WFS head

I am confused by the discussion during the call today. I revisited Hartmut's paper - the circuit in Fig 6 is essentially what I am calling "only 2f_2 notch stuffed" in my previous elog. Qualitatively, the plot I presented in Attachment #2 of the preceeding elog in this thread shows the expected behavior as in Fig 8 of the paper - the impedance seen by the photodiode is indeed lower. In Attachment #1, I show the comparison - the "V(anode)/I(I1)" curve is analogous to the "PD anode" curve in Hartmut's paper, and the "V(vout)/I(I1)" curve is analogous to the "1f-out" curve. I also plot the sensitivity analysis (Attachment #2), by varying the photodiode junction capacitance between 100pF and 200 pF (both values inclusive) in 20 pF steps. There is some variation at 55 MHz, but it is unlikely that the capacitance will change so much during normal operation?

I understand the motivation behind stuffing the other notches, to reduce intermodulation effects. But the impression I got from the call was that somehow, the model I presented was wrong. Can someone help me identify the mistake?

I didn't bother to export the LTspice data and make a matplotlib plot for this quick analysis, so pardon the poor presentation. The colors run from green=100pF to grey=200pF.

Attachment 1: anodeVsOutput.png
Attachment 2: sensitivity.png
15691   Sat Nov 28 21:44:53 2020 ranaUpdateASCPlanned mods for WFS head

I don't think your simulation looked inaccurate (at least not to me). In my opinion, we just want to minimize any excess noise from intermodulation. Of course, its possible that stuffing too many notches will make it difficult to have the same low noise as a simple circuit, so that's worth considering.

Also, the intermodulation is mainly a problem when the other peaks are not suppressed by some feedback: e.g. POP55_I can have excess noise if POP55_Q or POP11_I are not controlled by some MICH/PRCL/SRCL loops.

For the WFS, perhaps this is not a significant issue, but I'm not sure. My suggestion is to stuff 11 & 55 for sure, and then the others depending on the amplitude of the peaks and the consequent intermodulation. IF it works with all stuffed, that seems good. If its tricky to get it to work with all stuffed, I'd back off on a couple of them...but it probably takes more careful thought to figure out which ones are least important.

8806   Mon Jul 8 16:27:49 2013 AlexUpdate Planned rack additions

Alex and Eric

For the photodetector frequency response automation project, we plan to add modules to rack 1y1 as shown in the attached picture (Note: boxes are approximately to scale).

The RF switch will choose which photodetector's output is sent to the Agilent 4395A Network Analyzer.

The Diode Laser Module is powered by Laser Power Supply, will be modulated by the Network Analyzer and will be output to a 1x16 optical splitter which is already mounted in another rack (not pictured).

The Transformer Module has not been built yet.

We would like to install the power supply and the laser module tomorrow and will not begin routing fibers and cables until we post a drawing in the elog.

Also, our reference photoreceiver arrived today.

Attachment 1: Annotated_Rack_1y1.pdf
8829   Thu Jul 11 12:00:50 2013 AlexUpdate Planned rack additions

[Eric, Alex]

We mounted our Laser Module and Laser Power Source in rack 1y1. We plan to add our RF Switch and Transformer Module to the rack, as pictured. (Note: drawn-in boxes in picture are approximately to scale.) Note that the panel of knobs which the gray boxes overlap is obsolete and will soon be removed.

Attachment 1: Annotated_Rack_1y1_-_update.pdf
15842   Wed Feb 24 22:13:47 2021 JonUpdateCDSPlanning document for front-end testing

I've started writing up a rough testing sequence for getting the three new front-ends operational (c1bhd, c1sus2, c1ioo). Since I anticipate this plan undergoing many updates, I've set it up as a Google doc which everyone can edit (log in with LIGO.ORG credentials).

Please have a look and add any more tests, details, or concerns. I will continue adding to it as I read up on CDS documentation.

7672   Mon Nov 5 20:37:01 2012 AyakaUpdateWienerFilteringPlay with wiener filtering

I am trying to find what limits the reduction rate with wiener filtering.
I did some calculations below:

Reduction rate estimation by microphone noise

When the instrumental noise (noise in microphone) and noise injected to signal after the acoustic signal is injected exist, the noise cancellation rate is limited. (I will write a short document about it later.) I assumed that there is only instrumental noise and that the other noise in PMC is below enough, and calculated the cancellation rate. The instrumental noise is modeled according to the measurement before (ELOG).
The green line is the original PMC signal, the red one is PMC residual error, and the blue one is PMC residual error estimated by the cancelling rate.
Around 30 - 80 Hz, the wiener filtering seems to be already good enough. However, I do not know what limits the cancellation rate (such as 100 - 200 Hz).

Filtering signals

I hypothesized that the wiener filter is not good because of some peaks or other noise. So I filtered the PMC signal and mic signal to see the difference.
The red line is wiener filter with no filters, the blue one is with filters (low pass, high pass, and notch).
The wiener filter seems to get smoother but the PMC residual error did not change at all.

7688   Thu Nov 8 10:11:58 2012 AyakaUpdateWienerFilteringPlay with wiener filtering

I will attach a document which describes how the noise affect the wiener filter and the noise cancellation ratio.

And I re-estimate the SN ratio in the microphone (but still rough):

The yellow line is modeled signal level, and cyan line is modeled noise level.

Then, the estimated filtered residual noise is:

The noise is already subtracted enough below 80 Hz even though there is still coherence.
Above 300 Hz, the residual error is limited by other noise than acoustic noise since there is no coherence.
I am not sure about the region between 100-300 Hz, but I guess that we cannot subtract the acoustic noise because primary noise (see the document), such as a peak at 180 Hz, is so high.

Attachment 1: document.pdf
9078   Wed Aug 28 03:28:00 2013 JenneUpdateLSCPlaying with DRMI, some ASS automation prep

[Rana, Jenne]

We did lots of poking around with the DRMI tonight.  I should elog more in the morning, but the most important points are:

Locking settings same as elog 9068, except PRCL gain changed to 0.035, and the FMs that are triggered.  PRCL tonight had FM2,3,6 triggered.  MICH had FM1,2,3,7 triggered.  SRCL had FM1,2 triggered.  Engaging the MICH boosts helped make things more quiet, so that some of the SRC boosts could be enabled.  Still not as good of lock stretches as Koji got last Friday (elog 9060).

REFL55 and REFL11 were still saturating (only during acquisition), after the optical path changes I did last week (elog 9043).  We reduced the REFL55 whitening slider from 15 dB to 6 dB (but forgot to compensate with digital gain), to keep the counts (as seen on DTT time series, binning off) to less than ~20,000 counts.  REFL11 is still saturating, and we're not sure why, since it's slider gain is 0 dB.  To be investigated.

I was prepping the ASS to be more conveniently put into a wrapper script, which could be called from the IFO Configure screen.  This involved adding PRCL to the burt .req and .snap files, as well as modifying the scripts a little bit to include PRCL as an option.  I ended up changing the script names from DITHER_Arm_ON.py and DITHER_Arm_OFF.py to DITHER_ASS_ON.py adn DITHER_ASS_OFF.py, since they are no longer restricted to being arms-only.  You must still provide an argument to the script, to tell it which degree of freedom you want to activate.  I also changed the save offsets scripts.  The way they were, the X and Y arms just had separate hard-coded scripts, with no convenient way to incorporate PRCL.  I merged them (including PRCL) into WRITE_ASS_OFFSETS.py, which you must now provide the DoF as an argument.  I tested these new scripts on all 3 of the DoFs, and made changes to the ASS screen, so it now calls only the new scripts.  It should now be easy to incorporate future ASS modifications.

Rana was in the middle of modifying the ASS model to include SRCL, and we also need to include MICH.  The ASS model is not compile-ready, so don't compile it!!  If you need to compile the ASS, please save what's there as a different name, and do an "svn up" to get the latest working version.

We suspected that there might be angular drive issues with the SRM (it was wiggling a lot). We checked the damping via step responses - all Qs were less than 10. Then we found that the INPUT button on the SRM PIT OL was OFF (why ???). After turning this back on it behaved better. We measured the loop shape and found that the UGF was 7 Hz; good. Need to work on some loop shaping for this guy. Its just 1/f out to 300 Hz right now. UGF should be made a little lower so that we can stably turn on the Bounce/Roll notches and a ~50 Hz low pass filter.

Most importantly, the F2A filters need to be measured and implemented. They are a few years old.

9787   Tue Apr 8 01:58:53 2014 JenneUpdateLSCPlaying with PRMI + 2 arms

I played around with the PRMI + 2 arms situation again this evening.  (I'm not ready to call it "PRFPMI" until we're at least partially using IR signals for CARM and DARM control).

I'm still a little bothered by the fact that we lose almost all light in the PRC when we're reducing the CARM offset.  I'm not sure where the light is going, but it's not circulating in the PRC, since I see the POP camera get very dark.  I can bring back light by changing either the PRCL offset, the MICH offset, or to a lesser extent (or maybe I'm not going far enough in offset) the DARM offset.

Tonight, I was using ALS to push on the ETMs in DARM/CARM mode (I didn't push on MC2 today, since it was being finicky and I had a hard time locking CARM with the MC as the actuator today).

For the PRMI, I was using REFL 33 I&Q.  PRCL gain was -0.04, MICH gain was +0.8.  REFL 33I varied between +2 and +1.2 (smaller gain necessary as CARM offset was reduced, but it's easier to acquire at large CARM offset with larger gain), and REFL 33Q was +1.0.   PRCL has the usual FM 2,3,6,9 triggered, but MICH only had FM 2 triggered.  The others (particularly FM6) make MICH lose lock.  PRCL ASC was engaged, with the PRM oplev off.

Most of what I was trying tonight was to reduce the CARM offset, and then adjust some other offset (MICH, PRCL or DARM) to maximize POP DC.  It's possible that the POP 110 and 22 diodes are changing their optimal demod phases as the optical plant changes, but POPDC is just DC.

I wasn't able to get the CARM offset below about 40 counts.  At some point I had both CARM and DARM offsets at 50 counts, and had IR resonance in the Xarm, but no resonance in the Yarm.  I guess this is just part of having a simultaneous CARM and DARM offset.

EDIT:  If I leave the CARM offset at 0, and use a large DARM offset (100 counts), I can acquire PRMI lock, but I run into the same problems as I reduce the DARM offset - the POP power decreases, and I lose lock around 45 counts.

Side note: Earlier today I redid the POP 110 and 22 phases.  POP110 was -61 deg, and is not -101 deg.  POP22 was +164 deg, and is now -105 deg.  I'm not sure why they needed such radical changes.  When sideband locked on REFL33, POP110 had an average DC level of 580 cts, while POP22 had a value of 290 cts.

9788   Tue Apr 8 10:44:53 2014 KojiUpdateLSCPlaying with PRMI + 2 arms

I vaguely remember that the ALS count (Phase Tracker output) is converted to Hz@532nm by a factor  ~20kHz/cnt.
This means the calibration for the IR frequency is 10kHz/cnt.

If this is true 100cnt is 2MHz. Isn't it too big?

Assuming 38.5m for the arm length, FSR is 3.89MHz. (~389cnt)

Our sideband is at integer multiples of 11.03MHz. So...

1xf1 is 0.62MHz (62cnt) away from the carrier
2xf1 is 1.24MHz (124cnt)
3xf1 is 1.86MHz (186cnt)
5xf1=1xf2 is 0.79MHz (79cnt)
10xf1 = 2xf2 is 1.58MHz (158cnt)
15xf1 = 3xf2 is 1.52MHz (152cnt)

So we have to be well with in 62cnt to avoid resonating modulation sidebands.

There maybe some mistake in the factors.
e.g. Phase Tracker calibration is not correct, or CARM ALS OFFSET has factor 2 different calibration from the arm ALS offset.

6722   Thu May 31 00:56:13 2012 JamieMetaphysicsComputersPlease remember to check in code changes

I know it's really hard to remember, but our future selves will thank us dearly if we remember to commit all of our code changes to the svn with nice log messages.  At the moment there's a LOT of modified stuff in the userapps working directory that needs to be committed:

controls@pianosa:/opt/rtcds/userapps/release 0$svn status | grep '^M' M cds/c1/models/c1rfm.mdl M sus/c1/medm/templates/SUS_SINGLE.adl M sus/c1/models/c1mcs.mdl M sus/c1/models/c1sus.mdl M sus/c1/models/c1scx.mdl M sus/c1/models/c1scy.mdl M isc/c1/models/c1pem.mdl M isc/c1/models/c1ioo.mdl M isc/c1/models/ADAPT_XFCODE_MCL.c M isc/c1/models/c1oaf.mdl M isc/c1/models/c1gcv.mdl M isc/common/medm/OAF_OVERVIEW.adl M isc/common/medm/OAF_DOF_BLRMS.adl M isc/common/medm/OAF_OVERVIEW_BAK.adl M isc/common/medm/OAF_ADAPTATION_MICH.adl controls@pianosa:/opt/rtcds/userapps/release 0$


This doesn't even include things that haven't even been added yet.  It doesn't take much time.  Just copy and paste what you elog about the changes.

6658   Tue May 22 11:45:12 2012 JamieConfigurationCDSPlease remember to commit SVN changes

Hey, folks.  Please remember to commit all changes to the SVN in a timely manor.  If you don't, multiple commits will get lumped together and we won't have a good log of the changes we're making.  You might also end up just loosing all of your work.  SVN COMMIT when you're done!  But please don't commit broken or untested code.

pianosa:release 0> svn status | grep -v '^?'
M       cds/c1/models/c1rfm.mdl
M       sus/c1/models/c1mcs.mdl
M       sus/c1/models/c1scx.mdl
M       sus/c1/models/c1scy.mdl
M       isc/c1/models/c1lsc.mdl
M       isc/c1/models/c1pem.mdl
M       isc/c1/models/c1ioo.mdl
M       isc/c1/models/c1oaf.mdl
M       isc/c1/models/c1gcv.mdl
pianosa:release 0>


16804   Fri Apr 22 12:09:51 2022 AnchalUpdateCoil DriversPlease update DCC pages

Nice. Please put this information on the DCC pages of the coil driver units. You'll find links to all the units in this document tree LIGO-E2100447. For each page, click on "Change Metadata" from the left panel and add the change made to the resistor (including the resistor name on PCB, previous and new value), and add a link to your previous elog post which has more details like photos, to "Notes and Changes", and upload an updated version of the circuit schematic by creating an annotation in the previous circuit schematic pdf. Every unit that has a serial number in the lab has a DCC page (if not, we should create one) where we should track all such hard changes.

359   Wed Mar 5 12:35:09 2008 JohnSummaryComputer Scripts / ProgramsPlot photodiode responses in MatLab
A matlab function to plot the responses of photodiodes. There's still plenty of room for improvement but it should work for all our diodes without any changes. You may want to adjust which points are used in the fit to remove time delay.

% Plot data from diode response measurements
function out = diodeplot(f_Hz,mag_dB,phase_deg,f_beat_MHz)

% $$clear all %$$$close all % $$clc %$$$
% $$%$$$mag = dlmread('D:\40m\PD6\M7.txt','\t', 15, 0); % $$phase = dlmread('D:\40m\PD6\P7.txt','\t', 15, 0); %$$$
% $$% Frequency i.e. x-axis %$$$f = mag(:,1); % $$%$$$ % Magnitude in dB
% $$mag_dB = mag(:,2); %$$$% $$% Phase in degrees %$$$ phase_deg = phase(:,2);
% $$%$$$% Frequencies of interest % $$f_beat_MHz = [33 133 166 199]*1e6; %$$$
% \$ diodeplot(f, mag_dB, phase_deg, f_beat_MHz)

% x axis limits
xmin = 10e6;
xmax = 500e6;

% Unwrap phase
phase_deg = (180/pi)*unwrap((pi/180)*phase_deg);

%Find values at our freqeuncies of interest
Mag_f_beat = interp1(f_Hz,mag_dB,f_beat_MHz);

% Remove the time delay from the phase data
% (May want to adjust which points are selected here)

straight = @(a, x) a(1) * x + a(2);

xdata = f_Hz;
ydata = phase_deg;

aguess = [10 0.1];
a = lsqcurvefit(straight,aguess,xdata,ydata);
fit = straight(a,xdata);

phase_deg = phase_deg-fit;

figure(1)
ha = axes('units','normalized','position',[0 0 1 1]);
uistack(ha,'bottom');
hi = imagesc(I);
colormap gray
set(ha,'handlevisibility','off', ...
'visible','off')
plot(xdata,ydata,'r')
hold on
plot(xdata,fit,'k')
plot(xdata,phase_deg,'b')
hold off
ylabel('Phase/ degrees', 'FontSize',12)
xlabel('Frequency/ Hz', 'FontSize',12)
title('Removing the time delay','FontSize',16)
legend('data','fit','data-fit',0)
set(gca,'Color','None')
box off

figure(2)
set(gcf,'Color', [1 1 1])
subplot(4,1,[1 3])

semilogx(f_Hz,mag_dB,'k','LineWidth',2.5)
title('Response of PD6','FontSize',16)
ylabel('Magnitude/ dB', 'FontSize',12)
xlim([xmin xmax])
grid

MagLayout = get(gca, 'Position');
YLimits = get(gca, 'YLim') ;
LabelExt = [];

for ivar = 1:length(f_beat_MHz);

a = text(f_beat_MHz(ivar),1.05 * min(Mag_f_beat),...
sprintf('%2.1fdB @ %dMHz', Mag_f_beat(ivar),f_beat_MHz(ivar)/1e6),...
'FontSize',10,'FontWeight','Bold','HorizontalAlignment','right',...
'VerticalAlignment','top','BackgroundColor',[.7 .9 .7],...
'Margin',0.5, 'Rotation',90);
LabelExt = [LabelExt; get(a,'Extent')];
LabelPos = get(a,'Position');

end

% Change YLim so that it is around the bottom of the labels
% There must be a better way
set(gca, 'YLim', [min(LabelExt(:,2)) YLimits(2)])

% Remove the last tick mark so that it doesn't overlap with the
% +180 of the phase plot
YTickLabelNew = str2num(get(gca, 'YTickLabel'));
YTickNew =[[] YTickLabelNew(2:end) ];
set(gca,'XTickLabel', [], 'YTick', YTickNew)

% Add lines now we know what the YLims are
for ivar = 1:length(f_beat_MHz);
line([f_beat_MHz(ivar) f_beat_MHz(ivar)], get(gca, 'YLim'))
end

subplot(4,1,4)
semilogx(f_Hz,phase_deg,'r','LineWidth',2.5)
xlim([xmin xmax])
ylabel('Phase/ degrees', 'FontSize',12)
xlabel('Frequency/ Hz', 'FontSize',16)
grid
PhaseLayout = get(gca, 'Position');
PhaseLayout(4) = MagLayout(2)-PhaseLayout(2);

% Make the top of the phase plot align to the bottom of the
% magnitude plot
set(gca, 'Color', 'None', 'Position',PhaseLayout, 'YTick',[-180:45: ...
180])
set(gcf,'units','normalized','outerposition',[0 0 1 1]);
Attachment 3: PDbw.jpg
16937   Tue Jun 21 22:22:37 2022 TomislavUpdateASCPlots

In the attachment please find a comparison of error signals of simulation and reality after including air turbulence as input noise.

Attachment 1: sens_output_comparison_with_air_turbulence.png
3900   Thu Nov 11 21:07:49 2010 josephbUpdateCDSPlugged c1iscex into DAQ network - still causes network slowdown

I connected the c1iscex computer to the dedicated DAQ network switch (located in 1X7).

This does not seem to have helped c1iscex stop spewing out "OMX: Failed to find peer index of board 00:00:00:00:00:00 (Peer Not Found in the Table)" at the rate of ~1 Gigabyte per minute.

c1iscex is currently off until a solution can be found.

6515   Tue Apr 10 13:42:54 2012 JenneUpdateEnvironmentPlumbing guys are here

I don't know why, but they're looking around on the roof, and inside our ceiling above the bathrooms.

6519   Wed Apr 11 14:34:48 2012 JenneUpdateEnvironmentPlumbing guys are here

 Quote: I don't know why, but they're looking around on the roof, and inside our ceiling above the bathrooms.

Bob tells me that the carpenter is going to move the nitrogen bottles to the other side of the outside door, so that the plumbers can install a safety shower / eyewash right outside our door.

Also, the carpenter just mounted a new glass door cabinet from Bob's lab in the IFO room, so we have some new storage space.

10968   Tue Feb 3 15:20:13 2015 Steve, KojiUpdateVACPneumatic pressure is being read again

[Koji, Steve]

Summary

The N2 pressure reading (C1:VAC-N2PRES) is now up-to-date after rebooting c1vac1.
The vaccum system is "Vacuum normal". We now have a space pressure transducer.

Introduction

Our vacuum valves are manipulated with 60~75 PSI of nitrogen. All the valves are configured to be closed in the case of low N2 supply pressure.
In order to avoid this safety shutdown accidentally triggered, we have two N2 cylinders to sustain the vacuum valves. When one cylinder goes to low
the mechanical valve switches over to the other cylinder.

We have the monitor channel for this (combined) cylinder pressure. One shoulbe be able to see periodical pressure variation when the auto cylinder
switch is operating. However, the nirogen pressure reading got stuck at 66 PSI on Dec.16, 2014 (See attached 60-day plot of N2 supply pressure).

What we did

This morning we tracked down the cause of the trouble. We first closed the valves on EPICS and started to vary the N2 pressure.

Our first guess was the pressure transducer (Omega #236PC100GW) that was already 15 yrs old. We even has a sensor spare for replacement.
But it turned out that the direct voltage reading (to be 1mV/PSI) is changing correctly. The second guess was Omega Controller-Monitor
#DPiS32-C24 that is reading the voltage from the tranceducer. The display on this small black unit was changing corresponding to the
pressure change.

So our thought was
1) RS232C of the monitor unit is not working correctly
or
2) c1vac1 is not communicating with the monitor unit.

We wondered what could cause c1vac1 not communicating with the monitor unit, but we were afraid that some function got stuck
during either the nodus upgrade or chiara rebooting (or something else). So we decided to reboot c1vac1

In order to avoid any glitch in the main vacuum pressure, Steve disconnected some of the controller connectors for the closed valves.
We did this treatment before and it was successful.

Then c1vac1 was rebooted just by telnet and type reboot in the terminal.
Once the target is back in action, we noticed that the monitor value started to move.

Steve reverted the cables to the valves and operated the valves to recover "Vacuum Normal" state. Everything is now nicely settled.

9352   Wed Nov 6 08:33:53 2013 SteveUpdateIOOPoiting changes of PSL

 Quote: Full list tomorrow: IP-Ang & Pos, ETMY-T, ETMY-Oplev, ETMX-T, IOO-Ang & Pos  RA: No one in the control room this evening can understand what this ELOG means. Please use more words.

Yesterday the last steering mirror mount on the PSL was changed, Manasa recovered the MC alignment and Jenne locked the arms.

I centered the following qpds:  ASC-IBQPD, LSC-TRY, SUS-ETMY_OPLEV, LSC-TRX, SUS_ETMX_OPLEV

Touching the PSL pointing IOO-QPD_ANG & POS was a mistake. We lost the reference of the well refined MC input.

One and 20 days TRENDS  plot showing the PSL output drift in pitch can be power drop

However initial pointing is amazingly good. ( I wonder about the lens in front of the qpd ?)

Attachment 1: 1dayTRENDofPOITING.png
Attachment 2: 20dayTRENDioo.png
10308   Thu Jul 31 15:25:51 2014 HarryUpdateGeneralPolarizationExtinction Ratio of Fibers

Purpose

We wanted to measure the PER of the polarization maintaining fibers, so we could say to what extent they are truly polarization maintaining.

Setup

The experimental setup of this measurement includes: The NPRO, quarter and half wave plates for tuning ellipticity and orientation of the resultant polarization, attenuating optics, two steering mirrors for coupling, a polarizing beam splitter before and after the laser coupled fibers, the coupling assembly and fiber, and a powermeter.

I measured the beam power at all the pertinent locations, shown in the figure below. Note that dots represent S polarization, and orthogonal line segments represent P polarization.

Methods

I first assembled this, coupling the output to a fiber coupled powermeter, in order to adjust the coupling.

Then I needed to couple the fibers to the NPRO, which I did to 39.8%. This gave me enough output power to have a coherent, visible beam. (Visible to non-fiber coupled power meter, and on the viewer card). It was important to be sure that the fast axis of the fiber was aligned in some known orientation. Mine was aligned to the horizontal, using the key on the fiber as an indicator. This is to be certain that the output polarization is consistent with the input.

Once everything was coupled and collimated, I began tuning the polarization of the beam at different points.

Immediately after the NPRO, I used the quarter and half wave plates to first eliminate as much ellipticity as possible, and then turn the polarization to align it with the beam splitter and the fiber axis. I then tuned the first PBS to reflect as little as possible. At the output, I installed the second PBS. Since there was no fine adjustment for the angle of this one, I tuned it using the yaw controls of the 6-axis mount the collimator was held in.

Once all this tuning was done, I took power measurements (displayed above) using the unfiltered, Orion/PD power meter.

Results

From a theoretically completely P-polarized input, the Polarization Extinction Ratio, calculated at 10*log(P/S), was  -24.26 +/-  0.43 dB.

These results can be effected by environmental conditions, such as high tightly wound the cable it, its length, etc.

Moving Forward

The next measurement to make would be to characterize the frequency noise introduced by the fiber.

In addition to this measurement, the setup of the beat note system for FOL can be done as soon as we have more collimator adapters.

These measurements may be important in FOL, and in future experiments that may use these types of apparatuses.

15688   Tue Nov 24 16:51:29 2020 gautamUpdatePonderSqueezePonderomotive squeezing in aLIGO

Summary:

On the call last week, I claimed that there isn't much hope of directly measuring Ponderomotive Squeezing in aLIGO without some significant configurational changes. Here, I attempt to quantify this statement a bit, and explicitly state what I mean by "significant configurational changes".

Optomechanical coupling:

The I/O relations will generally look something like:

$\begin{bmatrix} b_1\\ b_2 \end{bmatrix} = \begin{bmatrix} C_{11} & C_{12}\\ C_{21} & C_{22} \end{bmatrix} \begin{bmatrix} a_{1}\\ a_2 \end{bmatrix} + \begin{bmatrix} D_1\\ D_2 \end{bmatrix} \frac{h}{h_{\mathrm{SQL}}}$.

The. magnitudes of the matrix elements C_12 and C_21 (i.e. phase to amplitude and amplitude to phase coupling coefficients) will encode the strength of the Ponderomotive squeezing.

For the inital study, let's assume DC readout (since there isn't a homodyne readout yet even in Advanced LIGO). This amounts to setting $\zeta = \phi$ in the I/O relations, where the former angle is the "homodyne phase" and the latter is the "SRC detuning". For DC readout, the LO quadrature is fixed relative to the signal - for example, in the usual RSE operation, $\zeta = \phi = \frac{\pi}{2}$. So the quadrature we will read out will be purely $b_1$ (or nearly so, for small detunings around RSE operation). The displacement noises will couple in via the $D_1$ matrix element. Attachment #1 and Attachment #2 show the off-diagonal elements of the "C" matrix for detunings of the SRC near RSE and SR operation respectively. You can see that the optomechanical coupling decays pretty rapidly above ~40 Hz.

SRC detuning:

In this particular case, there is no benefit to detuning the SRC, because we are assuming the homodyne angle is fixed, which is not an unreasonable assumption as the quadrature of the LO light is fixed relative to the signal in DC readout (not sure what the residual fluctuation in this quantity is). But presumably it is at the mrad level, so the pollution due to the orthogonal anti-squeezed quadrture can be ignored for a first pass I think. I also assume ~10 degrees of detuning is possible with the Finesse ~15 SRC, as the linewidth is ~12 degrees.

Noise budget:

To see how this would look in an actual measurement, I took the data from Lee's ponderomotive squeezing paper, as an estimate for the classical noises, and plotted the quantum noise models for a few representative SRC detunings near RSE operation - see Attachment #3. The curves labelled for various phis are the quantum noise models for those SRC detunings, assuming DC readout. I fudged the power into the IFO to make my modelled quantum noise curve at RSE line up with the high frequency part of the "Measured DARM" curve. To measure Ponderomotive Squeezing unambiguously, we need the quantum noise curve to "dip" as is seen around 40 Hz for an SRC tuning of 80 degrees, and that to be the dominant noise source. Evidently, this is not the case.

The case for balanced homodyne readout:

I haven't analyzed it in detail yet - but it may be possible that if we can access other quadratures, we might benefit from rotating away from the DARM quadrature - the strength of the optomechanical coupling would decrease, as demonstrated in Attachments #1 and #2, but the coupling of classical noise would be reduced as well, so we may be able to win overall. I'll briefly investigate whether a robust measurement can be made at the site once the BHD is implemented.

Attachment 1: QN_heatmap_RSE.pdf
Attachment 2: QN_heatmap_SR.pdf
Attachment 3: noiseBudget.pdf
14973   Wed Oct 16 11:42:17 2019 gautamUpdateLSCPoor separation of PRCL/MICH in 3f signals

Summary:

There is poor separation of the PRCL and MICH length error signals as sensed in the 3f photodiodes. I don't know why this is so - one possibility is that the MICH-->PRM matrix element in the LSC output matrix needs to be tuned to minimize the MICH -->PRCL coupling.

Details:

Over the last few days, I've been trying to make the 3f locking of the PRMI more reliable. Turns out that while I was able to lock the PRMI on 3f error signals, it was just a fluke. So I set about trying to be more systematic. Here are the steps I followed:

1. Lock the PRMI (i.e. ETMs misaligned) using REFL11 for PRCL, AS55 for MICH.
• This is the so-called 1f scheme.
• The servo signs are chosen such that the carrier field is resonant in the PRC.
• Run the dither alignment to maximize POPDC, minimize ASDC. This is the main purpose of locking in this config.
• Measure some loop TFs, make sure the servo gains are giving us ~100 Hz UGF on these loops.
2. Change the sign of the servo loops to make the sidebands resonant in the PRC.
• The error signals are still sourced from the 1f photodiodes.
• Measure loop TFs, and also the TF between the 1f and 3f error signals.
• This allowed me to determine how the servo gains (and signs) that would be appropriate when using the 3f signals in place of the 1f.
• Determine the offsets in the 3f error signals when the PRMI is locked on 1f error signals. This allows me to set the error point offsets for the PRCL_B and MICH_B paths, which are what is used for the 3f locking.
3. Change the error signals from 1f to 3f.
• After much trial and error, I finally managed to get a stable (>10 mins) lock going.
• Measured some loop TFs.
• Turned on the notch filters in the control filter bank at the sensMat oscillator frequencies, and ran some sensing lines.

Attachment #1 is the result. I don't know what is the reason for such poor separation of the MICH and PRCL error signals in REFL165. The situation seems very different from when I had the DRMI locked in Nov last year.

After this exercise, I tried for some hours to get the 3f PRMI locking going with the arm cavities held off resonance under ALS control, but had no success. The angular motion of the PRC isn't helping, but I feel this shouldn't be a show stopper.

Attachment 1: sensMat.pdf
14970   Mon Oct 14 17:32:28 2019 KojiUpdateCDSPortal Elog entry for the recent CM servo board tests

Updated Circuit Diagram and photos: https://dcc.ligo.org/D1500308-v2

- (1) and (6) of the diagram: TFs with various gain slider values for REFL1/REFL2/AO GAIN [ELOG 14948] (gain values and time delay modeling)
- Switching checks, latest photo of the board, Limiter check  [ELOG 14953]
- (2): Boost transfer functions [ELOG 14955]
- (3): Slow (aka Length) CM output path [ELOG 14965]
- (4): Pole-Zero filter TF [ELOG 14965]
- (5): TF from TESTA2 to TESTB2 [ELOG 14966]
- (6): AC coupling TF of the AO GAIN stage [ELOG 14967]
- (7): AC coupling TF of the IN2 stage on IMC servo board [ELOG 15044]

Slow path = (1)*(2 if necessary)*(3)*(4 if necessary)

Fast path = (1)*(2 if necessary)*(4 if necessary)*(5)*(6)

gautam 20191122: Adding the measured AC coupling of the IN2 input of the IMC servo board for completeness.

Attachment 1: CM_Servo_Diagram.png
9959   Thu May 15 16:46:35 2014 ericqUpdateLSCPossible Path to AO path

It's taken a lot of trial and error, but I've found a path through MATLAB loops that seems like it may be stable at all points.

CAVEAT: This doesn't give any indication as to why we weren't able to turn up the AO gain more last night, as far as I can tell, so it's not all good news.

However, it's still ok to at least have a plan that works in simulation...

Based on the location of the optical resonance peak in the CARM plant, we estimate our CARM offset to be 200pm. I haven't simulated TFs there exactly, but do have 100pm and 300pm TFs. This procedure works in MATLAB starting at either, though 100pm is a little nicer than 300. MATLAB data and code is attached in a zip.

The steps below correspond to the attached figures: Bode plots and step response of the Loop at each step.

0. [Not Plotted] DCTrans sensing, MCL actuation on CARM. FMs1,2,3,5,8; UGF = 120. (DARM not considered at all)

1. AO path just turned on. Crossover with MCL path ~ 3.5kHz.
2. AO gain increased. Crossover ~ 500 Hz. There are now multiple UGFs! Handling all of these in a stable manner is tricky.
3. AO gain increased. Crossover = 150Hz. [No simulations with a higher crossover survived the next steps]
4. Compensation filter applied to MCL path; 1 real Zero at 105Hz and a pole at 1k. From a TF point of view, this is sort of like switching to REFLDC, but the SNR at low frequencies is probably better in TR signals at this point.
5. CARM offset reduced to 30pm. (This smoothens out the optical plant resonance.)
6. Overall gain increased by factor of 3. There is now just one UGF at a few kHz, above the optical resonance. From here, gain can be further increased, boosts can go on, offset can go way down. In reality, we should switch to a single error signal once we're back to one UGF, and go from there.

#4 Seems like the most sticky part. While both sides of this look stable as far as I can tell. I feel that flipping from the red phase curve to the teal might not actually be ok, since they are on either side of the bad phase of 0 degrees. It isn't immediately evident to me how to easily model the transitions between steps, rather than just the stability of of each step in the steady state.

Attachment 3: AOCarmLoop.zip
2023   Tue Sep 29 22:51:20 2009 KojiUpdateMZPossible gain mis-calibration at other places (Re: MZ work done)

Probably there is the same mistake for the PMC gain slider. Possibly on the FSS slider, too???

 Quote: 2) The EPICS setting for the MZ gain slider was totaly wrong.     Today I learned from the circuit, the full scale of the gain slider C1:PSL-MZ_GAIN gave us +/-10V at the DAC.     This yield +/-1V to V_ctrl of the AD602 after the internal 1/10 attenuation stage.     This +/-1V didn't correspond to -10dB~+30dB, but does -22dB~+42dB and is beyond the spec of the chip.

9330   Sat Nov 2 19:36:15 2013 CharlesUpdateGeneralPossible misalignment?

I was working on the electronics bench and what sounded like a huge truck rolled by outside. I didn't notice anything until now, but It looks like something became misaligned when the truck passed by (~6:45-6:50 pm). I can hear a lot of noise coming out of the control room speakers and pretty much all of the IOO plots on the wall have sharp discontinuities.

I haven't been moving around much for the past 2 hours so I don't think it was me, but I thought it was worth noting.

3238   Fri Jul 16 16:07:14 2010 josephbUpdateComputersPossible solution for the last ADC

After talking with Jenne, I realized the ADC card in the c1ass machine was currently going unused.  As we are short an ADC card, a possible solution is to press that card into service.  Unfortunately, its currently on a PMC to PCI adapter, rather than PMC to PCIe adapter.  The two options I have are to try to find a different adapter board (I was handed 3 for RFM cards, so its possible there's another spare over in downs - unfortunately I missed Jay when I went over at 2:30 to check).  The other option is put it directly into a computer, the only option being megatron, as the other machines don't have full length PCI slot.

I'm still waiting to hear back from Alex (who is in Germany for the next 10 days) whether I can connect both in the computer as well as with the IO chassis.

So to that end, I briefly turned off the c1ass machine, and pulled the card.  I then turned it back on, restarted all the code as per the wiki instructions, and had Jenne go over how it looked with me, to make sure everything was ok.

There is something odd with some of the channels reading 1e20 from the RFM network.  I believe this is related to those particular channels not being refreshed by their source (which is other suspension front end machines), so its just sitting at a default until the channel value actually changes.

13609   Tue Feb 6 11:13:26 2018 gautamUpdateALSPossible source of ground loop identified

I think I've narrowed down the source of this ground loop. It originates from the fact that the DAC from which the signals for this board are derived sits in an expansion chassis in 1Y3, whereas the LSC electronics are all in 1Y2.

• I pulled the board out and looked at the output of Ch8 on the oscilloscope with the board powered by a bench power supply - signal looked clean, no evidence of the noisy ~20mVpp signal I mentioned in my previous elog.
• Put the board back into a different slot in the eurocrate chassis and looked at the signal from Ch8  - looked clean, so the ground of the eurocrate box itself isn't to blame.
• Put the board back in its original slot and looked at the signal from Ch8 - the same noisy signal of ~20mVpp I saw yesterday was evident again .
• Disconnected the backplane connector which routes signals from the DAC adaptor box to D000316 board - noisy signal vanished .

Looking at Jamie's old elog from the time when this infrastructure was installed, there is a remark that the signal didn't look too noisy - so either this is a new problem, or the characterization back then wasn't done in detail. The main reason why I think this is non-ideal is because the tip-tilt steering mirrors sending the beam into the IFO is controlled by analogous infrastructure - I confirmed using the LEMO monitor points on the D000316 that routes signals to TT1 and TT2 that they look similarly noisy (see e.g. Attachment #1). So we are injecting some amount (about 10% of the DC level) of beam jitter into the IFO because of this noisy signal - seems non-ideal. If I understand correctly, there is no damping loops on these suspensions which would suppress this injection.

How should we go about eliminating this ground loop?

 Quote: So either something is busted on this board (power regulating capacitor perhaps?), or we have some kind of ground loop between electronics in the same chassis (despite the D990694 being differential input receiving). Seems like further investigation is needed. Note that the D000316 just two boards over in the same Eurocrate chassis is responsible for driving our input steering mirror Tip-Tilt suspensions. I wonder if that board too is suffering from a similarly noisy ground?

13612   Tue Feb 6 22:55:51 2018 gautamUpdateALSPossible source of ground loop identified

[koji, gautam]

We discussed possible solutions to this ground loop problem. Here's what we came up with:

1. Option #1 - Configure the DAC card to receive a ground voltage reference from the same source as that which defines the LSC rack ground.
2. Option #2 - construct an adapter that is differential-to-single ended receiving converter, which we can then tack on to these boards.
3. Option #3 - use the D000186-revD board as the receiver for the DAC signals - this looks to have differential receiving of the DAC signals (see secret schematic).  We might want to modify the notches on these given the change in digital clock frequency

Why do we care about this so much anyways? Koji pointed out that the tip tilt suspensions do have passive eddy current damping, but that presumably isn't very effective at frequencies in the 10Hz-1kHz range, which is where I observed the noise injection.

Note that all our SOS suspensions are also possibly being plagued by this problem - the AI board that receives signals is D000186, but not revision D I think. But perhaps for the SOS optics this isn't really a problem, as the expansion chassis and the coil driver electronics may share a common power source?

gautam 1530 7 Feb: Judging by the footprint of the front panel connectors, I would say that the AI boards that receive signals from the DACs for our SOS suspended optics are of the Rev B variety, and so receive the DAC voltages single ended. Of course, the real test would be to look inside these boards. But they certainly look distinct from the black front panelled RevD variant linked above, which has differential inputs. Rev D uses OP27s, although rana mentioned that the LT1125 isn't the right choice and from what I remember, LT1125 is just Quad OP27...

ELOG V3.1.3-