40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 PSL, Page 28 of 52 Not logged in
ID Date Author Type Category Subject
191   Wed Jun 30 12:31:22 2010 taracHowToPMCPMC fixed

 Quote: the reason why you had this flickering problem was that you had too much power on the RFPD in reflection of the PMC. You already saturated it. I also reduced the RF power as the error signals were not signals anymore, just spikes. my new settings are: RF power : 3.0 Phase : 2.5 PMC Gain: 14dB reduced laser power to 40mW. Transmitted power is 32mW .You have to exchange the output coupler mirror in front of the RFPD in order to increase the power. I think 32mW is enough, it's something like 13mW per cavity.

Ok, I'll find another output coupler mirror and replace the current one, and make sure that it will not saturate the RFPD.

192   Wed Jun 30 12:39:17 2010 FrankHowToPMCPMC fixed

Quote:

 Quote: the reason why you had this flickering problem was that you had too much power on the RFPD in reflection of the PMC. You already saturated it. I also reduced the RF power as the error signals were not signals anymore, just spikes. my new settings are: RF power : 3.0 Phase : 2.5 PMC Gain: 14dB reduced laser power to 40mW. Transmitted power is 32mW .You have to exchange the output coupler mirror in front of the RFPD in order to increase the power. I think 32mW is enough, it's something like 13mW per cavity.

Ok, I'll find another output coupler mirror and replace the current one, and make sure that it will not saturate the RFPD.

the saturating power seems to be much to low. it saturates at .5V DC, usually you can have something like 2V or so. So we should propably fix the PD even if it is working with lower power levels.

For now it's much more important to connect all the signals to the DAQ and lock the refcav. You still have to make a lot of cables, like the ones going to the laser (fast & slow), RFPD DC, PMC and refcav transmitted light, refcav RFPD DC etc.

193   Wed Jun 30 15:51:05 2010 FrankHowToNoiseBudgetview factor for two cylinders to calculate heat transfer via radiation

view factor for two cylinders to calculate heat transfer to and from cavity via radiation

from Michael F. Modest  "Radiative Heat Transfer", Second Edition
ISBN: 0-12-503163-7

438   Mon Dec 20 22:52:55 2010 ranaHowToPMCnuts

The RefCav pole is 37 kHz, not 37 MHz.

To minimize the RFAM, you just look at the PMC REFL PD with the PMC unlocked and adjust the waveplate to minimize the peak. Before doing this, make sure that there is no signal on the PD with the light blocked.

439   Thu Dec 23 22:26:14 2010 ranaHowToPMCnuts

Ah right, that's embarassing. I'll try that.

 Quote: The RefCav pole is 37 kHz, not 37 MHz. To minimize the RFAM, you just look at the PMC REFL PD with the PMC unlocked and adjust the waveplate to minimize the peak. Before doing this, make sure that there is no signal on the PD with the light blocked.

464   Tue Feb 1 23:16:10 2011 FrankHowToElectronics EquipmentTF (attenuation) of 500ft of RG58

I've measured the TF of 500ft of RG58C/U cable to see if the loss is about the same calculated by that piece of software i've found.
I've measured 33.4dB attenuation for the LCOM cable, the calculated value is 32.1dB for some unknown RG58C/U cable.
So i think we should go ahead and calculate the required length and try it.

This is a picture of the 500ft spool we have. As you can see there is only about 1.5inch on that spool, the rest is empty. Height is a few inches.
So regarding the size we can easily have several 100m of cable in a small package

512   Thu Feb 24 15:47:10 2011 FrankHowToComputersperl script parameters for both loops inconsistent

after rebooting both crates i found that the perl script parameters for both loops are inconsistent with what's documented in the elog here.

Tara, can you plz check what the right numbers are. The numbers in the startup script are totally different from the values you posted.

515   Thu Feb 24 23:02:30 2011 taraHowToComputersperl script parameters for both loops inconsistent

Yes, I changed the numbers to see the response and haven't logged

or changed the values in the start up file yet. Will do that.

RCAV   ACAV

KP  -0.7      -0.85

KI   -0.007   -0.0035

set  35.03    37.1

 Quote: after rebooting both crates i found that the perl script parameters for both loops are inconsistent with what's documented in the elog here. Tara, can you plz check what the right numbers are. The numbers in the startup script are totally different from the values you posted.

520   Mon Feb 28 13:29:19 2011 FrankHowToSeismicmanual & datasheet for Trillium 240

568   Thu Apr 7 17:50:16 2011 FrankHowToVacuumtorque for CF flanges

639   Tue Jul 26 03:18:42 2011 JenneHowToLaserSpelling

 Quote: Jenny Laser

## Jenne Laser  (thanks!)

675   Mon Sep 12 01:21:39 2011 FrankHowToVCOtemporary VCO solution

thought a little bit about how to create the difference of 127MHz. Here are two ways how we can do this right now:

We only use one AOM (as before). We can't use the second one as we would have to use it way beyond it's operating range (which we already tried Friday) or in second order where we don't get enough light if double passed.
So using only one we have the following options:

1. we use the Isomet 19" 80MHz OM driver which can be tuned down to 63.5Mhz using an external voltage. The frequency tuning knob can't go that low.
We know that the phase noise is very high and the output signal is not even close to a sine wave. So this is OK for alignment but i would not use that for an actual measurement without detailed noise characterization.

2. we get one of the Marconi's from the 40m and use our 2W RF amplifier which we already used Friday. The phase noise is is very very low and we don't need a lot of tuning range, so it's even better.
This guarantees that we don't sit on the phase noise of the VCO even if we only have a low UGF for the second loop.
689   Tue Sep 20 16:28:32 2011 ranaHowToEnvironmentOptical Seismometer web page

http://gravity.ucsd.edu/research/optical_seismometer.php

699   Fri Oct 7 14:07:26 2011 FrankHowToVacuumsmall baking chamber

i've build a small baking chamber which we can use for small parts like posts, sensor and heater assemblies, wires, screws etc. It's a short (10" long) 6" CF reducer Tee with two heaters and a k-type thermocouple on it. We still don't have a RGA, but if we clean all parts carefully (made of materials we know that they are not a problem in general) and vacuum bake them for a few days we reduce the risk of contaminating our cavities by a lot. Current wait time for parts submitted for baking is ~2month. Would be great to find a slightly larger chamber to fit the larger parts in there as well (i don't want to use the (now) spare refcav chamber).

766   Fri Dec 23 01:11:11 2011 Koji, FrankHowToSeismicKistler Accelerometer preamp Type 5124A1 - gain settings

we were wondering what the gain in the accelerometer readout box is (Type 5124A1). According to the manual the gain can be changed between 0.1 and 100 (manual) but the device is not labeled. So we opened it to check the inside. The gain can be set using DIP switches. Each switch has 4 individual switches, 2 per amplifier stage. There is no label indicating which setting corresponds to which gain. We tried all four combinations while watching an excitation with fixed level and frequency on the FFT analyzer. Turns out that all channels in our preamp are configured to a gain of 1 at the moment. There is also no improvement in SNR when using a higher gain setting.

So the output using our small accelerometers is

~1V/g.

871   Wed Mar 7 00:43:05 2012 FrankHowToNoiseBudgetphase noise and other things

VERY IMPORTANT ! (HAS TO BE MEASURED NEXT BEFORE ANYTHING ELSE):

