40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 PSL, Page 46 of 52 Not logged in
ID Date Author Type Category Subject
2265   Mon Dec 17 22:13:03 2018 anchalDailyProgressTempCtrlProposed circuit for cavity temperature sensor Part 2

The second stage of the amplifier for temperature sensor would be subtractor circuits using OP27G.

• PFA the circuit schematic consisting of the instrumentation amplifier and different circuits for acromag channels.
• There would be 1 low-resolution channel with a range from about 15 $^\circ C$ to 95 $^\circ C$ with a response: 0.238053435115*T - 13.167938931297705
• Rest would high-resolution channels with a smaller range. These channels would give us about 1mV/mK slope so that we can read with mK precision with 16 bit $\pm 10$ V range.
• Channel 1: From 15 $^\circ C$ to 35 $^\circ C$ with a response: 0.952875*T - 22.5
• Channel 2: From 35  $^\circ C$ to 55 $^\circ C$ with a response: 0.943758551683*T - 43.329447115384596
• Channel 3: From 55  $^\circ C$ to 75 $^\circ C$ with a response: 0.955040625*T - 61.9375
• Channel 4: From 75  $^\circ C$ to 95 $^\circ C$ with a response: 0.9429496875*T - 79.74466991341995

I'm attaching calculations done in the jupyter notebook as zip file.

Wed Dec 19 17:13:14 2018

# There is an error in this schematic. This is not the final schematic.

Refer this only for the calculations. Use the updated schematic at DCC.

Attachment 1: Cavity_Temperature_Sensor_Calculations.zip
Attachment 2: CavTempSensorAcromagChannels.pdf
2266   Wed Dec 19 11:01:00 2018 awadeDailyProgressTempCtrlProposed circuit for cavity temperature sensor Part 2

## Missing current excitation to RTD?

I don't know if I'm missing it, or if you've yet to add it, but can't see current excitation into the RTD.  I remember you were looking into REF200 and some other voltage-> current highly stable sources (PSL:2264),  that part will be key to actually getting a high precision temperature readout.  I didn't understand how the op amp stage in your schematic (PSL:2264) worked; it looks like you pinned the inverting input to ground but then also connected the output pin for feedback.  Doesn't really make sense to me.

Do you want something more like this: technical note. There they use the op amp to bootstrap the voltage reference so that the actual applied voltage rises to whatever is necessary to get the design current fixed through the reference resistor AND sink it through the load. The point of the that design is that the resistance of the sensor and its cabling does not affect the current: current is set only by the reference resistor. The stablity of the excitation current will hinge on the goodness of the voltage reference and that of the reference resistor.

Also, as a side note, you were proposing a 5V reference.  I thought I read somewhere that the standard buried zenor reference in these types of voltage references were actually typically 7 V and the 5 V and 10 V versions some how stepped up/down using a precision resistor network buried within the chip.  My understanding was that 7V references were the best because there was no additional drift.  If the specs of the MAX6325 are good, then maybe its well compensated and its nothing to worry about.  It might be worth checking if that series of chips has other discreet​ voltage options that perform better.

## Add some impedance to output of OP27s

Its a good idea to add about 100 Ω (or more) of resistance to output of OP27s. Otherwise poor little chips are going to overdrawn in current for low impedance loads. Probably won't break them, but it will produce bogus voltages. The acromags are 10 kΩ impedance but you can never predict if someone is going to plug in a 50 Ω oscilloscope at some point.  Check what max current of OP27 is and adjust so that at full range you wont be overdrawing with 50 Ω load.

## How many wires?

RTD is pinned to ground on one side.  Not sure what your intending for the wiring scheme here? 3 wires, 4 wires.  Ideally you want to excite current through two wires and read back voltage drop across another two.  But if you're pinning one side to ground then you've already effectively reduced it to a three wire scheme: ok but not best.  I guess you want to think about how this scheme is going to minimize your uncertainty/sensitivity with respects to wiring (see maybe this). Four wires is best.  Be best.

Also are we going to miss out on the excellent CMRR of the instrument amplifier if it isn't a truly differential readout on the front end of the circuit?

## Best RTD nominal resistance

You've looked at a bunch of numbers for choice of RTD resistance @ 25 C.  From the numbers we looked at 1 kΩ seemed like the best for order 100 µA excitation (this is the break point with Johnson noise). It might be nice to have a plot or a table that shows the tradeoff off of sensing SNR (for various noise sources) for different choices of RTD nominal resistance, i.e. 100 Ω, 1 kΩ, 5 kΩ, 10 kΩ.   The excitation current and resistance determine the tradeoff points and the right choice is the one that gets below/close to the nominal input referred noise of available pre-amp stages. That would be good for framing a good science reason for choosing a particular RTD (with a particular slope).

## So many channels

Still not sure you need so many channels.  If we already have a good idea of the operating range, then a one high precision channel will do.  We are almost certainly not going to need all that dynamic range and changing resistors is easy.

 Quote: The second stage of the amplifier for temperature sensor would be subtractor circuits using OP27G. PFA the circuit schematic consisting of the instrumentation amplifier and different circuits for acromag channels. There would be 1 low-resolution channel with a range from about 15 $^\circ C$ to 95 $^\circ C$ with a response: 0.238053435115*T - 13.167938931297705 Rest would high-resolution channels with a smaller range. These channels would give us about 1mV/mK slope so that we can read with mK precision with 16 bit $\pm 10$ V range. Channel 1: From 15 $^\circ C$ to 35 $^\circ C$ with a response: 0.952875*T - 22.5 Channel 2: From 35  $^\circ C$ to 55 $^\circ C$ with a response: 0.943758551683*T - 43.329447115384596 Channel 3: From 55  $^\circ C$ to 75 $^\circ C$ with a response: 0.955040625*T - 61.9375 Channel 4: From 75  $^\circ C$ to 95 $^\circ C$ with a response: 0.9429496875*T - 79.74466991341995 I'm attaching calculations done in the jupyter notebook as zip file.

2267   Wed Dec 19 14:00:55 2018 anchalDailyProgressTempCtrlProposed circuit for cavity temperature sensor Part 2

• The current excitation circuit is there, it is just in another page in the schematic. I'm uploading full schematic now for clarity. I used  PSL:2264 circuit for the purpose only.
• Regarding the circuit, I think I found an error now in this schematic. I was implementing the circuit mentioned in the technical note you posted but I took it from another source and I failed to realize that I need to keep GND input of MAX6350 floating for it to work. I'll fix this in next version.
• I remembered your point about 7V being more fundamental but I couldn't find a good voltage reference at this voltage. Probably industry is too biased towards using 5V. In MAX63xx, 7V is not available.

## Safety resistors at outputs of OP27

• I designed the circuit for use with acromags only so I didn't try to affect the output signal at all.
• But you are right. Keeping in mind the mishaps I have seen myself, I will put a 100 Ohm resistors in the next version.

## No of wires at RTD:

• Yeah, I wanted to implement 4 wire method only. I by mistake grounded the incoming signal from RTD before InAmp.
• You are right, We will miss out CMRR if I do not keep inputs to InAmp floating. I'll fix this in next version.

## Best nominal RTD resistance:

I'll look into it but since the numbers work out for us for now (fortunately), I'll keep it at a lower priority. Having a good science reason will be good, I agree.

## Channels:

I couldn't think of a strong argument against having extra channels. Plus we don't really know what temperatures the cavities go to (and will go to with new heat shield on). So for the first version at least, I wanted to keep extra channels and decide this answer in the future.

## Next version required:

Unfortunately, I think the present version won't really work without a lot of ugly scratches on the pcb. I messed up this one. Thanks to JLCPCB, getting boards is cheaper and faster now. So I'll get to this right away to avoid Christmas delays.

2268   Wed Dec 19 17:47:02 2018 anchalDailyProgressTempCtrlCavity Temperature Sensor Circuit v1.1

From the review of PSL:2266 and the promises I made in PSL:2267, I think I have fixed the circuit. Corrected schematic is at DCC LIGO-D1800308-v1.
Main changes:

• I made GND pin of MAX6325 floating and hence controlled by the output of OPA827. OPA827 will drive the GND pin following voltage at RTD's non-grounded end. This will make sure 2.5 V is always applied across 20k resistor which will keep the current constant.
• The incoming Molex connector from RTD is now connected to AD8429 directly driving it differentially implementing the 4-wire topology.
• I added 100 Ohm series resistors to the outputs of OP27 for safety.
• Removed tantalum capacitors from the output of MAX63XX and added one to the input.
• Added 4-40 holes for mounting on a 1U chassis. The board is still small enough to be put in a 100mmx160mm Eurocard box if required.

## Testing:

I also made a proof-of-principle circuit on a breadboard. It has only one channel (25 $^\circ C$) and uses different chips but same principle. Following were the replacements:

• MAX6325 (2.5V Ref) -> LT1021 (5V Ref)
• Current source resistance, 20k -> 39k
• OPA827 -> OP27
• MAX6350 (5V Ref) -> LT1021 (5V Ref)
• AD8429 (Gain set to 81) -> AD620 (Gain set to 79.68)
• Subtractor circuit resistors: R1, 5k -> 5.1k;     R2, 25k  -> 24k
• Everything else was the same.

The circuit produced meaningful and predictable node voltages. So hopefully, this circuit is correct. Only remaining thing is to characterize noise and drift properties which would be done once the actual parts arrive.

Attachment 1: 48390116_529820604163457_2540948531154255872_n.jpg
2269   Mon Dec 24 16:52:26 2018 ranaDailyProgressTempCtrlCavity Temperature Sensor Circuit v1.1

post a plot of the times series and noise spectrum

Here is a link on how to choose R and C:

https://dcc.ligo.org/LIGO-T070016

2270   Tue Dec 25 11:45:15 2018 anchalDailyProgressTempCtrlVacuum Can Temperature Sensors (AD590) transimpedance amplifier board test

Yesterday, I put two boards of LIGO-D1800304 with two pairs of circuits populated in each of them for testing.

### Circuit 1:

• Installed inside an aluminum box and shielded with thermacol to keep it safe from external temperature fluctuations as much as possible.
• Driven by externally regulated 15V power supply.
• Channels C3:PSL-VCTMPSNS_0 and C3:PSL-VCTMPSNS_1 carry output signals from these boards

### Circuit 2:

• Kept open to the environment to see how much environmental fluctuations would affect the readings with respect to Circuit 1.
• Driven by externally regulated 15V power supply.
• Channels C3:PSL-VCTMPSNS_2 and C3:PSL-VCTMPSNS_13 carry output signals from these boards

### Sensors:

• All four AD590 sensors are taped next to each other near the center of a large copper block with aluminum tape.
• The power regulator of the above circuits is also taped to one end of this copper block away from sensors using kapton tape.
• The power regulators are inside here to increase the temperature of the block to bring it within the sensing range of transimpedance amplifier boards (26 $^\circ C$ to 44 $^\circ C$ roughly).

As of today, I see that all sensors have reached a temperature which is within the sensing range of boards. However, I see different readings on them, probably due to different actual resistor value on each copy of circuit. The channels are being saved by fb4. I'll pull out time series data after some more time when we can safely assume that everything has thermalized. The fluctuations in the difference of these signals would tell us about environmental coupling and the board noise and precision itself.

Attachment 5: CopperBlock.jpg
2271   Wed Dec 26 14:09:29 2018 anchalNotesEPICSws1 unable to read/write on some EPICS channels

ws1 is unable to read and write on some EPICS channels while I can see these channels in fb4 or acromag1. These channels are:

• C3:PSL-NCAV_FSS_SLOWOUT
• C3:PSL-SCAV_FSS_SLOWOUT
• C3:PSL-NCAV_FSS_FASTMON
• C3:PSL-SCAV_FSS_FASTMON
• C3:PSL-PRECAV_BEATNOTE_FREQ
• C3:PSL-HEATER_SHIELD_DIFF_POUT
• C3:PSL-PLL_AUTOLOCKER_BEATNOTE_FREQ
• C3:PSL-PRECAV_BEATNOTE_FREQ_SIGN
• All C3:PSL-VCTMPSNS_x where x is 0,1,2 and 3
• Maybe more

I'm not sure what is causing this. I have rebooted cromag1 several times but this problem persists. Interestingly, there are a lot of channels which are getting updated on medm screens so the origin of the problem is probably localized to a single .db file. But everything looks fine to me, at least after first few debugging trials.

Well, because of this, it is impossible almost impossible to even manually tune the beatnote frequency to the required point. I'll first fix this because it seems like an error which shouldn't be ignored. Suggestions are welcome as I am new to EPICS-Modbus-upstart-docker things and might be missing something silly.

2272   Fri Jan 4 16:42:28 2019 anchalSummaryNoiseBudgetLatest noisebudget update.
• Since we are working on temperature control of cavities, we worked out a hack to still take beat note spectrum meanwhile.

### Method of measurement:

