Motivation:

To test the hypothesis that the IMC lock duty cycle is affected by the PRM alignment. Rana pointed out today that the input faraday has not been tuned to maximize the output->input isolation in a while, so the idea is that perhaps when the PRM is aligned, some of the reflected light comes back towards the PSL through the Faraday and hence, messes with the IMC lock.

A script to test this hypothesis is running over the weekend (in case anyone was thinking of doing anything with the IFO over the weekend).

Methodology:

I've made a simple script - the pseudocode is the following:

• Align PRM
• For the next half hour, look for downward transitions in the EPICS record for MC TRANS > 5000 cts - this is a proxy for an MC lockloss
• At the end of 30 minutes, record number of locklosses in the last 30 minutes
• Misalign PRM, repeat the above 3 bullets

The idea is to keep looping the above over the weekend, so we can expect ~100 datapoints, 50 each for PRM misaligned/aligned. The times at which PRM was aligned/misaligned is also being logged, so we can make some spectrograms of PC drive RMS (for example) with PRM aligned/misaligned. The script lives at /opt/rtcds/caltech/c1/scripts/SUS/FaradayIsolationTest/FaradayIsolCheck.py. Script is being run inside a tmux session on pianosa, hopefully the machine doesn't crash over the weekend and MC1/CDS stays happy.

A more direct measurement of the input Faraday isolation can be made by putting a photodiode in place of the beam dump shown in Attachment #1 (borrowed from this elog). I measured ~100uW of power leaking through this mirror with the PRM misaligned (but IMC locked). I'm not sure what kind of SNR we can expect for a DC measurement, but if we have a chopper handy, we could put a chopper (in the leaked beam just before the PD so as to allow the IMC to be locked) and demodulate at that frequency for a cleaner measurement? This way, we could also measure the contribution from prompt reflections (up to the input side of the Faraday) by simply blocking the beam going into the vacuum. The window itself is wedged so that shouldn't be a big contributor.

I stopped the test earlier today morning around 11:30am. The log file is located at /opt/rtcds/caltech/c1/scripts/SUS/FaradayIsolationTest/PRM_stepping.txt. It contains the times at which the PRM was aligned/misaligned for lookback, and also the number of MC unlocks during every 30 minute period that the PRM alignment was toggled. This was computed by:

• continuously reading the current value of the EPICS record for MC Trans.
• comparing its current value to its values 3 seconds ago.
• If there is a downward step in this comparison greater than 5000 counts, increment a counter variable by 1.
• Reset counter at the end of 30 minute period.

I think this method is a pretty reliable proxy, because the MC autolocker certainly takes >3 seconds to re-acquire the lock (it has to run mcdown, wait for the next cavity flash, and run mcup in the meantime).

Preliminary analysis suggests no obvious correlation between MC lock duty cycle and PRM alignment.

I leave further analysis to those who are well versed in the science/art of PRM/IMC statistical correlations.

I've noticed this a couple of times today - when the autolocker runs the mcdown script, sometimes it doesn't seem to actually change the various gain sliders on the PSL FSS. There is no handshaking built in to the autolocker at the moment. So the autolocker thinks that the settings are correct for lock re-acquisition, but they are not. The PCdrive signal is often railing, as is the PZT signal. The autolocker just gets stuck waiting to re-acquire lock. This has happened today ~3 times, and each time, the Autolocker has tried to re-acquire lock unsuccessfully for ~1hour.

Perhaps I'll add a line or two to check that the signal levels are indicative of mcdown being successfully executed.

Looks like this problem presisted over the weekend - Attachment #1 is the wall StripTool trace for PSL diagnostics, seems like the control signal to the NPRO PZT and FSS EOM were all over the place, and saturated for the most part.

I traced down the problem to an unresponsive c1iool0. So looks like for the IMC autolocker to work properly (on the software end), we need c1psl, c1iool0 and megatron to all be running smoothly. c1psl controls the FSS box gains through EPICS channels, c1iool0 controls the MC servo board gains through EPICS channels, and megatron runs the various scripts to setup the gains for either lock acquisition or in lock states. In this specific case, the autolocker was being foiled because the mcdown script wasn't running properly - it was unable to set the EPICS channel C1:IOO-MC_VCO_GAIN to its lock acquisition value of -15dB, and was stuck at its in-lock value of +7dB. Curiously, the other EPICS channels on c1iool0 seemed readable and were reset by mcdown. Anyways, keying the c1iool0 crate seems to have fixed the probelm.

[koji, gautam]

1. I began my investigations by measuring the voltage noise of the demod board outputs with an SR560 (G=100) and SR785 in the audio band.
   • Measurement made with PSL shutter closed, LO input of demod board driven with the nominal level of ~2.5dBm, RF input terminated.
   • Motivation was to look for any noise features.
   • Expected noise level is ~2nV/rtHz (Johnson noise of 50ohm) since there are no preamp electronics post SCLF-5 LP filter on this board.
   • Attachment #1 shows the results of the measurement for a few scenarios. Spectra only shown for the I channel but the Q channel was similar. The LO=+5dBm curve corresponds to driving the input at 5dBm with a marconi, to see if the label of the nominal level being +5dBm had anything to it.
   • The arches above 1kHz seemed suspicious to me, so I decided to investigate further.
2. Looking at the IMC Demod board schematic, I I saw that there were 2 ERA-5SMs in there which are responsible for amplifying the 29.5MHz signal which serves as the LO to the oscillators.
3. I pulled the demod board out and tested it on the electronics workbench. Koji and I couldn't make sense of the numbers we were seeing (all measurements made with Agilent analyzer and active FET probe with 100:1 attentuator).
4. We eventually concluded that the ERA-5SMs were not exhibiting the expected gain of ~20dB. So we decided to swap these out.
5. This sort of measurement is not ironclad as the output of the ERA-5SM goes to the mixer whose input impedance is dynamically varying as the diodes are switching. So even after replacing the suspect amplifiers with new ones, we couldn't make the numbers jive.
6. We suspected that the new amplifiers were getting saturated. The 3dB saturation point for the ERA-5SM is spec'ed as ~19dBm.
   • We "measured" this by varying the input signal level and looking for deviation from linearity.
   • We saw that there was ~1dB compression for ~13dBm output from the ERA-5SM (after correcting for all attenuators etc). But this number may not be accurate in the absolute sense because of the unknown input impedance of the mixer.
   • Moreover, looking at the spec sheet for the mixer, JMS-1H, we found that while it wasn't ideal to operate the mixer with the LO level a few dBm below the expected +17dBm, it probably wasn't a show stopper.