• phase noise of Marconi locked to Rb-clock for input ranges 100Hz to 10kHz - current level in NB is too high below 1kHz
• projection of RF-AM contribution from both EOMs - we know that we are close to that if we are slightly misaligned
• proper RIN coupling - we know that it does not dominate at the moment as we can change optical power levels without seeing an effect, but we don't know when it does
• Acoustic coupling estimation - do we need acoustic shields for cavity readout or beat?

seismic is not important at the moment as it will change end of the week anyway

876   Thu Mar 8 14:56:21 2012 taraHowToNoiseBudgetNote on Noise Hunting

Seem that people have been asking what have we done to reduce the noise in the beat measurement, so I think it is a good idea to summarize it down here as a future reference.

I'm listing the topics for now, the corresponding details will be added in the future.

•      RFPD for PDH : we had problem with the PDH loop(psl:706). This might be the combination of bad RFPD, small modulation depth, problem with TTFSS.
•      Modified RFPD (PSL:792, PSL:795), with that the inloop noise is below coating noise level and the loop is not gain limited. (PSL:806)
•      14.75 MHz resonance EOM: We added a resonance EOM for adding the sideband frequency. The broadband EOM that we used before could not give us enough modulation depth (PSL:745).  Plus, we got rid of the RF summing box which might contribute to weird behaviors of the loop (PSL:711,720). Now the broadband one is only for feedback control.
•      Lower side band frequency: We lowered the sideband frequency from 35.5MHz to 14.75 MHz, because have better Q at lower frequency.
•      TTFSS position on the table (PSL:778) : Beofre: lower UGF(33kHz, psl:654)
•      Polarization of the beam (and RFAM effect)
•      Scattering light: (dump beam properly, use super polished mirrors, psl:647)
•      Seismic and Mechanical peaks (seismic, PSL:690), seismic stack(psl:668,837), softer spring(PSL:762,814), float table(psl:696), mechanical peaks (PSL:818,820,827)
•      Put two cavities in the same vacuum chamber: this reduce the thermal drift b/w the two cavities, and allow us to use lower tuning range on PLL, (psl:667), better thermal sheild (PSL:776)
•      Reduce RFAM: Thermal control EOM(PSL:744), setup(PSL:854)

plan:

bring up coating noise level, (psl:657), using shorter cavity, smaller spotsize.

note:

some useful numbers: psl:733

881   Mon Mar 12 15:28:37 2012 taraHowToNoiseBudgetNoise estimation for delay line technique

I finished the calculation for delay line. The detail is in psl:868. Plus, I edit my plot so that it looks nice ( see PSL:878).

899   Fri Apr 6 00:34:28 2012 ranaHowToNoiseBudgetscattered light hunting

How to find parasitic scatterers by the GEO600 gang.

1072   Fri Nov 9 18:56:49 2012 taraHowToRefCavHowto optically contact mirrors

I have been practicing to optically contact two flat mirrors together. I think now I get it.

Since I need to build my refcav by optically contacting mirrors to a spacer. I tried the procedure by contacting two flat blank mirrors together. I bought blank fused silica mirrors from Thorlabs, pf10-03. Here are the instructions:

2. Wear lab gown, mask, gloves to prevent dust from your clothes
3. Use a can duster to blow away any obvious dust/dirt from the mirrors. Clean the whole mirror if possible. Any dust on the mirror back or side might fall on the surface anytime.
4. Wipe the mirror with acetone (I wiped the back and the edge first, before wiping the front face). Then switch to isopropanol. I tried drag wipe first, but it did not remove one of a particle right in front of the surface, so I had to wipe it with more pressure.
5. Contact to surfaces together. I put one on top of another. You will see a fringe pattern changes as the surfaces become close together under gravity. Press it to make it contact properly. ( I pressed with my finger for ~ a minute with ~10-20 Newton). If the surfaces are clean, there should be no fringe pattern (see fig2).  There should be no change when you remove the applied pressure.

fig1: On the right, fringe patter can be seen when two surfaces are put close together. On the left, after applying pressure the fringe should go away. The fringe pattern(purple-yellowing) on the left side indicates that these surface are not properly contacted.

fig2:  These mirrors are optically contacted somehow, except the center. I don't know what happen here that cause white area in the center. I might be that the mirrors are not flat enough. But the rim seems to have a nice optical contact. I tried to remove the mirrors by hands but they are well stuck. I'll ask peter for more about what causes the white area here.

As I tried to do this, I got an idea of a fixture for optical contacting the spacer to mirrors. It will be a cap with a center hole for the mirror position. Here is a solidwork drawing. The part can be aluminum. I have to think about the tolerance of the piece, but from the calculation it can be an order of a  cm (to keep the beam to go through the window). So the hole can be ~ .01 inch larger than the spacer and the mirror.

1085   Wed Nov 28 20:37:57 2012 taraHowToRefCavassembling short ref cav

[Peter, Tara], we assembled 2 short reference cavities today. The bonding between the spacers and mirrors are strong and holding the mirrors nicely.

I got the cavity fixtures (made from delrin) from the machine shop today, so I asked Peter to help me assembling the cavities. All picture can be found here

• The mirrors are 1/4 stack SiO2, Ta2O5 T=300ppm, ROC =0.5m.
• Two spacers' serial numbers are 98 and 99.

I tested the bond by lifting the whole cavity by handling at the mirror on top only, and wiggling it a little bit. The bonds weren't broken. The hardest part was cleaning all surfaces to make sure that there was no dust.

From hindsight, I don't really need to see the fringes to do the bond. If the surface is clean, the pieces will be bonded instantly after a light pressure. If there are particles on the surface that cause fringes, the bond will not form anyway. So for Si cavity, Dmass can try to do optical contact without a setup to see the fringes.

fig1: the mirror is placed in position by the fixture. The mirror is not pressed on the spacer yet. Fringes can be seen on the polished ring on the mirror. See the video to see how the fringes vanish after applied pressure.

1143   Sat Apr 6 09:32:35 2013 ranaHowToTempCtrlestimated beat frequency

I would have guessed that you heat both cavities. Unless they are both at an elevated temperature, how can you control their individual temperatures?

The cooling rate (and thus the bandwidth for control) is determined by the steady state temperature. I would guess that each cavity needs to be at least 35 C in order to have some headroom.

1144   Mon Apr 8 15:15:06 2013 ranaHowToTempCtrlestimated beat frequency

Isn't heating up one cavity enough? The goal is to keep the beat frequency constant, so we need to control the differential length between the two cavities. The first cavity can sit still, the second one can be heated up (for enough cooling rate). We plan to use a frequency counter to change beat frequency to the servo's error signal for feedback to the second cavity.

Anyway, I still have to check if both heaters are working or not.

 Quote: I would have guessed that you heat both cavities. Unless they are both at an elevated temperature, how can you control their individual temperatures? The cooling rate (and thus the bandwidth for control) is determined by the steady state temperature. I would guess that each cavity needs to be at least 35 C in order to have some headroom.

1147   Sun Apr 14 16:51:21 2013 ranaHowToTempCtrlestimated beat frequency

No, both have to be stabilized to reduce the control signals sent to the lasers.

1484   Mon Aug 25 03:56:17 2014 taraHowToNoiseBudgetoptimization for ETM with a-Si/SiO2 coatings

