40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 77 of 335  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  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.

  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
2009-08-06_PSL_trends200days.png
Attachment 2: 2009-08-06_PSL_trends.png
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
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
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
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
fssloop.png
Attachment 2: sweep2.png
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?

  2724   Mon Mar 29 01:11:33 2010 ranaSummaryPSLFSS Work from Sunday: RF Out Spectrum

I measured the RF spectrum coming out the FSS RFPD to look for saturations - its close to the hairy edge. This is with the 8x power increase from my AOM drive increase. I will increase the FSS's modulation frequency which will lower the Q and gain of the PD to compensate somewhat. The lower Q will also gain us phase margin in the FSS loooop.

 

I put in a bi-directional 20 dB coupler (its only rated down to 30 MHz, but its only off by ~0.3 dB at 21 MHz) between the RFPD and the FSS box. I looked at the time series on the 300 MHz scope and measured the power spectrum.

The peak signal on the scope was 40 mV; that translates to 400 mV at the RFPD output. Depending on whether the series resistor in the box is 20 or 50 Ohms, it means the MAX4107 is close to saturating.

As you can see from the spectrum, its mostly likely to hit its slew rate limit (500 V/us) first. Actually its not going to hit the limit: but even getting within a factor of 10 is bad news in terms of distortion.

Besides the multiples of the modulation frequency, you can see that most of the RMS comes from the strange large peaks at 137.9 and 181.1 MHz. Anyone know what these are from?

TEK00000.PNGTEK00001.PNGTEK00002.PNG

On the middle plot above, I have enabled the 20 MHz BW limit so you can see how much the amplitude goes down when only the 21.5 MHz SB is included. You can also see from the leftmost plot that once in awhile there is some 400mV/10ns slewing. Its within a factor of 10 of the slew rate limit.

Attachment 1: rfout.png
rfout.png
  2722   Sun Mar 28 23:17:46 2010 ranaSummaryPSLFSS Work from Sunday: noise spec

This is the error point spectrum - it is filled with huge multiples of ~75 kHz as Yoichi noticed a couple years ago.

I tried to use the netgpib.py package to read out the Agilent 4395, but the SVN had been corrupted by someone saving over the netgpib.py package. To get it to work on rosalba I reverted to the previous version, but whoever is busy hacking on netgpib.py needs to checkin the original package and work on some test code instead.

I also noticed that the default output format for the AG4395.py file is in units of Watts. This is kind of dumb - we need someone to develop this package a little as Yoichi did for the SRS785.

Attachment 1: in2.png
in2.png
  134   Wed Nov 28 17:41:34 2007 robUpdatePSLFSS again
I investigated the FSS a bit more today. I looked at the signals coming out of the FSS frequency reference, and saw that both the LO and PC drive were distorted, non-symmetric waveforms. In addition, the LO path had a 3dB attenuator, meaning the mixer was starved. I placed mini-circuits SLP-30 filters in both paths, and now both are nice sine waves. I also took out the 3dB att. With this work, and the CG slider maxed out at 30, the FSS open loop gain (for real this time) goes up to ~250kHz. Still needs more investigation.
  1061   Mon Oct 20 20:50:09 2008 YoichiConfigurationPSLFSS board chip replacement
A quick update.

I changed two AD797s on the FSS board to AD829s to mitigate the 50MHz oscillation, which I plan to report later.
For some reason, the PA85 was broken after the replacement. So I had to replace it with a spare one too.
Right now the FSS is back and working. The oscillation is gone.
However, the maximum achievable gain is still about the same as before.
  10370   Tue Aug 12 18:20:13 2014 ericqUpdateIOOFSS box TFs

I made some measurements of the FSS box today, to have TFs for a loop model, but also to see what the difference between the different inputs was. 

As a reminder, the FSS box takes the error signal from the MC servo, does some filtering, and sends out two outputs: one to the laser PZT via KojiBox and Thorlabs HV amplifier, and one to be summed with the PMC modulation signal to the PC. Rana found the schematic at D040105