7. So we figured that we need 10dB of attenuation between the "nominal" LO input level of 2.7dBm and the input of the demod board in order to keep the ERA-5SM in the linear range. This has now been implemented in the form of an SMA attenuator.
8. IMC locked straight away. But I noticed that PC drive RMS level was unusually large.
9. I found that by increasing the "IN1" gain of the CM board to 12dB (from 2dB) and the "VCO gain" to 10dB (from 7dB), I could recover a transfer function with UGF ~140kHz and PM ~30degrees (need more systematic and wider span measurements of this, and also probably need to optimize the crossover gains). See Attachment #2 for my quick measurement tonight.
10. Updated mcup to reflect these new gains. Tested autolocker a few times, seems to work okay.
11. While it presumably was a good thing to replace the faulty amplifiers and prevent them from saturating, this work has not solved the primary problem of excess frequency noise on the PSL.

It is not clear to me why installing an attenuator to prevent amplifier saturation has necessitated a 10dB increase in the IN1 gain and 3dB increase in the VCO gain. Initially, I was trying to compensate for the gain by increasing the FSS "Common Gain" but in that setting, I found an OLTF measurement impossible. The moment I enabled the excitation input to the CM board, the lock was blown, even with excitation amplitudes as small as -60dBm (from the Agilent network analyzer).

This may also be a good opportunity to test out one of the aLIGO style FET mixer demod boards (recall we have 2 spare from the 4 that were inside the ALS demod box). I'm going to ask Steve to package these into a 1U chassis so that I can try that setup out sometime. From a noise point of view, the aLIGO boards have the advantage of having a x100 preamp stage straight after the mixer+LPF. We may need to replace the lowpass filter though, I'm not sure if the one installed is 1.9MHz or 5MHz.

I've left an SR785 and AG4395 near 1X2 in anticipation of continuing this work tomorrow.

Unrelated to this work - seems like the WFS DC and RF offsets had not been set in a while so I reset these yesterday. The frequent model restarts in recent times may mean that we have to reset these to avoid using dated offset values.

Re-measured the demod board noises after replacing the suspect ERA-5SMs, with LO driven by a marconi at the "nominal" level of 2.5dBm, and RF input terminated. Attachment #1 is the input referred voltage noise spectra. I used the FET low noise pre-amp box for this purpose. I cannot explain the shape of the spectra above 1kHz. I tried doing the measurement on a minicircuits mixer (non-surface mount) and found the shape to be flat throughout the SR785 span. Unclear what else could be going on in the demod board though, all the other components on it are passive (except the ERA-5SMs which were replaced). I considered adopting a PMC style demod setup where we do the demod using some separate Minicircuits Mixer+LowPass filter combo. But the RF flashes for the IMC monitored at the RFmon port are ~0.2Vpp, and so the RF input to the mixer is expected to be ~2Vpp. The minicircuits mixer selection guide recommends choosing a diode mixer with LO level at least 10dBm above the expected RF input signal level, and we don't have any standalone mixers that are >Level 7. I've asked Steve to package the aLIGO demod board in the meantime, but even that might not be a plug and play replacement as the IF preamp stage has ~120degrees phase lag at 1MHz, which is significantly higher than the existing board which just has a SCLF5 low pass filter after the mixer and hence has <45degrees phase lag at 1MHz.

This elog by koji inspired me to consider power supply as a possible issue.

The demod board receives +/-24V DC (which is regulated down to +/-15V DC by 7815/7915), and also +15V DC via the backplane. The ERA-5SM receives DC power from the latter (unregulated) +15V DC. I can't think of why this is the case except perhaps the regulators can't source the current the amp wants? In any case, it doesn't look feasible to change this by cutting any traces on the PCB to me. While I had the board out, I decided to replace the JMS-1H mixers in a last ditch effort to improve the demod board noise. Unfortunately I'm having trouble de-soldering these MCL components from the board. So for now, I'm leaving the demod board out, IMC unlocked. Work will continue tomorrow. 

After some persistence, I managed to get the mixers off.

• Having gotten the mxiers off, I decided to temporarily solder on 50ohms between the LO pin pad and ground on the demod board and measure the RF signal levels in the LO chain with the active probe again.
• Today, with this change, I confirmed that the ERA-5SM begins to saturate closer to the +19dBm advertised on its datasheet. So we need only 2dB of attenuation at the input to have 17dBm at the LO pin of the mixer, assuming 50ohm input impedance.
• But this begs the question - what does minicircuits mean by a Level-YY mixer? Do they expect YY dBm delivered to a 50ohm load? Or do we need to supply YY dBm accounting for the dynamically changing input impedance of the mixer, as monitored by a high impedance probe?
• I soldered on some new mixers (JMS-1H) I procured from Downs earlier today.
• Re-installed the demod board in the eurocrate.

Unfortunately, the coherent noise between the arms persists so the sensing noise injection must be happening elsewhere. IMC seems to lock fine though so I'm leving the autolocker on

As discussed at the meeting, I decided to calibrate the MC error point into physical units of Hz/rtHz (a.k.a. the PDH discriminant). This is to facilitate the debugging of the hypothesized excess IMC sensing noise. I did this as follows.