I used optimization codes for ETM. The optimization reduce the PSD of Brownian noise by ~ 3/4 (in units of [m^2/Hz]) from QWL structure.

Since we have not had all the material parameters for aSi:H at 120K with 1550nm, the optimization here is for room temperature with 1550 nm (for Brownian noise only).

fig1: optical thickness for ETM with minimized BR noise. The transmission is 5.4 ppm and the reflected phase is ~ 179 degree.

Parameters/configuration used in the optimization:

• T = 300 K   (room temp)
• wavelength = 1550 nm;
• Si substrate, n = 3.5;
• Low index material : fused silica, loss = 0.4e-4, n = 1.444;
• High index material: aSi:H, loss = 1e-6, n = 3.48;
• The coating has SiO2 cap (air-coating surface) for protection
• Spot radius = 6 cm.
•  This optimization is only for Brownian noise, we can do another optimization once the thermo-optical properties are known (thermal expansion, dn/dT)

It is remarkable that 5ppm transmission can be achieved with just 17 layers of coatings due to the largely different values between nL and nH. This makes the total thickness down to ~ 3 um.

BR noise from the optimized coating is  3.3x 10^-42 [m^2/Hz] at 100 Hz. This is converted to the strain of ~ 5x10^-25 [1/sqrt Hz] for 4 km interferometer.

Note: for QWL structure, with 14 layers + half wave cap of SiO2 (total of 15 layers), the transmission is ~5.2 ppm and the coating Brownian noise is 4.2x10^-42 [m^2 /Hz]. So the optimization reduced the PSD of BR noise by ~ 25%.

1602   Sun Nov 1 20:50:36 2015 ranaHowToDocumentationelog etiquette

Mama mia!

Per favore, utilizzare solo PDF.

1603   Wed Nov 4 10:54:30 2015 AntonioHowToDocumentationelog etiquette

Scusami :-(. D'ora in poi usero' solo PDF :-)!!!

 Quote: Mama mia! Per favore, utilizzare solo PDF.

1631   Wed Apr 13 16:45:18 2016 taraHowToRefCavOptical Contact Tutorial

I showed Antonio how to do optical contact (refcav-mirror setup).  The videos and pictures are posted on Google photo

I used a blank plane mirror (from coastline optics, intended for AlGaAs coating) and bonded it on the spare 1.45" refcav. It took me 4-5 tries and I scratched one mirror (I put it back and marked the box) before I could get a reliable bond. In the videos, I added comments for each failure. Mostly I think the problem is only cleanliness of the tools and the solvent.

After that I removed the mirror from the refcav. First I tried to use a setup to push the mirror along the mirror surface. To my surprise, the mirror did not pop out, but just slid off of center and still stuck on the surface of the refcav.

So I used a razor blade to wedge in between the mirro and the refcav, add some isopropanol. With little effort, the mirror popped out nice and easy. The edge of the HR surface of the mirror is beveled, so it is easy to wedge in a razor blade without scratching the refcav or mirror's surfaces.

To sum up, before trying to do the optical bond we should

• Prepare enough gloves, lens cleaning paper
• Use spectochromatography grade isopropanol, or other solvents
• Clean the area carefully.
• Have a bright light source to inspect the surface and the bond.

To do the bond

• clean the surfaces, make sure there is no dust
• Put the two surfaces together, give them a little push.
• Observe the fringe to disappear as the two surfaces get together ( if your objects are transparent), So if you bond silicon cavity, you can't see it, but you should be able to tell if the bond is good or not by just try to pull them apart.
• NOTE: I have done only dry bonding. The two surfaces are dry when I put them together.

Trouble shooting: If you can't form the bond

• If you see the fringe, there are dust, debris on the surface, clean the surface again.
• If you don't see the fringe. The two surfaces seem to have a contact, but still pop out with little force. You might want to push the mirror and the spacer together and see if the "color" of the bonding area changes or not. To have a good bond the contact surface should be completely transparent, not cloudy. You can tell by adding more pressure and see the cloudy area becomes more transparent, then there is some thing on the surface. It is most likely that the solvent has gone bad, or there is contamination in the solvent you use to clean the surface.
• For a good bond, ususlly you cannot pull the mirror/rafcav off by your hands.
1804   Fri Jan 6 13:38:04 2017 ranaHowToFSSDebugging the FSS loops

Once you make sure that the error point spectra and control spectra are OK (by plotting the spectra and integrated RMS in the elog), you have to plot the Bode plot here of the OLG of the two paths for each of the two cavities.

1807   Tue Jan 10 12:04:30 2017 awadeHowToFSSDebugging the FSS loops

I've taken a transfer function to find the OLG of the south path as well as PSD of error signal and fast control monitor signals.

The north path TF is included below too. However it is trash. I am not sure how its even locked. Last night the oscillations in the north path were 0.5 Vpp @ 30 kHz for the error signal (pretty sure the monitor is G=1 coming out the interface board, based on the schematics).

It was reduced this morning to 0.3 Vpp, oscillating at about 10 kHz now (this has changed since last night).

For the south path I haven't done any math piecing together the fast and EOM path components from the common path and EOM path.

The EOM TF looks suspicious: we should expect it to start with low gain and take over at HF, but it looks like it has LF gain and a UGF that doesn't look right to me.

Unless otherwise stated I used 15 mV excitation and measured using the test points before and after in the common and EOM gain stages.

Because the HP AG4395A has 50 ohm loading, this slightly changes the effective gains when hooked up to the field box BNCs.

To keep it all consistent I terminated with 50 ohms between measurements.

PSD of error signal with RMS summed from HF to LF:

And the north path error monitor PSD:

Fast monitors for north and south:

South path common and EOM OLG TFs:

Attachment 1: RMSNorthErrorMon.pdf
Attachment 2: RMSNorthErrorMon.pdf
Attachment 3: RMSSouthErrorMon.pdf
Attachment 4: RMSSouthFastMon.pdf
Attachment 5: RMSNorthFastMon.pdf
Attachment 6: SouthComTFOLG.pdf
Attachment 7: SouthEOMTFOLG.pdf
1810   Wed Jan 11 09:01:37 2017 ranaHowToFSSDebugging the FSS loops

Gotta measure spectra and TFs out to 5 MHz. The EOM path sometimes has issues that far up.

1816   Fri Feb 3 11:48:54 2017 awadeHowToFSSDebugging the FSS loops

Here are error sig spectra and fast control monitor spectra for the north and south paths.

Not sure what the ~20 kHz spike in the south error signal is, or for that matter what the 40 - 100 kHz stuff is there. The fast actuation signal monitor spectra also looks like there is less noise north path, which isn't right: that said, the loop is oscilating +/- 14 V (the full range) so the SA may be saturated.  From the error signal spectra the osciations in the north path are dominate around 10 kHz.

For reference gains on the south path are 880 common, 600 fast, 504 offset.  North path knobs are set to 300 common, 300 fast and 508 offset.

Edit (Fri Feb 3 11:52:04 2017): Attached zip of data.

 Quote: Once you make sure that the error point spectra and control spectra are OK (by plotting the spectra and integrated RMS in the elog), you have to plot the Bode plot here of the OLG of the two paths for each of the two cavities.

Attachment 1: SPandRMSNorthandSouthErrSig.pdf
Attachment 2: SPandRMSNorthandSouthErrSig_copy.pdf
Attachment 3: data20170203_SpectraErrorandFastMonSignals.zip
1819   Sun Feb 26 20:42:07 2017 awadeHowToFSSDebugging the FSS loops

