40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 78 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  17002   Thu Jul 14 00:10:08 2022 yutaSummaryLSCFPMI with REFL/AS55 trial continued

[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

Sensing matrix:
 - 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.

Next:
 - 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)

Attachment 1: AS55_I.png
AS55_I.png
Attachment 2: AS55_Q.png
AS55_Q.png
Attachment 3: REFL55_I.png
REFL55_I.png
Attachment 4: REFL55_Q.png
REFL55_Q.png
  11750   Tue Nov 10 19:25:42 2015 gautamUpdateGeneralFS725 Rubidium reference

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. 

  11898   Tue Dec 22 16:44:03 2015 gautamUpdateGeneralFS725 Rubidium reference - REPAIRED
Quote:

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:

  • Powered the unit on - it was locked to the internal rubidium reference within a few minutes as prescribed in the manual.
  • After it had locked to the internal reference, I checked that it was able to lock to an external 1pps reference from our GPS timing unit- this too was achieved within a few minutes as prescribed in the manualyes

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). 

Attachment 1: FS725_repaired.jpg
FS725_repaired.jpg
  13357   Wed Oct 4 17:38:25 2017 gautamUpdateLSCFS725 for Marconi stabilization

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. 

  13362   Thu Oct 5 18:40:27 2017 gautamUpdateLSCFS725 for Marconi stabilization

[steve, gautam]

  1. We installed the FS725 on the shelf inside the PSL enclosure - see Attachment #1.
  2. We ran a long BNC cable (labelled "GPS 1pps" on both ends) from 1X7 to the PSL enclosure - this was to pipe the 1PPS signal from the GPS timing unit (EndRun Technologies Tempus LX) rear panel (50 ohm output according to the datasheet) to the 1PPS input of the FS725 (high impedance). See Attachments #2. Note that the 1pps output was already tee'd on the rear panel. One port of the tee was unused (this now goes to the FS725) while the other was going to the 1PPS input of the Master Timing Sequencer (D050239), so I decided that there was no need to tee the 1pps input of the FS725 with a 50ohm terminator. In a few minutes, the Rb standard indicated that it was locked to its internal reference, and also to the external 1pps input (see Attachment #1). 
  3. We ran a long BNC cable (labelled "Rb 10MHz" on both ends) from the 10MHz output of the FS725 (50 ohm output impedance),  in the PSL enclosure to the rear BNC "FREQ_STD IN/OUT" BNC connector of the Marconi (1kohm input impedance). Changed the frequency reference setting on the Marconi to "External Direct". The FS725 datasheet recommends terminating the load with a 50ohm inline terminator, I have not yet done this (see Attachment #3). Is it appropriate to use a Balun (FTB-1-1) here? This would avoid ground loops between the Marconi and the FS725, and also make the load seen by the FS725 50ohms
  4. Found that there was an unused long cable from the PSL enclosure to the 1X2 electronics rack. We re-purposed this to drive the AOM driver via the DAC output in 1Y2. The cable is labelled "AOM driver" on both ends. This was to facilitate measurement of the coupling of laser intensity noise to AS55_Q in a DRMI lock.
  5. Removed 2 long cables between 1X7 and 1X2 that weren't connected to anything.
  6. 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.
  7. Removed a couple of unused power cables from the mess on the shelf in the PSL enclosure. Also removed an unused Sony Video Squential Switcher YS-S6 from the PSL enclosure. 
Quote:

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. 

 

Attachment 1: IMG_7617.JPG
IMG_7617.JPG
Attachment 2: IMG_7619.JPG
IMG_7619.JPG
Attachment 3: IMG_7618.JPG
IMG_7618.JPG
  13363   Fri Oct 6 00:25:45 2017 ranaUpdateLSCFS725 for Marconi stabilization

Steve, can you please connect this fan to the rack power and remove this extra power supply?

Quote:

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.

  11735   Thu Nov 5 02:18:32 2015 gautamUpdateLSCFSR and linewidth measurements with phase tracker

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). 

  11738   Fri Nov 6 15:56:00 2015 gautamUpdateLSCFSR and linewidth measurements with phase tracker

Summary:

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).