The MC error signal currently enters via a port called "IN1", but there is also a "Test 1 in," which experiences different filtering. I measured the TFs from each of these inputs to both the FAST and PC outputs. There is also an IN2, that is added after the offset point, but was not able to make a good measurement, for reasons unknown. From these TFs, I inferred the difference between the PC and FAST path, as well as the difference between IN1 and Test 1 in.

Specifically, I plugged the cable that is usually connected to the MC servo output, labelled "TO FSS BOX", into the RF out of the AG4395. I then took a BNC cable from the FAST out, or PC out, and fed it into a mini circuits DC block (BLK-89-S+), and then into input A, after checking on a scope that the signal was roughly zeroed and not too huge. Unbeknownst to me at the time, the PC drive output can be pretty big, and could potentially fry the analyzer's input. Fortunately, I think I avoided this fate. 

FSSbox.pdfFSSfilt.pdf

A ~1.3 MHz bump can be seen here, which would conspire with the bump in the demod board I measured yesterday, to steal even more phase around 1MHz. Maybe we can modify the FSS box to help our gain peaking situation out. 

The data is attached.

RXA: Shazam!

Attachment 3: FSSdata.zip
  10380   Wed Aug 13 23:08:17 2014 ranaUpdateIOOFSS box TFs

As EQ pointed out recently, we're injecting into the FSS error point just after an RF pi filter, but before the VGA. We wondered what the weird filter impedance was doing to our signal if we inject after it. I used LISO to model this FSS common section and attach the plots.

The first plot shows the TF between the Test 1 input and the AD602 VGA input. This is NOT the input that we are actually using.

The second plot shows the TF between the IN1 port (which we are actually using) and the VGA input.

Neither of them shows the 1 MHz bump that we see in the measurements, so I suspect that the board has been modified...the hunt continues. We've got to pop the top of the TTFSS and take photos and measure from IN1 to VGA input.

** FSScomm.fil is now in the LISO SVN. The following command line will run it with two different cases and cat the PDF files into one. If you use an auto-refresh PDF viewer like Okular or Mac Preview, its a nicer display than the usual GNUplot window:

./mfil FSScomm.fil; sleep 1; pdftk FSScomm_run*.pdf cat output FSScomm.pdf

Attachment 1: FSScomm.pdf
FSScomm.pdf FSScomm.pdf
  15230   Thu Feb 27 15:50:37 2020 gautamUpdateElectronicsFSS box power cable removed

In 1X1, there is a box labelled "FSS REF" below a KEPCO HV supply. This box had a power cable that wasn't actually connected to any power. I removed said cable.

  3573   Wed Sep 15 01:27:52 2010 rana, steve, valeraUpdatePSLFSS cables connected

- connected the TTFSS cables (FSS fast goes directly to NPRO PZT for now)

- measured the reference cavity 21.5 MHz EOM drive to be 17.8 dBm

-  turned on the HV for the FSS phase correcting EOM (aka PC) drive

- connected and turned on the reference cavity temperature stabilization

- connected the RefCav TRANS PD

- fine tuned the RefCav REFL PD angle

  958   Wed Sep 17 17:31:24 2008 YoichiUpdatePSLFSS calibration
I calibrated the reference cavity error signal with the following procedure.

(1) I disconnected the PC path BNC cable and locked the RC only using the PZT. To do so, I had to insert a 20dB attenuator
in the RF signal path going to the EOM to reduce the gain of the loop sufficiently.
The normal RF level going to the EOM is 17dBm. With the attenuator it is of course -3dBm.

(2) Using the SR785, I injected signal into the Test-IN2 (a sum-amp after the mixer) of the FSS box and measured the TF from the Ramp-IN to the IN1.
When the Ramp-In switch is off, the Ramp-IN port can be used as a test point connected to the PZT drive signal path just before the output.
There is a RC low-pass filter after the Ramp-IN. IN1 is the direct output from the mixer (before the sum-amp).
The attm1 is the measured transfer function along with the fitting by a first order LPF.
From this measurement, the DC transfer function from the applied voltage on the PZT to the error signal is determined to be 163.6 (V/V).
Since the RF level is lowered by 20dB, the cavity gain in the normal operation mode is 10 times larger (assuming that the modulation depth is
linearly proportional to the applied voltage to the EOM).