To test a theory that the North Path PD was the culprit introducing 10-20 kHz oscillations I switched in the south path PD in the place of the North PD.  I installed a phase delayer box to get the error signal with ideal demodulation phase quickly (rather than fiddling with cable lengths).

With the PD switch out the north path oscillations are gone. I tried to get a basic TF with the SR785, it didn't quite look like the right (with very low UGF @~2kHz) but I think this might be just an optimization playing around with some gain levels or not enough laser power.

Tomorrow I will make sure this is not just a result of a better optimized PDH error signal. Either way, this narrows the possibilities. For reference the schematics for the suspect RF photo detector are here: LIGO-D980454

Quote:

Here are error sig spectra and fast control monitor spectra for the north and south paths.

Not sure what the ~20 kHz spike in the south error signal is, or for that matter what the 40 - 100 kHz stuff is there. The fast actuation signal monitor spectra also looks like there is less noise north path, which isn't right: that said, the loop is oscilating +/- 14 V (the full range) so the SA may be saturated.  From the error signal spectra the osciations in the north path are dominate around 10 kHz.

For reference gains on the south path are 880 common, 600 fast, 504 offset.  North path knobs are set to 300 common, 300 fast and 508 offset.

Edit (Fri Feb 3 11:52:04 2017): Attached zip of data.

 Quote: Once you make sure that the error point spectra and control spectra are OK (by plotting the spectra and integrated RMS in the elog), you have to plot the Bode plot here of the OLG of the two paths for each of the two cavities.

1820   Mon Feb 27 20:03:16 2017 awadeHowToFSSDebugging the FSS loops

Attached is a PSD I took of the RF and DC outputs of the north path RF photo-detector with photo diode blocked and power on separate isolated power supply (from the rest of the experiment). The small peak at 9.4 kHz seemed more pronounced when I was looking close in (in the frequency domain) on the RF output, but then I had the resolution bandwidth turned right down ~10 Hz.  This data is a set of spans taken with the netgpibdata python scripts.  There is also noise roll up feature at 40 kHz.

Might need to measure this again or check if I had attenuator turned onto the default 20 dB (which the AG4395 often does).

---

Edit Tue Feb 28 13:59:59 2017 (awade): I made an error, incorrectly plugging PD into wrong input of analyzer.  One of these noise traces is correct, just not sure which one.  Will update the measurment soon.

Attachment 1: 20170227_SPNorthPDRF_D980454.zip
Attachment 2: D980454_NorthRFPD_PSDNoise_wrong.pdf
1821   Thu Mar 2 13:56:25 2017 awadeHowToFSSDebugging the FSS loops