Details:

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:

  1. Close PSL green and end green shutters. Turned off the power to the green transmission PDs on the PSL table and disconnected the couplers from their outputs.
  2. Connected the output of the Fluke 6061A RF signal generator to a splitter, and to the inputs of the couplers for the X and Y signal chains.
  3. Adjusted the amplitude of the RF signal output until the Q readout of the rotated X and Y outputs were between 1000 and 3000. The final value used was -17dBm. As a qualitative check, I also looked at the beat signal on the spectrum analyzer in the control room and judged the peak height to be roughly the same as that seen when a real beat note was being measured. The phase tracker gains after setting the UGF were ~83 and 40 for the X and Y arms respectively.
  4. Step through the frequency from 20MHz to 70MHz in steps of 1MHz, and record the outputs of (i) Digital frequency counter readout, and (ii) Phase tracker phase readout for the X and Y arms. I used the z avg -s utility to take an average for 10 seconds, and the standard deviation thus obtained correspond to the errorbars plotted. 
  5. Restore the connections to the green beat PDs and power them on again.

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.

Rubidium clock

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...

Attachment 1: Xcalib.pdf
Xcalib.pdf
Attachment 2: Ycalib.pdf
Ycalib.pdf
Attachment 3: Y_scan_log.pdf
Y_scan_log.pdf
Attachment 4: 2015-11-05_phase_tracker_calib.dat.zip
Attachment 5: 2015-11-04_y_arm_scan.dat.zip
  11740   Mon Nov 9 11:34:51 2015 yutaroUpdateLSCFSR and linewidth measurements with phase tracker

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.

 

Summary:

FSR = 3.9704 MHz (ave. of two FSRs, 3.9727 MHz and 3.9681 MHz)

finesse = 401 +/- 11

estimated loss = 1812 (+456 / - 431) ppm

 

Detail:

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. 

 

Note:

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.

 

Attachment 1: plt.png
plt.png
Attachment 2: fitresult_and_code.zip
  11741   Mon Nov 9 14:24:36 2015 yutaroUpdateLSCFSR and linewidth measurements with phase tracker

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. 

 

 

  11742   Mon Nov 9 15:59:06 2015 ericqUpdateLSCFSR and linewidth measurements with phase tracker
Quote:

- 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. 

  11743   Mon Nov 9 16:58:59 2015 gautamUpdateLSCFSR and linewidth measurements with phase tracker
Quote:

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. 

Summary:

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

Details:

  • To approximately locate the TEM10 and TEM20 resonances, I followed the methodology listed here (though confining myself to (m+n) = 1,2). 
  • To approximately locate the 11 MHz and 55 MHz sidebands, I used the mod command in MATLAB to locate approximately how far they should be from a carrier resonance. 
  • The results of these first two steps are demonstrated pictorially in Attachment #1. Red = carrier resonance, grey = 55MHz sideband resonance, cyan = 11MHz sideband resonance, green = TEM20 resonance, and yellow = TEM10 resonance
  • The FSR was calculated by fitting the center frequencies of fits to the three carrier resonances with a lorentzian shape, vs their index. The quoted error is the 95% C.I.s generated by MATLAB
  • The mode-matching efficiency was calculated by taking the fitted height of Lorentzian shapes to the TEM00, TEM10 and TEM20 shapes. The ratio of the peak heights was taken as a measure of the fraction of total power coupled into the TEM10 and TEM20 modes relative to TEM00. In calculating the final value, I took the average of the 3 available values for each peak to calculate the ratios.
  • The modulation depth was calculated by approximating that the ratio   \sqrt\frac{P_c}{P_s} = \frac{J_0(\beta)}{J_1(\beta)}, and solving for \beta. Attachment #2 shows a plot of the RHS of this equation as a function of \beta - the two datatips mark the location of the ratios on the LHS of the equation - both P_c and P_s were averaged over the 3 and 6 values available, respectively. The values I have obtained are different from those cited here - not sure why? The real red flag I guess is that I get the modulation depth at 11MHz to be larger than at 55MHz, whereas elog10211 reports the reverse... Do we expect a resonance for a 44MHz sideband as well? If so, it could be that the two peaks close to the carrier resonance is in fact the 55.30 MHz sideband resonance, and the peaks I've identified as 55MHz sideband resonances are in fact 44MHz sidebands.. If this were true, I would recover the modulation depth for 55.30 MHz sidebands to be approximately 0.22...

Misc Remarks and Conclusions:

  • The y-scale in Attachment #1 is log(transmission) - the semilogy command in MATLAB messed up the rendering of the overlaid semi-transparent rectangles, hence the need for adopting this scale...
  • I've attached the code used to split the entire scan into smaller datasets centered around each peak, and the actual fitting routine, in Attachment #3. I've not done the error analysis for the mode matching efficiency and the modulation depths, I will update this entry with those numbers as soon as I do. 
  • In my earlier elog11738, I had mislabelled some peaks as being sideband peaks - attachment #1 in this entry is (I think) a correct interpretation of the various peaks. 
  • There are two peaks on either side of every carrier resonance, spaced, on average, about 177kHz away from the resonance on either side. I am not sure what the interpretation of this peak should be - are they the 55.30 MHz resonances? 
  • These values should allow us to carry out alternative measurements of the round trip arm loss as estimating this from the cavity finesse seems to not be the best way to go about this. 

 

 