(3) According to elog:791, the conversion factor from the voltage on the PZT to the frequency change of the NPRO is 11.172MHz/V. Combining this with the
number obtained above, we get 6.83kHz/V as the calibration factor for converting the error signal (mixer output) to the frequency at DC.
Using 38kHz cavity pole frequency, the calibration factor is plotted as a function of frequency in the attm2.

(4) I took a spectrum of the error signal of the FSS and calibrated it with the obtained calibration factor. See attm3.
The spectrum was measured by SR785. I will measure wide band spectra with an RF analyzer later.

TO DO:
1: Use the actual modulation depth difference to extrapolate the calibration factor obtained by with a low RF signal for the EOM.
The cavity sweep was already done.

2: I assumed 38kHz cavity pole. I will measure the actual cavity pole frequency by cavity ringdown.

3: Measure out-of-the-loop spectrum of the frequency noise using PMC and MC.
Attachment 1: PZTresp.png
PZTresp.png
Attachment 2: Calibration.png
Calibration.png
Attachment 3: FreqNoiseSpectrum.png
FreqNoiseSpectrum.png
  991   Thu Sep 25 10:48:29 2008 YoichiUpdatePSLFSS calibration again
I did a calibration of the FSS error signal again with a different method.
This time, I swept the laser frequency with the NPRO PZT around a resonance.
The attached figures show the transmitted light power and the PDH error signal vs the applied voltage to the PZT.
From the width of the transmitted light power peak, we can obtain the PZT voltage to the laser frequency coefficient,
i.e. the HWHM (Half Width Half Maximum) equals to the FSR (38kHz).
Once the PZT is calibrated, the PDH error signal can be calibrated by the fitting the central slope with a line.

I repeated the measurement 8 times and fitted the obtained data to get the HWHM and the slope.
The results are the following:
PZT calibration = 6.3 +/-0.1 MHz/V
PDH calibration = 6.5 +/-0.5 kHz/V

Note:
(1) The calibration coefficient (6.5kHz/V) is almost consistent with the previous value (6.83kHz/V elog:958). However, that calibration
used a considerably different value for the PZT calibration (11.172MHz/V elog:791). The discrepancy in the PZT calibration is understandable
because my previous PZT calibration was very rough. The fact that the two calibrations still agree is a mystery.

(2) In the transmitted power curve, there seems to be a slight distortion, probably due to the thermal effect.
We should reduce the power to the reference cavity to remove this effect.

(3) This measurement was done after Peter installed his RF source. The demodulation phase had not yet been optimized. We should
repeat the calibration after he optimizes the phase.

(4) I used the Tektronix oscilloscope for the measurement.
Using the ethernet-wireless converter, you can connect the scope to the network from anywhere in the lab.
No hard wire required anymore.
Then you can download the data from a web browser. It is cool !
Attachment 1: PDTrans.png
PDTrans.png
Attachment 2: PDHsignal.png
PDHsignal.png
  15310   Wed Apr 22 17:29:14 2020 gautamUpdatePSLFSS debugging attempts

Summary:

On Monday, I hooked up an AG4395 to the PMC error point (using the active probe). The idea was to take a spectrum of the PMC error point every time the FSS PC drive RMS channel indicated an excursion from the nominal value. An initial look at the results don't suggest that this technique is particularly informative. I'll have to think more about a workaround, but please share your ideas/thoughts if you have some.

Also, the feature in the spectrum at ~110 kHz makes me suspect some kind of loop instability. I'll measure the IMC loop OLG at the next opportunity.