I retook these measurements with the RF and DC SMAs connected to the right inputs of the Aglient 4395A.  This is the spectrum around DC (not at 14.75 MHz of the detector resonance where demodulation is performed.  Perhaps the peaks we see in this spectrum are coupling in from the power supply.  These are things we will need to check with the detector back in situ in the north path.

 Quote: Attached is a PSD I took of the RF and DC outputs of the north path RF photo-detector with photo diode blocked and power on separate isolated power supply (from the rest of the experiment). The small peak at 9.4 kHz seemed more pronounced when I was looking close in (in the frequency domain) on the RF output, but then I had the resolution bandwidth turned right down ~10 Hz.  This data is a set of spans taken with the netgpibdata python scripts.  There is also noise roll up feature at 40 kHz. Might need to measure this again or check if I had attenuator turned onto the default 20 dB (which the AG4395 often does).   --- Edit Tue Feb 28 13:59:59 2017 (awade): I made an error, incorrectly plugging PD into wrong input of analyzer.  One of these noise traces is correct, just not sure which one.  Will update the measurment soon.

Attachment 1: batchplot20170228_SpecNorthPD_DCandAC.pdf
Attachment 2: 20170228_SPNorthPDRF_D980454_RedoneWithCorrectPort.zip
1866   Thu Aug 17 16:43:35 2017 awadeHowToComputersGenerating public-private keypairs for ssh sessions

Criag didn't have this configured for gitlab/github or any other computers. Having a public/private ssh key-pair is usefull for accessing machines and services securly without needing a password, plaintext or otherwise.  Here is a recipe for generating a public-private keypair that can be used with gitlab, github etc.  The public key is pasted into the remote service (aka github) and forms the basis for a good secure communication and simplifies pulling and pushing.

# TL;DR

cd ~/.ssh/
ssh-keygen -t rsa -b 4096 -C “label”

Where label = is some label to help you remember what service/computer it corresponds to. I use the format "usr:service" or “email@address” to identify which git or computer I’m keypaired with.

When prompted give name “id_rsa_namehere" and password.  Then copy the public part of the key to your clipboard

pbcopy <~/.ssh/id_rsa_namehere.pub
(case using linux)
xclip ~/.ssh/id_rsa_namehere.pub

Pastes clipboard to remote service, i.e. github, gitlab, other computer etc. (You can find a place to paste ssh keys in the settings/security tab of these services)

Now Add private key (the non .pub file) to local Mac keychain

Finally test to see if it works with an ssh test

ssh -T git@github.com (or other user@website relevant combination)

## Detailed instructions/explanation:

Generating a key pair:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com”

-C flag stands for comment, can be used to label what the ssh key is used for. Best to use an email or somthing you will remember.

If you hit enter you get a default name. But is best to give a unique name. Once you have a few different keys it can be  hard to tell what is what. Choose something like ‘id_rsa_github' if it is used for github etc.  File will be saved to .ssh/id_rsa* which is where you want it. [Here an below * indicates wildcard if you have changed the name]

It will also ask for a password, this is a good idea.

You need to add the key to the active ssh-agent service (change id_rsa if you named it something different). To add to your mac’s keychain (so that it can be loaded automatically on terminal session start) do the following:

where id_rsa*  is the name you gave your key file (note: this is the private part of the key-pair, do not store this in any public location. If you find it any publicly location, purge it and start again)

Add the following to your .bash_profile or .bashrc config files located at ~

cd ~

Now when you start terminal it will load all the key’s you’ve added.  If keychain is not open it will prompt for your keychain passwords.

# IMPORTANT:

There will be two files generated from ssh-keygen, your private key id_rsa* and your public key id_rsa*.pub.  Make sure you only give the public key to the remote machine/service. If you accidentally reveal through ANY plaintext communication then burn it and run ssh-keygen to make a new one.

### Setting up remote git/computer:

Copy the public key to clipboard:

pbcopy < ~/.ssh/id_rsa*.pub

and paste to remote computer/website.

Then test it using something like

ssh -T git@github.com

# Note: purge clipboard if it stores a history.

You now have a public/private key pair for secure communications.  Use it for github or ssh into machines that you use very frequently.  It is as secure as your local machine.

### Some other things

To see what saved keys you have try

ssh-add -l

To delete all cached keys

ssh-add -D

1875   Wed Aug 23 13:39:02 2017 Craig, awadeHowToComputersHow To Plot remote spectra and TF files in the ctn_labdata Git repo quickly

To measure off of the Agilent or SR785: use Eric Q's netgpibdata scripts to get the measurements.  Just update the .yml files and then run ./AGmeasure measure.yml or ./SRmeasure measure.yml.

To measure off of the Tektronix scope: You can only get one channel dumped at a time from Tobin's script in the 40m SVN.  Check out the /tektronix/ folder from the 40m SVN and run ./tek-dump 10.0.1.71 ch1 foo.csv

Now you have to plot the measurements you've taken.  I've prepared two scripts in the ctn_labdata/scripts Git repo.  One is twoColumnDataPlotter.py and the other is TFplotter.py.  Both have very good help messages, but I will give an example here.

Let's say that you just took a Noise spectrum with the Agilent using Q's netgpibdata script ./AGmeasure SPAG4395Atemplate.yml.  Then you will write your data to the /ctn_labdata/data/ Git repo like a good scientist in our lab.  You will also put your measurement in it's own folder, with a descriptive folder name like /ctn_labdata/data/YYYYMMDD_TransBeatnoteSpectrum/.

twoColumnDataPlotter.py and TFplotter.py are prepared to work with data like this.  In this case, since you have taken a spectrum, you have two columns of data in the resulting .txt file, frequency and the ASD.  So you will use go to ctn_labdata/scripts/twoColumnDataPlotter.py and use the script like so:

python twoColumnDataPlotter.py ../data/YYYYMMDD_TransBeatnoteSpectrum/ --xlabel "Frequency [Hz]" --ylabel "ASD [Vrms/$\sqrt{Hz}$" --title "Trans Beatnote ASD"

This will automatically create a folder called ctn_labdata/plots/YYYYMMDD_TransBeatnoteSpectrum/, and put the resulting plot in there with the title, x and y labels you specified.  The plot will be saved in a PDF format with a name of YYYYMMDD_HHMMSS_DataFileNameMinusTheDotTxt.pdf.  The ctn_labdata/plots/ directory will always have the same name as the ctn_labdata/data/ folder you made, and the actual plot PDF will always include the time and data you made the plot at the beginning, as well as the data file name minus the .txt at the end.

If you have a TF measurement from the Agilent, use TFplotter.py in the exact same way as above, just replace python twoColumnDataPlotter.py with TFplotter.py.   You may also specify the second y axis using a --y2label "Phase [degs]" flag.

Please use this method to plot spectra and TFs in the Git repo!  This will avoid confusion and make things consistent and easy to find in the Git repo.

1881   Sun Aug 27 16:07:03 2017 Craig, awadeHowToNoiseBudgetHow to get the noisebudget jupyter notebook working

First clone the git repo. The latest noiseBudget.ipynb and noiseBudgetQWL.ipynb should work if you run pip install requirements.txt in a clean python virtual env.

If you run it in another virtual environment, make sure that you have the 2.4.8.1 version of the uncertainties python package, otherwise the noise budget code will never finish.

1886   Tue Aug 29 22:44:11 2017 CraigHowToComputersGenerating public-private keypairs for ssh sessions

This was great... thanks a lot "Andrew".

These directions work ONLY if you register your ssh key with your github.com account and not your git.ligo.org account.  You'll have to generate TWO ssh keys on a single compypyie, and put one key on your github.com account and another on your git.ligo.org account.

I have done this for my git accounts on acromag1 and 2, so now we can git clone via ssh from both git.ligo.org and github.com.  V convenient.

1979   Mon Nov 13 15:45:19 2017 Craig, awadeHowToNoiseBudgetNov 12 Noisebudget revised

REVISED BOKEH NOV 12 2017 NOISEBUDGET.

I realized that the Nov 12 Spectrum 4 Hz frequency comb an strong spikes at 256 and 512 Hz are not true noise artifacts, but merely poor measurement post processing.

In particular, when spectra are stitched together, there is sometimes some overlap in the frequency domain.  When this happens, the data taken at lower resolution is supposed to be thrown out.  I neglected to do this, but now have fixed the code in iris to do this.  awade calls this the Hierarchical Chucker.

When I measured a spectrum with high span up to 102.4 kHz, the first point is at 0 Hz, and the second is at 256 Hz, and so on.  These points are inflated with all low frequency noise, and should be thrown away if we have spectra taken at higher resolution.  When one includes these points, we get the blue 'Nov 12 2017 Beat' line below.  When the points are properly hierarchically chucked, you get the gold 'Nov 13 2017 Beat' line.  These are the same measurement, just with some different post processing, so they ought to lie right on top of one another, which they do except for the line artifacts.

I have also included a plot of all the spectra so people can see why a comb can appear where it shouldn't if you don't throw out the low frequency data of your low resolution measurements.  The '4 Hz comb' was actually just the spectra plotting script switching between the light orange and dark orange spectra in Plot 2.  The light orange spectrum is taken at 1 Hz resolution, while the dark orange is taken at 4 Hz. The light orange, at higher resolution, should be the only spectrum reported at low frequency.  But if you leave in the low frequency dark orange points, the higher noise floor emerges as a 4 Hz frequency comb.  This is why hierarchical chucking is a very important process.

 Quote: The lastest noisebudget is attached.  Here is the online Bokeh version. We are reaching the levels that Evan and Tara reached in a small frequency region around 1 kHz.  We are supposed to do about 10 times better than them to reach the coating brownian noise floor for the AlGaAs coatings. We took the PLL OLG via the SR785, as well as the transmission beatnote spectra.  I divided every spectrum by two because of the impedence matching effect. The PLL was locked at 1 kHz/Vrms frequency modulation, and SR560 preamp gain of 2000.  This led to the PLL UGF of around 30 kHz.  With this high of a UGF we used the control signal to take the spectra, and set the Preamp Gain in calibratedBeatnoteSpectrum.py to one. Tomorrow awade and I will set up the intensity stabilization servo to try and get even lower noise on transmission.  The error signal from the North cavity is breathing in an unusual way, and we hope to get rid of this excess noise.

Attachment 1: 20171113_151130noiseBudget.pdf
Attachment 2: PLLControlSignalSpectrum_Avg_30_FMDevn_1kHz_PreampGain_2000_Span_102p4kHz_12-11-2017_211211_Spectrum.pdf
1992   Wed Nov 29 19:19:46 2017 BonoHowToFSSStuck in a FSS and You Can't Out of It?

Oi mate, seems like you've gone and got stuck in the FSS. Get out and start buzzing those mounts!

1995   Thu Nov 30 20:51:18 2017 BonoHowToFSSStuck in a FSS and You Can't Out of It?

Hey Bono do you like awade's song

 Quote: Oi mate, seems like you've gone and got stuck in the FSS. Get out and start buzzing those mounts!

2014   Mon Dec 18 13:42:21 2017 awadeHowToComputersHow to: update and restart the fb4 framebuilder

fb4 is now logging channels in the c3 (PSL) lab.  To update channels you need to:

1. ssh into 10.0.1.156 with username controls (ssh -Y controls@10.0.1.156);
2. cd to dir /opt/rtcds/caltech/c4/chans/daq/ and edit entries in C3CTN.ini, the setout and units are obvious from the file;
3. find the daqd process with "$ps -e | grep daqd" and then kill it with "$kill -9 <PID from previous command>";
4. Check with dataviewer, this can be launched by setting environment variable with "$LIGONDSIP=localhost" and then running "$dataviewer" on the fb4 machine.  You will need to have window forwarding on.

I have updated the environment temperature sensors and they should be logging properly now.  Unfortunately some channel name changes meant they were not logged over the weekend.

2040   Thu Jan 11 11:35:36 2018 CraigHowToComputersGetting data from our frame builder from anywhere

Steps to getting data from our framebuilder, since many of the steps are pretty hard to remember.  These steps were performed on a Macbook running OSX Sierra 10.12.5.  Dataviewer was opened locally using XQuartz.

1) SSH into PSL Lab computer ws3 through the public port 2022:

$ssh -Y controls@131.215.115.216 -p 2022 (I often alias this on my PC .bashrc as some command:$ alias ws3="ssh -Y controls@131.215.115.216 -p 2022")

2) SSH into framebuilder4 fb4:

$fb4 ("fb4" is already aliased on ws3 to be the command$ ssh -Y controls@10.0.1.156)

3) Launch dataviewer:

$dvlaunch ("dvlaunch" is an alias to$ LIGONDSIP=localhost dataviewer.  This tells dataviewer to look locally for frames.)

4) Dataviewer will launch.  Click the "Signal" tab.  Click the "Slow" button.  Channel options "C3" and "C4" should appear.  The PSL Lab is "C3".  Choose what channels you want to plot.

5) Click the "Playback" tab.  Click "Second Trend" because other modes don't work.  Unclick "Min" and "Max".  Select X Axis Time as "GPS".  Choose your start and stop times you want plotted. Finally select your signals.  Click "Start".

Wait a while.  The terminal you ran dvlaunch from should give a progress report.  After all data is retreived a plots page should automatically appear with the channels and plot start/stop times you requested.

If you want to save the data from your plot:

6) Click on the plot you want to save data from.  It will have little black boxes in the corners of the plot when selected.

7) Click the "Data -> Export -> ASCII" tab.  A window called "Grace: Write sets" should open.

8) Click on the option under "Write set(s)", and change the Format from "%.8g" to "%.10g" to get all the digits of the GPS time.  Change Selection to whatever you want to name your datafile.  Click "OK".

Your data should be saved.  Make sure it is formatted well.

2068   Fri Feb 2 22:53:24 2018 awadeHowToOtherHow to flip binary channels in EPICS/IOC

In some cases hardware logic is inverted relative to its function.  That is, a high state (voltage) disengages an amplifier (as in the case of the AD602) and a low state engages.  I've found that this is an issue when drop the PMC controls into an auto locker script where some of the logic of the PMC servo card is inverted.  It also flips the medm screen buttons around the wrong way.

A quick software fix in the EPICS IOC db entry is to use the following:

record(bi, "C3:PSL-NCAV_PMC_BLANKING_IN") {   field(SCAN, ".1 second")   field(DESC, "TEST")   field(VAL,0) }

record(calcout, "C3:PSL-NCAV_BLANKING_TEMP") {   field(SCAN, ".1 second")   field(OUT, "C3:PSL-NCAV_PMC_BLANKING")   field(CALC,"!A")   field(INPA,"C3:PSL-NCAV_PMC_BLANKING_IN") }

record(bo, "C3:PSL-NCAV_PMC_BLANKING") {   field(DTYP,"asynUInt32Digital")   field(OUT,"@asynMask(BIO_Reg_PMCN, 2, 0x1)")   field(ZNAM,"OFF")   field(ONAM,"ON")   field(SCAN, ".1 second") }

2112   Wed Feb 28 18:58:01 2018 CraigHowToComputersGetting CTN lab data from framebuilder using python nds2

Jaime and John R have done some work enabling NDS on our framebuilder in the subbasement, fb4.  I have figured out how to get data from fb4 to our CTN lab computer ws3, using python nds2.

1) Log into ws3 from your local machine: $ssh -Y controls@131.215.115.216 -p 2022 2) Run ipython on ws3:$ ipython

3) Enter the following code into the ipython session:

In [1]: import nds2
In [2]: c = nds2.connection('10.0.1.156', 8088)  # 10.0.1.156 is the fb4 local ip address.  8088 is the fb4 NDS broadcast port number.
In [3]: gpstime = 1201902464  # using old data from Feb 5th, because our lab has been out of commission for a couple of days.
In [4]: chanName = 'C3:PSL-SCAV_FSS_SLOWOUT'  # retrieve the SCAV slow laser control
In [5]: from pylab import *
In [6]: ion()
In [7]: data = c.fetch(gpstime, gpstime+50000, [chanName])
In [8]: plot(data[0].data)

A plot should appear on your computer.  It should be the same as the plot posted below.  It should take about 10 seconds to appear.

 Quote: Steps to getting data from our framebuilder, since many of the steps are pretty hard to remember.  These steps were performed on a Macbook running OSX Sierra 10.12.5.  Dataviewer was opened locally using XQuartz. 1) SSH into PSL Lab computer ws3 through the public port 2022: $ssh -Y controls@131.215.115.216 -p 2022 (I often alias this on my PC .bashrc as some command:$ alias ws3="ssh -Y controls@131.215.115.216 -p 2022") 2) SSH into framebuilder4 fb4: $fb4 ("fb4" is already aliased on ws3 to be the command$ ssh -Y controls@10.0.1.156) 3) Launch dataviewer: $dvlaunch ("dvlaunch" is an alias to$ LIGONDSIP=localhost dataviewer.  This tells dataviewer to look locally for frames.) 4) Dataviewer will launch.  Click the "Signal" tab.  Click the "Slow" button.  Channel options "C3" and "C4" should appear.  The PSL Lab is "C3".  Choose what channels you want to plot. 5) Click the "Playback" tab.  Click "Second Trend" because other modes don't work.  Unclick "Min" and "Max".  Select X Axis Time as "GPS".  Choose your start and stop times you want plotted. Finally select your signals.  Click "Start". Wait a while.  The terminal you ran dvlaunch from should give a progress report.  After all data is retreived a plots page should automatically appear with the channels and plot start/stop times you requested. If you want to save the data from your plot: 6) Click on the plot you want to save data from.  It will have little black boxes in the corners of the plot when selected. 7) Click the "Data -> Export -> ASCII" tab.  A window called "Grace: Write sets" should open. 8) Click on the option under "Write set(s)", and change the Format from "%.8g" to "%.10g" to get all the digits of the GPS time.  Change Selection to whatever you want to name your datafile.  Click "OK".  Your data should be saved.  Make sure it is formatted well.

Attachment 1: SCAV_SLOWOUT_examplePlot.png
2208   Fri Jun 22 00:35:31 2018 awadeHowToComputersRunning parallel tasks on Caltech LIGO cluster

Shruti and I are running various training routines for the machine learning and non-linear controls.  It can be hard to guess the best learning rates, random action injection rates and other hyperparameters of the NN and tensorflow optimizations.  Although the best approach is to work intuitively on simple examples and then scale up, the optimization and rates of learning can be a little opaque.  At some stage we will want to throw a bunch of computing power at systematically narrowing down what works and what doesn't.

We basically want to spin up a bunch of training trials to test a range of hyperparameters without having to wait a full day for turn around for each iteration through a list of values. Running tensorflow based training on GPU might offer speedup on each step but won't necessarily help if it isn't a well parallelized problem. Its not clear to me that, for instance, the baselines deepq minibatching will work faster if we simultaneously draw samples from the buffer and do the gradient decent in parallel with between-graph replication.  At the end of each training episode the outcomes of each separate minibatch gradients have to be combined (that seems non-trivial) and then redistributed across the GPU (which sounds like it will have some hefty overhead as we scale up).  Managing this kind of parallelizing seems too far down the rabbit-hole of optimization science for our investigations.

