Then we can estimate the noises.
Measurement with ARMs
ITMX: 5.0843e-9 /f^2 [m/count]
ITMY: 4.9677e-9 / f^2 [m/count]
In high frequency region there is the difference between xarm and yarm. These difference are already there in error signal. I'm not sure where these noise comes from. We will make measurement with Green PDH from tomorrow, so we can also check with those measurement.
In other region the two noises are very close and also very similar to the plot of the seismic motion in the control room (attached on the front of TV screen).
Measurement with FPMI
i)By locking the FPMI with AS55Q and arms using POX,POY we measured the OLTF on AS55Q, the response from BS actuation to error signal on AS55Q for H_mich. The fitted, measured OLTF and the residual function is in attachment1. I fitted two parameters and they are time-delay and the gain. The time delay is -275 usec. The time delay in three different control are almost same. The response from BS to AS55Q is in attachment 2.
With these two measuremets, I calclated the H_mich in FPMI. This H_mich should be different from simple MI because the cavity refrectivity is different from the front mirror. Acrually it changed and the value was
Hmich = 4.4026e7
ii) I excited the ETMX and ETMY and measure the response from actuation to the error signal of MICH on AS55Q. The response is in attachment 3 and 4. from these result I calculated the H_L-l by using the formula as I mentioned. The value was
H_Lx-l = 175.7650 (XARM)
H_Ly-l = 169.8451 (YARM)
iii) I measured the error signal of MICH and XARM and YARM and with measured H_L-l, I estimated the FPMI noise caused by ARM locking. You can see in the higher frequency region than 10 Hz is dominated by noise caused by ARM control in-loop noises. 150 Hz and 220Hz are the UGF of each arms, so the two peaks are caused by arm control. You can see the small difference between FPMI noise and noise from arms. There are two possibilities, one is that these measurement is not same time measurement so they should have small difference. and other possibility is the error of the caliculation. But I think it doesn't look so bad estimation.
We will do same measurement with lock the arms the ALS system on tomorrow. Then we will check the PDH servo or other noise source and investigate the ALS system
Hidden in Nakano-kun's previous entries was that the phase margin of the X-Arm was only 9 degrees!! This extremely close to instability and makes for huge gain peaking. The feedback loop is increasing noise above 100 Hz rather than suppress. After some tweaks of the LSC filters we got a much more stable loop/.
So we today started to examine the sources of phase lag in the arm cavity sweeps. There were a few unfortunate choices in the XARM LSC filter bank which we tuned to get less delay.
Then I wrote a bunch of detail about how that worked, but the ELOG ate my entry because it couldn't handle converting my error signal noise plot into a thumbnail. Then it crashed and I restarted it. We also have now propagated the changes to the Y arm by copy/paste the filters and the result there is pretty much the same: low phase margin is now 38 deg phase margin. Noise is less bad.
I made the plot of the phase of the digital filters which Rana change and also of the AA, AI, DAA, DAI filters. Now the biggest phase delay come from the timedelay of the digital system.
The UGF is around 150 Hz at that frequency the time delay has biggest phase delay. Second one is the FM9 filter (this filter is BOOST filter). Then we have the AA filter, AI filter and so on, but these delay is roughly 5 degree.
As I said in previous entry, the time delay of the XARM control is roughly 300 usec, and we have 120 usec even only in C1SUS. Also between the C!SUS and C1LSC we have another 120 usec time delay. We want to increase the UGF to 300 Hz but because of the time delay of the digital system we cannot increase. So we should fix this problem.
After changing these filters, the FPMI noise is become better at high frequency. Before we have peak around the 100 Hz (because of 8 degree phase margin...), but they are gone. i attached the noise spectrum. This plot is measured by the real time calibration output. But even then, you can see the extra noise around 100 Hz in FPMI conpare to only MICH.
We locked MICH with 2 arms stabilized by ALS control.
We measured the power spectrum of the LSC-MICH_IN1 at each step so as to know the in-loop noise of MICH. And also we measured the OLTF of MICH loop and the error signal with BS excited at 580 Hz and MICH notch filter at same frequency enabled to obtain the MICH calibration factor.
1. We locked MICH using the AS55Q error signal and fedback to BS actuator. (Red curve)
2. We locked MICH and locked both the arms using POX11 and POY11 error signals and fedback to ETMs actuators.(Blue curve)
3. We stabilized both the arms using ALS. We use the ALS error signals and fedback to ETMs actuators. And then we locked MICH.(Magenta curve)
The green and brown curve are the ALS in-loop noise, which is the _PHASE_OUT_Hz calibrated error signals. So for these two curves the unit of vertical axis is Hz/rHz. The other curves are the MICH in-loop noises and these are not calibrated. So for these curves the unit of vertical axis is counts/rHz.
The UGF of MICH loop is 10 Hz with phase margin of 45 degrees (measured today). The FPMI noise with ALS stabilized arms is much larger than the FPMI with IR PDH locked arms above 30 Hz. That is because the ALS arm stability is not as good as the stability of PDH locked arms. We have to analyze and verify the calibrated numbers for FPMI + ALS with model.
In 2arms + MICH configuration, residual motion of the cavity will couple with MICH signal. When cavity length change, the reflectivity of cavity also change. And that cause the phase shift in reflected light. That phase shift is detected in MICH signal. When we try to lock the DRMI + arm, that coupling will be problem for lock acquisition. For practice to estimate that coupling, I estimated the coupling between the cavity motion and the AS55Q signal.
What I did
- Measurement steps
I did the same measurement as that of this entry. For the estimation below steps are needed. The detail of each step will be written below.
--Measurement and calibration of the AS55Q error signal with MICH + 2arms locked by ALS control
--Measurement of the ALS in-loop noise and estimation of residual motion of the cavities.
--Calibration of the coupling from residual arm motion to AS55Q signal
- Calibration of the AS55Q signal
1. Sensor gain estimation
We used the same method as the previous entry,
We excited the BS at 580 Hz with a given amplitude (Vin). We enabled the notch filter at 580 Hz in the LSC MICH servo. We measured the peak height (Verr) of the AS55Q error signal. We used the actuator response (A_bs) of BS measured in this entry.
We can get the sensor gain (H) of AS55Q in unit of count/m
H = ------- -------
By this calculation H = 4.2e+07.
2. Fitting of OLTF for the MICH loop
We measured the OLTF of the MICH loop. Modelled OLTF is fitted into the measurement data. That modelled OLTF includes the actuator response of BS, the MICH servo filters, DAI,DAA,AI,AA filters, the TF of sample and hold circuit. (About DAI, DAA filters and S/H circuit please read this entry. About AI,AA filters please read this entry) Also I put time-delay into that OLTF. I estimated that time-delay and the gain of OLTF by fitting. The time delay was 311usec.
3. Estimation of the MICH free running noise
With modeled OLTF, I estimated the MICH free running noise.
Estimation of the coupling from residual cavity motion to AS55Q signal
The ALS in-loop noise data has the unit of Hz/rHz (disturbance of the cavity resonant frequency). By multiplying L_arm/f_laser we can convert the unit to m/rHz (disturbance of the cavity length) .
I used the same coupling constant between residual motion of cavity and MICH noise as this entry. For estimation of the coupling constant, we excited ETMs and measured the TF from excitation signal to AS55Q error signal. I assumed the cavity pole as 4000 Hz. The result is discussed below
ALS in-loop noise include the sensor noise. in high frequency region the in-loop noise is dominated by the sensor noise. So in this region in-loop noise does not mean actual residual motion of the cavity. And this sensor noise pushes the mirror. So we have to estimate the actual motion of the cavity by multiplying the servo transfer function of the control in this region.
I made 2 plots. Both include the MICH free running noise and estimated coupling noise from both arms. In one plot, for estimation of the coupling I multiplied only coupling constant to calibrated in-loop noise of the ALS loop. In another plot, I multiplied coupling constant and OLTF of ALS loop in order to estimate the actual motion of the cavity. If the 3 curves are coincide in first plot, that means the ALS in-loop noise is same as the residual cavity motion in that region and the MICH free running noise is dominated by coupling from residual cavity motion. If those curves are coincide in second plot, that means the ALS in-loop noise is sensor noise in that region.
Above 40 Hz, the 3 curves are totally in coincident in first plot. On the other hand in second plot the 3 curves look similar in this region. That may mean above 40 Hz the ALS noise are dominated by sensor noise and MICH free running noise is dominated by the coupling from residual cavity motion. Also in the region between 10 Hz and 40 Hz, the MICH free running noise seems to be dominated by coupling from cavity motion.
In second plot, the coupling from cavity motion is overestimated. It's possibly because of overestimation of coupling constant, but I'm not sure.
Koji mentioned that we should measure the residual motion of the cavity by using POX and POY. Now the ALS is much more stable than before, so I think we can easily do the measurement again with out of loop measurement. That will be more strait forward measurement.
After this, we locked DARM, CARM and MICH using POX11_I, POY11_I and AS55 error signals respectively, and actuating on ETMX, MC2, and BS with NO TRIGGERS (but FM triggers were on for boosts as usual). Under this condition, FM5 is used for lock acquisition, and FM1, FM2, FM3, FM6 are turned on with FM triggers. No FM4 was on. We also noticed:
DARM feedback should go to ETMY - ETMX, not just a single mirror: Differential ARM.
For it to work with 1 mirror the UGF of the CARM loop must be much larger than DARM UGF. But in our case, both have a UGF of ~150 Hz.
In principle, you could run the CARM loop with higher gain by using the CM servo board, but maybe that can wait until the X,Y -> CARM, DARM handoff.
[Anchal, Paco, Yuta]
We tried to lock FPMI with REFL55 and AS55 this week, but no success yet.
FPMI locks with POX11, POY11 and ASDC for MICH stably, but handing over to 55's couldn't be done yet.
What we did:
- REFL55: Increased the whitening gain to 24dB. Demodulation phase tuned to minimize MICH signal in I when both arms are locked with POX and POY. REFL55 is noisier than AS55. Demodulation phase and amplitude of the signal seem to drift a lot also. Might need investigation.
- AS55: Demodulation phase tuned to minimize MICH signal in I when both arms are locked with POX and POY. Whitening gain is 24dB.
- Script for demodulation phase tuning lives in https://git.ligo.org/40m/scripts/-/blob/main/RFPD/getPhaseAngle.py
- Locking MICH with REFL55 Q: Kicks BS much and not so stable probably because of noisy REFL55. Offtet also needs to be adjusted to lock MICH to dark fringe.
- BS coil balancing: When MICH is "locked" with REFL55 Q, TRX drops rapidly and AS fringe gets worse, indicating BS coil balancing is not good. We balanced the coils by dithering POS with different coil output matrix gains to minimize oplev PIT and YAW output manually using LOCKINs.
- Locking MICH with ASDC: Works nicely. Offset is set to -0.1 in MICH filter and reduced to -0.03 after lock acquisition.
- ETMX/ETMY actuation balancing: We found that feedback signal to ETMX and ETMY at LSC output is unbalanced when locking with POX and POY. We dithered MC2 at 71 Hz, and checked feedback signals when Xarm/Yarm are locked to find out actuation efficiency imbalance. A gain of 2.9874 is put into C1:LSC-ETMX filter to balance ETMX/ETMY. I think we need to check this factor carefully again.
- TRX and TRY: We normalized TRX and TRY to give 1 when arms are aligned. Before doing this, we also checked the alignment of TRX and TRY DC PDs (also reduced green scattering for TRY). Together with ETMX/ETMY balancing, this helped making filter gains the same for POX and POY lock to be 0.02 (See, also 40m/16888).
- Single arm with REFL55/AS55: We checked that single arm locking with both REFL55_I and AS55_Q works. Single arm locking feeding back to MC2 also worked.
- Handing over to REFL55/AS55: After locking Xarm and Yarm using POX to ETMX and POY to ETMY, MICH is locked with ASDC to BS. Handing over to REFL55_I for CARM using ETMX+ETMY and AS55_Q for DARM using -ETMX+ETMY was not successful. Changing an actuator for CARM to MC2 also didn't work. There might be an unstable point when turning off XARM/YARM filter modules and switching on DARM/CARM filter modules with a ramp time. We also need to re-investigate correct gains and signs for DARM and CARM. (Right now, gains are 0.02 for POX and POY, -0.02 for DARM with AS55_Q (-ETMX+ETMY), -0.02 for CARM with REFL55_I with MC2 are the best we found so far)
- Measure ETMX and ETMY actuation efficiencies with Xarm/Yarm to balance the output matrix for DARM.
- Measure optical gains of POX11, POY11, AS55 and REFL55 when FPMI is locked with POX/POY/ASDC to find out correct filter gains for them.
- Make sure to measure OLTFs when doing above to correct for loop gains.
- Lock CARM with POY11 to MC2, DARM with POX11 to ETMX. Use input matrix to hand over instead of changing filter modules from XARM/YARM to DARM/CARM.
- Try using ALS to lock FPMI.
[Paco, Koji, Yuta]
We managed to lock MICH using REFL55_Q by setting the demodulation phases and offsets right.
The following is the current FPMI locking configuration we achieved so far.
DARM: POX11_I / gain 0.007 / 0.5*ETMX-0.5*ETMY (or 1*ETMX) / UGF of ~100 Hz
CARM: POY11_I / gain 0.018 / 1*MC2 / UGF of ~200 Hz
MICH: REFL55_Q / gain -10 / 0.5*BS / UGF of ~30 Hz
Transitioning DARM error signal from POX11_I to 0.5*POX11_I+0.5*POY11_I was possible with FM4 filter off in DARM filter bank, but not to AS55_Q yet.
REFL55 and AS55 demodulation phase tuning:
- We found that both AS55 and REFL55 are contaminated by large non-MICH signal, by making a ASDC vs RF plot (see 40m/16929).
- After both arms are locked with POX and POY, MICH was locked with AS55_Q. ASDC was minimized by putting an offset to MICH filter.
- With this, REFL55 offsets were zeroed and demodulation phase was tuned to minimize REFL55_Q.
- Locked MICH with REFL55_Q, and did the same thing for AS55_Q.
- Resulting ASDC vs RF plots were attached. REFL55_Q now looks great, but REFL55_I and AS55 are noisy (due to signals from the arms?).
Jupyter notebook: https://git.ligo.org/40m/scripts/-/blob/main/CAL/MICH/MICHOpticalGainCalibration.ipynb
- With FPMI locked using POX/POY, DARM and CARM lines were injected at around 300 Hz to measure the sensing gains. For line injection, C1:CAL-SENSMAT was used, but for the demodulation we used a script. The following is the result.
Sensors DARM (ETMX) CARM (MC2)
C1:LSC-AS55_I_ERR 3.10e+00 (-34.1143 deg) 1.09e+01 (-14.907 deg)
C1:LSC-AS55_Q_ERR 9.96e-01 (-33.9848 deg) 3.30e+00 (-27.9468 deg)
C1:LSC-REFL55_I_ERR 6.75e+00 (-33.7723 deg) 2.92e+01 (-34.0958 deg)
C1:LSC-REFL55_Q_ERR 7.07e-01 (-33.4296 deg) 3.08e+00 (-33.4437 deg)
C1:LSC-POX11_I_ERR 3.97e+00 (-33.9164 deg) 1.51e+01 (-30.7586 deg)
C1:LSC-POY11_I_ERR 6.25e-02 (-20.3946 deg) 3.59e+00 (38.4207 deg)
Jupyter notebook: https://git.ligo.org/40m/scripts/-/blob/main/CAL/SensingMatrix/MeasureSensMat.ipynb
- By taking the ratios of POX11_I and AS55_Q for DARM, POY11_I and REFL55_I for CARM, we tried to find the correct gains for REFL55 and AS55 for DARM and CARM. x3.96 more gain for AS55_Q than POX11_I and x0.123 less gain for REFL55_I than POY11_I.
- Try locking the arms with no triggering, and then try locking FPMI with REFL/AS without triggering. No FM4 for this, since FM4 kills gain margin.
- Lock single arm with AS55_Q and make a noise budget. Make sure to misalign ITMX(Y) completely when locking Y(X)arm.
- Lock single arm with REFL55_I and make a noise budget.
- Repeat Xarm noise budget with Yarm locked with POY11_I and MC2 (40m/16975).
- Check IMC to reduce frequency noise (40m/17001)
In the last few days, with Koji's help, I have recovered both the FS725 Rubidium references from W. Bridge, one from the ATF lab, and one from the CTN lab. Both are back at the 40m at the moment.
However, the one that was recovered from the ATF lab is no longer locking to the Rubidium reference frequency, although it was locked at the time we disconnected it from the ATF lab. I emailed the support staff at SRS, who seem to think that either the internal oscillator has drifted too far, or the Rb lamp is dead. Either ways, it needs to be repaired. They suggested that I run a check by issuing some serial commands to the unit to determine which of these is actually the problem, but I've been having some trouble setting up the serial link - I will try this again tomorrow. I'm also having trouble generating an RMA number that is needed to start the repair/maintenance process, but I've emailed SRS support again and hope to hear back from them soon.
The other FS725, recovered from the CTN lab earlier today, seems to work fine and is locked to the Rb reference at the moment. I plan to redo the calibration of the phase tracker with an 'absolute' frequency reference with the help of the FS725 and out GPS timing unit tomorrow. Once that is done, the working unit can be returned to the CTN lab.
However, the one that was recovered from the ATF lab is no longer locking to the Rubidium reference frequency, although it was locked at the time we disconnected it from the ATF lab. I emailed the support staff at SRS, who seem to think that either the internal oscillator has drifted too far, or the Rb lamp is dead. Either ways, it needs to be repaired. They suggested that I run a check by issuing some serial commands to the unit to determine which of these is actually the problem, but I've been having some trouble setting up the serial link - I will try this again tomorrow.
The Rubidium standard we had sent in for repair and recalibration has come back. I checked the following:
However, I am still having trouble setting up a serial communications link with the FS725 with a USB-serial adaptor - I've tried with a Raspberry Pi and my Mac (using screen to try and connect), and also using one of the old Windows laptops lying around on which I was able to install the native software supplied by SRS (still using the USB-serial adaptor to establish connection though). Could it be that the unit is incompatible with the USB-serial adaptor? I had specifically indicated in the repair request that this was also a problem. In any case, this doesn't seem to be crucial, though it would have been nice for diagnostics purposes in the future...
I've stored the repaired FS725 inside the electronics cabinet (marked "Eletronics Modules") for now (the other unit was returned to Antonio in W. Bridge some weeks ago).
I've located the Stanford Research FS725 Rb reference unit. The question is where to put it. This afternoon Steve and I put it inside the little electronics rack next to 1X3, but in hindsight, this probably isn't such a great place for a timing reference as there are a bunch of Sorensen power supplies in there (and presumably the accompanying harmonics from these switching supplies).
The unit itself was repaired in 2015, and powering it on, it locked to the internal reference within a few minutes as prescribed in the manual.
Steve, can you please connect this fan to the rack power and remove this extra power supply?
Re-arranged the DC bench supply on the shelf in the PSL enclosure, whose only purpose seems to be to supply 12V to a fan attached to the rear of the PSL NPRO controller. Seems to be a waste of space! The fan was momentarily disconnected but has since been reconnected and is spinning again.
While the ETMx issues are being investigated - with Eric's help, I took some data from arm scans of the Y arm through ~2FSRs using ALS. I've also collected the data from the frequency counter readout during these scans but since they were done rather fast (over 60seconds), I am not sure how accurate this data will be. The idea however is to use the frequency readout from the phase tracker - this has to be linearized though, which I will do during the daytime tomorrow. The plan is to use our GPS timing unit to synchronize the following chain :
GPS timing unit 1PPS out --> FS725 Rb Clock 1PPS in (I recovered one which was borrowed from the 40m some time ago from the ATF lab yesterday evening, waiting for it to lock to the Rb clock now)
FS725 Rb Clock 10 MHz out --> Fluke 6061A 10MHz reference in
FS725 Rb Clock 10 MHz out-->agilent network analyzer 10MHz reference in (for measurement of the frequency of the signal output from the Fluke RF signal generator independent of its front panel display)
Then I plan to look at the phase tracker output as a function of the driving frequency (which will also be measured, offline, using the digital frequency counter setup) over a range of 20 MHz - 50 MHz in steps of 1 MHz. Results to follow.
Earlier tonight, Eric and I tweaked the PMC alignment (the mode cleaner was not staying locked for more than a couple of minutes, for almost an hour).
I performed a preliminary calibration of the X and Y phase trackers, and found that the slopes of a linear fit of phase tracker output as a function of driven frequency (as measured with digital frequency counter) are 0.7886 +/- 0.0016 and 0.9630 +/- 0.0012 respectively (see Attachments #1 and #2). Based on this, the EPICS calibration constants have been updated. The data used for calibration has also been uploaded (Attachment #4).
I found that by adopting the approach I suggested as a fix in elog 11736, and setting a gate time of 1second, I could eliminate the systematic bias in measured frequency I had been seeing, the origin of which is also discussed in elog 11736. This was verified by using a digital oscillator to supply the input to the frequency counting block, and verifying that I could recover the driving frequency without any systematic bias. Therefore, I used this as a measure of the driving frequency independent of the front panel display of the Fluke 6061A.
The actual calibration was done as follows:
Y-arm transmission scan
I used the information from Attachment #2 to calibrate the X-axis of the Y-arm transmission data I collected on Wednesday evening. Looking at the beat frequency on the analyzer in the control room, between 24 and 47 MHz (green beat frequency, within the range the calibration was done over), we saw three IR resonances. I've marked these peaks, and also the 11MHz sideband resonances, in Attachment #3. It remains to fit the various peaks. I did a quick calculation of the FSR, and the number I got using these 3 peaks is 3.9703 +/- 0.0049 MHz. This value is ~23 kHz greater than that reported in elog 9804, but the error is also ~4 times greater (6 IR resonances were scanned in elog 9804) so I think these measurements are consistent.
I had brought an FS725 Rubidium clock back from W Bridge - the idea was to hook this up to the GPS 1PPS output, and use the 10MHz output from the FS725 as the reference for the fluke 6061A. However, the FS725 has not locked to the Rb frequency even though it has been left powered on for ~2days now. Do I have to do something else to get it to lock? The manual says that it should lock within 7 minutes of being powered on. Once this is locked, I can repeat the calibration with an 'absolute' frequency source...
I fitted the data obtained with the FSR and linewidth measurements and I've got FSR and finesse of y-arm by fitting.
The fitted data and the fitting results are attached.
FSR = 3.9704 MHz (ave. of two FSRs, 3.9727 MHz and 3.9681 MHz)
finesse = 401 +/- 11
estimated loss = 1812 (+456 / - 431) ppm
I found peaks from the data and fitted each peak by Lorentzian, automatically with Python (the sourse code I used is attached).
3 parameters of Lorentzian for each peak and their fitting errors are attached.
Then, using 3 peaks of carrier resonance, I calculated FSR, finesse, and loss.
The error of finesse came from that of linewidth.
When calculating the loss, I used the value of 1.384 % for transmission of ITMY.
Since the finesse is mostly determined by the transmission of ITM, the relative error of loss estimation is larger (about 25 % ) though the relative error of finesse is about 3 %. Therefor we have to find the reason why each estimated linewidth varies that largely, and measure finesse more accurately.
I'd like to add a few calculation results, mode matching ratio for Y arm and modulation depth.
Here I assumed peaks marked in the bottom figure shown in elog 11738 as resonances of carrier and modulated sidebands and others as resonances of HOM.
- mode matching ratio = 94.92 +/- 0.19 % WRONG
How I calculated: for each peak of carrier, you can find 6 peaks of HOM resonaces. Then I calculated the sum of the hight of 6 peaks divided by the hight of carrier resonance peak, and took average of this values for 3 resonance peaks of carrier.
- modulation depth = 0.390 +/- 0.062 WRONG
How I calculated: I took average of the hight of 6 peaks of modulated sideband resonance, and normalized it with the hight of peaks of carrier resonance. Using the relation 'normalized hight' = (J_1(m)/J_0(m))^2, I got modulation depth, m.
- modulation depth = 0.390 +/- 0.062
There are two modulation frequencies that make it to the arm cavities, at ~11MHz and ~55MHz. Each of these will have their own modulation depth indepedent of each other. Bundling them together into one number doesn't tell us what's really going on.
As an update to Yutaro's earlier post - I've done an independent study of this data, doing the fitting with MATLAB, and trying to estimate (i) the FSR, (ii) the mode matching efficienct, and (iii) the modulation depths at 11MHz and 55MHz.
The values I've obtained are as follows:
FSR = 3.9704 MHz +/- 17 kHz
Mode matching efficiency = 92.59 % (TEM00 = 1, TEM10 = 0.0325, TEM20 = 0.0475)
Modulation depth at 11MHz = 0.179
Modulation depth at 55MHz = 0.131
Misc Remarks and Conclusions:
FSS SLOW control did not drift during the lock at night with MCL path working and AC coupled.
The IR sensitive Olympus 570 camera gives us a really nice view of these IR beams. Its actually a lot better than what you can get with the analog IR viewers:
I measured the phase noise of the LO output of the FSS box from the DAQ. I'm attaching the results.
As we expected, the measurement is limited by the internal phase noise of the Marconi.
The measurement was done as shown in this diagram.
The differences between this setup and the one used previously is the lack of the 50 Ohm terminator in the mixer output and
that the SR560 readout with the G=100 should come before the first SR560 via T, so as not to be spoiled by the high noise of the G=1 SR560.
I removed the 50 Ohm in-line terminator when I did the measurement with the SR785. The for some reason I was getting more noise, so I removed it.
Now I put it back in and I did the measurement with the DAQ. I also moved the SR560 that amplifies the signal for the DAQ, Tee'ing it with the input of the in-loop SR560.
Now the setup looks like this:
And the phase noise that I measure is this:
Comparing it with the phase noise measured with the previous setup (see entry 3506), you can see that the noise effectively is reduced by about a factor of 2 above 10 Hz.
With the setup now working, we should now test the power filtering for the crystal and amplifier.
I have put in a new nominal value for the FSS fast gain: 21.5 dB.
There is an oscillation peak in the MC error point spectra around 41.5 kHz if the FSS gain is set too high. I used the 4395 to have a look at the MC error point, and saw that if I set the FSS fast gain any lower than about 18 dB, the peak wasn't getting any smaller than -41 dBm. If I set the fast gain any higher than about 26 dB the peak wouldn't get any larger than about -34 dBm.
However, if I set the gain to 19.5dB, the PC RMS drive is consistently above 2 V, which isn't so good. If I crank the gain up to 27 dB or more, the PC RMS will stay below 0.9 V, which is great.
As a compromise, I have decided on 21.5 dB as the new FSS fast gain. This puts the oscillation peak at about -39.5 dBm, and the PC RMS around 1.6 V.
I changed the nominal gain by ezcawrite C1:PSL-STAT_FSS_NOM_F_GAIN 21.5. This sets the nominal value so that the FSS screen's fast slider doesn't turn red at the new value. And, since the MC autolocker reads this epics channel and puts that into the gain during the mcup script, the MC autolocker now uses this new gain. For reference, it used to be set to 23.5 dB.
ezcawrite C1:PSL-STAT_FSS_NOM_F_GAIN 21.5
A few weeks ago, on Jul 24, Rana and I measured the phase noise of the FSS frequency box (aka the 'Kalmus Box'). See elog entry 3286.
That time, for some reason, we measured a phase noise higher than we expected; higher than that of the Marconi.
I repeated the measurement today using the SR785 spectrum analyzer. Here is the result:
(The measurement of July 24 on the plot was not corrected for the loop gain. The UGF was at about 30 Hz)
To make sure that my measurement procedure was correct, I also measured the combined phase noise of two Marconis. I then confirmed the consistency of that with what already measured by other people in the past (i.e. Rana elog entry 823 in the ATF elog).
This time the noise seemed reasonable; closer to the Marconi's phase noise, as we would expect. I don't know why it was so bad on July 24.
The shoulder in the Marconi-to-Marconi measurement between 80Hz and 800Hz is probably due to the phase noise of the other Marconi, the one used as LO.
I'm going to repeat the measurement connecting the setup to the DAQ, and locking the Marconi to the Rubidium standard.
Ultimately, the goal is to measure the phase noise of the new Sideband Frequency Generation Box of the 40m Upgrade.
I've taken the FSS frequency generation box out of the 1Y1 rack. It's sitting on one of the electronics benches. I'm measuring its phase noise.
Today we measured the phase noise of the oscillator used for the FSS.
The source is a Wenzel crystal at about 21.5MHz that Peter Kalmus built some time ago.
We basically used the same technique that Frank and Megan have been using lately to measure the Marconi's phase noise.
Today we just did a quick measurement but today next week we are going to repeat it more carefully.
Attached is a plot that shows the measurement calibrated for a UGF at about 60 Hz. The noise is compared to that specified by Wenzel for their crystal.
The noise is bigger than that of the MArconi alone locked to the Rubidium standard (see elog entry). We don't know the reason for sure yet.
We'll get back to this problem next week.
I reconnected the RF signal to the FSS and to the FSS' EOM so that we could lock the refcav again.
I then started a 3 sec. period trianglewave on the AOM drive amplitude to see if there is a direct coupling from RIN to Frequency. Ideally we will be able to measure this by looking at the RCTRANS and the FSS-FAST.
1) Check cable between RFPD and FSS box for quality. Replace with a good short cable.
2) Using a directional coupler, look at the RFPD output in lock on a scope with 50 Ohm term.
I suspect its a lot of harmonics because we're overmodulating to compensate for the bad
3) Purchase translation stages for the FSS mode matching lenses. Same model as the PMC lenses.
Fix the mode matching.
4) Get the shop to build us up some more bases for the RFPDs on the PSL such as we have for the LSC.
Right now they're on some cheesy Delrin pedestals. Too soft...
5) Dump the beam reflected off the FSS RFPD with a little piece of black glass or a razor dump.
Anodized aluminum is no good and wiggles too much.
I found that FSS SLOW servo is not engaged. Is this intentional test to keep the NPRO temp constant?
This is making the FSS Fast unhappy (~ -7.5V right now).
Yes, I had turned it off while looking for the PSL/X AUX beat, and forgot to turn it back on.
I will post an elog with more detail this evening, but I found a temperature which restored the X green beatnote at its nominal amplitude (-30dBm) with no mode hops within +-1 IR beat GHz, and offloaded the slow offset slider to the X-end laser crystal dial. I will look for the Y beatnote after dinner.
Currently the control room analyzer is hooked up to recieve the Y IR and green beats; no X signals.
I was trying to debug why the NPRO PZT is all over the place, and it turns out that the new FSS SLOW script is not actually running.
The BLINKY is blinking, but the script is not running. I wasn't able to figure out how to kill the broken Docker thing, but if the code reports that its running but actually does not, we should probably just put back the old perl or python script that ran before. I don't know how to debug this current issue, but the IMC locks will be limited in length due to this servo being broken. Whoever knows about this, please stop that Docker PID and we can just run the old python script on megatron.
I also tried to post a trend plot, but the minute trends don't yet reach the current date (!!!). They seem to have stopped recording a few days ago, so I guess the Framebuilder still needs some help or its tough to figure out things like when exactly the new SLOW servo stopped working.
The problem with trends was due to the epics data collection process (standalone_edc) that runs on c1sus. When all the FEs were rebooted earlier this week, this process was started automatically, but for some reason it hasn’t been doing its thing and sending epics data to the framebuilder. I restarted it just now, and it’s working again. Until this problem is sorted out, we need to remember to check on this process after rebooting c1sus.