Attachment 1: Y_scan.pdf
Y_scan.pdf
Attachment 2: modDepth.pdf
modDepth.pdf
Attachment 3: Matlab_code.zip
  90   Fri Nov 9 21:36:14 2007 robConfigurationPSLFSS
rob, rana

We looked at the FSS a bit today. The most we could get out of it with the gain sliders was a UGF of around 95kHz. After a bit of tweaking the waveplate after the AOM, this got up to ~115kHz. We should be able to get at least 500kHz. This system needs a fair amount of work.
  95   Mon Nov 12 15:05:49 2007 robConfigurationPSLFSS

Spent a bit of time fiddling with the FSS again today. In a not-particularly-systematic manner, I raised the input-side of the 21.5MHz PC, adjusted the half-wave plate in front of it, touched up the RC alignment and the alignment onto the transmitted and reflected diodes. This got us a ~15% increase in
transmitted light, and I was able to push the UGF to 140kHz with the common gain slider at 30dB and the FAST gain slider at 22dB. The next options include adjusting the AOM setup, mode matching into the RC, and just increasing the pickoff fraction right from the getgo.
  127   Tue Nov 27 20:47:00 2007 tobinUpdatePSLFSS
Rana, Tobin

We looked at the RF PD signal to the FSS (siphoning off a signal via a minicircuits directional coupler) and also took an open loop transfer function of the FSS. In the transfer function we saw the step at 100 kHz (mentioned by Rob) as well as some peculiar behavior at high frequency. The high frequency behavior (with a coupling of ~ -20 dB) turns out to be bogus, as it is still present even with the beam blocked. Rearranging the cabling had no effect; the cause is apparently inside the FSS. The step at 100 kHz turns out to be a saturation effect, as it moved as we lowered the signal amplitude, disappearing as we approached -60 dBm. (Above the step, the measurement data is valid; below, bogus.)

Transfer functions will be attached to this entry.

Some things to check tomorrow: the RF signal to the PC, RF AM generation by the PC, LO drive level into the FSS, RF reflection from the PC, efficiency of FSS optical path, quality of RF cabling.
Attachment 1: fss-tf0001.pdf
fss-tf0001.pdf fss-tf0001.pdf
  128   Wed Nov 28 04:21:46 2007 ranaUpdatePSLFSS

Quote:
Rana, Tobin

We looked at the RF PD signal to the FSS (siphoning off a signal via a minicircuits directional coupler) and also took an open loop transfer function of the FSS. In the transfer function we saw the step at 100 kHz (mentioned by Rob) as well as some peculiar behavior at high frequency. The high frequency behavior (with a coupling of ~ -20 dB) turns out to be bogus, as it is still present even with the beam blocked. Rearranging the cabling had no effect; the cause is apparently inside the FSS. The step at 100 kHz turns out to be a saturation effect, as it moved as we lowered the signal amplitude, disappearing as we approached -60 dBm. (Above the step, the measurement data is valid; below, bogus.)

Transfer functions will be attached to this entry.

Some things to check tomorrow: the RF signal to the PC, RF AM generation by the PC, LO drive level into the FSS, RF reflection from the PC, efficiency of FSS optical path, quality of RF cabling.


I would also add to Tobin's entry that we believe what Rob was seeing was saturation.

With the bi-directional coupler in there, the RF signal into the FSS board clearly went UP if moved the offset slider away from zero.
With a scope looking at the IN2 testpoint, we can see that there's less than 2 mV offset at zero slider offset.

One tangential thing we noticed with the coupler is that, in lock, the amount of reflected RF is around the same as that going in to the mixer.
I have always wanted to look at this but have only had uni-directional couplers in the past. I think that the double balanced mixer is inherently
not a 50 Ohm device during the times where the diodes are being switched. IF that's the case we might do better in the future by having an RF
buffer on board just before the mixer to isolate the PD head from these reflections.
  736   Thu Jul 24 21:04:58 2008 ranaUpdatePSLFSS
Since Jenne and Yoichi are going to finish up their refcav/FSS work in the morning I decided to
look at the trends. I set the RF modulation level from 10.0 back down to 7.5 so that we would
have the same RF modulation depth as before. I also set the FSS common gain and its nominal to
1.0 dB since it seemed more stable this way.