1. Trust the POX calibration that was last updated in Aug 2017.
2. Hook up spare DAC channel (piped from LSC rack to 1X2) to IN2 of IMC CM board.
3. Inject excitation into MC error point via "IN2" input of the common board. For an excitation of 30cts with the IN2 gain at -32dB, I was able to see a peak in the calibrated X arm control signal that was ~x10 above the nominal noise level around 150Hz without seeing any nonlinear coupling effects in the DTT spectrum (I'm assuming 150Hz is sufficiently above the UGF of the X arm locking loop such that no loop correction is necessary).
4. Took a spectrum of the IMC error signal, teed off into the SR785 at the I output of the demod board with the same linewidth as the DTT spectrum.
5. Confirmed that without any excitation,
6. Did the math to make these two peaks line up. The resulting calibration is: 13kHz/Vrms.

Math details:

• DTT peak height @ 150 Hz with Hanning window, 25 avgs = 1.97e-4 nm/rtHz (See Attachment #1).
• X arm cavity length = 37.79m, using which the above number becomes 1.47 Hz/rtHz.
• Peak height in SR785 spectrum with Hanning window, 25 avgs = 1.13e-4 Vrms/rtHz (See Attachment #2).
• Dividing, we get 13kHz/Vrms.

Using this, I can now make up a noise budget of sorts for the IMC sensing.

gautam 20180327 4.30pm: I re-checked the PDH error signal calibration using the oscilloscope method. Attachment #3 shows the PDH I and Q error signals and also the output of the RF monitor port, during a TEM00 flash. This attachment should be compared to Attachment #2 of elog 12822, and the answer lines up quite well. From my Finesse model of the IMC, I calculated that the x-axis of the PDH horn-to-horn is ~12.3kHz. Comparing to the top row of Attachment #3, I get a PDH error signal calibration of ~12.4kHz/Vrms, which lines up well with the number quoted above. So I trust my calibration, and hence, the y-axis of my noise budgets in reply to this elog.

I did a preliminary noise budget of the transmitted frequency noise of the IMC. Attachment #1 shows the NB. I'm going to use this opportunity to revisit my IMC modeling. Some notes:

1. The blue, green and red traces are from my measurement of the voltage noise of the demod board with LO driven by Marconi, RF input terminated, measured using the FET preamp + SR785, and calibrated into Hz/rtHz using the number from the immediate preceeding entry.
2. The grey trace is measured by closing the PSL shutter, manually engaging the POX11 whitening, and looking at the calibrated POX. This sensing noise is ~100x higher than the IMC curves - but I think this makes sense as for the IMC, I am measuring directly at the output of the demod board, whereas for POX, the signal goes through the whole whitening infrastructure first.
3. The purple trace is the calibrated X-arm control signal converted to Hz/rtHz.
4. I've only showed the region up to ~1kHz as this is where the excess noise was seen in the original ALS study that precipitated this whole investigation.

Conclusion: From this study, assuming my PDH discriminant calibration was correct, looks like IMC demod / POX11 demod electronics noises are not to blame (this surprises me since there were apparently so many things wrong on the demod board, and yet that wasn't the worst thing in the IMC chain it would seem ). The POX11 photodiode "dark" noise is also not the problem I think, given the grey curve. Next curve to go on here is the demod board noise with the PSL shutter closed but the IMC REFL PD connected to the RF input (or maybe even better, have light on the PD, but macroscopically misalign MC2 so there is no 29.5MHz PDH signal), just to make sure there isn't anything funky going on there...

I've added two curves to the NB. Both are measured (with FET preamp) at the output of the demod board, with the LO driven at the nominal level by the Wenzel RF source pickoff (as it would be when the IMC is locked) and the RF input connected to the IMC REFL PD. For one curve, I simply closed the PSL shutter, while for the other, I left the PSL shutter open, but macroscopically misaligned MC2 so that there was no IMC cavity. So barring RFAM, there should be no PDH signal on the REFL PD, but I wanted to have light on there. I'm not sure if I understand the difference between these two curves though, need to think on it. Perhaps the IMC REFL PD's optical/electrical response needs to be characterized?

[Gautam, Arijit]

PMC and IMC re-aligned and re-locked. Both cavities are staying locked. Arm cavities are also locked.

Gautam, Rana

While at the MC2 table, we noticed that it has some optical problems:

1. There is an ND filter mounted to the beam reducing lens. ND filters are illegal, Steve. It causes too much scattering noise. We should instead have a beamsplitter and a dump.
2. One of those bad U100-AC28 mounts is in use. This is one of those ones with plastic clips that Osamu liked, but the plastic gets in the way of the beam. Needs to be removed.
3. Reflections from the QPD and the PDA255 are not dumped. This causes noise. Bad.
4. The QPD transimpedance should be reduced so that it can handle more light. I don't know what it has now, but its probably 10-100 kOhm.

We estimated that the power in the IMC is (1 W)*Finesse/pi = 500 W. The MC2 Transmission spec is < 10 ppm, so the power on the table is probably ~5 mW. Since the PDA255 has a transimpedance of 10 kOhm and a max output power of 10V, it can handle up to ~1 mW. Probably we can get the QPD to handle 4 mW.

Gautam, Steve  3-27

We measured MC2 transmitted power right at the uncoated window ~2.5 mW  The beam was just a little bigger than the meter.

[rana, gautam]

we measured the RIN of the MC2 transmission using the PDA255 I had put on the MC2 trans table sometime ago for ringdowns. Attached are (i) spectra for the RIN, (ii) spectra for the classical rad. pressure noise assuming 500W circulating power and (iii) a tarball of data and code used to generate these plots.

We took a full span measurement (to make sure there aren't any funky high-freq features) and a measurement from DC-800 Hz (where we are looking for excess noise). The DC level of light on the photodiode was 2.76V (measured using o'scope)

I'll add this to the noise budget later. But the measured RIN seems consistent with a 2013 measurement at 100Hz (though the 2013 measurement is using DTT and so doesn't have high frequency information).

While Kevin and Arijit were doing their MC_REFL PD noise measurements (which they will elog about separately shortly), I noticed a feature around 600kHz that reminded me of the NPRO noise eater feature. This is supposed to suppress the relaxation oscillation induced peak in the RIN of the PSL. Surprisingly, the noise eater switch on the NPRO front panel was set to "OFF". Is this the normal operating state? I thought we want the noise eater to be "ON"? Have to measure the RIN on the PSL table itself with one of the many available pick off PDs. In any case, as Attachment #1 showed, turning the noise eater back on did not improve the excess IMC frequency noise.

Kevin, Gautam and Arijit

We made a measurement of the MC_REFL photodiode transfer function using the network analyzer. We did it for two different power input (0dB and -10dB) to the test measurement point of the MC_REFL photodiode. This was important to ensure the measurements of the transfer function of the MC_REFL photodiode was in the linear regime. The measurements are shown in attachment 1. We corrected for phase noise for the length of cable (50cm) used for the measurement. With reference to ELOG 10406, in comparison to the transimpedance measurement performed by Riju and Koji, there is a much stronger peak around 290MHz as observed by our measurement.

We also did a noise measurement for the MC_REFL photodiode. We did it for three scenarios: 1. Without any light falling on the photodiode 2. With light falling on the photodiode, the MC misaligned and the NPRO noise eater was OFF 3. With light falling on the photodiode, the MC misaligned and the NPRO noise eater was ON. We observed that the noise eater does reduce the noise being observed from 80kHz to 20MHz. This is shown in attachment 2.

We did the noise modelling of the MC_REFL photodiode using LISO and tried matching the expected noise from the model with the noise measurements we made earlier. The modeled noise is in good agreement with the measured noise with 10Ohms in the output resistance. The schematic for the MC_REFL photodiode however reveals a 50Ohm resistance being used. The measured noise shows excess noise ~ 290MHz. This is not predicted from the simplied LISO model of the photodiode we took.

Discussion with Koji and Gautam revealed that we do not have the exact circuit diagram for the MC_REFL photodiode. Hence the simplified model that was assumed earlier is not able to predict the excess noise at high frequencies. One thing to note however, is that the excess noise is measured with the same amplitude even with no light falling on the MC_REFL photodiode. This means that there is a positive feedback and oscillation in the op-amp (MAX4107) at high frequencies. One way to refine the LISO model would be to physically examine the photodiode circuit.

We also recorded the POX and POY RF monitor photodiode outputs when the interferometer arms are independently stabilized to the laser. Given the noise outputs from the RF photodiodes were similar, we have only plotted the POY RF monitor output for the sake of clarity and convenience.

I've removed the MC REFL PD unit from the AS table for investigation. So MC won't lock.

PSL shutter was closed and location of PD was marked with sharpie (placing guides to indicate position wasn't convenient). I also kapton taped the PD to minimize dust settling on the PD while I have it out in the electronics area. Johannes has the camera, and my cellphone image probably isn't really high-res enough for diagnostics but I'm posting it here anyways for what it's worth. More importantly - the board is a D980454 revision B judging by the board, but there is no schematic for this revision on the DCC. The closest I can find is a D980454 Rev D. But I can already see several differences in the component layout (though not all of them may be important). Making a marked up schematic is going to be a pain . I'm also not sure what the specific make of the PD installed is.

The lid of the RF cage wasn't on.

More to follow tomorrow, PD is on the electronics workmench for now...

gautam 28 March 2018: Schematic has been found from secret Dale stash (which exists in addition to the secret Jay stash). It has also been added to the 40m electronics tree.

I re-installed the MC REFL photodiode. Centered beam on the PD by adjusting steering mirror to maximize the DC signal level (on o'scope) at the DC monitoring port. Curiously, the DC level on the scope (high-Z) was ~2.66V DC, whereas the MEDM screen reports ~twice that value, at ~5.44 "V". We may want to fix this "calibration" (or better yet, use physical units like mW). Noise-eater On/Off comparison of MC error signals to follow.

Kevin, Gautam and Arijit

We did a optical measurement of the MCREFL_PD transimpedance using the Jenny Laser set-up. We used 0.56mW @1064nm on the NewFocus 1611 Photodiode as reference and 0.475mW @1064nm on the MCREFL_PD. Transfer function was measured using the AG4395 network analyzer. We also fit the data using the refined LISO model. From the optical measurement, we can see that we do not have a prominent peak at about 300MHz like the one we had from the electrical transimpedence measurement. We also put in the electrical transimpedence measurement as reference. RMS contribution of 300MHz peak to follow.

As per Rana`s advice I have updated the entry with information on the LISO fit quality and parameters used. I have put all the relevant files concerning the above measurement as well as the LISO fit and output files as a zip file "LISO_fit" . I also added a note describing what each file represents. I have also updated the plot with fit parameters and errors as in elog 10406.

Kevin, Gautam and Arijit

Today we performed the in-loop noise measurements of the MCREFL-PD using the SR785 to ascertain the effect of the Noise Eater on the laser. We took the measurements at the demodulated output channel from the MCREFL-PD. We performed a series of 6 measurements with the Noise Eater ''ON'' and ''OFF''. The first data set is an outlier probably, due to some transient effects. The remaining data sets were recorded in succession with a time interval of 5 minutes each between the Noise Eater in the ''ON'' and ''OFF'' state. We used the calibration factor of 13kHz/Vrms from elog 13696 to convert the V_rms to Hz-scale.

The conclusion is that the NOISE EATER does not have any noticeable effect on the noise measurements.

ALS beat spectrum and also the arm control signal look as they did before. coherence between arm control signals (in POX/POY lock) is high between 10-100Hz, so looks like there is still excess frequency noise in the MC transmitted light. Looking at POX as an OOL sensor with the arm under ALS control shows ~10x the noise at 100 Hz compared to the "nominal" level, consistent with what Koji and I observed ~3weeks ago.

We tried swapping out Marconis. Problem persists. So Marconi is not to blame. I wanted to rule this out as in Jan, Steve and I had installed a 10MHz reference to the rear of the Marconi.

the noise eater on/off measurements should be done for 0-100 kHz and from the demod board output monitor

[Gautam, Kevin]

We redid the measurement measuring the voltage noise from the REFL PD demod board output monitor with an SR785 with the noise eater on and off. We used a 100x preamp to amplify the signal above the SR785 noise. The SR785 noise floor was measured with the input to the preamp terminated with 50 ohms. The spectra shown have been corrected for the 100x amplification.

This measurement shows no difference with the noise eater on or off.

[Gautam, Kevin]

We measured the MC coil driver noise at the output monitors of the coil driver board with an SR785 in order to further diagnose the excess IMC frequency noise.

Attachments 1 and 2 show the noise for the UL coils of MC3 and MC2 with various combinations of output filters engaged. When the 28 Hz elliptic filter is on, the analog dewhitening filter is off, and vice versa. The effect of the analog low pass filter is visible in MC3, but the effect of the digital low pass filter is swamped by the DAC noise.

We locked the arms and measured the ALS beatnote in each of these filter combinations, but which filters were on did not effect the excess IMC frequency noise. This suggests that the coil drivers are not responsible for the excess noise.

Attachment 2 shows the noise for all five coils on MC1, MC2, and MC3 as well as for ITMY, which is on a different DAC card from the MCs. All filters were on for these measurements.

Why is MC2 LR so different from the others???

While Kevin is working on the MC2 electronics chain - we disconnected the output to the optic (DB15 connector on coil driver board). I decided to look at the 'free' freeswinging MC2 OSEM shadow sensor data. Attachment #1 suggests that the suspension eigenmodes are showing up in the shadow sensors, but the 0.8Hz peak seems rather small, especially compared to the result presented in this elog.

Maybe I'll kick all 3 MC optics tonight and let them ringdown overnight, may not be a bad idea to checkup on the health of the MC suspensions/satellite boxes... [MC suspensions were kicked @1207113574]. PSL shutter will remain closed overnight...

The previous measurements were made from the coil driver output monitors. To investigate why the MC2 LR coil has less noise than the other coils, I also measured the noise at the output to the coils.

The circuit diagram for the coil driver board is given in D010001 and a picture of the rack is on the 40m wiki here. The coil driver boards are in the upper left quadrant of the rack. The input to the board is the column of LEMOs which are the "Coil Test In" inputs on the schematic. The output monitors are the row of LEMOs to the right of the input LEMOs and are the "FP Coil Volt Mon" outputs on the schematic. The output to the coils "Coil Out" in the schematic are carried through a DB15 connector.

The attachment shows the voltage noise for the MC2 LR coil as well as the UL coil which is similar to all of the other coils measured in the previous measurement. While the LR coil is less noisy than the UL coil as measured at the output monitor, they have the same noise spectrum as measured at the output to the coils themselves. So there must be something wrong with the buffer circuit for the MC2 LR voltage monitor, but the output to the coils themselves is the same as for the other coils.

1. I analyzed the data from the free swinging MC test conducted over the weekend. Attachment #1 shows the spectra. Color scheme is same for all panels.
   • I am suspicious of MC3: why does the LR coil see almost no Yaw motion?
   • The "equilibrium" values of all the sensor signals (at the IN1 of the coil input filters) are within 20% of each other (for MC3, but also MC1 and MC2).
   • The position resonance is also sensed more by the side coil than by the LR coil.
   • To rule out satellite box shenanigans, I just switched the SRM and MC3 satellite boxes. But coherence between frequency noise as sensed by the arms remain.
2. I decided to clean up my IMC nosie budget a bit more.
   • Attachment #2 shows the NB as of today. I'll choose a better color palette for the next update.
   • "Seismic" trace is estimated using the 40m gwinc file - the MC2 stack is probably different from the others and so it's contribution is probably more, but I think this will suffice for a first estimate.
   • "RAM" trace is measured at the CM board input, with MC2 misaligned.
   • The unaccounted noise is evident from above ~8 Hz.
   • More noises will be added as they are measured.
   • I am going to spend some time working on modeling the CM board noise and TF in LTspice. I tried getting a measurement of the transfer function fron IN1 to the FAST output of the CM board with the SR785 (motivation being to add the contribution of the input referred CM board noise to the NB plot), but I suspect I screwed up something w.r.t. the excitation amplitude, as I am getting a totally nonsensical shape, which also seems to depend on my input excitation amplitude. I don't think the output is saturated (viewed during measurement on a scope), but perhaps there are some subtle effects going on.

I am working on IMC electronics. IMC is misaligned until further notice.

[kevin, gautam]

activities done today - details/plots/data/evidence tomorrow.

1. Checked XARM loop shape. Updated NB code to fetch POX data from NDS and undo loop shape rather than using calibration filter bank.
2. Checked POX loop calibration (m/ct). Number I was using was 8e-13. Tonight we measured 9e-13. Updated filter bank.
3. Tried to get Y arm green ALS going.
   • Improved GTRY from ~0.05 to 0.3.
   • Tried to improve mode matching onto BBPD on PSL table to see a green beat.
   • But we were unsuccessful.
   • I think I got the near and far field alignment right, and the EY laser temp is set such that I can see an IR beat @~30MHz (so green beat should be at 60 MHz).
   • But I couldn't see anything with scope or with HP spec analyzer.
   • More tomorrow. Motivation to get green ALS working is to get some more confidence that the excess noise is indeed on the PSL light.

I'm working on fixing these (and the associated MEDM scripts) up so that we can get some reliable readback on how well centered the spots are on the MC mirrors. Seems like a bunch of MEDM display paths were broken, and it looks like the optimal demod phases (to put most of the output in I quadrature) are not what the current iteration of the scripts set them to be. It may well be that the gains that convert demodulated counts to mm of spot offset are also not correct anymore. I ran the script ~4times in ~1 hour time span, and got wildly different answers for the spot centering each time, so I wouldn't trust any of those numbers atm...

As you can see in Attachment #1, I stepped the demod phase of one of the servos from -180 to 180 degrees in 5degree increments. The previously used value of 57degrees is actually close to the worst possible point (if you want the signal in the I quadrature, which is what the scripts assume).

I used Attachment #2 to change up the demod phases to maximize the I signal. I chose the demod phase such that it preserved the sign of the demodulated signal (relative to the old demod phases). I also made some StripTool templates for these, and they are in the MC directory. Doing the spot centering measurement with the updated demod phases yields the following output from the script:

Seems totally unbelievable still that we are so far off center on MC1 yaw. Perhaps the gains and calibration to convert from counts to mm of spot offset need to be rechecked.

Summary:

As shown in the Attachments, it seems like IMC DAC and coil driver noise is the dominant noise source above 30Hz. If we assume the region around the bounce peak is real motion of the stack (to be confirmed with accelerometer data soon), this NB is starting to add up. Much checking to be done, and I'd also like to get a cleaner measurement of coil driver and DAC noise for all 3 optics, as there seems to be a factor of ~5 disagreement between the MC3 coil driver noise measurement and my previous foray into this subject. The measurement needs to be refined a little, but I think the conclusion holds.

Details:

1. I had a measurement of the MC3 coil driver noise from ~2weeks ago when I was last working on this that I had not yet added to the NB.
2. Today I added it. To convert from measured voltage noise to frequency noise, I assumed the usual 0.016N/A per coil number, which is probably a large source of systematic error.
3. I define the "nominal" IMC operating condition as MC1 and MC3 having the analog de-whitening filters switched on, but MC2 switched off.
4. So length noise should be dominated by coil driver noise on MC1 and MC3, and DAC noise on MC2.
5. The measurement I had was made with the input to the coil driver board terminated in 50ohms. Measurement was made in-situ. The measurement has a whole bunch of 60Hz harmonics (despite the Prologix box being powered by a linear power adapter, but perhaps there are other ground loops which are coupling into the measurement). So I'd like to get a cleaner measurement tmrw.
6. To confirm, Koji suggested some On/Off test by driving some broadband noise in the coils. I figured toggling the analog de-whitening, such that the DAC noise or coil driver electronics dominate is an equally good test.
7. Attachment #2 shows the effect in arm error and control signal spectra. Note that I engaged analog de-whitening on all 3 optics for the red curves in this plot. But even leaving MC2 de-whitening off, I could see the read curve was below the black reference trace, which was taken with de-whitening off on all 3 optics.

Remarks:

Since I sunk some time into it already, the motivation behind this work is just to try and make the IMC noise budget add up. It is not directly related to lowering the IR ALS noise, but if it is true that we are dominated by coil driver noise, we may want to consider modifying the MC coil driver electronics along with the ITM and ETMs.

Summary:

Today, I repeated the coil driver noise measurement. Now, the coil driver noise curve in the noise budget plot (Attachment #1) is the actual measurement of all 12 coils (made with G=100 SR560). I am also attaching the raw voltage noise measurement (input terminated in 50ohms, Attachment #2). Note that POX11 spectrum has now been re-measured with analog de-whitening engaged on all 3 optics such that the DAC noise contribution should be negligible compared to coil driver noise in this configuration. The rows in Attachment #2 correspond to 800 Hz span (top) and full span (bottom) on the FFT analyzer.

Details:

The main difference between this measurement, and the one I did middle of last year (which agreed with the expectation from LISO modeling quite well) is that this measurement was done in-situ inside the eurocrate box while last year, I did everything on the electronics benches. So I claim that the whole mess of harmonics seen in the raw measurements are because of some electronics pickup near 1X6. But even disregarding the peaky features, the floor of ~30nV/rtHz is ~6x than what one would expect from LISO modeling (~5nV/rtHz). I confirmed by looking that the series resistance for all 3 MC optics is 430ohms. I also did the measurement with the nominal bias voltages applied to the four channels (these come in via the slow ADCs). But these paths are low-passed by an 8th order low pass with corner @ 1Hz, so at 100 Hz, even 1uV/rtHz should be totally insignificant. I suppose I could measure (with EPICS sine waves) this low-pass filtering, but it's hard to imagine this being the problem. At the very least, I think we should get rid of the x3 gain on the MC2 coil driver de-whitening board (and also on MC1 and MC3 if they also have the x3 factor).

Summary:

In the IMC actuation chain, it looks like the MC1/MC3 de-whitening boards, and also all three MC optics' coil driver boards, are showing higher noise than expected from LISO modeling. One possible candidate is thick film resistors on the coil driver boards. The plan is to debug these further by pulling the board out of the Eurocrate and investigating on the electronics bench.

Why bother? Mainly because I want to see how good the IR ALS noise is, and currently, the PSL frequency noise is causing the measurement to be worse than references taken from previous known good times.

Details:

Sometime ago, rana suggested to me that I should do this measurement more systematically.

• Attachments #1, #2 and #3 show noise measurements in various conditions for MC1, MC2 and MC3 respectively.
• In the above three attachments, I stitched together multiple spans from the SR785, and so the bin-width is different. The data is downloaded from the analyzer normalized by the bin-width (PSD units).
• The roll-off at ~800Hz in the orange trace for MC1 and MC3 is consistent with an 800 Hz LPF that was used for anti-image filtering from the old 2 kHz era.
• While it may look like the analog de-whitening isn't being switched on in some of these plots, I confirmed by transfer function measurement that it is indeed switching.
• Data used to make these plots are in Attachment #4. Unfortunately, the code requires some of my personal plotting libraries and so I'm not uploading it.
• Sketch of measurement setup is shown in Attachment #5. It is not indicated in the schematic, but the SR560 was operated in battery mode for this measurement.
• For MC1, I did the additional measurement of terminating the LEMO input to the coil driver and measuring (what should have been) just the coil driver electronics noise. But this measurement doesn't look very clean, and hence, the decision to pull the board out to continue debugging.
• While at 1X6, Rana tightened the LEMO connectors going to MC1. We should opportunistically do MC2 and MC3 as well.
• Some changes to be made:
  • Thick film ---> thin film.
  • Reroute HPF-ed back-plane Vmon output to the front panel LEMO.

I've now restored all the wiring at 1X6 to their state before this work.

I have pulled out MC1 coil driver board from its Eurocrate, so IMC is unavailable until further notice. Plans:

1. Thick film --> Thin Film
2. AD797 --> Op27
3. Remove Pots in analog actuation path.
4. Measure noise
5. Route HPF signal (UL DAQ Mon) to front panel. I think we should use the SMA connectors. That way, we have DC and AC voltage monitors available for debugging.

If there are no objections, I will execute Step #5 in the next couple of hours. I'm going to start with Steps 1-4.

This work is now complete. MC1 coil driver board has been reinstalled, local damping of MC1 restored, and IMC has been locked. Detailed report + photos to follow, but measurement of the noise (for one channel) on the electronics workbench shows a broadband noise level of 5nV/rtHz () around 100Hz, which is lower than what was measured here and consistent with what we expect from LISO modeling (with fast input terminated with 50ohm, slow input grounded).

• Marked up schematic + photo post changes uploaded to DCC page.
• There was a capacitor in the DAQ monitor path making a 8kHz corner that I now removed (since the main point of this front panel HPF monitor point is to facilitate easy coil driver noise debugging, and I wanted to be able to use the SR785 out to high frequencies without accounting for an additional low pass). Transfer function from front panel LEMO input to front panel LEMO monitor is shown in Attachment #1.
• Voltage noise measured at DB25 output (with the help of a breakout cable and SR560 G=100) with front panel LEMO input terminated to 50ohm, Bias input grounded, and pin1 of U21A grounded (i.e. watchdog enabled state) is shown in Attachment #2. This measurement was taken on the electronics bench.
• Inside the lab (i.e. coil driver board plugged into eurocrate), the noise measured in the same way looks identical to what was measured in elog13870.
• I tried repeating the measurement by powering the board using an bench power supply and grounding the bias input voltage near 1X6, and the strange noise profile persists. So this supports the hypothesis that some kind of environmental pickup is causing this noise profile. Needs more investigation. 

In any case, if it is indeed true that the optic sees this current noise, the place to make the measurement is probably the Sat. Box. Who knows what the pickup is over the ~15m of cable from 1X6 to the optic.

[rana,gautam]

Summary:

Last night, Rana fact-checked my story about the coil driver noise measurement. Conclusions:

1. There is definitely pickup of strong lines (see Attachment #1. These are hypothesized to come from switching power supplies). Moreover, they breathe. Checkout Rana's twitter page for the video.
2. The lines are almost (but not quite) at integer multiples of 19.5 kHz. The cause of this anharmonicity is to be puzzled out.
3. When the coil driver board is located ~1m away from the SR785 and the bench supply powering it, even though the lines are visible in the spectrum, the low frequency shape does not show the weird broad features I reported here. The measured noise floor level is ~5nV/rtHz, which is consistent with LISO noise + SR560 input noise (see Attachment #2). However, there is still some excess noise at 100 Hz above what the LISO model leads us to expect. 
4. The location of the coil driver board and SR560 relative to the SR785 and the bench power supply I used to power the coil driver board can increase the line heights by ~x50. 
5. The above changes the shape of the low frequency part of the spectrum as well, and it looks more like what is reported in elog13870. The hypothesis is that the high frequency lines are downconverted in the SR560.

Note: All measurements were made with the fast input of the coil driver board terminated with 50ohms and bias input shorted to ground with a crocodile clip cable.

Next steps:

The first goal is to figure out where this pickup is happening, and if it is actually going to the optic. To this end, I will put a passive 100 kHz filter between the coil driver output and the preamp (Busby Box instead of SR560). By getting a clean measurement of the noise floor with the coil driver board in the Eurocrate (with the bias input driven), we can confirm that the optic isn't being buffeted by the excess coil driver noise. If we confirm that the excess noise is not a measurement artefact, we need to think about were the pickup is actually happening and come up with mitigation strategies.

RXA: good section EMI/RFI in Op Amp Applications handbook (2006) by Walt Jung. Also this page: http://www.electronicdesign.com/analog/what-was-noise

I was checking on the slow machine channels and found something I could not understand.

On the IOO WFS HEAD screen, there are two sets of 4 switches (magenta rectangles in Attachment 1) labeled 2/4/8/16dB.
But as far as I could confirm with the WFS demod (D980233) and WFS head (D980012) drawings, they are the gain (attenuation) switches for the individual segments.
Their epics variable names are "C1:IOO-WFS1_SEG1_ATTEN", "C1:IOO-WFS1_SEG2_ATTEN", etc...

I confirmed the switches are alive (effective), and they are not all ON or OFF. I wonder what is the real situation there...

The unfortunate discovery today was that the attenuator switches on the IMC WFS heads are actually assigned to individual segments, and they are active. That means that we have been running the WFS with an uneven gain setting. The attached PDFs show that the signals with the attenuators on and off all at the same time, while the WFS servo output was frozen. A more annoying feature is that when some of the attenuators are on, this does not lower the gain completely. I mean that the attenuated channels show some reduction of the gain, but that is not the level of reduction we see when all attenuators are turned on. This RF could come from some internal RF coupling or some similar effect.

Moreover, the demodulation phases are quite off for most of the segments.

So far, the WFS is running with this uneven attenuation. We take time to characterize the gain and retune the demod phases and input matrices.

its painful, but you and I should probably take these out, bypass the switches and use them with fixed gain; the 'Reed Relay' attenuators are not a good part for this app.

The historical problem is that they tend to self oscillate with full gain because they had 2 MAX4106 in series which couple to each other in the bad way --- need to remove one of them and set the gain of the other one to 10.

IMC WFS tuning

- IMC was aligned manually to have maximum output and also spot at the center of the end QPD.
- The IMC WFS spots were aligned to be the center of the WFS QPDs.
- With the good alignment, WFS RF offset and MC2 QPD offsets were tuned via the scripts.

The PMC and IMC were unlocked. Both were re-locked, and alignment of both cavities were adjusted so as to maximize MC2 trans (by hand, input alignment to PMC tweaked on PSL table, IMC alignment tweaked using slow bias voltages). I disabled the inputs to the WFS loops, as it looks like they are not able to deal with the glitching IMC suspensions. c1lsc models have crashed again but I am not worrying about that for now.

9pm: The alignment is wandering all over the place so I'm just closing the PSL shutter for now.

I restarted the LSC models in the usual way via the c1lsc reboot script. After doing this I was able to lock the YARM configuration for more noise coupling scripting.

The IMC has been misbehaving for the last 5 hours. Why? I turned the WFS servos off. afaik, aaron was the last person to work on the IFO, so i'm not taking any further debugging steps so as to not disturb his setup.

That was likely me. I had recentered the beam on the PD I'm using for the armloss measurements, and I probably moved the wrong steering mirror. The transmission from MC2 is sent to a steering mirror that directs it to the MC2 transmission QPD; the transmission from this steering mirror I direct to the armloss MC QPD (the second is what I was trying to adjust).

Note: The MC2 trans QPD goes out to a cable that is labelled MC2 op lev. This confusion should be fixed.

I realigned the MC and recentered the beam on the QPD. Indeed the beam on MC2 QPD was up and left, and the lock was lost pretty quickly, possibly because the beam wasn't centered. Lock was unstable for a while, and I rebooted C1PSL once during this process because the slow machine was unresponsive.

When tweaking the alignment near MC2, take care not to bump the table, as this also chang es the MC2 alignment.

Once the MC was stably locked, I was able to maximize MC transmission at ~15,400 counts. I then centered the spot on the MC2 trans QPD, and transmission dropped to ~14800 counts. After tweaking the alignment again, it was recovered to ~15,000 counts. Gautam then engaged the WFS servo and the beam was centered on MC2 trans QPD, transmission level dropped to ~14,900.

This problem resurfaced. I'm doing the debugging.

6:30pm - "Solved" using the same procedure of stepping through the whitening gains with a small (10 DAC cts pk) signal applied. Simply stepping through the gains with input grounded doesn't seem to do the trick.

Gautam was doing some DRMI locking, so I replaced the photodiode at the AS port to begin loss measurements again.

I increased the resolution on the scope by selecting Average (512) mode. I was a bit confused by this, since Yuki was correct that I had only 4 digits recorded over ethernet, which made me think this was an i/o setting. However the sample acquisition setting was the only thing I could find on the tektronix scope or in its manual about improving vertical resolution. This didn't change the saved file, but I found the more extensive programming manual for the scope, which confirms that using average mode does increase the resolution... from 9 to 14 bits! I'm not even getting that many.

There's another setting for DATa:WIDth, that is the number of bytes per data point transferred from the scope.

I tried using the *.25 scope instead, no better results. Changing the vertical resolution directly doesn't change this either. I've also tried changing most of the ethernet settings. I don't think it's something on the scripts side, because I'm using the same scripts that apparently generated the most recent of Johannes' and Yuki's files; I did look through for eg tds3014b.py, and didn't see the resolution explicitly set. Indeed, I get 7 bits of resolution as that function specifies, but most of them aren't filled by the scope. This makes me think the problem is on the scope settings.

sstop using the ssscope, and just put the ssssignal into the DAQ with sssssome whitening. You'll get 16 bitsśšß.

I ran a BNC from the PD on the AS table along the cable rack to a free ADC channel on the LSC whitening board. I lay the BNC on top of the other cables in the rack, so as not to disturb anything. I also was careful not to touch the other cables on the LSC whitening board when I plugged in my BNC. The PD now reads out to... a mystery channel. The mystery channel goes then to c1lsc ADC0 channels 9-16 (since the BNC goes to input 8, it should be #16). To find the channel, I opened the c1lsc model and found that adc0 channel 15 (0-indexed in the model) goes to a terminator.

Rather than mess with the LSC model, Gautam freed up C1:ALS-BEATY_FINE_I, and I'm reading out the AS signal there.

I misaligned the x-arm then re-installed the AS PO PD, using the scope to center the beam then connecting it to the BNC to (first the mystery channel, then BEATY). I turned off all the lights.

I went to misalign the x-arms, but the some of the control channels are white boxed. The only working screen is on pianosa.

The noise on the AS signal is much larger than that on the MC trans signal, and the DC difference for misaligned vs locked states is much less than the RMS (spectrum attached); the coherence between MC trans and AS is low. However, after estimating that for ~30ppm the locked vs misaligned states should only be ~0.3-0.4% different, and double checking that we are well above ADC and dark noise (blocked the beam, took another spectrum) and not saturating the PD, these observations started to make more sense.

To make the measurement in cds, I also made the following changes to a copy opf Johannes' assess_armloss_refl.py that I placed in /opt/rtcds/caltech/c1/scripts/lossmap_scripts/armloss_cds/   :

• function now takes as argument the number of averages, averaging time, channel of the AS PD, and YARM|XARM|DARK.
• made the data save to my directory, in /users/aaron/40m/data/armloss/

I started taking a measurement, but quickly realized that the mode cleaner has been locked to a higher order mode for about an hour, so I spend some time moving the MC. It would repeatedly lock on the 00 mode, but the alignment must be bad because the transmission fluctuates between 300 and 1400, and the lock only lasts about 5 minutes.

Back to loss measurements.

I replaced the PD I've been using for the AS beam.

I misaligned the x arm.

I tried to lock the y arm, but PRC was locked so I could was unable. Gautam reminded me where the config scripts are.

The armloss measurement script needed two additional modifications:

• It was setting the initial offset of the PIT and YAW demod signals to 0, but due to the clipping on the heater we are operating at an offset. I commented out these lines.
• When the script ran UNFREEZE_DITHER, it was running it using medmrun. The scope script hadn't been using this, and it seemed that when it ran UNFREEZE_DITHER in this way the YARM_ASS servo was passing only '0'. I don't really know why this was, but when I removed the call to medmrun it worked.

I ran successfully the loss measurement script for the x and y arms. I'm getting losses of ~100ppm from the first estimates.

I made the following changes to the lossmap script:

• make the averaging time an input to the script, so we can exceed 2 second averages
• remove anything about getting data from the scope, replace it with the correct analogues to save the averages for POX/POY refl, MC trans, op lev P/Y, and ASDC signal.
• record the GPS time in the file with the cds averages (this way I can grab the full data)
• Added a step in the lossmap script to misalign the optic, so we can continue getting data for the 'misaligned' state, both for the centered and not-centered measurements (that is, for every position on the lossmap).

When the optic aligns itself not at the ideal position, I'm noticing that it often locks on a 01. When the cavity is then misaligned and restored, it can no longer obtain lock. To fix this, I've moved my 'save' commands to just before the loop begins. This means the script may take longer to run, but as long as the cavity is initially locked and well aligned, this should make it more robust against wandering off and never reacquiring lock.

I left the lossmap script running for the x-arm. Next would be to run it for the y arm, but I see that after stepping to a few positions the lock is again lost. It's still trying to run, but if you want to stop it no data already taken will be lost. To stop it, go to the remaining terminal open on rossa and ctrl+c

the analysis needs:

• Windowing
• Filter, don't average
• detrend to get rid of the linear drifts in lock that we see.
  • Is this the right thing?