• Spectrum is measured by SR785 at 800 points from 0 Hz to 6392 Hz.
• No averaging is used and autorange is switched on.
• Units of V_rms/sqrt(Hz) are used in the measurement.
• I wrote a script, measBNnoise.py which is in Git, which continuously saves data from SR785 which is set as stated above.
• Saving data takes from 90s to 120s, so data is being saved stroboscopically.
• We are hoping that as the beatnote frequency is drifting slowly, Marconi will follow it almost always nicely except when it re-ranges.
• So taking data in this way will mostly take data when Marconi is not re-ranging.
• Data was taken for 12 hours in which total 381 measurements were made. 346 were filtered and used as described below.
• Then I used another script I wrote, BNspectrum.py which does following:
1) Reads all data files and computes the area under the curve. (We are using it as a figure of merit to filter out instances when Marconi was re-ranging)
2) Throws away data sets which have this area above 2*sigma from the mean value of the whole set.
3) Computes median at each frequency bin of remaining data set.
4) Computes standard deviation from the median at each frequency bin.
5) )Plots this data like iris (plot attached) and saves it in a .txt file to be used by noisebudget.ipynb later.

### Present state of the experiment:

• FSS on both paths has been upgraded to higher modulation frequencies (36 MHz on North, 37 MHz on South) (see PSL:2242 and PSL:2247)
• PMC is installed on the South Path. (see PSL:2251)
• See alignment details at PSL:2253.
• ISS is not installed at this point.
• Wideband NewFocus 1811 (DC-125MHz) RF Photodetector is used.
• Temperature control on cavity shields was not on. They were put in a known almost stable heating state of 0.3871W Common and 0.7742W differential heating.

### Conclusions:

• This beatnote is as good as Feb 2018 measurement only.
• In my opinion, ISS will help in reducing the noise further.
• Presently, I have not optimized polarization of light going into EOM according to amplitude modulation produced by it. This in absence of ISS must be putting in more noise then we think.
• Lens positions have not been optimized and are at there eyeballed positions where I put them after ala mode calculations. They might be off in order of cms.
• The older elliptical filters in FSS boxes have not been replaced yet.
• I'm not sure how big this is a factor, but in absence of temperature control, the frequency must be picking up more noise through drift in cavity lengths due to uncontrolled heating.
• We are not using lower noise narrowband RF detector as we are presently not controlling BN frequency.
• I also think we should have had taken data for a longer time. I will do this over the weekend.
• I'll over the weekend write a script so that this hacked measurement will start happening every weekend. This way we can see any changes in our measurement from new things we work on during the week.
Attachment 1: Jan03_2019_BNnoise__Iris.pdf
Attachment 2: 20190104_171447noiseBudget.pdf
2273   Fri Jan 4 19:04:29 2019 awadeDailyProgressRFAMTime to look at RF AM and RIN

That roll up in the HF range to 3 kHz hump looks suspect.

## PLL?

We need to check that we're actually implementing the PLL properly and unwrapping the BN PSD properly from the actuation signal.  You could end up from a result like this if the UGF was, say, ~ 1 kHz: then the PSD * (marconi slope) approximation will no longer be true and would look more like PSD * (marconi slope + 1/Mix*SR560).  As demodulation for PLL frequency gives a 1/f in closed loop (from freq->V_out), this would give a roll up directly proportional to frequency around and above UGF when inverting. We should go back and check again that the transfer function measured yesterday of the PLL had a UGF of >60 kHz. You should remeasure the PLL open loop gain and post it on the elog. Make sure you use a small excitation signal and play around with the cycle averaging settings to smooth out noise for a nice clean trace. Also a schematic of exactly where signals are injected, values of gains, slopes and mixer conversion efficiencies (spec sheet value will do) and RF power from beat note detector.

You'll also way to check that you're not saturating the NF1811.  You don't want weird artifacts from not being linear in response at RF... slew rate limit etc. Details of internals of NF1811 can be found in the PSL Electronics Wiki.

## Just Marconi noise?

Also see figure 4.8 of Tara's thesis.  I'm having trouble making out the colours but there is peaking there in the marconi frequency noise at around 3 kHz. This plot places the 10 kHz/V modulation slope as being clear by at least an order of magnitude.  Always be suspicious. Are our macnoni's still performing?  Add this to the moderate-to-low-priorities list of things to check.

## RF AM again?

The BN PSD doesn't extend high enough to compare fully to all the others but if we find that the PLL -> BN is correct then maybe this is an old problem related to excess AM from the 36 MHz and 37 MHz EOMs producting AM and PM.  See PSL:2083 and related backlinks.  In particular we want to know if the laser RIN has some coherence with the BN.  See what Evan did in PSL:1524.  Before screwing around with optimizing the AM (maybe a 1-2 day task) figure out how you can use the transmission signals to get a RIN of both cavities and make a coherence plot.  This would be your smoking gun.  After that maybe look into whether you should sink time into optimizing RF AM and ISS.

Checking RIN and coherence with the beat note is maybe a 1/2 day task once everything is locked up and working.

Also, put those thermal hats back on those EOMs.  Its winter, have a heart.

2274   Fri Jan 4 19:17:00 2019 anchalSummaryTempCtrlVacuum Can Temperature Sensors (AD590) transimpedance amplifier board test - RESULTS

Over the break, the test of Vacuum Can Temperature Sensors transimpedance circuit was running and fb4 has logged the values. PFA time series data from fb4. See PSL:2270 for experiment details.

To reiterate:

• Channel 0 and 1 are from the same board (Circuit 1) which is enclosed inside an aluminum box which is sitting inside a thermacol box. So this circuit should be well insulated from environmental fluctuations
• Channel 2 and 3 are on another board (Circuit 2) which is in the open.

As seen in timeseries data, something is wrong in Ch2 data as it is fluctuating too much arbitrarily. I'll see what went worng in this particular circuit. Thankfully, I had an extra circuit on same board which is recorded in channel 3 so that we can compare the channels.

### Inferences:

• In terms of fluctuations over small periods, it seems both circuits perform similarly with no noticeable drift.
• The EPICs channels are updating at 10 Hz while I found that fb4 records channels at 16 Hz. Due to this, I think we can not really do fft properly.
• Standard deviation of a 1minute time series data for the three channels came out to be, Ch0 -> 22.5 mV , Ch1 -> 18.0 mV and Ch3 -> 15.0 mV
• The boards are designed to have a response of 1.625 mV/mK. So either temperature is fluctuating by around 20-30 mK or the boards are 20 times worse than the design.
• Also, clearly the offsets of each board are very different. This could be because of the difference in thin film resistor values at the adder stage or reference voltage chips.
• There are visible offset jumps in the time series data. I'm not sure this is due to any gap in the recording which fb4 didn't understand or something actually happened. But these are periodic themselves with a period of about 2 hrs.
• Since fb4 is running again properly now, I'll check back timeseries data of tonight.
• Next, I'll try to make some controlled heating environment and a precise temperature sensor so that we can see if different AD590s have different slopes for temperature changes.

Edit: Fri Jan 11 11:24:11 2019

Added lighter plots. The plots now have mean value (averaged over 1 minute of data) with the shaded region showing one sigma uncertainty region. I've added the jupyter notebook in .zip file.

Attachment 1: VacCanTemSensorTest_Time_Series_Data_1229716818_to_1229904318.pdf
Attachment 2: VCTemperatureSensorsTest.zip
2275   Wed Jan 9 17:25:38 2019 anchalDailyProgressRFAMTime to look at RF AM and RIN

I measured RIN of the two paths yesterday through taking spectrum of transmission PDs and measured cross-correlation with the Beatnote.

## Measurement conditions:

• Beatnote frequency was not temperature controlled and was arounf 127 MHz slowly increasing.
• Note, this is near the edge of the DC-125 MHz wideband RF detector used for BN measurement.\
• PLL Actuation slope was 5 kHz/V
• Cross-correlation was measured as a FFT group measurement by SR785 using Cross Spec measurement.
• Averaging was on and set to 50 with Linear averaging.

## Conclusions:

From the plots attached, it is clear that RIN of both paths have a peak near 3 kHz but the south path has excessive RIN in comparision to North parth and has much more coherence with BN. I'm looking into possible RF AM in south path.

Edit Wed Jan 16 14:08:03 2019 :

I forgot to convert the noise spectrum measured to laser power spectrum earlier. I am also realizing now that I should have measured the transmitted power to get the RIN. So this measurement only provides Intenisty (or Power) noise of transmitted lasers. I'm attaching the fixed plot now.

Attachment 1: RIN_DBN_Coherence_Measurement.pdf
2276   Wed Jan 9 19:05:56 2019 anchalDailyProgressRFAMTime to look at RF AM and RIN

## Preliminary testing

I hooked up an HP8560E to RF port of the South FSS Refl RFPD. I unlocked laser from the cavity and brought it to a place which seemed far away from any mode of the cavity.

I was hoping to see a peak at 37 MHz which is PDH modulation frequency of FSS on this path. To my surprise, signal level was ~-80 dBm only at 37 MHz. On zooming out, I saw a 29.5 MHz peak instead of about ~-55dBm. @9.5 MHz is second harmonic of the modulation frequency for South PMC PDH loop. This seemed weird as sidebands of EOM before PMC should not reach after PMC. So I have taken noted some preliminary numbers for future. This isn't complete analysis:

Laser Slow Freq Offset (V) Peak Frequency (MHz) Peak Value (dBm)
-5.9975 0 -11
-5.9975 29.5 -55
-5.9975 37 -60
-5.9875 0 -11
-5.9875 29.5 -55
-5.9875 37 -60
-6.0275 0 -11
-6.0275 29.5 -55
-6.0275 37 -70

All data was taken with a span of 50 MHz. Note how on changing the frequency offset, I got a offset point where 37 MHz Peak almost disappears but the 29.5 MHz peak is present irrespective of the frequency. Need to investigate more.

Thu Jan 10 14:31:56 2019, in reply 2278

It is a resonant EOM.

2277   Thu Jan 10 10:39:27 2019 anchalDailyProgressNoiseBudgetNew noise budget code is ready, but

The new noise budget code is ready. However, there are few discrepancies which still need to be sorted.

The code could be found at https://git.ligo.org/cit-ctnlab/ctn_noisebudget/tree/master/noisebudget/ObjectOriented

Please look into How_to_use_noiseBudget_module.ipynb for a detailed description of all calculations and code structure and how to use this code.

### Discrepancy #1

In the previous code, while doing calculations for Thermoelastic contribution to Photothermal noise, the code used a weighted average of coefficients of thermal expansion (CTE) of each layer weighted by their thickness. However, in the same code, while doing calculations for thermoelastic contribution to coating thermo-optic noise, the effective CTE of the coating is calculated using Evans et al. Eq. (A1) and Eq. (A2). These two values actually differ by about a factor of 4.

Currently, I have used the same effective CTE for coating (the one from Evans et al)  and hence in new code, prediction of photothermal noise is higher. Every other parameter in the calculations matches between old and new code. But there is a problem with this too. The coating thermoelastic and coating thermorefractive contributions to photothermal noise are no more canceling each other out as was happening before.

So either there is an explanation to previous codes choice of using different effective CTE for coating, or something else is wrong in my code. I need more time to look into this. Suggestions are welcome.

### Discrepancy #2

The effective coating CTR in the previous code was 7.9e-5 1/K and in the new code, it is 8.2e-5 1/K. Since this value is calculated after a lot of steps, it might be round off error as initial values are slightly off. I need to check this calculation as well to make sure everything is right. Problem is that it is hard to understand how it is done in the previous code as it used matrices for doing complex value calculations. In new code, I just used ucomplex class and followed the paper's calculations. I need more time to look into this too. Suggestions are welcome.

2278   Thu Jan 10 11:38:53 2019 awadeDailyProgressRFAMTime to look at RF AM and RIN

Is this the resonant EOM or a BBEOM driven with an external circuit? The driving requirements are different, if you overdrive you'll get a bunch of higher harmonics.

Maybe check the modulation depth, make sure it isn't too excessive.  Beta=0.3 should be enough. Error signal Vpp = $\inline V_\textrm{pp} = G\times4\sqrt{P_cP_s} = G\times 2P_0\beta$ (where P0 is the incident power, and G is the PD + mixer gain. Just make sure beta it isn't excessive in producing significant higher order components.

You want to figure out if the 29.5 MHz harmonic feature is an electrical cross coupling or optical. Check your cable routing, are you getting any cross coupling pickup from collocated coaxial lines?  Pretty sure we got the mode cleaner PDH demodulation stuff right, but check mixer is right power level with 4th order LP filter + 50 ohm termination on input side of the LP filter with a RF compatible T-junction.

Also, looking back at the design documents for the PMC, it looks like the nominal design frequency considered was ~30 MHz modulation.  Have a look Evan's earlier​ calculations, especially with respect to HOM suppression.  It looks like for 30 MHz the 60 MHz harmonic is in a relatively low transmission point for HOM. If the issues are optical artifacts transmitted it might be HOM... you can always up the frequency to something closer to 30 MHz.