With 7.5, the transmission of the refcav is ~6.9 V. It was around 0.7 V before so there's already
been a factor of 10 improvement in the power since the work started. In addition to the mode matching
work which is about to commence, we should attenuate the RC TRANS with a real mirror (not ND) so that
the camera and PD don't saturate. We should also do the same for the REFL PD and camera and make sure
to put in a steering mirror for the REFL PD and orient REFL so that it faces West (so that we can
look at its face with a viewer) and dumps its reflection.

Since the common gain is so low now, I expect that we will want less light in total. We can achieve
this by turning down the RF drive to the VCO.

I also fixed the MC down script which was putting the FSS common gain to the unstable +10 dB level
during the MC locking process.
  7530   Thu Oct 11 12:02:15 2012 DenUpdateIOOFSS

FSS SLOW control did not drift during the lock at night with MCL path working and AC coupled.

fss.png

  909   Tue Sep 2 07:58:34 2008 ranaSummaryPSLFSS & PMC LO trends for 2 years
The attached plot is a 2 year minute trend of the EPICS readback of the PMC & FSS LO Monitors (FSS_LODET & PMC_LODET).
Clearly the FSS LO has been dying for at least 2 years. The step up from 10 months
ago is probably when Rob removed a 3dB attenuator from in front of the box.
Attachment 1: psl-lo-trend.png
psl-lo-trend.png
  3568   Mon Sep 13 19:41:38 2010 ranaUpdatePSLFSS AOM alignment

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:

 

PSLAOMdogs
  3506   Wed Sep 1 11:34:39 2010 AlbertoUpdateElectronicsFSS Box Phase Noise from DAQ

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.

2010-09-01_FSSPhaseNoise.png

The measurement was done as shown in this diagram.

2010-09-01_FSSphaseNoiseMeasurementSetup.png

  3508   Wed Sep 1 12:34:14 2010 ranaUpdateElectronicsFSS Box Phase Noise from DAQ

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.

  3509   Wed Sep 1 16:29:28 2010 AlbertoUpdateElectronicsFSS Box Phase Noise from DAQ - Measurement setup modified

Quote:

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:

FSSphaseNoiseMeasurementSetup02.png

And the phase noise that I measure is this:

2010-09-01_FSSPhaseNoise_DAQ_02.png

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.

2010-09-01_FSSPhaseNoise_DAQ_00-02_comparison.png

  3510   Wed Sep 1 17:17:42 2010 ranaUpdateElectronicsFSS Box Phase Noise from DAQ - Measurement setup modified

With the setup now working, we should now test the power filtering for the crystal and amplifier.

  912   Tue Sep 2 14:28:41 2008 YoichiUpdatePSLFSS EOM driving signal spectra
Rich advised me to change the +10V input of the FSS crystal frequency reference board from whatever voltage supply we use now to a nice one.
This voltage is directory connected to the signal lines of both LO and RF output amps. Therefore, fluctuations in the voltage directly appear
in the outputs, though DC components are cut off by the AC coupling capacitors.

I changed the source of this voltage from the existing Sorensen one to a power supply sitting next to the rack.
The attached plots shows the difference of the RF output spectra between the two 10V sources.
The low frequency crap is almost gone in the new 10V spectrum.

I tried to increase the FSS gain with the new 10V, but still it goes crazy. I suspect it is because the LO power is too low.
Attachment 1: RFDrive1.png
RFDrive1.png
Attachment 2: RFDrive2.png
RFDrive2.png
  10173   Thu Jul 10 02:09:20 2014 JenneUpdatePSLFSS Fast gain set

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.

  3499   Tue Aug 31 17:58:38 2010 AlbertoUpdateElectronicsFSS Frequency Generation Box - Phase Noise

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:

2010-08-31_FSSPhaseNoise04modified.png

