40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 79 of 344 Not logged in
ID Date Author Type Category Subject
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
Attachment 2: 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
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.

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

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.

The measurement was done as shown in this diagram.

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:

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.

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
Attachment 2: 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:

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

17261   Fri Nov 11 20:01:56 2022 ranaFrogsComputer Scripts / ProgramsFSS SLOW servo not running

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.

17262   Fri Nov 11 20:59:13 2022 ChrisFrogsComputer Scripts / ProgramsFSS SLOW servo not running

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.

 Quote: 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.
17263   Sat Nov 12 21:59:24 2022 AnchalFrogsComputer Scripts / ProgramsFSS SLOW servo not running

I stopped the Docker PID script and started the old python script on megatron. Instructions on how to do this are here.

On optimus I ran:

sudo docker stop scripts_PID_FSS_Slow_1

On megatron I ran:

sudo systemctl enable FSSSlow
sudo systemctl restart FSSSlow

However, the daemon service keeps failing and restarting. So currently the FSSSlow is not running. I do not know how to debug this script.

On a side note, I tested the docker service by restarting it, and it was working. From the logs, it seems like it got stuck because it could not find C1:IOO-MC_LOCK channel which occurs when c1psl epics servers fail or get stuck. The blinker on this script runs when the script is running but it does not stop if the script gets stuck somewhere. If someone decides to use this script in the future, they would need to correct error catching so that no reply from caget looks like an error and the script restarts rather than keep trying to get the channel value. Or the blinker implementation should change in the script so that it displays a stuck state.

17281   Thu Nov 17 16:48:07 2022 AnchalFrogsComputer Scripts / ProgramsFSS SLOW servo running Now

I've moved the FSS Slow PID script running to megatron through systemd daemons. The script is working as expected right now. I've updated megatron motd and the always running scripts page here.

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

1842   Thu Aug 6 09:33:08 2009 albertoUpdateLockingFSS Transmitted and Reflected Power Trends

I've now also trended the MOPA output power for the last 200 days to check a possible correlation with the FSS reflected power. See attachment.

The trend shows that the laser power has decayed but it seems that the FSS reflected power has done it even faster: 30% drop in the FSS vs 7% for the MOPA in the last 60 days (attachment n.2).

Attachment 1: 2009-08-06_PSL_trends200days.png
Attachment 2: 2009-08-06_PSL_trends.png
1079   Thu Oct 23 21:52:27 2008 YoichiUpdatePSLFSS UGF now 450kHz
I measured the open loop transfer function of the FSS, for the first time after I mitigated the oscillation.
The attached plot shows the comparison of the OPLTF before and after the oscillation was mitigated.
Blue curves are when AD797 was oscillating, and the red ones are after AD797s were replaced by AD829s.
The FSS gain slider values are the same for the both measurements.
There is a notable difference in the shape of the TF.
Right now the UGF is around 450kHz with the phase margin of 50deg.
When the gain is increased by a few dBs in the common gain slider, the PC path becomes saturated.
This might be caused by the peak in the OPLTF at 1.7MHz sticking out of the 0dB line.
Another peak at 770kHz is also annoying.
Too bad that I did not take the TF above 1MHz before the oscillation was mitigated.
Also at 100kHz, the new TF has a lower gain than the old one, although it looks like the slope of the red curve is getting steeper and
it is catching up the blue one at lower frequencies.
I will measure the TF below 100kHz later.

With this bandwidth, I was able to increase the MC gain further.
I will report on the MC open loop measurements soon.
Attachment 1: FSS_OPLTF.png
2720   Sun Mar 28 20:05:33 2010 ranaSummaryPSLFSS Work from Sunday: AOM/VCO level set wrong

Just before working on the FSS today, I noticed that the VCO RF output level was set incorrectly.

This should ALWAYS be set so as to give the maximum power in the first order diffracted sideband. One should set this by maximizing the out of lock FSS RFPD DC level to max.

The value was at 2.8 on the VCOMODLEVEL slider. In the attached plot (taken with the FSS input disabled) you can see that this puts us in the regime where the output power to the FSS is first order sensitive to the amplitude noise on the electrical signal to the AOM. This is an untenable situation.

For adjusting the power level to the FSS, we must always use the lamba/2 plate between the AOM and the RC steering mirrors. This dumps power out to the side via a PBS just before the periscope.

Attachment 1: Untitled.png
2721   Sun Mar 28 20:51:31 2010 ranaSummaryPSLFSS Work from Sunday: Cavity Suspension is Ridiculously Undamped!

What is the Transfer Function of the suspension of the reference cavity? What were the design requirements? What is the Q and how well does the eddy current damping work? What did Wolfowitz know about the WMD and when? Who cooked the RTV in there and why didn't we use Viton??

To get to the bottom of these questions, today I shook the cavity and measured the response. To read out the pitch and yaw modes separately, I aligned the input beam to be misaligned to the cavity. If the beam is mis-aligned in yaw, for example, the transmitted light power becomes first order sensitive to the yaw motion of the cavity.

In the attached image (10 minute second-trend), you can see the second trends for the transmitted and relfected power. The first ringdown comes from the pitch or vertical mode. The second (shorter) one comes from the yaw misalignment and the yaw shake.

To achieve the up/down shake, I leaned onto the table and pumped it at its eigenfrequency. For the yaw shake, I put two fingers on the RC can's sweater and pushed with several pounds of force at the yaw eigenfrequency (2.6 Hz). For the vertical, I jumped up and down at half the vertical eigenfrequency (4 Hz).

I also made sure that the .SCAN field on these EPICS records were set to 9 so that there is no serious effect from a beating between the eigenfrequency and the EPICS sample rate.

Punchline:

f_vert   = 4 Hz

tau_vert = 90 seconds

Q_vert   = 1000            (yes, that number over there has 3 zeros)

f_hor    = 2.6 Hz

tau_hor  = 30 seconds

Q_hor    = 250

This is an absurd and probably makes us very sensitive to seismic noise - let's make sure to open up the can and put some real rubber in there to damp it. My guess is that these high Q modes

are just the modes of the last-stage steel spring / pendulum.

Attachment 1: Untitled.png
2723   Sun Mar 28 23:47:47 2010 ranaSummaryPSLFSS Work from Sunday: Open Loop Gain

I measured the open loop gain of the FSS (as usual, I have multiplied the whole OLG by 10dB to account for the forward loop gain in the box). I used a source level of -20 dBm and made sure this was not saturating by changing the level.

Its clear that the BW is limited by the resonance at ~1.7 MHz. Does anyone know what that is?

Attachment 1: fssloop.png
Attachment 2: sweep2.png
2726   Mon Mar 29 02:07:50 2010 KojiSummaryPSLFSS Work from Sunday: Open Loop Gain

 Quote: I measured the open loop gain of the FSS (as usual, I have multiplied the whole OLG by 10dB to account for the forward loop gain in the box). I used a source level of -20 dBm and made sure this was not saturating by changing the level. Its clear that the BW is limited by the resonance at ~1.7 MHz. Does anyone know what that is?

EO resonance in the RC path?

ELOG V3.1.3-