Take all of the above with a grain of salt.  Consider how much time to sink into it based on whether you think its actually driving a noise source in the system.  Eliminating this 14.75 MHz harmonic may be in the basket of diminishing returns for your time.  The 36 MHz and 37 Mhz AM components are a much bigger concern for FSS related coupling of RIN into frequency noise.

Quote:

## Preliminary testing

I hooked up an HP8560E to RF port of the South FSS Refl RFPD. I unlocked laser from the cavity and brought it to a place which seemed far away from any mode of the cavity.

I was hoping to see a peak at 37 MHz which is PDH modulation frequency of FSS on this path. To my surprise, signal level was ~-80 dBm only at 37 MHz. On zooming out, I saw a 29.5 MHz peak instead of about ~-55dBm. @9.5 MHz is second harmonic of the modulation frequency for South PMC PDH loop. This seemed weird as sidebands of EOM before PMC should not reach after PMC. So I have taken noted some preliminary numbers for future. This isn't complete analysis:

Freq Offset Peak Frequency (MHz) Peak Value (dBm)
-5.9975 0 -11
-5.9975 29.5 -55
-5.9975 37 -60
-5.9875 0 -11
-5.9875 29.5 -55
-5.9875 37 -60
-6.0275 0 -11
-6.0275 29.5 -55
-6.0275 37 -70

All data was taken with a span of 50 MHz. Note how on changing the frequency offset, I got a offset point where 37 MHz Peak almost disappears but the 29.5 MHz peak is present irrespective of the frequency. Need to investigate more.

2279   Thu Jan 10 14:19:46 2019 anchalDailyProgressRFAMTime to look at RF AM and RIN

I found this paper on OSA: Control of residual amplitude modulation in Lithium Niobate phase modulators. It suggests a control mechanism which does not require controlling the temperature. The main point in it is that if a DC offset is present in the RF signal going into the EOM, it is effectively the same as changing the temperature by some amount. So, in principle, by changing the DC bias of the RF signal with a bias-tee just before the EOM, one can minimize the RF AM modulation. The paper though doesn't suggest the feedback mechanism or what sensor would be good for this. If we think this is worth giving a shot, in my opinion, if we fork the output of EOM somehow, measure the RFAM through it and employ a feedback circuit to control the DC offset, we can actively suppress the RFAM. Just a thought at this moment.

Just after writing above, I realized people at JILA have done something similar (with more complexity though):
Reduction of residual amplitude modulation to 1 × 10-6 for frequency modulation and laser stabilization

2280   Thu Jan 10 17:30:24 2019 anchalDailyProgressRFAMTime to look at RF AM and RIN

We measured the modulation index of 0.142 rad when we installed the PMC (See PSL:2251). I checked both PMC loops, none of them are oscillating.

I think I understand now what is happening. The Amplitude modulation from EOM behind the PMC is about -21 dBm . From Evan's earlier calculations , this RF AM should be suppressed by 0.02 only since it is at 14.75 MHz. This corresponds to -34 dB and hence we are seeing a 29.5 MHz amplitude modulaion ahead of about -55 dBm. There is some mechanism which is frequency doubling this modulation and we are seeing it at 29.5 MHz after the PMC.

I think I will try reducing this RFAM with a combination of PBS and tuning both polarizer and EOM angles. But if we had an extra resonant 21.5 MHz EOM and RFPD, this problem would completely go away as PMC will be able to reduce the RFAM more effectively there.

2281   Thu Jan 10 18:52:20 2019 anchalDailyProgressRFAMTime to look at RF AM and RIN

I think I found the culprit. the polarizer behind the EOM (PMC loop EOM) was a multi-order one and hence was extremely sensitive to temperature. I replaced it with a zero order half wavepleate and realigned the EOM to minimise the RF AM to about -70 dBm. The PMC has got misaligned in this procedure, so tomorrow I'll align it back and see if our changes made a difference.

2282   Sat Jan 12 13:11:02 2019 awadeDailyProgressRFAMTime to look at beatnote after RF AM and RIN tuneup

Nice.

It would be a good time to retake the BN + cross spectrum with RIN to see if these improvements squash the 3 kHz hump.  You'll probably want to recheck the RFAM levels immediately before retaking the BN in case there has been any drift.  When plotting the RIN you should include a trace that quantifies the dark noise of the PDs and the shot noise. The traces are not much use if they are limited by either of these, the elog readers would benefit from having such traces as a bench mark.

A good thing to do, as well, would be to resurrect the AEOM power controls in both paths.  You can then use a swept sine to take a transfer function from intensity noise to beat note directly without just relying on the residual RIN of the laser*.  This will help you model the expected real TF from intensity noise to frequency noise (for the noise budget) and help justify the design choices of the ISS (how far along is the ISS BTW?).  It also lets you know the susceptibility of each path to RIN, regardless of the performance differences between the two laser.  Maybe its also possible to fine tune the offsetting on the FSS PDH controls by watching the transfer function live and adjusting the DC offset to minimize Intensity->FSS->Freq Noise conversion.  The offsets and gains on the FSS loop are now more or less arbitrary, this is something you can try next time you tweak up these loops.

THe AEOMs should be configured with s-polarized light (vertical) going into the modulator with a quarter-wave plate, followed by a PBS at the output.  Adjust the quarter-wave plate to get yourself to 50:50 splitting, this gives you the maximum W/V slope with close to linear response. You'll need to adjust upstream powers accordingly to give you 1.5 mW at the input of the RefCavs. Be aware of how hard you are driving the modulators so that you are sure that it is in the linear regime.  Terminate AEOMs when not in use.

* It would also be nice to have a tap off somewhere (<10%) to be able to sample the pre-cavity RIN.  Given that any BS/ wedge you insert will misaligned the beams it will be a 0.5 day exercise to realign cavities etc, thus mid-low priority.

 Quote: I think I found the culprit. the polarizer behind the EOM (PMC loop EOM) was a multi-order one and hence was extremely sensitive to temperature. I replaced it with a zero order half wavepleate and realigned the EOM to minimise the RF AM to about -70 dBm. The PMC has got misaligned in this procedure, so tomorrow I'll align it back and see if our changes made a difference.

2283   Wed Jan 16 11:07:41 2019 anchalDailyProgressNoiseBudgetBeatnote after RF AM and RIN tuneup

## Intensity noise to the beatnote transfer function

• I resurrected the AEOM power control lines with SMA cables to junction plate on the north side.
• AEOM was driven in linear amplitude modulation regime by aligning input polarization to s (vertical) and making output polarization circular by a quarter waveplate and dumping the s (vertical) polarization through a PBS.
• $I_o = \frac{I_i}{2} \left( 1 + \sin(\frac{V_i}{V_\pi}\pi) \right )$
• For the New Focus 4103 models, we have, $V_\pi = 300 V$ . I used source signal for amplitude modulation of $V_i = 5 V$ . This gives modulation index $\beta = 0.052 \, rad$ and maximum deviation from linearity by $I_i \times 1.17 \times 10^{-5}$ .
• The measurement was done as a swept sine with input at reference signal as the modulation signal to the AEOM and output as PLL control voltage.
• The TF is then converted to units of Hz/W using PLL actuation slope of 5 kHz/V. The gain in the PLL loop was set to 100.
• Beat note frequency during the measurement was near 135 MHz.
• For the measurement in the North path, Settle Cycle was set to 10 and integration cycle was set to 10.
• During the measurement in the South path, the beatnote started drifting faster so Settle Cycle was set to 2 and integration cycle was set to 4 and average of 3 measurements is taken.
• PFA transfer functions. Note, transfer functions are mentioned from different initial points for future use. They were converted by scaling down by the ratio of the DC power measured at Cavity input, PMC output, and AEOM output.

## Transmission RIN:

I measured transmission RIN before the beatnote measurement. Unfortunately, we can not compare with earlier intensity noise measurement I took because I didn't take transmission power measurements then.

These measurements were taken in 4 steps of frequency ranges and stitched together. See the attached notebook for further details.

## Beat Note Frequency Noise Spectrum

I used the same measurement method as explained in (PSL:2272). Following are some experiment state measurements I made:

Experiment State
Parameter North Path South Path Common Unit
PLL Gain     100 -
PLL Actuation Slope     5 kHz/V
BN Frequency

~ 130 MHz

drifting down

-
PMC Input Power 1.82 2.404   mW
PMC Output Power 1.615 1.619   mW
PMC Overlap 89% 67%   %
Incident Power on Cavity 1.497 1.497   mW
Transmitted Power from Cavity 0.96 0.82   mW
Cavity overlap 64% 55%   %

PMC Reflection RFAM

(@ PMC loop RFPM frequecy)

-52 dBm

@ 21.5 MHz

<-71 dBm

@ 14.75 MHz

dBm

Cavity Reflection RFAM

(@ PMC loop RFPM frequency)

<-87 dBm

@ 21.5 MHz

< -77 dBm

@ 14.75 MHz

dBm

Cavity Reflection RFAM

(@ FSS loop RFPM frequency)

-76 dBm

@ 36 MHz

-75 dBm

@ 37 MHz

dBm

Cavity Reflection RFAM

(@ 2x PMC loop RFPM frequency)

< -87 dBm

@ 43 MHz

-54 dBm

@ 29.5 MHz

dBm

Note: I also found that half waveplate behind North FSS EOM had no marked order and was probably multi-order. I replaced it with a zero-order half waveplate and found significant improvement in RFAM at Cavity Reflection RFPD. Above mentioned numbers were taken after this change.

## Updated Noise Budget:

I'm still using the old code here as there are some unresolved questions with the new code I want to be sure about first.

• The new spectrum is lower at noise at lower frequencies. This might be due to the unmeasured amount of light falling on the cavities in the previous measurement.
• RFAM and RIN tuneup decreased noise slightly at 2 and 3 kHz.
• However, the method used for taking these measurements keeps the uncertainty high. So maybe the effects of our changes are actually negligible and something else is more pressing.
• Clearly, the growth of noise beyond 1 kHz is still happening and this is one major difference between earlier noise measurements and new measurements.
• I think installing ISS should be the next step in the queue because these high-frequency bump is probably coming from there.
• I will also work on tuning up the FSS loop parameters to see if that changes anything.

Attachment 1: LaserPowerNoise_to_BNFreqNoise_TF.pdf
Attachment 2: IN_to_BN_TF.zip
Attachment 3: Transmission_RIN_Jan15_2019.pdf
Attachment 4: RIN_Measurement_20190115.zip
Attachment 5: 20190116_130937noiseBudget.pdf
2284   Wed Jan 16 22:07:44 2019 awade, anchalDailyProgressPLLPLL noise from the Marconi 2023A FG

This is not a detailed post as I didn't collect data.  We need to check the actual noise performance of the Marconi and compare.  It seems like the marconi used in the PLL has some nasty frequency spikes and generally higher noise.