(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.

  3484   Sat Aug 28 08:17:51 2010 AbertoUpdateElectronicsFSS Frequency Generation Box under test

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.

  569   Wed Jun 25 18:03:21 2008 YoichiConfigurationPSLFSS Input Offset slider problem
While working on the PMC scanning, I noticed that the FSS input offset slider is doing nothing.
I traced the signal flow and checked the cables/boards.
The slider changes the output voltage from a VMIVME4116 DAC in the PSL rack. This output voltage is confirmed to be correct at the FLKM64 connector. The signal is connected to the FSS servo interface box (D040423) trough a ribbon cable. However, the output from the interface box is always -27V regardless of the slider position.
Therefore, either the interface box (D040423) or the ribbon cable has a problem.
I will debug the interface box using an extension card when no one is working on the interferometer.
  1078   Thu Oct 23 20:47:28 2008 peteConfigurationPSLFSS LO calibration for MEDM
Today I took a quick series of measurements to calibrate the FSS LO power measurement in the MEDM. This was done by using the spec.an. to measure the 21.5 MHz peak in dBm at the LO input to the FSS box on the PSL table, and recording the MEDM value, for attenuations applied at the FSS REF box output ranging from -5 dBm to -30 dBm.

I measured the loss due to the BNC cable I used, which was (19.66-19.50) dBm. I accounted for this and plotted ln(MEDM) vs. dBm on the attached plot. A linear fit of this gives the CALC field of a calc record for the IOC db:
6.29*LOGE(A)+5.36

Since no one knew how to do this nonlinear conversion in EPICS I will describe how to do it in detail tomorrow. It is simple, although it requires power cycling the scipe3 bunch (typing "reboot" or "ctl-x" at the command prompt took it down, but it did not come back). I did power cycle those computers a few times today.
Attachment 1: fss_lo_calibration.png
fss_lo_calibration.png
  1083   Fri Oct 24 11:21:26 2008 peteConfigurationPSLFSS LO input calibrated in dBm
Based on the measurements described in my previous elog, I created a new calc record in the file /cvs/cds/caltech/target/c1psl/psl.db
grecord(calc, "C1:PSL-FSS_LOCALC")
{
        field(INPA,"C1:PSL-FSS_LODET")
        field(SCAN,".1 second")
        field(PREC,"4")
        field(CALC,"6.29*LOGE(A)+5.36")
}

After restarting scipe3 to load this change, I told C1PSL_FSS.adl to look at this record instead of *LODET. That MEDM screen now shows LO input calibrated in dBm.

For reference, the operators available for use in the CALC field are listed in the EPICS Record ref manual, Chapter 9. The manual can be found here:
http://www.aps.anl.gov/epics/EpicsDocumentation/AppDevManuals/RecordRef/Recordref-3.html

Yoichi said he was fixing an SVN problem, so I have not yet committed the two files I changed: /cvs/cds/caltech/target/c1psl/psl.db and /cvs/cds/caltech/medm/c1/psl/C1PSL_FSS.adl.
  1431   Thu Mar 26 04:01:24 2009 YoichiUpdatePSLFSS Open Loop Gain
Yoichi, Peter, Jenne

Attached is the open loop transfer function of the FSS as of today with the common gain = 12dB and the fast gain = 16dB.
The UGF is only 250kHz. If we increase the common gain, the PC goes crazy. Exactly the same symptom as before I fixed the oscillating op-amp.

I wanted to check the cross over frequency but there is no excitation point in the fast path nor PC path. Therefore, it is not easy.
Attachment 1: OpenLoopTF.png
OpenLoopTF.png
  3285   Sat Jul 24 14:03:19 2010 AlbertoUpdateElectronicsFSS Oscilaltor Phase Noise Measurement

[Rana, Alberto]

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.

Attachment 1: FSScrystalPhaseNoiseHigherGain.pdf
FSScrystalPhaseNoiseHigherGain.pdf
  3286   Sat Jul 24 14:27:36 2010 ranaUpdateElectronicsFSS Oscilaltor Phase Noise Measurement

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.

  1064   Tue Oct 21 17:52:30 2008 ranaSummaryPSLFSS Photo: early October
This is a photo of the FSS board before Yoichi did his surgery - it was taken with the D40 in macro mode, sitting on the big Gorilla pod.
Attachment 1: fss.jpg
fss.jpg
  719   Wed Jul 23 01:42:26 2008 ranaConfigurationPSLFSS RFPD: Examined, "repaired", and re-installed
Rob said that there might be something wrong with the FSS RFPD since the loop gain is so low.
Next time we should just use the Jenne laser on it in-situ and compare with our reference.

We had a 24.5 MHz LSC PD which Rob got from Sam. Sam got it from Rai. I gave it to Rai in Livingston
because it seemed suspicious. Seems fine now. This black box PD had a lower overall response than
the goldbox one we already had. The 2001-2005 era diodes which we got from the Canadian Perkin-Elmer
all had high capacitance and so that's not a surprise.

So the goldbox one was not broken totally.

I found that the offset came from a cracked capacitor. C25 was a yellow thru-hole ceramic 0.1 uF.
Its a surface mount board...don't know why this was like this but there's also no reason it should
have cracked unless it was soldered on with too much heat. I replaced it with a 0.47 uF ceramic
surface mount. Also R24 was a 20 Ohm resistor and L3 was not stuffed?? Removed R24 and put a 1 uH
inductor into L3. This is there so that the input to the MAX4107 is AC coupled.

However, the DC signal that Rob saw was actually because of the cracked C25. It had shorted and was
making a 25 mV signal at the input to the MAX4107 which has a gain of 10. This was producing ~165 mVdc
into a 50 Ohm load and so it could have saturated most mixers. The FSS board, however, has an overly
monstrous level 21 (I think) mixer and so this should not have been an issue. Maybe.

I was able to lock with the 24.5 MHz black box PD but it was not too hard to repair the gold box one
so I did. I tuned it so that the notch is truly at 43 MHz (2x the FSS 21.5 MHz modulation) but because
someone has done this using a hacky cap in parallel with the main PD, I am unable to get the resonant
peak to line up at 21.5 MHz. Its at 23 MHz instead. This loses us ~2 dB in signal. Since the frequency
is so low, we can increase the gain in the MAX4107 by another factor of 3 or so in the future.


So the PD is not our problem. Still worth verifying that the cable is good -- its around 10 miles long!!
And loops around in there with a bunch of other cables. We have an electronic phase shifter so this seems
totally misguided.

The other bad problem is that the mode matching is pretty horrible. Something like 1/3 of the carrier
power doesn't go into the cavity.
FSS TODO:
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
   mode matching.

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.

The attached PDF shows photos of the old and new style PDs. One page 3 there's a wire that I soldered on
as a handle so that we can remove the RF can (occasionally people claim that soldering to the lid screws
up the magnetic shielding magic of the lid. use this as a litmus test of their electronics know-how; its
a tin can - not an orgone box). Pages 4 & 5 are the circuit before I soldered, page 6 the cap after I
tried to remove it, page 7 is the circuit after I put in the new cap, and page 8 is the schematic with
the mark up of the changes.
Attachment 1: Untitled.pdf
Untitled.pdf Untitled.pdf Untitled.pdf Untitled.pdf Untitled.pdf Untitled.pdf Untitled.pdf Untitled.pdf
  11332   Thu May 28 17:00:04 2015 KojiUpdateIOOFSS SLOW not engaged: is this intentional?

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).

  11333   Thu May 28 17:12:32 2015 ericqUpdateIOOFSS SLOW not engaged: is this intentional?

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. 

  3109   Wed Jun 23 18:05:00 2010 KojiConfigurationPSLFSS SLOWDC should be ~-4.0