Details:

  • The PMC servo bandwidth is ~2 kHz, so above this, the PMC error point should be a faithful monitor of the PSL frequency noise, provided the sensing noise is low enough.
  • The PMC error point sensing noise is ~100nV/rtHz (I'm monitoring this straight after the Minicircuits mixer+bandpass filter that we are using as a demodulator). This corresponds to ~2 Hz/rtHz, using the ~10 MHz/V PDH discriminant calibration from January. Seems consistent with this elog.
  • I was hoping to see if there was a particular frequency band in which the noise gets elevated, and if the crossover frequency is a few kHz and the IMC servo BW is ~110 kHz, I would have expected this to be in the 10-100 kHz region. Possibly my frequency resolution isn't good enough? But with the Agilent, doing a finer grid would mean a longer measurement time, in which case the IMC might lose lock before the measurement is done.
  • But, as shown in Attachment #1, there isn't any clear evidence, from the ~20 excursions that were recorded last night. The color of the line is meant to be indicative of the average value of the PC drive RMS channel in the measurement time.
  • A significant bottleneck in this whole process is that it takes ~1 minute to initiate the GPIB measurement, and download the data. The pseudo-code I used is:
    • While the IMC is locked, watch PCdrive RMS EPICS channel's "ALARM" state, which becomes non-zero when the PCdrive RMS exceeds 1 V (this is how it is defined in the EPICS db record right now).
    • Make sure this isn't a transient feature - I do this by waiting 5 seconds and checking that the ALARM flag is still flagged.
    • Initiate a AG4395 measurement over GPIB - I use the measurement span of 1 kHz - 1 MHz with a BW/span ratio of 0.1%, 5 averages.
    • Check that the IMC is still locked (if it got unlocked while the measurement was made, presumably the measurement is garbage).
  • Is there a better monitor of the laser frequency noise? I can imagine using POX/POY which I think have a lower electronics noise floor but I'm not sure if that's true at 100 kHz and having the arms locked in addition to the IMC seems more complicated...
  • Since we are planning a laser upgrade, is this worth spending more time on? I may leave the measurement running on pianosa in a tmux session while I'm not in the lab...
Attachment 1: FSSspec.pdf
FSSspec.pdf
  15312   Thu Apr 23 10:42:02 2020 ranaUpdatePSLFSS debugging attempts

I had set up the 4395 to do this automatically a few years ago, but it looked at the FSS/IMC instead. When the PCDRIVE goes high there is this excess around ~500 kHz in a broad hump.

But the IMC loop gain changes sometimes with alignment, so I don't know if its a loop instability or if its laser noise. However, I think we have observed PCDRIVE to go up without IMC power dropping so my guess is that it was true laser noise.

This works since the IMC is much more sensitive than PMC. Perhaps one way to diagnose would be to lock IMC at a low UGF without any boosts. Then the UGF would be far away from that noise making frequency. However, the PCDRIVE also wouldn't have much activity.

  929   Thu Sep 4 17:44:27 2008 YoichiUpdatePSLFSS error signal spectrum
Attached is a spectrum of the FSS error signal.
There are a lot of sharp peaks above 100kHz (the UGF of the servo is about 200kHz).
These are mostly harmonics of 77kHz. They are the current suspects of the FSS slew rate saturation.
I remember when I blocked the light to the PD, these peak went away. So these noises must be
in the light. But I checked it a few weeks ago. So I will re-check it later.

One possible source of the lines is a DC-DC converter in the NPRO near the crystal.
We will try to move the converter outside of the box.
Attachment 1: FSS-Error-Spe.png
FSS-Error-Spe.png
  8587   Thu May 16 01:41:31 2013 JenneSummaryIOOFSS gain settings set

Quote:

I'm not sure yet what this points to as the best gain settings.  We can of course explore more of the space.  I'm going to leave it at 13/23.5, which leaves the PC RMS at ~1.5 and the FAST Monitor at ~6.0.

 I changed the value of the nominal FSS common gain in the PSL Settings screen (It's called the 'FSS global gain' there).  To get to this screen:  sitemap -> PSL_main -> PSL_settings.  The MC autolocker reads these settings from the screen and uses those values.  Now the FSS returns to this value of 13 that Jamie has chosen.  For the past few days, it's been going back to the old value of 10.1 .  The FAST gain was already set to this 23.5 value.

  684   Wed Jul 16 17:36:51 2008 JohnDAQPSLFSS input offset
I changed the nominal FSS input offset to 0 from 0.3. Tolerance remains unchanged at +/-0.05.
  10928   Thu Jan 22 02:56:07 2015 ericqUpdateIOOFSS input offset adjusted

Since Rana's overhaul of the IMC, the FSS input offset had been sitting at zero. 

Over the last day or so, I had noticed the MC refl wall striptool trace looking noisier, and earlier this evening, we were suffering from a fair amount of downtime due to IMC unlocks, and failure to autolock for times on the order of ten minutes. 

While we had used ezcaservo for this in the past, I set the FSS offset manually tonight. Namely, I popped open a dataviewer trace of MC_F, and scanned the FSS offset to make MC_F go to zero. It required a good amount of offset, 4.66 V according to the FSS screen. I did this while the FSS slow servo was on, which held the FSS Fast output at zero. 

That was four hours ago; MC_F is still centered on zero, and we have not had a single IMC unlock since then. The MC refl trace is thinner too, though this may be from nighttime seismic. 

  575   Thu Jun 26 18:24:28 2008 YoichiUpdatePSLFSS input ofset slider problem - fixed
I checked the FSS servo interface board and found that a LT1125CSW used to differentialize offset channel was broken (no virtual short).
So I replaced it. Now the slider is working.
The op-amp was hitting the rail. So it seems like we had been applying the maximum offset to the FSS input all the time.
The reason why the FSS loop still worked with the large offset is that the applied offset (~14V) is attenuated by a factor of 500 at the summing point.
  1048   Tue Oct 14 19:24:34 2008 YoichiConfigurationPSLFSS light power reduced
Rana, Yoichi

To change the gain distribution in the FSS, Rana reduced the VCO power for the AOM to reduce the light incident to the reference cavity.
Now the transmitted power of the RC is 2.3V compared to 6.5V before.
The FSS common gain can be increased to 5dB. I haven't changed the normal gain for this slider, so the mcup script will still set
the common gain to 1.5dB after an MC lock.
With this change, we take some gain from the optical part and give more gain in the electronics.
This might relieve the slew rate limit problem if it is happening in an early stage of the electronics.
  3574   Wed Sep 15 01:58:28 2010 valeraUpdatePSLFSS locking

The RefCav is locked and aligned. I changed the fast gain sign by changing the jumper setting on the TTFSS board. The RefCav visibility is 70%. The FSS loop ugf is about 80 kHz (plot attached. there is 10 dB gain in the test point path. this is why the ugf is at 10 dB when measured using in1 and in2 spigots on the front of the board.)  with FSS common gain max out at 30 dB. There is about 250 mW coming out of the laser and 1 mW going to RefCav out of the back of the PMC. So the ugf can be made higher at full power. I have not made any changes to account for the PMC pole (the FSS is after the PMC now). The FSS fast gain was also maxed out at 30 dB to account for the factor of 5 smaller PZT actuation coefficient - it used to be 16 dB according to the (previous) snap shot. The RefCav TRANS PD and camera are aligned. I tuned up the phase of the error signal by putting cables in the LO and PD paths. The maximum response of the mixer output to the fast actuator sweep of the fringe was with about 2 feet of extra cable in the PD leg.

I am leaving the FSS unlocked for the night in case it will start oscillating as the phase margin is not good at this ugf.

Attachment 1: DSC_2510.JPG
DSC_2510.JPG
  3575   Wed Sep 15 03:08:26 2010 KojiUpdatePSLFSS locking

Brilliant! This is the VERY way how the things are to be conquered!

Quote:

The RefCav is locked and aligned. I changed the fast gain sign by changing the jumper setting on the TTFSS board. The RefCav visibility is 70%. The FSS loop ugf is about 80 kHz (plot attached)  with FSS common gain max out at 30 dB. There is about 50 mW coming out of the laser and a few mW going to RefCav out of the back of the PMC. So the ugf can be made higher at full power. I have not made any changes to account for the PMC pole (the FSS is after the PMC now). The FSS fast gain was also maxed out at 30 dB to account for the factor of 5 smaller PZT actuation coefficient - it used to be 16 dB according to the (previous) snap shot. The RefCav TRANS PD and camera are aligned. I tuned up the phase of the error signal by putting cables in the LO and PD paths. The maximum response of the mixer output to the fast actuator sweep of the fringe was with about 2 feet of extra cable in the PD leg.

I am leaving the FSS unlocked for the night in case it will start oscillating as the phase margin is not good at this ugf.

 

  124   Tue Nov 27 15:45:08 2007 robConfigurationPSLFSS loop

It's unclear (to me, at least) what was the end result of the FSS path tweaking before Thanksgiving. Today I measured the open loop gain, and it was still around 100kHz, even with the gain sliders maxed out, but it looked really crappy with a sharp cutoff around the UGF. Then, on a lark, I pushed around the "Input Offset Adjust" slider, which sums an offset into the signal coming out of the mixer. By moving this slider to 7V, I got the UGF to 500kHz with 45 deg of phase. That would be fine, and we could go offset hunting, but the same thing happens if one puts in a large negative value! I don't really understand what's going on, but it seems like weirdness in the electronics. Unfortunately the web interface to the conlog is not running (presumably because the `new' linux1 doesn't have its apache server running) and my command line conlog efforts have been stymied. So, I don't know what the historical settings of this offset are, but zero is definitely not a good setting right now. Here's a snapshot:

FSS
UGF: 500kHz
CG : 24dB
FG : 19dB
input offset: 7V
Phase Adjust: 1.09V
Phase Button: 0
RF Amp Adjust: 7.38V

margins:
phase: 45 deg
gain: 8dB
Attachment 1: FSSsmall.jpg
FSSsmall.jpg
  791   Mon Aug 4 13:43:02 2008 YoichiSummaryPSLFSS loop calibration
As a part of the effort to repair the FSS loop bandwidth, I tried to calibrate the FSS loop.

First, I scanned the MOPA frequency by injecting a triangular wave into the ramp-in of the FSS box, which goes to the PZT of the NPRO.
The first attachment shows the transmitted light curve (pink one) along with the PDH signal (light blue).
The sweep was very slow (0.1Hz for 2Vp-p). From this measurement, the FWHM was 6.8e-3V. Then fpol = FWHM/2=3.4e-3V, where fpol is the cavity pole frequency.
So the PZT's DC response is 294*fpol/V. If we use the canonical fpol=38kHz, it is 11.172MHz/V.

Then I tried to measure the cavity pole. First I tried the cavity ring down measurement, by blocking the beam abruptly. Unfortunately, my hand was not fast enough.
The ring down shape was not an exponential decay.
I then locked the reference cavity only using the PZT with very narrow bandwidth (UGF=2kHz). I injected signal into the external modulation input of the 80MHz VCO
for the AOM. The second attachment shows the transfer function from this input to the IN2 (mixer output monitor port) of the FSS servo box.
To plot this, I corrected the measurement for the open loop TF (i.e. multiplying the measured TF with (1+G)), and other filters in the path (8MHz LPF after the ext. mod.
input of the 80MHz VCO, and an RCL network after the mixter). The gain looks like a cavity pole, but the phase decreases very rapidly.
If you look at the third attachment showing a wider band transfer function, there are notches at 1.8MHz and above. I couldn't find this kind of filter in the schematic.
Maybe this is the RFPD's bandpass filter. I will check this later. From these plots, it is difficult to tell the cavity pole frequency. From the -3dB point, fpol is around 83kHz,
but from the phase=-45deg point, fpol is around 40kHz.

Finally, I calibrated the cavity's optical gain by locking the Ref. Cavity with only PZT, and injecting a signal into the loop.
The signal was injected from Test-In2 of the FSS servo box and the transfer function from the PZT output signal (TP10) to IN1 (mixer output) was measured.
The transfer function was corrected for a 10Hz LPF after TP10.
The attachment4 shows a nice flat response up to 30kHz. Above 30kHz, the measurement is too noisy. The optical gain at DC is about 22dB from the PZT drive to the error signal (IN1).
Using fpol=38kHz, it means 887kHz/V calibration factor for the signal at IN1. There is a mixer output monitor DAQ channel in the FSS but it seems to be not working at the
moment. I will look into this later. There is a gain of 10dB between IN1 and the mixer monitor channel.
By looking at the phase response of the attachement4, there is a cavity pole like behavior around 30kHz. If we assume the PZT response is flat up to this frequency, it is
roughly consistent with fpol=38kHz.

I was not able to take a sensible spectrum of IN1 using the network analyzer. When the FSS servo was engaged, the signal was too small.
I will try to use an AF spectrum analyzer later to get a calibrated spectrum.
Attachment 1: P7310048.JPG
P7310048.JPG
Attachment 2: cavity-response.pdf
cavity-response.pdf
Attachment 3: cavity-response2.pdf
cavity-response2.pdf
Attachment 4: cavity-gain.pdf
cavity-gain.pdf
  758   Tue Jul 29 19:41:38 2008 YoichiUpdatePSLFSS loop transfer functions
Last night I measured a bunch of transfer functions on the FSS loop.
All the loop gains were measured with the common gain = 30db and the fast gain = 18dB.

(1) The first attachment is the overall open loop transfer function of the FSS loop. I put a signal from the Test IN2 and observed signals from IN1 and IN2.
The UGF is about 180kHz.
By increasing the RF amplitude going to the EOM (i.e. increasing the sideband power), I can further increase the gain of the servo.
However, it made the PC drive immediately crazy. Probably it was some oscillation.

(2) Then I locked the ref. cav. with only the PZT actuator. I did so by simply unplugging the cable going to the PC.
Surprisingly, the cavity locked with the *same* gain setting as before. The second attachment shows the open loop transfer function measured in this configuration. It seems wrong, I mean, it should be unstable. But the cavity locked. A mystery.

(3) The third plot is the measured TF from the Test IN1 of the FSS board to the fast out (output to the PZT).

(4) By dividing the TF measured in (2) with the TF of (3), I got the response of the PZT times the cavity response. This is shown in the attachment 4.

(5) We can guess the open loop TF of the PC path by subtracting the TF in (2) from (1). It is shown in the attachment 5.

(6) The filter shape of the PC path is measured by injecting signal from the Test IN1 of the FSS board and observing it at the PC output. Since it is a high voltage output, I reduced the common gain to -8.5dB during the measurement. The attachment 6 is the measured filter shape. The gain is corrected to show what it should look like when the common gain = 30dB.

(7) By dividing (5) with (6), I plotted the response of the PC times the cavity response in the attachment 7. Since the 1/f cavity pole and the response of the PC, which is proportional to f, should cancel out, we expect a flat response above the cavity pole frequency (38kHz). You could say it is a sort of flat, if you have obscured eyes.

The measurement of the PZT open loop TF is very suspicious. According to this, the PC path has a very large gain even at very low frequencies (there is no cross over above 1kHz). This cannot be true. Maybe the cavity's optical gain was low when it was locked with only the PZT. I will re-measure it.
The plot (4) is also strange becaues it does not show the low pass feature expected from the cavity pole.
Attachment 1: OverallOPLTF.eps
OverallOPLTF.eps
Attachment 2: OpltfPZTOnly.eps
OpltfPZTOnly.eps
Attachment 3: PZTFilter.eps
PZTFilter.eps
Attachment 4: PZTxCavityPole.eps
PZTxCavityPole.eps
Attachment 5: OpltfPCOnly.eps
OpltfPCOnly.eps
Attachment 6: PCFilter.eps
PCFilter.eps
Attachment 7: PCxCavityPole.eps
PCxCavityPole.eps
  761   Tue Jul 29 23:04:34 2008 YoichiUpdatePSLFSS loop transfer functions

Quote:

The measurement of the PZT open loop TF is very suspicious. According to this, the PC path has a very large gain even at very low frequencies (there is no cross over above 1kHz). This cannot be true. Maybe the cavity's optical gain was low when it was locked with only the PZT. I will re-measure it.


I measured it again and found that the loop was oscillating at 13.5kHz. I think this oscillation prevented the ref. cavity from building up the power and consequently lowered the optical gain making it marginally stable. So the PZT path open loop TF posted in the previous entry is wrong.

I was able to stop the oscillation by lowering the gain down to CG=-7.6dB and FG=-8.78dB.
The first attachment shows the measured open loop transfer function.
Since the gain setting is different from when the over all open loop TF was measured, I scaled the gain (attachment 2).
However, this plot seems to have too much gain. Scaling it down by 20dB makes it overlap with the over all open loop TF.
Maybe the gain reading on the EPICS screen is wrong. I will measure the actual gain tomorrow.
Attachment 1: OpltfPZTOnlyRaw.eps
OpltfPZTOnlyRaw.eps
Attachment 2: OpltfPZTOnly.eps
OpltfPZTOnly.eps
  905   Fri Aug 29 22:57:48 2008 YoichiUpdatePSLFSS loop transfer functions
I've been measuring a bunch of transfer functions of the FSS related stuffs.
There are a lot to be analyzed yet, but here I put one mystery I'm having now.
Maybe I'm missing something stupid, so your suggestions are welcome.

Here is a conceptual diagram of the FSS control board

                                                          TP3             TP4
                                                           ^               ^
                                                           |               |
RF PD -->--[Mixer]-----[Sum Amp]------>--[Common Gain]--->----[Fast Gain]----[Filter]--> NPRO PZT
              ^     |      ^        |                  |     
              |     V      |        V                  |
LO ---->-------    TP1     IN      TP2                 -->---[Filter]--[High Volt. Amp.] --> Phase Corrector

What I did was first to measure a "normal" openloop transfer function of the FSS servo.
The FSS was operated in the normal gain settings, and a signal was injected from "IN" port.
The open loop gain was measured by TP1/TP2.
Now, I disconnected the BNC cable going to the phase corrector to disable the PC path and locked the ref. cav. 
only using the PZT. This was done by reducing the "Common Gain" and "Fast Gain" by some 80dB.
Then I measured the open loop gain of this configuration. The UGF in this case was about 10kHz.
I also measured the gain difference between the "normal" and "PZT only" configurations by injecting 
a signal from "IN" and measuring TP3/TP2 and TP4/TP3 with both configurations (The signal from the Mixer was
disconnected in this measurement). 

The first attachment shows the normal open loop gain (purple) and the PZT only open loop gain scaled by the 
gain difference (about 80dB). The scaled PZT open loop gain should represent the open loop gain of the PZT
path in the normal configuration. So I expected that, at low frequencies, the scaled PZT loop TF overlaps the normal
open loop TF.
However, it is actually much larger than the normal open loop gain.
When I scale the PZT only TF by -30dB, it looks like the attachment #2.
The PZT loop gain and the total open loop gain match nicely between 20kHz and 70kHz.
Closer look will show you that small structures (e.g. around 30kHz and 200kHz) of the two
TFs also overlap very well. I repeated measurements many times and those small structures are always there (the phase is
also consistently the same). So these are not random noise.

I don't know where this 30dB discrepancy comes from. Is it the PC path eating the PZT gain ?

I have measured many other TFs. I'm analyzing these.
Here is the TO DO list:

* Cavity response plot from AOM excitation measurements.
* Cavity optical gain plot.
* Reconstruct the open loop gain from the electric gain measurements and the optical gain above.
* Using a mixer and SR560(s), make a separate feedback circuit for the PZT lock. Then use the PC path
  to measure the PC path response.
* See the response of the FSS board to large impulse/step inputs to find the cause of the PC path craziness.
etc ...
Attachment 1: OPLTFs.pdf
OPLTFs.pdf
Attachment 2: OPLTFsScaled.pdf
OPLTFsScaled.pdf
ELOG V3.1.3-