Today I dug out a Wenzel crystal OCOX oscillator (Freq 24.483 MHz) from the QIL lab to check the performance of the Marconi FG against a stable reference. These crystals are a good reference to compare to as they should have a noise floor of -165 dBc/Hz vs the marconi performance of -124 dBc/Hz (@ 20 kHz) operating at 470 MHz (datasheet didn't have values for smaller freq).

The output is +13 dBm so I attenuated by 13 dB to give a simulated BN signal of about 0 dBm (gives mixer gain 0.210V/rad).  This was then substituted for the beat note signal and and the PLL was locked with the Marconi carrier close to the nominal crystal frequency.  Marconi slope was set to 1 kHz/V, LO carrier was +13 dB into mixer (lv13), SR560 gain was 20.  Screen shot picture (attached below) shows the original Marconi (labeled #539) in the reference trace and the spare PSL lab Marconi (labeled BD90200).  Sorry there is no data capture, I was using the SR785 from the EEshop that isn't configured for our lab IP addresses.

What we see is at least 10 dB worse performance for exactly the same marconi settings.  We can also see that there is also a huge spike at about ~1kHz.  This could be the source of some of the humping in the BN spectrum. Not sure about this but maybe some of the LF noise in the spectrum gets convoluted about this strong spike, smearing noise out at the higher frequencies.

The Marconi in the cryo lab, from the cryo-CTN experiment was also procured.  The noise on that Marconi was even lower and did not have any spike artifacts. However, I was able to see a bit of a spike when the external modulation voltage was a little bit negative.

I then messed around with some of the settings buried in the menu, I turned the external RF clock reference off on the cryo Marconi and also activated the RFDC null with the modulation BNC 50Ω terminated.  After I had changed some of these things I was not quite sure if I recovered the same noise performance from the better units.  Also, I noticed that the 10 kHz/V range on the cryo Marconi didn't want to lock at all, it was as if there was no actuation going on; it worked fine on settings <=4 kHz/V, just not higher, not sure what is wrong here.

We need to do some detailed measurements tomorrow at a range of different frequencies to nail down exactly what is going on here.  As the VCO noise in the PLL loop is not suppressed by the loop gain, this goes strait to the bottom line of the BN spectrum.  We need to know that PLL is not limited by the Marconi noise.

Measurements to do:

1. PLL BN spectrum with all three Marconis at 24.483 MHz for 0.5 kHz, 1 kHz, 5 kHz and 10 kHz
2. PLL BN spectrum with all three Marconis at doubled/ tripled and quadrupled frequencies (or whatever Wenzel crystals we can get) to check if its just this frequency range
3. Debug cryo Marconi and see why it won't lock PLL on the 10 kHz range
4. Stabilize Marconi to external Rb clock from cryo lab and see if performance is improved
5. (optional) run 10 MHz line along back of labs to PSL lab from cryo so we have a GPS stabilized reference to work with (low priority)

---

Also, we want to take some BN with the old Marconi swapped out.  You should have all the data you need for drift of AD590 sensor traducers by now. The old TIA circuit is so badly designed that its almost certainly doing a feed forward from room temperature to can heaters. Either install the new circuit proto or turn the vacuum can thermal controls OFF completely. Just install what you have and use the secondary circuit as a your tester.  But don't spend any more time making everything perfect: you are getting 1/t returns on your time on this one. You'll want to box it up and make a yellow Styrofoam insulator box to shield it more from room temp changes.

Attachment 2: IMG_4877.JPG
2285   Thu Jan 17 11:55:12 2019 anchalSummaryTempCtrlVacuum Can Temperature Sensors (AD590) transimpedance amplifier board noise test

I wanted to take a direct spectrum noise measurement of the circuit. However, if I have simply hooked the output of the circuit to SR785, I wouldn't know if the noise is coming due to temperature fluctuations or due to circuit noise itself. So I made a quick subtraction circuit of unity gain with an OP27 and subtracted different pairs of channels and then took their spectrum using SR785.

### Method:

• First I shorted the input to the subtraction circuit and measured the spectrum. This gave me an estimate of output noise due to this additional circuit and SR785 measurement.

• I assumed the gain of the subtraction circuit is just 1 so, the output noise of the circuit under test wasn't assumed to get amplified from subtraction circuit.

• Then I took measurements of the difference of signals for each pair from CH0, CH1, and CH3 in both permutations. All measured spectrums are plotted in the first plot.

• I used both permutations to nullify any effect of different gains in positive and negative inputs of the subtraction circuit due to slightly different resistor values.

• Then I averaged the spectrum from the 2 permutations of difference and subtracted output noise of the subtraction circuit measured earlier in quadrature. These are plotted in 2nd plot.

• Then for the Circuit 1 which was insulated from the environment, assuming the two circuits have identical noise, I divided by sqrt(2) to get individual channels output noise.

• I subtracted this insulated individual channels output noise from the difference noise with 'open to environment' channel in quadrature to get an estimate of noise when the circuit is open to the environment.

• The individual channel output noises are plotted in Plot 3.

### Conclusions:

• There is a high peak at 60 Hz because of AC frequency. I am not sure about the origin of the 7 Hz peak. Other peaks look like reflections during the measurement.

• There is about a factor of 2 improvement by insulating the box.

• The circuit is designed for 1.625 mV/mK transduction.

• Since EPICS channels are read at 16 Hz rate, we should be interested in the 0-16 Hz bandwidth. In this bandwidth, voltage output noise for the insulated channel is 0.79 mVrms and 'open to environment' channel is 1.74 mVrms.

• So the noise wouldn't harm the designed 1mK sensitivity. In practice, even if these estimates are bad, the circuit should be ok for our needs.

• So the only thing that can endanger our precision really would be temperature drift of circuit components on which we have already invested enough money and time during design.

• So agreeing with Andrew, I'm going to go ahead and install these new circuits and directly see their performance towards improving BN spectrum as we think the Vacuum Can temperature is oscillating more than lab temperature due to poor circuits presently employed.

Attachment 1: Vacuum_Can_Temperature_Sensor_Transimpedance_Circuit_Noise_Analysis.pdf
Attachment 2: VCTMPSNS_Noise.zip
2286   Fri Jan 18 13:10:02 2019 anchalDailyProgressPLLPLL noise from the Marconi 2023A FG

I took the noise spectrum of beat note in PLL when it is fed with a low noise Wenzel Crystal Oscillator of frequency 24.483 MHz and doubled frequency 48.967 MHz.

### Method:

• Instead of feeding Beat note from cavities, I fed crystal oscillator signal to the mixer in PLL.
• We tried to keep the strength of the crystal oscillator signal similar to beatnote strength from cavities which is around 0 dBm.
• At 24.483 MHz, the signal was -0.1808 dBm.
• I also took readings with a frequency doubled signal. Frequency was doubled by splitting the 24.483 MHz signal and mixing the two outputs at a mixer with an appropriate phase delay in one path.
• At 48.967 MHz, the signal was -1.16 dBm.
• Spectrum was taken for 4 different actuation slopes (S) at Marconi, 0.5 kHz/V, 1 kHz/V, 5 kHz/V and 10 kHz/V. The gain of SR560 (A) was changed accordingly to keep S*A = 500 kHz/V. This was the maximum we were able to achieve without overloading the SR560.
• Two different Marconi were tested. One is labeled '#539' and other one is labeled 'PD9020'. We tried to work with a third one from cryo lab but it was giving a weird GPIB error 'Fractional N-Loop High' without GPIB-Ethernet controller connected at all RF Level above -90 dBm.
• During all measurements, Marconis were using external frequency standard (direct mode) and were connected to Rubidium Frequency Standard SRS FS725 10 MHz sine wave output.
• Each measurement was taken in two parts, one with linewidth 16 Hz up to 1.28 kHz and one with linewidth 128 Hz up to 102.4 kHz. RMS averaging was done for an averaging factor of 100. BMH window was used.

### Conclusions:

• Marconi '#539' won the race with lower noise at all frequencies.
• The plots show noise for the beat note frequency but since the crystal oscillator is about 25 dB less noisy then Marconi, this noise is almost entirely due to Marconi and SR560. SR560 has ~ $2 \, mHz/\sqrt{Hz}}$ noise contribution above 10 Hz for all actuation slope values (this remains constant as S*A = 500 kHz/V always).
• Clearly lower actuation slope decreased the noise due to Marconi significantly. So we would like to keep drift of beat note frequency of cavities as low as possible.
• One alarming concern is the presence of a sharp peak in Marconi noise at ~900 Hz. This will mix with low-frequency noise of incoming beat note frequency and would create humps near kHz region.
• We need to figure out why this peak is there in the Marconi noise spectrum and what we can do to take it off.
• Possible candidates: Spurious cross-coupling with something else, reflections between the mixer and low pass filter in PLL due to impedance mismatch, inherent peak in SR560??
Attachment 1: MarconiPLLNoiseAnalysis.pdf
Attachment 2: Marconi_PLL_Noise.zip
2287   Mon Jan 21 19:01:11 2019 anchalNotesPLLPLL Transfer Function and Noise Study

I see that we were lacking in complete documentation of PLL transfer function and noise analysis. I made this document for the same.

https://git.ligo.org/cit-ctnlab/ctn_noisebudget/blob/master/technicalNotes/Beatnote_PLL_Loop_Study.pdf

Edit Fri May 17 14:02:14 2019:

Above link is no longer maintained. Now there is a DCC doc (see LIGO-T1900263) for this analysis.

2288   Tue Jan 22 19:04:51 2019 anchalDailyProgressPLLNew Focus 1811-FC Dark noise Measurement

We suspected if the wideband RF detector New Focus 1811-FC could be the source of noise floor through its dark noise. So I took dark noise spectrum measurements today of this photodetector.

### Method:

• I blocked the photodetector with a beam dump.
• First I took the spectrum directly from the RF port using HP 4395A in spectrum analyzer mode, from 0 to 130 MHz with 3kHz ResBW and 50 averages.
• I converted dBm to V_rms using 10**((P_dbm-13)/20) and then divided by np.sqrt(3e3) to get spectrum in Vrms/rtHz.
• Next, I measured the dark noise spectrum by mixing it down with a local oscillator using the same ZX05-1MHW mixer we use in the PLL.
• First I used the Wenzel crystal oscillator at 24.483 MHz as LO.
• Then I used Marconi at the same frequency for comparison.
• I also took mixed down measurements for 27.34 MHz(Resonant RFPD peak point), 50MHz, 75 MHz, 100MHz and 125MHz.
• All these later measurements were taken by SR785 from 0 to 102.4 kHz (in 3 steps) with rms averaging of 100 factor and BMH windowing.

### Conclusions:

• Contrary to our expectation, mixed down dark noise is more than the direct dark noise from RF port. The mixer should have same conversion loss for dark noise and should also be suppressing one quadrature, so the output from the mixer should be less noisy.
• I think I have missed something in these measurements. It looks too bad to be true. In past, we have been running beat note measurements with S*A (Actuator Slop x Amplifier gain) of 200-500 kHz. With the measured noise after mixing down, it would correspond to 0.6 - 1.5 Hz/rtHz.
• We do have a noise floor around these values but we also have measurements going below 1 Hz/rtHz, so something seems fishy.
• At the time of writing this post, we quickly did a dark noise measurement with the resonant RFPD at 27.34 MHz with Marconi and its dark noise after mixing down is around 12 nV/Hz. Much much better!

Edit Tue Jan 22 20:06:00 2019

## Correction:

• When we measured resonant RFPD, measurements made more sense. The direct noise from RF port was higher and the noise after mixing down was lower by conversion loss and factor of sqrt(2) due to the suppression of one quadrature.
• So we decided to measure the wideband RFPD again. To our surprise, this time the measurements made sense. PFA the new plots with new measurements.
• The mystery is still on for what caused the measurements to be bad earlier. We can not find anything that we changed except for switching RFPDs back and forth.
• So from new measurements, it seems like mixed down dark noise is at the level of 100 nV/rtHz. It is higher at other frequencies mostly because of Marconi's inherent noise. We should trust the result with crystal oscillator (black curve) more.
• This would correspond to 50 mHz/rtHz of flat noise contribution from the dark noise. This is way below the measured noise floor in our beat note spectrums. So phot detector dark noise is off the hook (for now).
• We need to continue our search for the culprit.
Attachment 1: NewFocus1811-FC_DarkNoiseSpectrum.pdf
Attachment 2: NewFocus1811-FCDarkNoiseSpectrum.ipynb.zip
Attachment 3: NewFocus1811-FC_DarkNoiseSpectrum_New.pdf
Attachment 4: NewFocus1811-FCDarkNoiseSpectrumNew.ipynb.zip
2289   Tue Jan 22 20:26:18 2019 awadeDailyProgressTempCtrlRunning relay controller overnight on refcavs

Beat note is still not under control. Its drifting at 10 kHz/min, too much for a lower range marconi measurement.

We would like to bring the frequency down from ~140 MHz  to something closer to 27.34 MHz  of Koji's resonant BN detector.  I'm going to try to use the relay auto locker feature of the PIDLocker_beta.py script again to get the BN to converge on some steady value (see PSL:2142). In the past the relay method was able to actually get a convergence to a BN value but failed to give good values as there was a thing with the cycle limit converging to zero in the case of these really slow BN thermal controls.  I suspect this was due to a relay step that was too small, the asymmetry of the heater actuation and/or large time lag caused issues.

For now I'll leave the relay on overnight to see if we are able to get a good convergence with a relay step of 0.1 W about mean heater power of 0.77320 W and common power offset of 0.48710 W.  The setpoint was left at 100 MHz, we will step it down to the 27.43 MHz gradually so as not to overshoot the BN past 0 Hz and flip the direction of the frequency.

The service running the PIDLocker_beta.py script for the cavity slow heater controls was stopped and was then manually restarted in a tmux session on ws1 using the following command:

> python PIDLocker_beta.py PIDConfig_CAVHeater.ini --autotune -d 0.1 -o 0.7732 -t 86400 -e

This should run the relay mode of the auto locker for 24 hours (86400 s) about a mean of 0.7732 W and a relay step of 0.1 W (bigger than in previous tests).  We'll see how it goes and reassess tomorrow morning.

2290   Wed Jan 23 11:28:53 2019 awadeDailyProgressTempCtrlCorrecting BN after running relay controller overnight on refcavs

This test relay test was a failure.  I got impatient late last night and downed the midpoint diff heating to 0.5732 W.  There wasn't enough range on the upper side of the relay switch and BN flew past the 100 MHz setpoint and was around -400 MHz about 8:30 am this morning.

I did a bit of manual tuning driving the diff heater slider hard to 0.9732 W (common heater 0.48710 W) and then breaking the BN swing driving the opposite direction with diff heater of 0.4732 W for about 30 min.  I'm now at about diff 0.73320 W and the BN is beginning to settle about 80 MHz on the other side of the BN 0 Hz crossing point. I think right now we should let it passively settle again so we can get another VCO=10 kHz/V BN measurement to see if recently reduced noise of NF1811 makes a difference (see PSL:2288).

 Quote: Beat note is still not under control. Its drifting at 10 kHz/min, too much for a lower range marconi measurement. We would like to bring the frequency down from ~140 MHz  to something closer to 27.34 MHz  of Koji's resonant BN detector.  I'm going to try to use the relay auto locker feature of the PIDLocker_beta.py script again to get the BN to converge on some steady value (see PSL:2142). In the past the relay method was able to actually get a convergence to a BN value but failed to give good values as there was a thing with the cycle limit converging to zero in the case of these really slow BN thermal controls.  I suspect this was due to a relay step that was too small, the asymmetry of the heater actuation and/or large time lag caused issues. For now I'll leave the relay on overnight to see if we are able to get a good convergence with a relay step of 0.1 W about mean heater power of 0.77320 W and common power offset of 0.48710 W.  The setpoint was left at 100 MHz, we will step it down to the 27.43 MHz gradually so as not to overshoot the BN past 0 Hz and flip the direction of the frequency. The service running the PIDLocker_beta.py script for the cavity slow heater controls was stopped and was then manually restarted in a tmux session on ws1 using the following command: > python PIDLocker_beta.py PIDConfig_CAVHeater.ini --autotune -d 0.1 -o 0.7732 -t 86400 -e This should run the relay mode of the auto locker for 24 hours (86400 s) about a mean of 0.7732 W and a relay step of 0.1 W (bigger than in previous tests).  We'll see how it goes and reassess tomorrow morning.

2291   Wed Jan 23 11:43:02 2019 awade, anchalDailyProgressPLLNew Focus 1811-FC Dark noise Measurement

The first measurement here seems like a smoking gun for limiting noise.  A mixer down converted noise of 1.3 µV/rtHz (directly out of the mixer) with a S*A (VCO + SR560) gain of 200 kHz/V would be 0.26 Hz/rtHz. That would be consistent with the noise floor of the more recent BN PSDs. The PLL open loop gain will change this estimate, but the 200 kHz/V gives a lower bound. This initial measurement of NF1811 noise was a factor of ten more than spec for this detector. It should be ~100 nV/rtHz (equivalent to input ref noise of 2.5 pW/rtHz at peak responsively).  We should have traced back to the source of this earlier, but now that we know its a potential problem we should double check if we're having issues with BN noise floor not matching up with the noise budget.

Its weird that the second measurement of the same NF1811 seems to show it performing closer to its spec value. The setup for measurment was exactly the same.  I should note that when we were making these measurements we switched the BN cable from the NF1811 to the resonant 27.34 MHz detector and back again.  I also wiggled the power cable at the time. I've seen in the past that when there is a power connector issue, the NF1811 can produce something that looks like signal but with RF oscillations if there is a problem with one of the power rails.  We probably should have checked at the time with an oscilloscope to see if there were any issues with the RF signal coming out of the NF1811.  It could be that there was some kind of oscillation or other bad thing going on and the act of unloading and reloading the output with 50 Ω and wiggling the power connector some how got it back to proper operation.

For now we should should recheck the NF1811 dark noise (after mixing down) before making another BN measurement and not touch connectors on the detector side in case there is a flaky connection.

You definitely​ saw the higher noise state, so I wouldn't dismiss it yet. I guess we won't know if the reduced noise second measurement will bring down out noise floor until we see a BN measurement.

Quote:

We suspected if the wideband RF detector New Focus 1811-FC could be the source of noise floor through its dark noise. So I took dark noise spectrum measurements today of this photodetector.

### Method:

• I blocked the photodetector with a beam dump.
• First I took the spectrum directly from the RF port using HP 4395A in spectrum analyzer mode, from 0 to 130 MHz with 3kHz ResBW and 50 averages.
• I converted dBm to V_rms using 10**((P_dbm-13)/20) and then divided by np.sqrt(3e3) to get spectrum in Vrms/rtHz.
• Next, I measured the dark noise spectrum by mixing it down with a local oscillator using the same ZX05-1MHW mixer we use in the PLL.
• First I used the Wenzel crystal oscillator at 24.483 MHz as LO.
• Then I used Marconi at the same frequency for comparison.
• I also took mixed down measurements for 27.34 MHz(Resonant RFPD peak point), 50MHz, 75 MHz, 100MHz and 125MHz.
• All these later measurements were taken by SR785 from 0 to 102.4 kHz (in 3 steps) with rms averaging of 100 factor and BMH windowing.

### Conclusions:

• Contrary to our expectation, mixed down dark noise is more than the direct dark noise from RF port. The mixer should have same conversion loss for dark noise and should also be suppressing one quadrature, so the output from the mixer should be less noisy.
• I think I have missed something in these measurements. It looks too bad to be true. In past, we have been running beat note measurements with S*A (Actuator Slop x Amplifier gain) of 200-500 kHz. With the measured noise after mixing down, it would correspond to 0.6 - 1.5 Hz/rtHz.
• We do have a noise floor around these values but we also have measurements going below 1 Hz/rtHz, so something seems fishy.
• At the time of writing this post, we quickly did a dark noise measurement with the resonant RFPD at 27.34 MHz with Marconi and its dark noise after mixing down is around 12 nV/Hz. Much much better!

Edit Tue Jan 22 20:06:00 2019

## Correction:

• When we measured resonant RFPD, measurements made more sense. The direct noise from RF port was higher and the noise after mixing down was lower by conversion loss and factor of sqrt(2) due to the suppression of one quadrature.
• So we decided to measure the wideband RFPD again. To our surprise, this time the measurements made sense. PFA the new plots with new measurements.
• The mystery is still on for what caused the measurements to be bad earlier. We can not find anything that we changed except for switching RFPDs back and forth.
• So from new measurements, it seems like mixed down dark noise is at the level of 100 nV/rtHz. It is higher at other frequencies mostly because of Marconi's inherent noise. We should trust the result with crystal oscillator (black curve) more.
• This would correspond to 50 mHz/rtHz of flat noise contribution from the dark noise. This is way below the measured noise floor in our beat note spectrums. So phot detector dark noise is off the hook (for now).
• We need to continue our search for the culprit.

2292   Wed Jan 23 18:13:48 2019 anchal and awadeDailyProgressFSSFSS Gain and Offset tuning

Today we checked FSS Common path and Fast path transfer functions to see unity gain frequencies and any possible optimizations.

### North Path:

• With new photo detector at 36 MHz in, we found that we are able to maximize the common gain setting the voltage control to +10V giving us ~160 kHz unity gain frequency. This was around 30 kHz before.
• For the fast path, I set the gain voltage control to 1V to keep unity gain frequency around 7-9 kHz.
• I tuned the offset to bring DC offset at OUT1 of common path to zero using a multimeter.
• RMS error of the mixer channel (just at the output of common gain stage) is found to be ~12 mV (averaged for 10s with an oscilloscope)

### South Path:

• Here, we found that the FSS loop was completely screwed up. The error signal wasn't high enough and the transfer function had a weird drop between 3kH to 6kHz.
• I optimized input polarization to the EOM and faraday isolator again and optimized the phase delay cable by adding a short cable as well.
• I still couldn't manage to get PDH error signal peak to peak more than ~180 mV. With about 1.1 mW light coming to the photo detector which has transimpedance of ~1.5 kOhm, this would be just 0.07 rad of modulation depth.
• I checked RF monitor port of the EOM driver which had a signal strength of -4.5 dBm. If we use 155 coupling factor as mentioned in DCC document, this corresponds to ~38.5 dBm power going into EOM and it requires 36 dBm only for 0.3 rad modulation depth.
• So something is not right in our calculation and/or EOM phase modulation happening.
• However, after doing these optimizations, I was able to get a good transfer function at the common gain stage and was able to maximize common gain setting the voltage control to 10V giving us ~ 77 kHz of unity gain frequency.
• For the fast path, I was unable to get a good transfer function due to poor signal to noise ratio.
• I tuned the offset to bring DC offset at OUT1 of common path to zero using a multimeter.
• RMS error of the mixer channel for this path is surprisingly lower than North path, at around 6 mV (averaged over 10s with an oscilloscope).

I have switched off auto gain and offset tuner services. I'll start a beat note measurement today to see if our changes in FSS loop and reattaching wideband photo detector changed anything.

2293   Thu Jan 24 12:38:47 2019 anchalDailyProgressNoiseBudgetBeat Note Noise Spectrum after tuning FSS Loop

## PLL Readout Noise and Open-Loop Transfer Function:

• I remeasured dark noise of wideband photodetector after mixing down with mixer when beat note frequency was around 46.985 MHz.
• The detector was behaving nicely with effective noise contribution to beat note spectrum of less than $40 mHz/\sqrt{Hz}$ .
• The noise spectrum is almost flat above 100 Hz with a mean value of $36.24 mHz/\sqrt{Hz}$ between 100 Hz and 10 kHz.
• I also remeasured PLL's open loop transfer function. It turned as a nice 1/f curve with unity gain frequency of 28.75 kHz.

## Beat Note Frequency Noise Spectrum

I used the same measurement method as explained in (PSL:2272). Changes in the setup from before:

• FSS loops were tuned up. See (PSL:2292).
• During measurement of New FOcus 1811-FC wideband RF detector Dark Noise, we found that after disconnecting and connecting back the RF port, we found a significant decrease in dark noise. See (PSL:2288).
• In the noise budget notebook, I have updated the PLL Oscillation Noise (coming from Marconi) and PLL Readout Noise (coming from detector dark noise) as measured this week.

### Conclusions:

• Good news first, we got rid of roll up near high frequencies and are now close to Nov 2017 spectrum.
• There are some disturbing bumps at 150-160 Hz, 300 Hz, 800 Hz and 900 Hz. I think these would be our new points of attack.
• I do think that higher noise <100 Hz is due to the way we are taking measurements. Our spectrum is just 16 Hz linewidth throughout the range and due to the marconi jumping points, the lower frequencies are wordt affected.
• I think we should do some correlation mesurements to search the sources of above mentioned noise bumps.
• There is also a new noise floor of roughly $100 mHz/\sqrt{Hz}$ to push against.

Edit Tue Aug 13 17:08:46 2019 anchal:

The PLL Readout noise added on this plot was erroneous and I can't find where it came from either. So the noisebudget attached is wrong! I was a dumbo then.

Attachment 1: PLLDarkNoiseandOLTF_Jan23_2019.pdf
Attachment 2: BeatNoteJan24_2019_Iris.zip
Attachment 3: 20190125_150848noiseBudget.pdf
2294   Thu Jan 24 14:24:10 2019 awadeDailyProgressTempCtrlCustom implementation of PIDLocker script for finer control of intergration on cav heaters

Probably a lot of our problems of the PID tuning of the cavity temperature controls (for controlling BN freq) come back back to our P, I and D constants being too course. This is a hangover from earlier implementations of this script where the precision of the constants was set by limits on the EPICS channels max significant figures.

We no longer use the finite difference approximation for our discreet digital PID controller and are free to use a lot more precision on the accumulated integrator values.

I've made a modified version of the PIDLocker_beta.py script that divides the value of the P, I and D slider values by 1000 before doing all the usual operations to compute the actuation value. Here the integrator variable in the python script holds the previous loops value over and adds the error on every loop cycle at maximum precision allowed by numpy.  The value of the actuation is then only rounded to 5 SF at the very last step.

To assist further with fine control of the heating I also changed the way the process variable is rounded before writing out to EPICS.  The current operation in PIDLocker_beta.py (see PSL:2142) is to round up based on the lowest digit so 0.770465 -> 0.77047 and 0.770463 -> 0.77046.  A better way is to do probabilistic rounding. If the last digit to be rounded off is 3 then there is a 30% probability of rounding up and 70 % probability of rounding down.  Its a kind of poor man's oversampling.  It allows us to get intermediate bits between ADC levels.

The script is a hacked version of PIDLocker_beta.py and is called PIDLocker_cavcontrol.py located in the ~/Git/cit_ctnlab/ctn_scripts dir.  I've attached a copy (zipped) below and have committed into the git.  During testing the script is running on a tmux session on ws1 using:

> python PIDLocker_cavcontrol.py PIDConfig_CAVHeater.ini

We only need a gentle push from the integrator to hold the BN in place and before it was overkill. Hopefully by lowering the gain on the 'I' term the 1/f component of the PID will not exceed the corner frequency of the cavity+heater system and stop the instabilities that we were seeing to this point.

For reference the probabilistic​ rounding code is given below:

def truncFloat(x,dp):     '''Truncates a numpy float to given decimal places (dp)'''     return np.trunc(x * 10 ** dp) / 10 ** dp

def probRound(x, dp):     '''Rounds float to given decimal places (dp), with        last digit round done on a probabilistic basis.'''          xTrunc = truncFloat(x, dp)  # Truncate to dp figures     xrem = x - xTrunc  # find remainder of truncation          p = np.abs(xrem) * 10 ** dd  # prob of rounding up based on trunc remainder     if np.random.uniform(0,1) < p:         xout = xTrunc + np.sign(x) * 10 ** -dd     else:         xout = xTrunc     return xout

 Quote: This test relay test was a failure.  I got impatient late last night and downed the midpoint diff heating to 0.5732 W.  There wasn't enough range on the upper side of the relay switch and BN flew past the 100 MHz setpoint and was around -400 MHz about 8:30 am this morning.  I did a bit of manual tuning driving the diff heater slider hard to 0.9732 W (common heater 0.48710 W) and then breaking the BN swing driving the opposite direction with diff heater of 0.4732 W for about 30 min.  I'm now at about diff 0.73320 W and the BN is beginning to settle about 80 MHz on the other side of the BN 0 Hz crossing point. I think right now we should let it passively settle again so we can get another VCO=10 kHz/V BN measurement to see if recently reduced noise of NF1811 makes a difference (see PSL:2288).

Attachment 1: PIDLocker_cavcontrol.py.zip
2295   Fri Jan 25 10:46:24 2019 awadeDailyProgressTempCtrlPID locking of cavity heaters to BN

Testing of this seems to confirm that lower intergrator values are the way to go.  We had excellent locking with <1.2 kHz/min for a period of about 12 hours.  This is almost good enought to move down to 500 Hz/V VCO slope with some averaging.

Settings were P=0.0015, I=0.000050, D=0.0.  The heater diff value hovers around 0.68 W for a setpoint of 69.2 MHz.

## Glitches and BN sign

Bad news is we had a glitch that spiked the pre-cavity BN detector frequency at about 5:07 am this morning.  This spiked the intergrator value and drove the heater value up for about 30 min before the BN crossed the 0 Hz point.  There wasn't enough time for the intergrator to wind back down the sign change of the BN frequency ment that the loop then just drove away from the setpoint eventually railing at 1.1 W diff heating.

This will be more a problem down at the 27 MHz point that we want to lock to. As the set point is so close to the BN flip across 0 Hz any disturbance can drive our loop into this runaway state. Its not clear how we reject these glitches or reliably sense the flip across 0 Hz.  Filtering pre-cav BN for glitches seems bad as it will introduce poles that then affect the loop.  Trying to sense a change in BN slope (I think anchal implemented this?) will be hard if the slope is very shallow as it crosses, this will give confusion about the sign if the noise dominates over the derivative value.

Machine learning would be helpful here maybe.  If you include information about the laser slow frequency controls (for both lasers) its really obvious when the direction of the BN evolution is inconsistent with frequency direction of the laser evolution for both cavities.

For now I am going to narrow the hard stops on the PID script.  This should prevent the loop from railing hard and taking hours to recover.  It seems that without a drastic change in the environment temperature we will never need more than 0.1 W of movement either side for the actuator center point.  I'll set the limits to [0.65, 0.75] W for now, this should be enough to gently hold the BN in the 0- 100 MHz range and will prevent hard railing way out of range.

Attachment 1: PID_locking_GlitchAndRunAway_2019-01-25_at_10.50.19_AM.png
2296   Fri Jan 25 15:45:48 2019 anchalDailyProgressTempCtrlPID locking of cavity heaters to BN

About BN slope detector: I just made few extra EPICS channels to do this. But acromag1 hasn't rebooted since for testing if it works. However, since the pre-cavity beat note frequency counter fails to update values sporadically, there would be glitches in this slope readout as well. Another way is to do this in python keeping track of past few pre-cavity beat note frequency recordings.

About BN sign checker: I was working on this more like a side hobby project so far. I had successfully implemented it before when I was trying that semi-smart temperature control. I'll take a look again at BNFreqSignUpdate.py which needs to be run in a tmux session for this to work.

 This will be more a problem down at the 27 MHz point that we want to lock to. As the set point is so close to the BN flip across 0 Hz any disturbance can drive our loop into this runaway state. Its not clear how we reject these glitches or reliably sense the flip across 0 Hz.  Filtering pre-cav BN for glitches seems bad as it will introduce poles that then affect the loop.  Trying to sense a change in BN slope (I think anchal implemented this?) will be hard if the slope is very shallow as it crosses, this will give confusion about the sign if the noise dominates over the derivative value.

2297   Mon Jan 28 10:56:49 2019 awade and anchalDailyProgressNoiseBudgetNoisebudget with Resonant Beat Note Photo Detector - Touching new lows

### Shot Noise of Photocurrent:

• Assuming 0.5 mW power is falling on the wideband beat note photodetector New Focus 1811-FC, with 40 kV/A of transimpedance $Z_{TI}$ and 0.75 A/W  responsivity $\mathrm{R}$ , shot noise of the photocurrent itself is:
\begin{aligned} S_V^{Shot Noise} &= (2 e P_{inc} \mathrm{R}) Z_{TI}^2 \\&= (2\times1.6\times10^{-19} C\times0.5\times10^{-3}\,W\times0.75\, \frac{A}{W})\times (40\times10^3\,\frac{V}{A})^2 \\&= 1.92\times10^{-13}\,\frac{V^2}{Hz} \end{aligned}
• Edit anchal Tue Jan 29 18:33:55 2019
This shot noise would be present as both amplitude and phase noise in the incoming BN signal. Amplitude noise affects negligible (through slight changes in open loop gain) to the PLL loop but phase noise directly affects the measured frequency noise. Effective phase noise contribution from shot noise is (here $V_{BNpkpk}$ is peak to peak amplitude of Beat Note signal):
\begin{aligned} \sqrt{S_\phi^{ShotNoise}}&=\frac{\sqrt{S_V^{ShotNoise}}}{V_{BNpkpk}}\pi\\ &= \frac{\sqrt{1.92\times10{-13}\frac{V^2}{Hz}}}{2\times0.5\times10^{-3}\,W\times0.75\frac{A}{W}\times40\times10^3\frac{V}{A}}\pi\\ &=4.589\times10^{-8}\frac{rad}{\sqrt{Hz}} \end{aligned}
• The phase noise is perceived as frequency noise as follow:
\begin{aligned} \sqrt{S_f^{ShotNoise}} &= f\sqrt{S_\phi^{ShotNoise}} \end{aligned}
• So, the noise due to shot noise of photocurrent will remain below $10 mHz/\sqrt{Hz}$ up to 217.93 kHz. So below written statements with red background were incorrect.
• This means the contribution of shot noise of photocurrent in the beat note noise ASD at amplifier gain of 200 and actuation slope of 1 kHz/V is:
\begin{aligned} \sqrt{S_{BNf}^{ShotNoise}} &= \sqrt{S_V^{ShotNoise}}\times200\,\frac{V}{V}\times 1\times10^3\frac{Hz}{V}\\ &= 87.64 \frac{mHz}{\sqrt{Hz}} \end{aligned}
• So a major portion of the noise floor recorded in Jan 24th measurement is actually due to photocurrent shot noise at the beat note detector.
• So our limiting factor is SNR of the beat note detector.

### Noise budget with Resonant BNPD:

On Friday, awade ran beat note measurement with resonant beat note photodetector to see how low we can get with improved SNR of this resonant detector. The method is the same as (PSL:2272) with 1000 measurements. The new noise budget is attached.

• Results are little better than using the wideband New Focus 1811-FC.

• Noise floor between 100-1000 Hz is about $90 mHz/\sqrt{Hz}}$ and above 1kHz it is $70 mHz/\sqrt{Hz}}$.