I've been poking the people over at the jupyterhub LIGO chat channel about running parallelized clusters from notebooks.  LIGO is now running python notebooks on the LDG at http://jupyter.ligo.caltech.edu (and test server http://jupyter2.ligo.caltech.edu).  These can now launch a cluster of n nodes directly from the jupyter gui and we can use the ipyparallel python module to run parallel tasks directly from jupyter.  The only problem is that it ships with a generic virtualenv for the python3 kernel that doesn't include our gym or baselines environments from OpenAI.  We've also made modifications to these packages making them even more propritory.  Furthurmore, there is a problem with ipyparallel clusters, we've found that they won't launch worker engines unless the version of python is exactly the same. The juputer notebook kernals that we are using are python 3.5.4 and the workers are something like python 3.6

As a workaround we can launch our own ipcluster cluster on the ldas-pcdev14 headnode (or ldas-pcdev5) and connect easly directly from jupyter notebooks. ipyparallel manages all of the scheduling and we can launch over 20 learning runs simultaneously and/or schedule a longer list to run. This is relativlty easy to do and doesn't involve much hackery.

I've got this working from within a python notebook (attached) and have documented the steps needed to get it running.  The actual worker nodes work just a little slower (15% slower maybe) than our Macbook Pros.  The advanage is that we now have more scope to make a bunch of parrallel trials and to detach from those instances.

Edit (awade) Sun Jun 24 00:24:20 2018: fixed issue where tensorflow graph is kept somehow as a global variable by baselines.

Attachment 1: MinWorkingExample_baselines_with_ipyparallel.ipynb.zip
2300   Wed Jan 30 15:07:32 2019 awade, anchalHowToFSSShot noise in FSS loops?

The FSS at some point is going to be limited by shot noise. I understand that the apparent frequency noise should go as [1]:

$\dpi{100} S^\textrm{SH}_f = \frac{1}{8 L \mathcal F}\sqrt{\frac{hc^3}{P_0\lambda}}\quad [\textrm{Hz}/\textrm{rtHz}]$

where h is plank's constant (6.626e-34), c is the speed of light (3e8), L is cavity length (36.83 mm), F is finesse (~15000), lambda is wavelength (1064 nm) and P0 is incident power (order 1 mW right now).  The inherent frequency equivalent shot noise would then be $\inline \dpi{100} \small \delta f_\textrm{SN}=\sqrt{S_f^\textrm{SN}}$, which for our cavities would be 30 mHz/rtHz for each path for 1 mW of incident powerWhere does this leave the frequency noise of the transmitted light?  Within the cavity line width does it not just pass all the frequency/phase noise?

Obviously our SN value will be slightly worse than this because we don't have excellent mode matching.  But even in the ideal case do we have to use 100 mW of light to get to 10 mHz/rtHz where the brownian noise is at?

These may be stupid questions but I'm not sure how SN limited PDH frequency noise looks like on transmission from a reflection locked cavity.

So for 1 mW of power we should be getting 0.9 mHz/rtHz in the ideal case that MM to the cavity is perfect. So we are good on the ultimate SN limit of the FSS loops.

Edit awade Wed Jan 30 16:34:59 2019: Correction to original post the quoted spectum is and ASD not a PSD, I got the units wrong. Values are corrected above

### References

[1] Black, E. D. An introduction to Pound–Drever–Hall laser frequency stabilization. Am. J. Phys. 69, 79 (2001).

2301   Fri Feb 1 14:59:01 2019 awade, anchalHowToFSSNoise tallies

We've hit a flat (white) noise floor at around 70 mHz/rtHz.  Time to tally all the unaccounted for noises.

## Photo detector sensor contributions

Tally of photodetector sensor contribution to final white noise floor
Noise Output measured noise Input referred noise Freq. Equivalent Noise
BN detector (Koji 27 MHz, G=1.27 kΩ) Dark 9 nA/rtHz 12.0 pW/rtHz 48.0 nrad/rtHz * f or 48 µHz/rtHz @ 1 kHz
BN detector (Koji 27 MHz) Shot noise (est from DC power 0.5 mW) - 13.7 pW/rtHz 54.8 nrad/rtHz *f or 54.8 µHz/rtHz @1 kHz
FSS North PD (36 MHz, G=2.7 kΩ) Dark (measured) 14.7 nV/rtHz out of mixer, 26.7 nV/rtHz at detector 13.2 pW/rtHz 3 mHz/rtHz
FSS North PD (36 MHz, G=2.7 kΩ) Shot (est from DC power 1.2 mW, gamma=0.3, vis=0.5) - 15.6 pW/rtHz 2.9 mHz/rtHz
FSS South PD (36 MHz, G=1.5 kΩ) Dark (measured) 16.1nV/rtHz out of mixer, 26.0 nV/rtHz at detector 14.5 pW/rtHz 5.9 mHz/rtHz
FSS North PD (36 MHz, G=1.5 kΩ) Shot (est from DC power 1.2 mW, gamma=0.3, vis=0.5) - 15.6 pW/rtHz 2.9 mHz/rtHz
Total - - 7.8mHz/rtHz

Here the FSS resonant detector dark noises were measured using a Lv13 ZX05-1MHW+ mixer with a 4th order LP + 50 Ω terminator on a SR785.

Frequency equivalent noise is just input referred noise divided by the PDH discriminator value. The PDH discriminator value is computer assuming gamma=0.3 rad modulation depth, visibility of 0.5, Finesse of 15000, cavity length 3.8 cm.  This gives 4.4 nV/Hz for the slope of the error signal about resonance.

BN detector input referred noise is just input referred power divided by 1/2 Vpp of the beat note.  For 0 dBm beat note, then input equivalent power is (dividing through 1.27 kΩ TI gain) works out to 0.25 mW/rad.

So the upshot  is that there is too much FSS RFPD noise to see Brownian noise clearly but is not our current dominant noise source. We are missing about 69.6 mHz/rtHz.

## Also noise contributions​ at the summing stage in FSS

I'm including this because it was a question we thought about and dismissed.  There is a 100kΩ - 1 µF - 100 kΩ  LP filter from the FSS offset channel into U3 on the servo board (R8-C5-R9, in D040105-C). There is an estimated 0.4 pA/rtHz of thermal current noise there. Also the AD829 has a current noise of 1.5 pA/rtHz  (op amp U3).  These are additive and indistinguishable from sensor noise.  The mixer output equivalent voltage noise is just the equivalent voltage across R3 and R9 in the FSS RF board (LIGO-D0901894): i.e. 0.4 pA/rtHzx146 Ω = 58.4 pV/rtHz at mixer output.  Dividing back through the mixer conversion, transformer coupler and PD gains (see PSL: 2242 for values and links) we come to some input referred noises in units of optical power tabulated below.

 Noise Output measured noise Input referred noise Freq. Equivalent Noise Offset LP filter Johnson noise R8-C5-R9, D040105-C) 0.4 pA/rtHz 0.05 pA/rtHz 12 µH/rtHz U3 current noise (D040105-C) 1.5 pA/rtHz 0.2 pA/rtHz 45 µH/rtHz