FSS SLOWDC slider is at around 0.

Please someone relock this at ~-4.0 to exploit some last juice of the fruit.

See this entry for the details of the operating point.

 

Attachment 1: C1PSL_FSS.png
C1PSL_FSS.png
  3110   Wed Jun 23 23:08:30 2010 ranaConfigurationPSLFSS SLOWDC should be ~-4.0

 

  7265   Thu Aug 23 22:44:32 2012 KojiUpdatePSLFSS Slow DC servo is turned off (not temporary)

[Koji Rana]

The FSS Slow DC servo was turned off.

As MCL stabilizes the MC_F (Fast PZT), we no longer need to use the laser temp to do so.

In other word, if you like to turn off the MCL servo for some reason, we need to turn it on in order to keep the MC locked.

  13249   Thu Aug 24 17:36:11 2017 gautamUpdateCDSFSS Slow Python maintenance

A couple of weeks ago, I was trying to modernize the python version of the FSS Slow temperature control loops, when I accidentally ended up deleting it frown. There was no svn backup. So the old Perl PID script has been running for the last few days.

Today, I checked out the latest version that Andrew and co. have running in the PSL lab. I had to make some important modifications for the script to work for the 40m setup.

  1. The script is conveniently setup in a way that the channels it needs to read from / write to are read in from an .ini file. I renamed all the channels to match the appropriate 40m ones.
  2. We don't have a soft epics channel in which to define the setpoint for our PID servo (which is 0). Rather than poke around with slow machine EPICS records, I simply commented out this line in the script and included the hard-coded value of 0. When we modernize to the Acromag era, we can setup an EPICS channel + MEDM slider for the setpoint.
  3. The way the Perl script was setup, the error signal was pre-scaled by a factor of 0.01, supposedly to make the PID gains be of order 1. For consistency, I re-inserted this scaling, which awade and co. had removed.
  4. Modified the FSSslowPy.init file to call the script in accordance with the new syntax:
python FSSSlow.py -i FSSSlowPy.ini

Then I stopped the Perl process on megatron by running

sudo initctl stop FSSslow

and started the Python process by running

sudo initctl start FSSslowPy

I have now committed the files FSSSlow.py and FSSSlowPy.ini to the 40m svn.  Things seem to be stable for the last 20 mins or so, let's keep an eye on this though - although we had been running the Python PID loop for some months, this version is a slightly modified one. 