• The bumps at 150-160 Hz, 300 Hz, 800 Hz, and 900 Hz are still present. So their origin is something else in the experiment.

Edit Tue Aug 13 17:08:46 2019 anchal:

The PLL Readout noise added on this plot was erroneous and I can't find where it came from either. So the noisebudget attached is wrong! I was a dumbo then.

Attachment 1: BeatNoteJan25_2019_Iris.zip
Attachment 2: 20190128_105844noiseBudget.pdf
2298   Tue Jan 29 17:47:14 2019 anchalDailyProgressTempCtrlCavity Temperature Sensor Breadboard Circuit Noise Analysis

Here are the noise spectrum and time series plots that were asked of me ages ago. Apologies for the delay. I've also attached the analysis files in .zip.

### Noise Spectrum:

• I took noise spectrum by hooking the output of circuit directly into SR785.
• 100 rms averages were taken at AC coupling with BMH window.
• The RTD (I guess) was still getting into equilibrium as the DC voltage was higher after some time. So the noise spectrum includes low-frequency drift due to RTD self-heating.
• I calculated effective input referred noise of temperature sensing assuming no noise from 5V ref, no noise from instrumentation amplifier, no current source noise and no inherent temperature noise.
• So the input referred value is simply output divided by the theoretical transfer function.