So electronic noise, at least from the point of summing the error signal with offsets is negligible.  We might want to revisit this later, but most points of noise injection into the FSS loop will be suppressed by the closed loop function and will be small.

## Laser frequency noise

The current state of the FSS loops is ~180 kHz UGF for north and ~70 kHz UGF for south (woeful).  South is worst because the RF PD has only half the TI gain and we are at maximum gain for the FSS variable gain stages.  The whole point of these loops is to suppress laser frequency noise.  Their current performance is just not good enough.

If we assume that the laser noise is modeled as

$\dpi{100} S_f^\textrm{Laser} =\frac{1\textrm{Hz}}{f}\times10^4 \quad\textrm{[Hz}/\sqrt{\textrm{Hz}}\textrm]$

and that we need a clearance of 10 dB at the 100 Hz point where we expect to see Brownian noise (10 mHz/rtHz @ 100 Hz), then we need to get to 1 mHz/rtHz or a a factor of 1e5 1/(1+G) suppression. This means that its very likely that our current limitation is actually FSS loop bandwidth.

### Here is what we need to do.

Naively if we assume 1/f loop shape, that means that we would need a UGF of 10 MHz to reach 1e5 gain by 100 Hz.  Nope.  Of course we have some loop shaping in the lower frequency reaches of the PZT path of the FSS.  There is a boost pole-zero pair installed in the common path (PZT servo path U7) that uses R29 of 5.6 kΩ and capacitors of either 4.7 µF or 6.8 µF depending on the box.  This would put the corners between 6.0Hz and 4.1 Hz, too low (don't know why so low). If we move the boost up to 1 kHz or higher then we would be able to reach 1 mHz/rtHz by 100Hz with a overall path open loop gain crossing 0dB at 1 MHz.

Right now we cannot turn up the gain of the loops much more than 200 kHz.  We can see from looking at the EOM control signals that above a certain amount of OLG the EOM is taking too much of the actuation load and rails.  Basically the the cut off frequency for the EOM servo is not aggressive enough and the EOM is working too hard in the frequency band below 10 kHz where the laser PZT should be doing the heavy lifting.  I outlined some of the changes that need to be done in PSL:1902.  This is based on Matt Evan's modifications of the MIT Squeezer FSS system.

MIT's FSS boxes are a few versions on from our FSS boxes but the main points remain:

• R19 24.9k to 2k (lower first zero from 1.94 kHz to 24.1 kHz)
• C23 1uF to 33nF (more AC coupling, move first zero from 145 Hz to 4.38 kHz)
• C24 1uF to 100nF (more AC coupling, move second pole from 122 Hz to 1.22 kHz)

In addition to this we want to modify the boost stage by removing the ~5 µF chunkers and trying something more like 28 nF or more.  I think what we need here is a metal film cap (no ceramic) and the question is whether setting the corner so high will be an issue with it railing between locks if there is some kind of offsetting there.  Maybe this isn't an issue.

These are relatively​ strait forward changes providing we have the appropriate capacitors in stock. It seems like boosting FSS UGF by offloading EOM path LF onto the PZT and making the boost good is the most obvious way to squash this noise and make fast progress.  Lets try and hit the 1 mHz/rtHz target with a 1 MHz FSS UGF effort.

Efforts on characterizing thermal sensors need to wrapped up but we want to get to our actual noise source.  The more recent PID improvements on the cavity temperature control (PSL:2295) have gotten us to a point where we have usable 1kHz/V VCO measurements which is as good as we need for now. Maybe a shift in effort from thermal control to laser stabilization is the best use  of our time.

I've attached a block diagram of the FSS controls below.  It shows at a glance the current configuration of the EOM, PZT and slow laser controls.

Edit awade Sat Feb 2 00:44:47 2019: Revised down FSS shot noise estimates based on correct sidebands, visibility and modulation depth values (from Tara's thesis).

Attachment 1: CTN_FSS_south_blockdiagram.pdf
2302   Fri Feb 1 20:20:11 2019 awadeHowToFSSModifying North FSS EOM path

I'm implementing the suggested cap and resistor updates in the last post (PSL:2301).

## Changes to FSS board (North 36 MHz field box)

I couldn't find any 100 nF or 33 nF caps in polycarbonate in WB EEshop.  These haven't been manufactured since 2000 and I couldn't find stock at the 40 m either.  Instead I used polypropylene as they have comparable specs (as far as I can tell) and should be good up to ~1 MHz (I think).  If not, its easy enough to fix.

Replacements on D040105-C FSS servo board:

• C24 was changed from 1 µF polycarbonate cap to a 100 nF polypropylene cap (Digikey 1928-1302-ND an FKP3 series).  This was an exact fit to the PCB board pins.
• C23 was changed from 1 µF polycarbonate cap to 0.033 µF polypropylene cap (Digikey 1928-1231-ND and FKP2 series).  This wasn't the same size.  I made some slight pin extentions with some resistor lead cutoffs.
• R19 was changed from 24.9 kΩ to 2 kΩ.  I used a 0805 thin film here.
• C36 was changed from 3.3 nF to 560 pF to push the pole of U8 from 9.9 kHz out to 58.3 kHz.  I did this after I realized that there was not enough phase margin in the fast (PZT) path at the crossover frequency, it just wasn't stable for fast path gains high enough for a smooth handoff to the EOM.

I also checked the boost that hacked onto U7 of the FSS servo board.  This is a capacitor in series with R29 (5.6 kΩ).  I checked the actual value it is 6.8 nF in the North FSS box.  This combination (5.6 kΩ + 6.8 nF) in the feed back path of U7 gives a pole at 4.18 kHz.  This should be enough to give an increase of gain of 10 dB by 418 Hz and 16.2 dB by 100 Hz.  This is probably more than we need.  It could be shifted down to 1 kHz (28 nF) if we do eventually reach 1 MHz UGF.

## New Loop Bandwidth Limits

The loss of gain from changing R19 means that we are getting a factor 12.45 less gain in the EOM path.  I turned the common gain  slider up to max of 10V (+32 dB) and see a UGF 224 kHz.  The loop is stable with boost on and fast gain set to -1.07 V and also with the boost off; the cross over for this configuration of gains is 11.3 kHz. The RMS noise on north PDH error monitor is 19.4 Vrms (just looking on the oscilloscope). It seems pretty stable for now, I'll take a TF later after a few more tweaks of values. Also its late and I want to go home.

Now we have a problem with gain, we need more of it. It looks like that if we could find gain of +10 dB somewhere we could push the UGF out to 593 kHz and have a healthy phase margin of 42 deg. If we can find more gain we can probably go further.  The phase margin gets to 30 deg at 806 kHz so that might be a logical point to stop.     However, there appears to be a little peaking at 750 kHz that we need to watch out for.  Not sure what it is, don't think I've seen it before. We'll have a closer look at it when it becomes a problem, but we might need to reexamine tuning of notches or putting another notch in if the combination of OLG UGF and and boost mean we need to push out this far.

We could collect error signals and actuator signal PSDs and model the optimal ballance and crossover between PZT and EOM, but this will take weeks to build an actuate model. For now its probably faster and easier to see empirically if the EOM can handle the higher gains without running out of actuation range.

In terms of finding more gain, we can get a bit by boosting do any of the following:

• the RF signal from the detectors (up to whatever still gives us linear range of mixer without compression)
• turn up the laser power a little