The initctl stuff still isn't very robust - I think both the Autolocker and the FSS slow servos have to be manually restarted if megatron is shutdown/restarted for whatever reason. It doesn't seem to be a problem with the initctl routine itself - looking at the logs, I can see that init is trying to start both processes, but is failing to do so each time. To be investigated. The wiki procedure to restart this process is up to date.

GV Edit 0000 25 Aug 2017: I had to add a line to the script that checks MC transmission before enabling the PID loop. Change has been committed to svn. Now, when the MC loses lock or if the PSL shutter is kept closed for an extended period of time, the temperature loop doesn't rail.

  12627   Fri Nov 18 17:52:42 2016 gautamUpdatePSLFSS Slow control -> Python, WFS re-engaged

[yinzi, craig, gautam]

Yinzi had translated the Perl PID script used to implement the discrete-time PID control, and had implemented it with Andrew at the PSL lab. Today afternoon we made some minor edits to make this suitable for the FSS Slow loop (essentially just putting the right channel names into her Python script). I then made an init file to run this script on megatron, and it looks to be working fine over the last half hour of observation or so. I am going to leave things in this state over the weekend to see how it performs.


We have been running with just the MC2 Transmission QPD for angular control of the IMC for a couple of months now because the WFS loops seemed to drag the alignment away from the optimum. We did the following to try and re-engage the WFS feedback:

  • Close the PSL shutter, turned off all the lights in the lab and ran the WFS DC offsets script : /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_DC_offsets
  • Locked the IMC, optimized alignment by hand (WFS feedback turned off) /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_DC_offsets
  • Unlocked the IMC, went to the AS table and centered the spots on the WFS
  • Ran WFS RF offsets script - this should be done with the IMC unlocked (after good alignment has been established) /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_DC_offsets
  • Re-engaged WFS servo

GV addendum 23Nov2016: The WFS have been working well over the last few days - I've had to periodically (~ once in a day) run the WFS reflief script to keep the outputs to the suspension PIT and YAW DOFs below 50cts, but the WFS aren't dragging the alignment away as we had noticed before. The only thing I did differently is to follow Rana's suggestion and set the RF offsets with the MC unlocked as opposed to locked. I've added a line to the script to remind the user to do so... Also, note that EricQ has recently cleaned up the scripts directory to remove the numerous obsolete scripts in there...

 

  12628   Sun Nov 20 23:53:38 2016 awadeUpdatePSLFSS Slow control -> Python, WFS re-engaged

I made a very slighly updated version of Yinzi's script that pulls the channel names and actuator hardstop limits from an external .ini config file. The idea was to avoid having as many versions of the script as there are implimentations of it. Seems like slighly better practice, but maybe I'm wrong. The config files are also easier to read. Its posted on the elog (PSL:1758) with lastest on the 40mSVN .../trunk/CTNLab/current/computing/scripts . 

If you're working off her first implimentation 'RCAV_thermalPID.py' then there is an indent issue after the if statement on line 88: only line 89 should be indended. If you deactivate the debug flag then the script fails to read in PID factors and dies.

Quote:

[yinzi, craig, gautam]

Yinzi had translated the Perl PID script used to implement the discrete-time PID control, and had implemented it with Andrew at the PSL lab. Today afternoon we made some minor edits to make this suitable for the FSS Slow loop (essentially just putting the right channel names into her Python script). I then made an init file to run this script on megatron, and it looks to be working fine over the last half hour of observation or so. I am going to leave things in this state over the weekend to see how it performs.


We have been running with just the MC2 Transmission QPD for angular control of the IMC for a couple of months now because the WFS loops seemed to drag the alignment away from the optimum. We did the following to try and re-engage the WFS feedback:

  • Close the PSL shutter, turned off all the lights in the lab and ran the WFS DC offsets script
  • Locked the IMC, optimized alignment by hand (WFS feedback turned off)
  • Unlocked the IMC, went to the AS table and centered the spots on the WFS
  • Ran WFS RF offsets script
  • Re-engaged WFS servo

 

 

  14472   Sat Mar 2 14:19:35 2019 gautamUpdateCDSFSS Slow servo gains not burt-ed

PSL NPRO PZT voltage showed large low frequency (hour timescale) excursions on the control room StripTool trace, leading me to suspect the slow servo wasn't working as expected. Yesterday evening, I keyed the unresponsive c1psl crate at ~9 PM PST, and had to run the burtrestore to get the PMC locking working. I must have pressed the wrong button on burtgooey or something, because all the FSS_SLOW channels were reset to 0. What's more, their values were not being saved by the hourly burt-snap script, so I don't have any lookback on what these values were. There isn't any detailed record on the elog about what the optimal values for these are, and the most recent reference I could find was Ki=0.1, Kp=Kd=0, which is what I've set it now to. The servo isn't running away, so I'm leaving things in this state, PID tuning can be done later.