### Time series data:

• I took time series data by SR785's Time1 function under FFT for 32 seconds.
• This data was taken in the end and RTD was already at equilibrium.
• While taking data, I set coupling to DC and units to Volts peak.
• Again, I calculated sensed temperature assuming all components working ideally.

Even with a breadboard circuit and different opamps (see PSL:2268 for changes), the circuit has less than $0.1\,mK/\sqrt{Hz}$ of input referred noise almost in all frequency range. The time series data also fluctuates less than $3\,mK_{pkpk}$  during 32 seconds of data, so worst case, this circuit would be precise to at least 5mK. However, since this circuit has no bypassing capacitors and high drift resistors, the PCB version should perform even better. I'll do same analysis with a stuffed PCB board soon.

 Quote: post a plot of the times series and noise spectrum Here is a link on how to choose R and C: https://dcc.ligo.org/LIGO-T070016

2299   Wed Jan 30 12:17:05 2019 ranaDailyProgressTempCtrlCavity Temperature Sensor Breadboard Circuit Noise Analysis

that's a good start, but we don't care about the noise above 10 Hz. So you should re-take the data and plot from 1 mHz to 10 Hz. Instead of using SR785, just record the time series on a cymac somewhere. You can run a cable into Gabriele's lab if you have to.

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
• change R21 (in D040105-C ) from 10 kΩ to something a little higher (20 kΩ would give us +3 dB)
• change the C23 + R22 combination to something with a larger capacitance and smaller resistance (i.e. 330 nF + 110 Ω)
• do same/similar as above with C24+ R24
• raise the value of R4 in the common path by factor of 10?, here we need to careful that its not going to saturate the subsequent stages

2303   Tue Feb 5 11:40:02 2019 awadeHowToFSSModifying South FSS boost

## Shortening the capacitor leads on U7 boost

I checked the boost stage on U7 of LIGO-D040105-C on the south path box (37 MHz).  It appears that Craig had changed its value to 6.8 nF to match the North path.

The resistor was actually 5.088 kΩ, instead of 5.6 kΩ as listed. The resistor was changed from the radial thick film (5.088 kΩ) to a thin film surface mount type (5.6 kΩ). I moved the capacitor from the switch (at the end of the wires) to immediately at the board. The switch on the side of the box now only has two wires to short the capacitor when we want to disable boost. This should mean that there is an integrator with a pole at DC and a zero at 4.2 kHz and won't have any funny feedback impedance due to long wires and switch. This now matches the North path.

## Adding gain to RF PD

Anchal is going to figure out how to increase gain of south FSS RFPD from ~1.5 kΩ to 2.5 kΩ of the north path.  In the meantime I've added a mini circuits low noise amplifier to the output of the RFPD. This has a noise figure of about 3 dB and a gain of +24 dB.  I put a 20 dB attenuator after the amplifier.  I think the extra gain stage will only add a few mHz/rtHz to the input referred noise, so should be fine for now.  Once Anchal has solved the crossover TF optimization he'll have time to fix this.

2304   Tue Feb 5 20:39:52 2019 anchalSummaryFSSComplete model of TTFSS box with TF and crossover analysis

I'm attaching the first results of the transfer function from liso model of complete TTFSS box. I've also attached the jupyter notebook with some important formulas used.

Both files are present in git/cit_ctnlab/ctn_electronics/TTFSS_lisomodel/ git repo.

I'm just posting results for the analysis I did so far. I'll be able to make better inferences with some more work I intend to do tomorrow.

Edit: Wed Feb 6 16:59:59 2019

The updated plot is at git. Added analysis of variation of crossover frequency and phase margin with changing Fast gain.

Attachment 1: FSS_Modified_Analysis.pdf
Attachment 2: FSS_Mod_Analysis.zip
2305   Wed Feb 6 19:13:06 2019 anchalSummaryFSSComplete model of TTFSS box with TF and crossover analysis

I added some more graphs to our FSS analysis.

• I modeled AD602 variable gain amplifier with a circuit similar to how it actually works internally. The resultant circuit now has a right input resistance of 100 Ohm and capacitance of 2 pF. It is slightly noisier than AD602.
• I calculated the total suppression function and suppressed laser frequency noise.
• I did a parametric analysis by varying the PZT gain and obtained a range of cross over frequencies and phase margin we can attain.
• Everything looked awesome so far, but the real problem is EOM railing.
• So I calculated that if the said suppression is achieved, what is the actuation signal that is sent to EOM.
• The last plot is the spectral density of this actuation signal. Since $V_{\pi}=209.44\, V$only, we clearly are going to rail the EOM and the said suppression will never actually happen.
• We need to shift actuation region of EOM to even higher frequencies so that it doesn't rail. But at the same time, we need to keep the crossover frequency and phase margin of crossover decent. And to top it off, we need to do all this making sure we get at least $10^5$ suppression at 100 Hz.
• So from here, I guess we need to work on shifting the poles and zeros and tune in the gain values right to get point.
• I'm not 100% sure about this analysis, please let me know if I am doing something wrong here. The latest notebook and pdf are on git.
 Quote: I'm attaching the first results of the transfer function from liso model of complete TTFSS box. I've also attached the jupyter notebook with some important formulas used. Both files are present in git/cit_ctnlab/ctn_electronics/TTFSS_lisomodel/ git repo. I'm just posting results for the analysis I did so far. I'll be able to make better inferences with some more work I intend to do tomorrow. Edit: Wed Feb 6 16:59:59 2019 The updated plot is at git. Added analysis of variation of crossover frequency and phase margin with changing Fast gain.

Edit Thu Feb 7 11:32:13 2019 :

Last plot in the attachment is wrong. See following discussion in PSL:2306 and PSL:2307

Attachment 1: FSS_Modified_Analysis.pdf
2306   Wed Feb 6 21:30:24 2019 awadeSummaryFSSComplete model of TTFSS box with TF and crossover analysis

Hmm... Last estimate of V_rms applied to EOM can't be true.

If laser frequency noise is

$\dpi{100} S^\textrm{Laser}_f (f)= \frac{1 \textrm{Hz}}{f} \times 10^4 \quad [\textrm{Hz}/\sqrt{\textrm{Hz}}]$

Total frequency noise down to 1 kHz should then be 316 Hz_rms. As you've noted in your jupyter notebook the EOM frequency domain response to actuation signal goes as f, i.e.

$\dpi{100} \delta f(t) = \frac{1}{2\pi}\frac{d \Delta\phi}{dt} = \frac{m_s}{2\pi} \frac{d V_{EOM}}{dt}$

where ms is EOM phase slope (15 mrad/V) and V_EOM is the applied actuation voltage. As you wrote, that leads to

$\dpi{100} \delta \tilde f(f) = \frac{m_s}{2\pi} (-i 2 \pi f) \tilde V_{EOM}(f) = -i m_s f\tilde V_\textrm{EOM}(f) \quad [\textrm{Hz}/\textrm{V}]$

If we assume that the EOM is taking 100% of the load for canceling laser frequency noise at a given frequency then it follows that the applied voltage to exactly cancel laser frequency noise is

$\dpi{100} \delta \tilde V_\textrm{EOM}(f) = \frac{S^\textrm{Laser}_f (f)}{\delta \tilde f(f)} = i \frac{10^4}{m_s} \frac{1}{f^2}\quad [\textrm{V}/\sqrt{\textrm{Hz}}]$

This would indicate that the burden on the EOM becomes 1/f heavier in frequency because of the laser noise roll up and 1/f heaver because the EOM responds as f to signals in the Fourier domain.  The above puts an upper bound on the ASD curve of load that the EOM is absorbing to cancel laser frequency noise.

Integrating the above V_EOM PSD down from high frequency will give the total V_rms load that the loop would need to apply to suppress laser frequency noise:

$\dpi{100} V_\textrm{rms}(f) = \sqrt{\int^\infty_f (\frac{10^4}{m_s} \frac{1}{f^2})^2 \textrm df} \quad [\textrm{V}_\textrm{rms}]$

or

$\dpi{100} V_\textrm{rms}(f) = \frac{10^4}{m_s}\frac{1}{f^{3/2}} \quad [\textrm{V}_\textrm{rms}]$

I've plotted this below and attached the notebook used for the calculation.  It kind of looks like the maximum load at 1 kHz hits about 200 Vrms.  Maybe I've gotten some factors wrong here but you can sort of see the scaling of how the maximum load on the EOM will look.

One thing to note is that the above estimates are an upper bound assuming that the EOM is taking all of the load down to that frequency point and that the PZT path isn't fighting or out of phase with EOM.  To correctly compute the load on the EOM you are going to have to break down the EOM only portion of the loop from the laser frequency to the point of voltage injected into the EOM.  This can be done by effectively nesting the PZT loop into the round trip gain in a way similar to that described in Josh Smith's Thesis section 2.6.2.  Finding the actuation signal should be similar to finding the PLL actuation signal, at this point in the loop it is the G/(1-G)/A copy of the sensor noise.  In the high gain regime the applied EOM control signal should just be the laser frequency  divided by the EOM frequency slope. Of course you can compute for G_EOM OLG to get a true value with a bunch of algebra.

Quote:

I added some more graphs to our FSS analysis.

• I modeled AD602 variable gain amplifier with a circuit similar to how it actually works internally. The resultant circuit now has a right input resistance of 100 Ohm and capacitance of 2 pF. It is slightly noisier than AD602.
• I calculated the total suppression function and suppressed laser frequency noise.
• I did a parametric analysis by varying the PZT gain and obtained a range of cross over frequencies and phase margin we can attain.
• Everything looked awesome so far, but the real problem is EOM railing.
• So I calculated that if the said suppression is achieved, what is the actuation signal that is sent to EOM.
• The last plot is the spectral density of this actuation signal. Since $V_{\pi}=209.44\, V$only, we clearly are going to rail the EOM and the said suppression will never actually happen.
• We need to shift actuation region of EOM to even higher frequencies so that it doesn't rail. But at the same time, we need to keep the crossover frequency and phase margin of crossover decent. And to top it off, we need to do all this making sure we get at least $10^5$ suppression at 100 Hz.
• So from here, I guess we need to work on shifting the poles and zeros and tune in the gain values right to get point.
• I'm not 100% sure about this analysis, please let me know if I am doing something wrong here. The latest notebook and pdf are on git.
 Quote: I'm attaching the first results of the transfer function from liso model of complete TTFSS box. I've also attached the jupyter notebook with some important formulas used. Both files are present in git/cit_ctnlab/ctn_electronics/TTFSS_lisomodel/ git repo. I'm just posting results for the analysis I did so far. I'll be able to make better inferences with some more work I intend to do tomorrow. Edit: Wed Feb 6 16:59:59 2019 The updated plot is at git. Added analysis of variation of crossover frequency and phase margin with changing Fast gain.

Attachment 1: EOM_Vrms_FunctionOfLowerFrequencyBoundOfTF.pdf
Attachment 2: TTFSS_lisomodel_FSS_Mod_Analysis.ipynb.zip
2307   Thu Feb 7 10:33:27 2019 anchalSummaryFSSComplete model of TTFSS box with TF and crossover analysis
 Quote: where ms is EOM phase slope (15 mrad/V) and V_EOM is the applied actuation voltage. As you wrote, that leads to $\dpi{100} \delta \tilde f(f) = \frac{m_s}{2\pi} (-i 2 \pi f) \tilde V_{EOM}(f) = -i m_s f\tilde V_\textrm{EOM}(f) \quad [\textrm{Hz}/\textrm{V}]$

This actually has units of Hz/Hz. Note, that $\delta \tilde{f}(f)$ is just Fourier transform of frequency actuation, so it is unitless. I used this to get the transfer function of EOM actuation, from applied signal in V to resulting actuation in Hz, which is the prefactor of $-\iota m_s f$ above having units of Hz/V.

 Quote: If we assume that the EOM is taking 100% of the load for canceling laser frequency noise at a given frequency then it follows that the applied voltage to exactly cancel laser frequency noise is  $\dpi{100} \delta \tilde V_\textrm{EOM}(f) = \frac{S^\textrm{Laser}_f (f)}{\delta \tilde f(f)} = i \frac{10^4}{m_s} \frac{1}{f^2}\quad [\textrm{V}/\sqrt{\textrm{Hz}}]$

So, if EOM is taking the whole load of frequency noise, actuation signal ASD would be:

$\delta \tilde{V_{EOM}}(f) = \frac{TF_{EOMpath}}{-\iota m_s f} S_f^{laser}(f) \quad \left[ V/\sqrt{Hz} \right]$

But obviously, this is wrong because this just assume that we are not feeding back the actuation signal at all. So instead, I assumed that if everything is 'ideally' working and we actually have the frequency noise suppressed by a teamwork of PZT and EOM, the incoming noise signal to EOM path's transfer function is:

$\frac{1}{1+TF_{PZTpath}(f) + TF_{EOMpath}(f)} S_f^{laser}\quad \left[ Hz/\sqrt{Hz}\right]$

So, the actuation signal generated for EOM by EOM path's transfer function in an ideally working loop is:

$\delta\tilde{V_{EOM}}(f )=\frac{TF_{EOMpath}(f)}{-\iota m_sf}\frac{1}{1-TF_{PZTpath}(f) - TF_{EOMpath}(f)} S_f^{laser}\quad \left[ V/\sqrt{Hz}\right]$

The error in the last plot in PSL:2305. is that I forgot to divide by $-\iota m_sf$ since transfer functions in the code are from Hz to Hz. So I think this is the real error.

 Quote: One thing to note is that the above estimates are an upper bound assuming that the EOM is taking all of the load down to that frequency point and that the PZT path isn't fighting or out of phase with EOM.  To correctly compute the load on the EOM you are going to have to break down the EOM only portion of the loop from the laser frequency to the point of voltage injected into the EOM.  This can be done by effectively nesting the PZT loop into the round trip gain in a way similar to that described in Josh Smith's Thesis section 2.6.2.  Finding the actuation signal should be similar to finding the PLL actuation signal, at this point in the loop it is the G/(1-G)/A copy of the sensor noise.  In the high gain regime the applied EOM control signal should just be the laser frequency  divided by the EOM frequency slope. Of course you can compute for G_EOM OLG to get a true value with a bunch of algebra.

But on reading section 2.6.2 of Josh Smith's Thesis (which btw has a typo in Eq. 2.33 and 2.34), I did the thing of nesting the PZT path with the plant. So as per Eq. 2.31:

$TF'_{PZTpath,roundtrip} = \frac{1}{1 - TF_{PZTpath}(f)}$

is the transfer fucntion of Plant for the simplified loop with just EOM as the actuator. Then the actuation signal ASD would be (note $S_f^{laser}(f)$ is free running laser frequency noise ASD):

$\delta \tilde{V_{EOM}}(f) = \frac{TF_{EOMpth}(f)}{-\iota m_s f}\frac{TF'_{PZTpath,rountrip}(f)}{1-TF'_{PZTpath,rountrip}(f)TF_{EOMpath}(f)}S_f^{laser}(f)$

which turns out to:

$\delta \tilde{V_{EOM}}(f) = \frac{TF_{EOMpth}(f)}{-\iota m_s f}\frac{1}{1-TF_{PZTpath}(f)-TF_{EOMpath}(f)}S_f^{laser}(f)$

Which is exactly the same as above. But still my model has this error. I'll fix it and post it soon. For readers in the future, the last set of equations are the only correct equations to the best of my knowledge.

2308   Tue Feb 26 02:45:20 2019 anchalNotesComputersMigrating epics channels from acromag1 to c3iocserver

We have been thinking for a while to migrate all epics channels from acromag1 (10.0.1.33) to c3iocserver (10.0.1.36) which is rack mount with the latest supported ubuntu Debian.

Unfortunately, my first attempt failed and I tried to put everything back to the status quo but the docker instance on iocserver which was running PMC interface is not working. Here are the steps I took:

• I created a modified acromag.cmd file to be used in ioc4server with docker. The file is attached. All the running acromag cards and their db file addresses were added in this single file.
• I copied all the relevant db files to /home/modbus/db/ in the iocserver computer.
• I stopped the running docket container with NPMC and SPMC interface channels. I stopped AcromagBoot service on acromag1 and removed it from /etc/init/ (preserving the copy).
• I rebooted acromag1 for a clean start. No channels were running at this point.
• Then at iocserver, I ran:
sudo docker run -dt --name AcromagChannels -v :/home/controls/modbus/acromag.cmd -v  :/home/modbus/db -p 5064:5064 -p 5065:5065 -p 5064:5064/udp -p 5065:5065/udp andrewwade/modbusepicsdocker
• This started a docker container but I couldn't see any channel from acromag1 using caget. So either the channels are not broadcasted properly or the modbus command file is not running properly.
• So, to go back to previous state, I stopped and removed container AcromagChannels and ran the previous IOCStart.cmd file with:
sudo docker run -dt --name AcromagPMC -v :/home/controls/modbus/IOCStart.cmd -v  :/home/modbus/db -p 5064:5064 -p 5065:5065 -p 5064:5064/udp -p 5065:5065/udp andrewwade/modbusepicsdocker
• I put back the AcromagBoot.conf file in acromag1's /etc/init and rebooted acromag1 again.
• This brought back all the channels hosted by acromag1 but not the PMC interface channels from iocserver. So there is definitely some problem with the way I ran docker.