I also added the FSS Slow servo channels to the burt snapshot requirement file at /cvs/cds/caltech/target/c1psl/autoBurt.req, and confirmed that the snapshots are getting the channels from now onwards.

While looking at the req file, I saw a bunch of *_MOPA* channels and also several other currently unused channels. Probably would benefit from going through these and commenting out all the legacy channels, to minimize disk space wastage (though we compress the snapshot files every few years anyways I guess).

Reminder that this (unrelated) issue still needs to be looked into... Note also that the new vacuum system does not have burt snapshot set up (i.e. it is still trying to get the old channels from the c1vac1 and c1vac2 databases, which while has significant overlap with the new system, should probably be setup correctly).

  10820   Fri Dec 19 16:59:32 2014 ericqUpdateComputer Scripts / ProgramsFSS Slow servo moved to megatron

Given that op340m showed some undesired behavior, and that the FSS slow seems prone to railing lately, I've moved the FSS slow servo job over to megatron in the same way I did for the MC autolocker. 

Namely, there is an upstart configuration (megatron:/etc/init/FSSslow.conf), that invokes the slow servo. Log file is in the same old place (/cvs/cds/caltech/logs/scripts), and the servo can be (re)started by running: 

controls@megatron|~ > sudo initctl start FSSslow

Maybe this won't really change the behavior. We'll see

  10824   Fri Dec 19 20:44:23 2014 JenneUpdateComputer Scripts / ProgramsFSS Slow servo moved to megatron

Today Q moved the FSS slow servo over to some init thing on megatron, and some time ago he did the same thing to the MC auto locker script.  It isn't working though.

Even though megatron was rebooted, neither script started up automatically.  As Diego mentioned in elog 10823, we ran sudo initctl start MCautolocker and sudo initctl start FSSslow, and the blinky lights for both of the scripts started.  However, that seems to be the only thing that the scripts are doing.  The MC auto locker is not detecting lockloses, and is not resetting things to allow the MC to relock.  The MC is happy to lock if I do it by hand though.  Similarly, the blinky light for the FSS is on, but the PSL temperature is moving a lot faster than normal.  I expect that it will hit one of the rails in under an hour or so. 

The MC autolocker and the FSS loop were both running earlier today, so maybe Q had some magic that he used when he started them up, that he didn't include in the elog instructions?

  10825   Sat Dec 20 00:00:03 2014 ericqUpdateComputer Scripts / ProgramsFSS Slow servo moved to megatron

I ssh'd in, and was able to run each script manually successfully. I ran the initctl commands, and they started up fine too. 

We've seen this kind of behavior before, generally after reboots; see ELOGS 10247 and 10572

  10840   Tue Dec 23 18:43:33 2014 diegoUpdateComputer Scripts / ProgramsFSS Slow servo moved to megatron

Quote:

I ssh'd in, and was able to run each script manually successfully. I ran the initctl commands, and they started up fine too. 

We've seen this kind of behavior before, generally after reboots; see ELOGS 10247 and 10572

In the plot it is shown the behaviour of the PSL-FSS_SLOWDC signal during the last week; the blue rectangle marks an approximate estimate of the time when the scripts were moved to megatron. Apart from the bad things that happened on Friday during the big crash, and the work ongoing since yesterday, it seems that something is not working well. The scripts on megatron are actually running, but I'll try and have a look at it.

  10844   Fri Dec 26 18:20:42 2014 ranaUpdateComputer Scripts / ProgramsFSS Slow servo thresh change

Quote:

 

In the plot it is shown the behaviour of the PSL-FSS_SLOWDC signal during the last week; the blue rectangle marks an approximate estimate of the time when the scripts were moved to megatron. Apart from the bad things that happened on Friday during the big crash, and the work ongoing since yesterday, it seems that something is not working well. The scripts on megatron are actually running, but I'll try and have a look at it.

I guessed that what was happening was that the SLOW servo settings were not restored to the right values after the code movements / reboots. The ON threshold for the servo was set at +6 counts and the channel is MC TRANS. Since the ADC noise on that channel is ~50 counts, this means that the servo keeps pushing the laser temperature off in some direction when the MC is unlocked.

I reset the threshold to +6666 counts (the aligned MC transmission is ~16000 for the  TEM00 mode) so that it only turns on when we're in a good locked state.

ELOG V3.1.3-