I couldn't debug remotely further for the cause of this problem. So the status is worse than I started. The PMC channels are not running and hence everything must be unlocked in the lab right now.

Edit Mon Mar 11 18:38:03 2019 (awade): crossed out Ubuntu added Debian

Attachment 1: acromag.cmd
dbLoadDatabase("\$(EPICS_ROOT)/modules/modbus/dbd/modbus.dbd")
modbus_registerRecordDeviceDriver(pdbbase)

# Use the following commands for TCP/IP
# drvAsynIPPortConfigure(const char *portName,
#                        const char *hostInfo,
#                        unsigned int priority,
#                        int noAutoConnect,
#                        int noProcessEos);
# Example: drvAsynIPPortConfigure("c3test1","10.0.0.42:502",0,0,1)

... 93 more lines ...
2309   Tue Mar 12 17:04:03 2019 anchal and awadeSummaryComputersMigrating epics channels from acromag1 to c3iocserver
• The migration of all EPICS channel hosting and all python programmes has been done from Acromag1 to C3IOCServer. Now Acromag1 is neither hosting anything nor running any codes.
• All channels are hosted in C3IOCServer through docker services. The channels are grouped into 5 groups which can be independently stopped or restarted now. This will allow to cahnge any channels or add channels without disrupting everything else.
• All python programmes (Autolockers, PID scripts etc) are also running as separate services.
• All these services are run inside a container which is utilizing an IP address in our local netwrok. Addresses 10.0.1.96-127 are reserved for such services.
• At any time, to see the list of services, ssh into C3IOCserver (ssh 10.0.1.36) and run sudo docker ps.
• Using the container names, the services can be stopped (sudo docker stop container name), started (sudo docker start container name) or restarted (sudo docker restart container name)
• To shut down all the python programmes, go to /home/controls/Git/cit_ctnlab/ctn_scripts and run sudo docker-compose down.   To start them again, run  sudo docker-compose up. To run it in background, use flag -d.
• To shut down all the channels, go to /home/controls/modbus and run sudo docker-compose down. Rest instructions are as above.
• For adding a new python script as a service, you would need to add any additional packages in /home/controls/Git/pyEPICSDocker/requirement.txt and run "sudo docker build -t pyep ." at the same directory. Delete any previous instance of the image to save space.
• After this, add the service in Git/cit_ctnlab/ctn_scripts/docker-compose.yml following the examples of existing services.
• If the packages are LIGO propietary, you would need to mount the cloned git dir into "/dev" folder in the docker-compose.yml file and add sys.path.append('/dep') in your python script. Follow example of netgpibpackage used in PLLautolocker.py.
2310   Sun Mar 17 18:28:06 2019 awade and anchalSummaryComputersMigrating epics channels from acromag1 to c3iocserver: killing acromag1 services

Wandered into the PSL just now.  Slow controls were going wild.  Traced it back to the fact that acromag1 and its auto-restarting services were still live. The new dockerized python script services on C3IOCServer were fighting the Acromag1 machine processes.  I've copied the service scripts into the ~/Downloads/ folder of acromag1 and deleted them from /etc/init/.   I then rebooted acromag1 and the problems went away.

We should achieve whatever is on Acromag1 and probably rebuild that machine with an operating system that is still in long term support

 Quote: The migration of all EPICS channel hosting and all python programmes has been done from Acromag1 to C3IOCServer. Now Acromag1 is neither hosting anything nor running any codes. All channels are hosted in C3IOCServer through docker services. The channels are grouped into 5 groups which can be independently stopped or restarted now. This will allow to cahnge any channels or add channels without disrupting everything else. All python programmes (Autolockers, PID scripts etc) are also running as separate services. All these services are run inside a container which is utilizing an IP address in our local netwrok. Addresses 10.0.1.96-127 are reserved for such services. At any time, to see the list of services, ssh into C3IOCserver (ssh 10.0.1.36) and run sudo docker ps. Using the container names, the services can be stopped (sudo docker stop container name), started (sudo docker start container name) or restarted (sudo docker restart container name) To shut down all the python programmes, go to /home/controls/Git/cit_ctnlab/ctn_scripts and run sudo docker-compose down.   To start them again, run  sudo docker-compose up. To run it in background, use flag -d. To shut down all the channels, go to /home/controls/modbus and run sudo docker-compose down. Rest instructions are as above. For adding a new python script as a service, you would need to add any additional packages in /home/controls/Git/pyEPICSDocker/requirement.txt and run "sudo docker build -t pyep ." at the same directory. Delete any previous instance of the image to save space. After this, add the service in Git/cit_ctnlab/ctn_scripts/docker-compose.yml following the examples of existing services. If the packages are LIGO propietary, you would need to mount the cloned git dir into "/dev" folder in the docker-compose.yml file and add sys.path.append('/dep') in your python script. Follow example of netgpibpackage used in PLLautolocker.py.

2311   Tue Mar 19 16:39:20 2019 anchalDailyProgressFSSNeed to track down 60 Hz spike source in FSS

• We were curious on actual actuation signal being sent to EOM by the TTFSS boxes.
• So we opened the north path and hooked up clips to TP4 in D090183. This point is used for PCMON signal.
• We found that there is a strong ~5V spike happening at this point at a rate of 60 Hz.
• This spike rails the EOM and hands of the error correction to pzt which happens slower.
• But when we increase the common gain in our circuit, this spike makes everything unstable at a much smaller gain then what we want to use.
• This is clearly a leak from AC supply, from where and how is unknown at the moment.

### The good news...

• We got something to work at and hopefully this is our culprit.
• If we get to remove this and increase our common gains high in FSS, we might get a deeper look in the noise.

☐ Reroute AC power cables separate from signal cables.

☐ Add chokes or loop cables around ferrite cores to increase impedance to ground loop current.

☐ Shield the FSS 37 wires cable with aluminium foil.

☐ Add a thick grouning from table to rack.

☐ Grounding all DC supplies to a single point in a star configuration with thick metal/wire.

☐ Check all DC power supplies if they are leaking these 60 Hz spikes.

☐ Removing the AC power strips from the table sides. Connect the camera power cables far way from table top.

2312   Sat Mar 23 21:50:40 2019 anchalSummaryElectronics EquipmentPower tripping incident and follow-up

This week on 19th March in the evening, I was working on replacing the GND connections of the power supply with thicker wires and checking out any AC rms voltage between different ground points to look for ground loops. During this, I found that the high voltage power supply for PMCs wasn't directly grounded with the rest of the power supplies. These are Kepco PCX 200-0.1 MAT power supplies. From here onwards, I'll tell about this incident chronologically:

Before the incident:

• Pins 4 (Sensing -) and 5 (Output -) were not shorted with a shorting clip to keep voltage regulation good.
• Pins 8 and 9 were shorted. These pins are for the external resistor for voltage control. At this point, my understanding from the manual was that front panel voltage knob overrides this external voltage control.
• Pin 5 was GND terminal for two such power supplies connected in series and operated at 80V each, totaling to 160 V for the single-sided rail of PA85 in the PMC servo boards.

The incident:

• I removed the shirt between PIN 8 and PIN 9 leaving it open and used this clip to short PIN 4 and PIN 5. I also connected PIN 4 to the rest of the GND of other power supplies which is GND for the rest of the lab.
• Then to test this, I switched on all power supplies, leaving one pair of +-24V power supplies at the bottom. I left them as at this point already, +18 V supply used for FSS boxes showed me a trip (it became a current source limiting to 3 A with about 3V voltage). Also, the Kepco power supplies for PMC where I did the changes shot to maximum 200V (instead of set 80V).
• I shut down everything and rewired everything as before.

My understanding of what happened here:

• Since short between PIN 8 and PIN 9 were removed, the external voltage control of Kepco power supply got activated and rose to maximum 200V making rail of PA85 in PMC servo card +280 V (Maximum allowed +450V).
• This allowed the PMC PZTs to be driven to upto 280V (Maximum allowed being 200V) if the control signal required it to. So far after all the tests, I came to the conclusion that this didn't happen and PZTs are healthy.
• The +18V power supply simply tripped because the FSS boxes use 18V rails to power 24V rail circuits as well in absence of power at 24V rails (which I didn't switch on yet). So the lesson here is that always switch on 24V rails power supply first for the FSS boxes.
• Finally, this is just a guess, the sudden rise of Kepco power supplies to 200V might have sent a surge of charge to rest of the GND. It doesn't really make sense, but something must have happened because I found RF amplifier of PMC reflection RFPD dead after all of this.

Current state:

• I replaced the MAX4107 RF amplifier in SN020 RFPD (and actually after doing this twice), this RFPD became as before with same transfer function as measured in PSL:2247.
• I noticed that PDH error signal for South FSS was too low. Later I found this was just because Andrew added a microwave amplifier in the RF output which mismatched the phase matching of FSS PDH.
• There are more findings on the South reflection RFPD and FSS of South path. I'll report this in a future post with some numbers.
• I have tested all FSS boxes and PMC Servo cards as well as EOM drivers. Everything else in the lab seems ok at this point. The lasers are locking nicely and following Slow PID as well.
• Regarding the ground loop issue which was the start point of all this, everything is status quo, so it is also there.
2313   Wed Apr 3 16:23:26 2019 anchalDailyProgressPMCRehabilitation of PMCs

Since the last incident of power supply tripping, I tested all photodiodes and electronics in the lab one by one. During the process, I realized that we are using way too low power in our experiment. According to my calculations, the current RFPD are such that they will be shot noise limited only with more than 2.8 mW light falling on them.

### North Path

• The north path's PMC servo card was used with external mixers. I found that we were driving EOMs way too lightly with the modulation index of about 0.05 rad only.
• The path from FPTest1 to the first summing junction had a MAX333A and a low pass filter of an arbitrary pole in it. We are already using an external in-line 19 MHz low pass filter after the mixer downconversion.
• This path has something which has broken down as it is railing the rest of the circuit.
• I switched to input point FPTest2 which directly goes to the inverting input of the summing junction. This however changed required LO phase delay by pi.
• So I optimized the phase delay again and cut a RG-178 cable for it.
• In the end, with 6.08 mW power falling on North PMC, I see PDH error signal of about 490 mVp-p with power going into EOM being 17.54 dBm (giving about 0.238 rad modulation index).
• These numbers actually do not match expectations. I'm sure the modulation depth is correct as I cross-checked with sideband powers. So most probably the RF amplification is somehow getting attenuated.
• However, the RF path looks fine when I did a TF analysis using Test Ports and used liso model to convert into how photodiode signal would behave. But this test didn't really go to high enough simulated photocurrent (to create photocurrent in the paths equivalent to 3 mW light, 144 V input is required).
• Not sure why this is happening as the MAX4107ES chip on the RFPD is also new. All rails and voltage regulators are at nice values. There is no clipping as well as the PDH error signal is beautifully ideal.
• But the PMC is locked robustly, so I'm gonna look past this for now.
• 4.292 mW light is reaching the cavity.

### South Path

• South path's PMC was in good running condition even after the incident. So I didn't open the RFPD at all.
• I did the same thing in this path, increased EOM driving signal to 17.54 dBm and measured PDH error signal.
• This path has exceptionally attenuated RF response given this RFPD (SN001) was measured to have 14430 V/A AC transimpedance.
• With 6.32 mW light falling on the RFPD, PDH error signal is 780 mVp-p.
• The exact reason for low error signal is still a mystery, but the PMC is locking robustly with good looking PDH error signal.
• The overlap at South PMC is poorer than North PMC because the incoming light has a lot of higher order modes.
• 2.768 mW light is falling on the cavity. Clearly, this is not just higher more losses. More alignment is required on South PMC overlap so that more power can reach afterward.

### Near future steps:

• Do same analysis for FSS loops. Already have done some part in this regard.
• Align the beams better everywhere.
• Get beatnote and test beatnote detector.
• Fix the actual ground loop noise issue!
2314   Thu Apr 4 15:33:34 2019 anchalDailyProgressPMCRehabilitation of PMCs

Today, I tried to replace the Reflection Photodiode on South PMC with another 14.75 MHz Resonant (which from test port analysis has TI of 57623 Ohm at 14.75 MHz). Since this another photodiode had been sitting in box for months, I expect it to behave better if the power supply tripping incident caused any harm to the existing photodiode. To my surprise, the error signal turned out to be nearly same. With 6.765 mW incident power, PDH error signal is 900 mVp-p. So I am not sure what is causing this limitation on the output signal strength. From the comparison of sideband strength to carrier strength, we are definitely near 0.88 rad modulation depth. I'll reduce this to 0.3 to avoid power in higher harmonics. But the main concern is that there is some limiting factor because of which the error signal is not going high enough.

The reason I'm worried about this is that PMC lock looks robust enough that it remain locked all night, but whenever I try to scan laser pzt for FSS analysis, the PMCs get unlocked by just connecting a switched off function generator to the laser pzt.

ELOG V3.1.3-