40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 79 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  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
  907   Mon Sep 1 04:34:00 2008 ranaUpdatePSLFSS loop transfer functions
I started from 6th item in Yoichi's todo list.

1) Increased the setpoint of the thermostat next to the framebuilder from 73F to 79F. Its freezing over there
in the room with the drill press. Steve's illegal mercury thermometer is reading 19 C.


2) Looked the RFPD's output spectrum using the 20 dB coupled output from the coupler that's in-line.
The first attached PDF file (n.pdf) has several plots:
page 1: 0-500 MHz anomolous peaks at 138 & 181 MHz but nothing too crazy
page 2: 0-100 MHz 80 MHz peak is RF pickup from the VCO Driver - not on the light
page 3: 10-30 MHz totally nuts
page 4: 18-25 MHz that's just wrong

The RF spectrum should only have some action around 21.5 MHz and a little peak at 2x 21.5 MHz. All that extra
junk means that something is broken!


3) To see if I could rid of any of the 80 MHz signal or any of that other trash from 18-25 MHz, I wound the RF cable
around a large toroidal ferrite core. This should have given us many uH of inductance for any signals common to
both the center and shield of the cable with no effect on the differential RF signals. There was no effect.


4) Next went to look at the 21.5 MHz Crystal Oscillator Reference card (D980353...I bet you can't figure out how
this one works). These have the Mini-Circuits SMA 30 MHz low pass (SLP-30) filters on both the LO and EOM outputs.

FSSLO.PNG shows the waveform after 20 dB attenuation going into a scope terminated with 50 Ohms.
FSSLO-Spec.png shows the spectrum of this signal - its pretty distorted. Here's the levels
   f (MHz) |  before filter (dBm) | after filter (dBm)
   ---------------------------------------------------
     21.5  |       -12.8               -13.1       
     43            -24                 -46
     64.5          -50               < -80
     86            -64               < -80

This would be OK after the filter, but the level is very low. Only 7dBm (accounting for my 20 dB att) !!
The FSS uses a JMS-1H mixer which needs, as everyone knows, a +17 dBm LO signal. Que lastima.

There seems to be something wrong already, but wait...


5) PC25.PNG shows the output signal going to the EOM from 0 - 25 MHz. The step that's visible there at
around 10 MHz is just something inherent to the analyzer (??). But see all that crap there down below
5 MHz ? That is NOT supposed to be there.

pc.pdf shows on the first page the comparison in EOM drive with 2 different slider values on the
RF AM adjust screen for the FSS. But page 2 is the punchline of this long entry: There is a bunch of
excess junk on the drive signal going to the FSS's phase modulator.
The FSS is then trying to handle
this extra frequency noise and getting into trouble.

We have to fix this board. I have also ordered a few SBP-21.4 from mini-circuits (SMA bandpass around 21.4 MHz)
just in case. Another option is to just replace this thing with a Marconi and an RF amp.






Attachment 1: n.pdf
n.pdf n.pdf n.pdf n.pdf
Attachment 2: FSSLO.PNG
FSSLO.PNG
Attachment 3: FSSLO-Spec.png
FSSLO-Spec.png
Attachment 4: PC25.png
PC25.png
Attachment 5: pc.pdf
pc.pdf pc.pdf
  3561   Sun Sep 12 23:16:52 2010 valeraUpdate FSS mode matching

The attached plot shows the beam scans of the beam leaking from the back mirror of the PMC to the BS cube that first turns the S-pol beam 90 deg to the AOM and then transmits the AOM double passed and polarization rotated P-pol beam to the reference cavity. The beam from the PMC is mode matched to the AOM using a single lens f=229 mm. The ABCD file is attached. The data were taken with VCO control voltage at 5 V. We then reduced the voltage to 4 V to reduce the astigmatism. Tara has the data for the beam scan in this configuration in his notebook.

The beam from AOM is mode matched to the reference cavity using a single lens f=286.5 mm. The ABCD file is attached.

Attachment 1: fss.pdf
fss.pdf
Attachment 2: fssaom-abcd.tiff
Attachment 3: fssrc-abcd.tiff
  923   Thu Sep 4 13:48:50 2008 YoichiUpdatePSLFSS modulation depth
I scanned the reference cavity with the NPRO temperature (see the attached plot).
The power ratio between the carrier and the sideband resonances is about 26.8.
It corresponds to gamma=0.38.
The RF power fed into the EOM is now 14.75dBm (i.e. 1.7V amplitude). The NewFocus catalog says 0.1-0.3rad/V. So
gamma=0.38 is a reasonable number.




Attachment 1: RCScan.png
RCScan.png
  1899   Thu Aug 13 22:53:48 2009 YoichiConfigurationPSLFSS nominal common gain changed, MC WFS centered

Koji, Yoichi

We found that the FSS PC feedback easily goes crazy (saturated).
It was because the common gain was too low. Probably the recent decrease of the
laser power is responsible for this.
We increased the nominal value of the common gain from 12 to 16.5.
The value was chosen just to make the PC path quiet. We should check
the FSS UGF later.
 
The MC WFS QPDs seemed off centered. So we unlocked the MC and lowered
the input power by the usual MZ half fringe technique.
Actually, the direct reflection beam was not much off the center. In anyway, we adjusted
the beam to the exact center of the QPDs.
The MC now locks fine.

 

  10340   Wed Aug 6 17:29:36 2014 JenneUpdateIOOFSS offset changed

The MC has been unstable and unhappy for the last several hours.  When I looked, I saw that the FSS_FAST monitor has been hovering around 1 V, when it is supposed to be closer to 5ish. 

I changed the C1:PSL-FSS_INOFFSET from -0.08 to -0.8537, and will see if the MC sticks around for longer this time around.

  10341   Wed Aug 6 21:22:09 2014 KojiUpdateIOOFSS offset changed

The fast feedback should be around zero now!

  10344   Thu Aug 7 12:25:14 2014 JenneUpdateIOOFSS offset changed

Quote:

The fast feedback should be around zero now!

 Dang it, I completely forgot.  Well, anyhow, it pulled itself back down to less than 1V, and the MC stayed happy for several hours.  I'm not totally sure what changing the offset did, but the MC seems happy for right now.  I should take a quick look at the error point to make sure that I didn't mess up your tuning.

  908   Mon Sep 1 19:23:17 2008 YoichiConfigurationPSLFSS on an auxiliary loop
Summary: The FSS is now temporarily disabled. Naturally, the MC won't lock. I will fix it tomorrow morning.

Today, I did the 4th item of my TO DO list.
Using a mini-circuit mixer and two SR560s, I constructed an auxiliary servo loop for the reference cavity.
With this loop, I was able to lock the reference cavity without using the FSS box.
By locking the reference cavity with this auxiliary servo, I was able to measure the PC path transfer function.
I will post the analyzed results later.

I borrowed the PD RF and the LO signals from the main FSS loop by power splitters. Therefore, the gain of the main FSS loop
is now about 3dB low. I tried to compensate it by increasing the EOM modulation depth, but the PC path is still a bit noisy.
Probably the already too low LO power is now seriously low (the LO power cannot be changed from EPICS).
Because I did not want to leave the PC path with large output overnight (it will heat up the PA85, and might cause damage, though unlikely),
I disabled the FSS for now.
  910   Tue Sep 2 09:58:42 2008 YoichiConfigurationPSLFSS on an auxiliary loop

Quote:
Summary: The FSS is now temporarily disabled. Naturally, the MC won't lock. I will fix it tomorrow morning.


Now I removed the power splitters for the aux. reference cavity servo. The FSS is back and the MC locks.
I'm now returning one of the active high-impedance probes to the Wilson house. They need it today.
We are left with only one active probe. If anyone finds another active probe in the 40m lab.,
please let me know (according to Rana we should have one more).
  927   Thu Sep 4 17:12:57 2008 YoichiUpdatePSLFSS open loop TF
I changed the gain settings of the FSS servo.
Now the Common Gain is 5dB (the last night it was 2dB) and the Fast Gain is 12dB (formerly 16dB).
I measured the open loop TF with this setting (the attachment).
I also plotted the OPLTF when CG=2dB, FG=20.5dB. With this setting, the MC looses lock every 30min.

You can see that the OPLTF is smoother with FG=12dB.
When the FG is high, you can see some structure around 250kHz. This structure is reproducible.
This may be some interruption from the fast path to the PC path through a spurious coupling.
Attachment 1: FSS-OPLTFs.png
FSS-OPLTFs.png
  711   Tue Jul 22 03:03:22 2008 John, RobUpdatePSLFSS open loop transfer function
With the common gain slider maxed out the unity gain frequency is 58kHz.

The reference cavity refl diode appears to be okay. RF OUT/ TEST IN transfer function was normal.
There is a ~220mV offset in the RF out. We removed this using a coupler - no change. We also checked the
diode->FSS cable.

Tomorrow I'll take a closer look at the board.
  715   Tue Jul 22 13:16:09 2008 John, RobUpdatePSLFSS open loop transfer function

Quote:
With the common gain slider maxed out the unity gain frequency is 58kHz.

The reference cavity refl diode appears to be okay. RF OUT/ TEST IN transfer function was normal.
There is a ~220mV offset in the RF out. We removed this using a coupler - no change. We also checked the
diode->FSS cable.

Tomorrow I'll take a closer look at the board.


Should note that the UGF of 58kHz was measured with the test cable (from RFPD to board), so the demod phase was presumably sub-optimal.
  2343   Sat Nov 28 20:27:12 2009 KojiUpdatePSLFSS oscillation: Total gain reduced

I stopped by the 40m for some reason and found that the MC trans was 7.5.
This was caused by an oscillation of FSS, which seemed to be started by itself.

The oscillation stopped by reducing the FSS total gain to +9dB (from +11dB).
This is not a permanent fix (i.e. autolocker will restore the gain).
If it seems necessary to reduce the FSS gain always, we change the MC autolocker script.

Attachment 1: 091128_PSL.png
091128_PSL.png
  1054   Thu Oct 16 16:26:26 2008 peteConfigurationPSLFSS phase matching cable installed
RG 405 cable has a solid teflon dielectric, and a velocity factor of 0.69. To get the 8.2 degrees of additional phase on the LO output at 21.5 MHz then requires 22 cm of cable. I made a cable that ended up being 21 cm long after I'd gained some experience putting on the connector. It gives a phase difference between LO and RF of about 10 degrees. It is currently installed.
  1046   Tue Oct 14 14:19:36 2008 peteConfigurationPSLFSS ref phase
Today I made several measurements which should yield the optimized phase for the FSS 21.5 MHz reference. I made two sets of measurements, using the 166 MHz phase delay shifter. For each phase value I made 5 measurements of a 500 kHz injection into test2 at 1 Vpp, with the 4195 spectrum analyzer on in1 with the high impedance probe, 51 points, a 10 kHz range. It was surprisingly noisy. I will make plots using matlab to find the maximum, and hope for consistent results between the two sets of measurements. If it is too noisy or inconsistent I will repeat the measurement at ~800 kHz.

Once I find the phase which yields peak amplitude in in1, I will measure the relative phase between LO and RF going in to the FSS, measure the speed of light in RG58 cable, and construct a new cable which will implement the desired relative phase.
  1050   Wed Oct 15 22:07:52 2008 peteConfigurationPSLFSS ref phase measurements
Optimizing the FSS LO/RF phase at 500 kHz, above the servo band, proved to be noisy and those measurements were useless. Today I repeated
the measurement at 35 kHz and got good signal to noise. I've attached a plot of the 35 kHz peak in dBm as measured at IN2 by SR785, with
an injection into TEST2 at 35 kHz with 0.2 Vpp, as a function of delay in ns given by the delay phase shifter normally used by the 166 MHz.
I fit the bottom (quadratic) portion of this curve, and found an optimum delay of 25.8 ns, which can be implemented as 25.81 ns on the phase
shift box (25 + 1/2 + 1/4 + 1/16). This is an uncalibrated number and meaningless.. For all these measurements a very long SMA cable
(did not measure) was inserted on the RF output of the 21.5 MHz reference box. The actual phase difference depends on these cable lengths
which I didn't measure.

To determine the actual phase difference I compared the LO and RF input points with the 25.81 ns delay, using a scope with poor man's
averaging (33 manual triggers and recording the phase measurements). The phase difference was 8.24 degrees with an error on the mean of 3.4%,
with the LO having the longer effective cable (cable plus delay from the phase delay box). As a sanity check I set the phase delay box
to 20 ns and re-measured, and found 49.5 degrees. (1/21.5 MHz) * (49.5-8.24)/360 = 5.3 ns, which is about the difference between 20 ns
and 25.81 ns. I did the same with 0 ns dialed in, and found a difference of 21.5 ns (I expected 25.8 ns). So it is possible that the
phase delay box isn't too precise.

Finally, to determine the length of cable needed to implement 8.24 degrees of phase at 21.5 MHz with RG58 cable, I made some phase measurements
using the FSS reference box and mismatched cables. I used three cable lengths (93 cm, 140.5 cm, and 169.5 cm ) and two mismatched pairs with
dL of 29 and 76.5 cm. For each pair I took average of 20 measurements, finding 22.54 degrees mean for the dL=29 cm pair (0.78 degrees/cm, or
a speed of light of 1.0e10 cm/s, or 10.6 cm of cable length on the LO) and 43.57 degrees mean for dL=76.5 cm pair (0.57 degrees/cm, or a speed
of light of 1.4e10 cm/s, or 14.5 cm of cable length on the LO). I expected more precise agreement.

Maybe the 21.5 MHz reference box is not zero phase between the outputs. This could be easily tested. It might be interesting to repeat this
measurement with a few more dL values.
Attachment 1: phasedelay.png
phasedelay.png
  1052   Thu Oct 16 09:47:49 2008 YoichiConfigurationPSLFSS ref phase measurements

Quote:
I fit the bottom (quadratic) portion of this curve, and found an optimum delay of 25.8 ns, which can be implemented as 25.81 ns on the phase shift box (25 + 1/2 + 1/4 + 1/16).


The gain of the loop is sinusoidally dependent on the phase delay. So the fit will be better with a function like this: 1/(1+G*sin(dphi + const)).
  8460   Thu Apr 18 02:51:52 2013 DenUpdatePSLFSS slow servo

Today Rana pointed out that our FSS slow servo is malfunctioning. It has been for a while that our laser temperature control voltage drifted from 0 to 10.

I looked at FSSSlowServo script that runs at op340m and controls the servo. Script disables the servo when MC transmission is less then FSS_LOCKEDLEVEL. But his value was set to 0.2 probably till reference cavity time.

This means that slow servo was not disabled when MC was unlocked. I changed this value to 7000.

Also I increased integral gain from 0.0350 to 0.215 such that fast control is always in the range 4.5 - 5.5

  121   Wed Nov 21 14:31:41 2007 robUpdatePSLFSS twiddle

I `tweaked' the FSS path today. Here's what I did:

1) Shut down the FSS autolocker

2) Turn off FSS servo

3) Assume the beam coming back from the AOM is double-first-order, and don't make any changes large enough to lose it.

4) Tweak the alignment of these components to maximize the incident power on the RC reflected diode:

a) PBS before AOM
b) AOM
c) curved mirror after the AOM

5) Translate the AOM such that the beam moves away from the PZT, then when it levels off (no more power gains with movement),
move it back just a little bit so there's a teensy drop in power. This should but the beam as close to the edge as possible,
but whether or not it's the best place is still to be determined.

6) Lock the FSS, and align the mirrors into the frequency reference cavity.

After all this, the RC transmitted power went from .57 to .73 -- probably not a big enough change to account for the missing loop
gain, but we'll know more once the loop gets measured (after Alberto stops hogging the Agilent network analyzer).

Other possible routes include a systematic check of the upstream path (e.g., the Pockels cell) and just increasing the pickoff fraction for the FSS.
  751   Mon Jul 28 23:41:07 2008 robConfigurationPSLFSS/MC gains twiddled

I found the FSS and MC gain settings in a weird state. The FSS was showing excess PC drive and the MC wouldn't lock--even when it did, the boost stage would pull it off resonance. I adjusted the nominal FSS gains and edited the mcup and mcdown scripts. The FSS common gain goes to 30dB, Fast gain to 22dB, and MCL gain goes to 1 (which puts the crossover back around ~85 degrees where phase rises above 40 degrees).
  3346   Sun Aug 1 21:40:27 2010 ranaSummaryPSLFSS: SLOWDC response

I bet you thought that the NPRO slow actuator response could be well represented by a pole at ~0.1 Hz? Well, that's just what they want you to believe.

I attach the response measured in FSS-FAST (with no feedback to the SLOW actuator) when the SLOW is given a step. As you may remember from

kindergarten, the response of a single pole low pass should just be an exponential. Clearly, there's more here than 1 pole.

 I also inserted a factor of 0.01 in the FSSSlowServo code so I could make the gain sliders have reasonable values (they used to all be ~1e-3). The SVN and the MEDM snapshot are updated.

Attachment 1: Untitled.png
Untitled.png
  17047   Fri Jul 29 20:21:11 2022 KojiUpdatePSLFSSSlow/MCAutolocker issue (docker)

MCAutolocker/FSSSlow are not properly documented and not properly working.
Tidy up the script and documentation, or bring it back to megatron


I was aware that the FSSSlow was misbehaving since the shutdown upon the July power outage.
- FSS Slow servo did nothing even though the apparent settings in C1:PSL_SLOW screen looked fine and heart beat blinking
- Wanted to restart FSSSlow at megatron. Despite the login message showing how to do it, the system service does not exist anymore, because it was moved somewhere.
- Searched 40m wiki but found no info how to kill and restart it
- Found an elog. It was moved to docker on optimus ELOG 16480 . The restart procedure can only be found here. Please fix all the documentation inconsistency >> Anchal

According to this elog, the following commands need to be run for starting up MCAutolocker and FSSSlow on optimus:

cd /opt/rtcds/caltech/c1/Git/40m/scripts/MC
sudo docker-compose up -d

- Problem continues. Now FSSSlow is running but only when the IMC is locked. It does not stop even when the IMC lock is lost. How can we debug docker thing?
- This is minor but the MCAutolocker log (/opt/rtcds/caltech/c1/scripts/MC/logs/AutoLocker.log) is no longer updated even though MCAutolocker is running. Was it moved somewhere?

 

  17049   Sat Jul 30 10:38:12 2022 AnchalUpdatePSLFSSSlow/MCAutolocker issue (docker)

The FSSSlow script was not properly documented and it was not working, so I had to use one that I knew worked from CTN. This scripts lives in

/opt/rtcds/caltech/c1/Git/40m/scripts/PSL/FSS/PIDLocker.py

and uses a configuration file

/opt/rtcds/caltech/c1/Git/40m/scripts/PSL/FSS/PIDConfigFSS.yml

The script runs all the time inside docker container which keeps it running. The heart-beat blinker shows if the script is active or not, but it only starts working when C1:IOO-MC_LOCK is 1 and C1:PSL-FSS_SLOWLOOP is 1. The second channel is a button on C1PSL_SLOW screen to engage autolocker. It has to be turned on for FSS to work.

 


docker instructions:

The following message is displayed on login in optimus:

-------------------------------------------------------------------------
This computer runs four services as of Feb 18, 2022 for 40m lab. To check
status of these services, type
> sudo docker ps
For restarting a particular service, type:
> sudo docker restart container_name
where container name can be found from ps command above.
Fimilarly, to check status of a service, type:
> sudo docker logs container_name

In case, you have just rebooted the machine, to start these services do
following:
> cd /opt/rtcds/caltech/c1/Git/40m/softchansmodbus
> sudo docker-compose up -d
> cd /opt/rtcds/caltech/c1/Git/40m/scripts
> sudo docker-compose up -d

To stop the docker services completely, for example before a reboot, do
following:
> cd /opt/rtcds/caltech/c1/Git/40m/scripts
> sudo docker-compose down
> cd /opt/rtcds/caltech/c1/Git/40m/softchansmodbus
> sudo docker-compose down

This should remove all active containers from the computer.

To check IP address of running containers, type:
> sudo docker inspect -f '|| {{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}   ||   {{.Name}} ||' $(sudo docker ps -aq)

The softchansmodbus directory runs modbusEPICS docker image to host some
useful soft EPICS channels. The scripts directory runs pyep docker
image to run MC autolocker, PMC autolocker and FSS PID locker.
-------------------------------------------------------------------------

For checking log files of autolocker script, on optimus do:

sudo docker logs scritps_AL_MC_1

For checking log files of FSS PID loop, on optimus do:

sudo docker logs scripts_PID_

In the above commands, add < | tail -15> to just see the most recent 15 lines in the log file. change 15 to whatever number of lines you want to see from the end.

At any time, if you want to know how docker is running stuff, check out the /opt/rtcds/caltech/c1/Git/40m/scriptsdocker-compose.yml file for self-explanatory script usage.

I'll add some documentation on the wiki soon. That is indeed required and should have been done already.


Debugging scripts:

All scripts could be debugged by running them on rossa by directly using python command. You can stop the docker container on optimus using:

sudo docker stop container_name

and then run the file on rossa to check it's behavior. After debugging and fixing any issues, please commit the file to gitlab repo and go back to optimus and restart the docker container:

sudo docker restart container_name

I'll add this procedure to a wiki page as well.


Reverting back to systemd on megatron

The setup on megatron was not removed at all. All service files exist in same place and old scripts can be started in the old manner by doing following on megatron:

For FSSSlow:

sudo systemctl enable FSSSlow
sudo systemctl restart FSSSlow

For MC autolocker:

sudo systemctl enable MCautolocker
sudo systemctl restart MCautolocker

For diabling these services again, do:

sudo systemctl stop FSSSlow
sudo systemctl disable FSSSlow
sudo systemctl stop MCautolocker
sudo systemctl disable MCautolocker

Note that one should stop docker containers on optimus before starting these systemd services to avoid conflicting scripts running together.

I have added above instructions on megatron motd. So on loging into megatron, these updated instructions would come.

If someone wants to fix the old scripts and use systemd for managing those scripts, please do so but I won't be able to help in debugging those old scripts. The shell scripts are very complicated and beyond my knowledge and python scripts are lacking documentation.

I'm happy to help debug or extend the functionality of the new scripts that live in the git directory.

  17050   Sat Jul 30 12:48:18 2022 KojiUpdatePSLFSSSlow/MCAutolocker issue (docker)

> it only starts working when C1:IOO-MC_LOCK is 1 and C1:PSL-FSS_SLOWLOOP is 1.

- OK. Your new MCAutolocker does not reflect the lock status to C1:IOO-MC_LOCK. This causes FSS Slow to go crazy when the IMC is not locked. Can you fix that?

- So C1PSL_SLOW.adl screen, which spawns by the "SLOW Servo" button on the FSS screen, has no effect on the FSS SLOW servo anymore. It is obsolete. At least the screen (or the link to the screen) should be removed. (Work on it once you are back.)

- Also, please make a wiki page and copy the description on the previous page.

  17057   Thu Aug 4 11:28:22 2022 AnchalUpdatePSLFSSSlow/MCAutolocker issue (docker)

Added C1:IOO-MC_LOCK to ALConfigMC.yml which solved the isse with FSS Slow. We should tune the FSS Slow Servo PID coefficients for a better performance.

the C1PSL_SLOW.adl screen is not obsolete. It can be used to change the PID coefficients, engage/disengage the PID loop, monitor the PID script blinker, and monitor FAST actuator value C1:PSL-FSS_FAST. the functionality of this screen has not changed from before.

I've also added a wiki page for scripts documentation.

  17065   Mon Aug 8 14:47:10 2022 ranaUpdatePSLFSSSlow/MCAutolocker issue (docker)

can't we just go back to the old python script that was working for many years, and tested? I imagine that as soon as someone besides you tries to debug the docker setup, this is what will happen.

Quote:

Added C1:IOO-MC_LOCK to ALConfigMC.yml which solved the isse with FSS Slow. We should tune the FSS Slow Servo PID coefficients for a better performance.

the C1PSL_SLOW.adl screen is not obsolete. It can be used to change the PID coefficients, engage/disengage the PID loop, monitor the PID script blinker, and monitor FAST actuator value C1:PSL-FSS_FAST. the functionality of this screen has not changed from before.

I've also added a wiki page for scripts documentation.

 

  10315   Fri Aug 1 00:51:07 2014 KojiUpdatePSLFSSSlowServo update

FSS Slow set point to be zero


op340m:FSS>cat FSSSlowServo
#!/usr/bin/perl -w

# PID Servo for PSL-FSS (Slow)
# Tobin Fricke 2007-01-09

use strict;
#use Scalar::Util qw(looks_like_number);

sub looks_like_number {
    return ($_[0] =~ /^-?\d+\.?\d*$/);  #FIXME
}

use EpicsTools;

# Parameters
my $process  = 'C1:PSL-FSS_FAST';
my $actuator = 'C1:PSL-FSS_SLOWDC';
#my $setpoint = 5.5;
my $setpoint = 0;
my $blinkystatus = 0;
 

op340m:scripts>/opt/rtcds/caltech/c1/scripts/PSL/FSS/FSSSlowServo > /cvs/cds/caltech/logs/scripts/FSSslow.cronlog &

  633   Thu Jul 3 16:57:23 2008 JohnSummaryGeneralFSS_RMTEMP
The FSS room temp alarm has been beeping a lot recently. I altered the FSS_RMTEMP alarm levels using the
same method as Rana.

The alarm is still souding so, at least by my calculations, it must be colder than usual.
Attachment 1: FSStime.png
FSStime.png
Attachment 2: FSSalarm.png
FSSalarm.png
  12992   Mon May 15 19:21:04 2017 KojiUpdateComputer Scripts / ProgramsFSSslow / MCautolocker restarted

It seems that FSS slow servo stopped working.

I found that megatron was restarted (by Rana, to finish an apt-get upgrade) on ~18:47 PDT today.

controls@megatron|~> last -5
controls pts/0        192.168.113.216  Mon May 15 19:15   still logged in   
controls pts/0        192.168.113.216  Mon May 15 19:14 - 19:15  (00:01)    
reboot   system boot  3.2.0-126-generi Mon May 15 18:50 - 19:19  (00:29)    
controls pts/0        192.168.113.200  Mon May 15 18:43 - down   (00:04)    
controls pts/0        192.168.113.200  Mon May 15 15:25 - 17:38  (02:12)


FSSslow / MCautolocker were restarted on megatron.

  13820   Mon May 7 11:46:07 2018 gautamUpdatePEMFW parameter update

As part of investigation into this issue, Jonathan Hanks pointed out that the "minute trends" being recorded by our system were actually only being recorded every 120 seconds (a.k.a. 2 minutes). He had fixed the appropriate line in the parameter file, but had not restarted the FW processes. I had restarted it on Friday. (but failed to elog it !) no

To check if this made any difference, I pulled 1 hour of "minute trend" data for the PSL table temperature channel from ~1 hour ago, and compared the number of datapoints against a 1 hour minute trend time series from 2 May. I've put the display with # of datapoints (for an identical length of time) from before [left] and after [right] the restart next to the plots in Attachment #1. Seems like we are getting minute trends written every 60 seconds now, as it should be yes.

The unavailability of trends from nodus is a separate issue for which JH has suggested another fix, to be elogged separately.

Quote:

for whatever reason, I am unable to get minute or second trends from nodus for any channels (IMC, PEM, etc) since the reboot. has there been some more recent FB failure or is this still a bug since last years FB catastrophe?

Attachment 1: FWreboot.png
FWreboot.png
  8012   Wed Feb 6 15:20:55 2013 yutaSummaryGeneralFWHM was wrong

I have to blame Jamie for putting extra 2 randomly.
Measured PRM-PR2 cavity finesse was actually 108 +/- 3 (even if you use digital system to get data).

Lorentzian fit:
  Lorentzian function is;

f(x;x0,gamma,A) = A * gamma**2/((x-x0)**2+gamma**2)

  where x0 is the location of the peak, gamma is HWHM, and A is the peak height.
  Lorentzian fitting function in my original code (/users/yuta/scripts/modescanresults/analyzemodescan.py) was

fitFunc = lambda p,x,m: (m-p[2])*p[0]**4/(4*(x-p[1])**2+p[0]**4)+p[2]

  In this function, p[0] is sqrt(FWHM), not sqrt(HWHM). I doubled gamma to make it FWHM and squared it because they should be positive.
  During Jamie's modification of my code, he doubled p[0]**2 to get FWHM, which is wrong (/users/jrollins/modescan/modescan.py).

  I should have commented that p[0] is sqrt(FWHM).

Redoing the analysis:
  1. I pulled 2 out, and modified Jamie's modescan.py so that you can name each peak with peakdistinguish=True option. I also modified fitpeak function so that it throws away "peaks" which don't look like a peak.

  2. If you run /users/yuta/PRCmodescan/run.py and name each peak, you will get peaks.csv which includes peak position, FWHM, and the type of the peak;

0.065017,0.001458,l
0.070446,0.001463,3
0.075940,0.001509,2
0.081552,0.001526,1
0.087273,0.001565,0
0.112027,0.001911,u
0.278660,0.002211,u
0.306486,0.001658,0
0.312480,0.001576,1
0.313626,2.507910,
0.318486,0.001626,2
0.319730,2.633097,
0.324801,0.001739,3
0.331848,0.001922,l
0.527509,0.001603,l
0.533231,0.001445,3
0.538648,0.001488,2
0.544081,0.001455,1
0.549517,0.001498,0
0.551725,2.422759,
0.570972,0.001346,u


  3. /users/yuta/PRCmodescan/calcmodescanresults.py reads peaks.csv and tells you the results;

Time between TEM00 and sideband  0.0239435  pm  0.00115999887452  sec
Calibration factor is  462.167602898  pm  22.3907907867  MHz/sec
FSR is  78.4797010471  MHz
FWHM is  0.729828720682  pm  0.0174145743828  MHz
TMS is  2.64718671684  pm  0.0538858477824  MHz
Finesse is  107.53166986  pm  2.5658325169
Cavity g-factor is  0.994390582331  pm  0.000228155661075
Cavity g-factor is  0.988812630228  pm  0.000453751681357   (Edited by YM; see elog #8056)
RoC of PR2 is  -187.384503001  pm  4.26100999578  m (assuming PRM RoC= 122.1  m)
RoC of PRM is  217.915890722  pm  5.65451518991  m (assuming PR2 RoC= -600  m)

  6772   Wed Jun 6 22:04:19 2012 JamieUpdateComputersFailed attempt to get pianosa to support dual monitors

I've spent an inordinate amount of time trying to figure out how to get pianosa to support dual monitors.  It apparently has some special nvidia graphics that are not well supported in Ubuntu (10.04 at least).  I've tried installing a newer kernel (3.0.0) and installing the special nvidia compile-from-source Ubuntu packages, but nothing is working.  And now unfortunately he's not giving me any video at all.  I'm sick of this today, so I'll try again tomorrow.

In the future we should avoid these bullshit nvidia cards like the plague.

  6773   Wed Jun 6 22:23:53 2012 JamieUpdateComputersFailed attempt to get pianosa to support dual monitors

I managed to get pianosa working again with just a single monitor.  I'm done trying to configure it for dual, though.

  5601   Mon Oct 3 14:05:41 2011 JenneUpdateSUSFailing to set SUS summary screen values

I assume it's because the burt restore didn't work for the SUS summary screen, but all of the values for the ifo suspensions (not the MCs...they're okay) are red. 

I am trying to run Rana's setSensors.py script, but am failing.  Any inspiration would be appreciated:

rosalba:SUS_SUMMARY>./setSensors.py 1001708529 500 .1 .25
['./setSensors.py', '1001708529', '500', '.1', '.25']
/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages/nds/__init__.py:28: RuntimeWarning: No protocol specified, attempting protocol nds_v2
  super(daq, self).__init__(host, port)
Connecting NDS2 .... authenticate done
Traceback (most recent call last):
  File "./setSensors.py", line 81, in ?
    mean = acquire(x)
  File "./setSensors.py", line 73, in acquire
    daq.request_channel(chans[x])
Boost.Python.ArgumentError: Python argument types in
    daq.request_channel(daq, str)
did not match C++ signature:
    request_channel(_daq_t {lvalue}, daq_channel_t*)

I'm not exactly sure what the problem is.  Line 73, looks like it should have 2 arguments in the daq.request_channel, but even if I put in the "daq" variable (which is set a few lines above), I get the exact same error.  So...something else is wrong.  Ideas from someone who "speaks" python??

  5604   Mon Oct 3 17:27:23 2011 JenneUpdateSUSFailing to set SUS summary screen values

Quote:

I am trying to run Rana's setSensors.py script, but am failing.  Any inspiration would be appreciated:

rosalba:SUS_SUMMARY>./setSensors.py 1001708529 500 .1 .25
['./setSensors.py', '1001708529', '500', '.1', '.25']
/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages/nds/__init__.py:28: RuntimeWarning: No protocol specified, attempting protocol nds_v2
  super(daq, self).__init__(host, port)
Connecting NDS2 .... authenticate done
Traceback (most recent call last):
  File "./setSensors.py", line 81, in ?
    mean = acquire(x)
  File "./setSensors.py", line 73, in acquire
    daq.request_channel(chans[x])
Boost.Python.ArgumentError: Python argument types in
    daq.request_channel(daq, str)
did not match C++ signature:
    request_channel(_daq_t {lvalue}, daq_channel_t*)

I'm not exactly sure what the problem is.  Line 73, looks like it should have 2 arguments in the daq.request_channel, but even if I put in the "daq" variable (which is set a few lines above), I get the exact same error.  So...something else is wrong.  Ideas from someone who "speaks" python??

 My guess is that this has something to do with the NDS client version you're using.  Try running the script on a machine where pynds and nds-client are known to be compatible, like pianosa.

  5674   Sun Oct 16 05:35:18 2011 ranaUpdateComputer Scripts / ProgramsFailing to set SUS summary screen values

Quote:

Quote:

I am trying to run Rana's setSensors.py script, but am failing.  Any inspiration would be appreciated:

rosalba:SUS_SUMMARY>./setSensors.py 1001708529 500 .1 .25
['./setSensors.py', '1001708529', '500', '.1', '.25']
/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages/nds/__init__.py:28: RuntimeWarning: No protocol specified, attempting protocol nds_v2
  super(daq, self).__init__(host, port)
Connecting NDS2 .... authenticate done
Traceback (most recent call last):
  File "./setSensors.py", line 81, in ?
    mean = acquire(x)
  File "./setSensors.py", line 73, in acquire
    daq.request_channel(chans[x])
Boost.Python.ArgumentError: Python argument types in
    daq.request_channel(daq, str)
did not match C++ signature:
    request_channel(_daq_t {lvalue}, daq_channel_t*)

I'm not exactly sure what the problem is.  Line 73, looks like it should have 2 arguments in the daq.request_channel, but even if I put in the "daq" variable (which is set a few lines above), I get the exact same error.  So...something else is wrong.  Ideas from someone who "speaks" python??

 My guess is that this has something to do with the NDS client version you're using.  Try running the script on a machine where pynds and nds-client are known to be compatible, like pianosa.

 Doesn't work on pianosa either. Has someone changed the python environment?

pianosa:SUS_SUMMARY 0> ./setSensors.py 1000123215 600 0.1 0.25
Traceback (most recent call last):
  File "./setSensors.py", line 2, in <module>
    import nds
ImportError: No module named nds

  2918   Wed May 12 03:56:54 2010 KojiUpdateIOOFaraday aligned

Zach and Koji

The old small MMT was removed and wrapped by Al foils.

The steering mirror IM2-IM4 were displaced and aligned.

The Faraday isolator block is moved and aligned.

The MC is realigned and resonatng TEM-00.

Now the MC has slightly miscentered beam on the mirrors owing to change of the stack leveling.
OSEMs are also in a strange state. We should check this later.

  9302   Mon Oct 28 12:53:23 2013 JenneUpdateCDSFarfalla and Asia added to Host Table in Wiki

Quote:

I have updated the hostable on linux1 to give farfalla the 230 IP address and let 'asia' keep 225.

 Neither of these computers were listed in the Martian Host Table in the wiki, so I put them on there.  It's handy to keep this updated, so that we know what IP addresses are available.

  3674   Thu Oct 7 17:53:07 2010 yutaUpdateComputersFarfalla with Firefox, fixed

(Kiwamu, Yuta)

Symptom:
 Farfalla(Acer Aspire one KAV60 netbook) couldn't run Firefox and returned the following error:
  Error: platform version '1.9.2.8' is not compatible with
  minVersion >= 1.9.2.9
  maxVersion <= 1.9.2.9

What we did:
1. Added the following line to ~/.cshrc.
  alias firefox "/usr/lib/firefox-3.6/firefox"
2. Made a cool launcher for firefox.

Result:
 Farfalla can fly into the web with Firefox now.

Notes:

 Even if it was then before, bash could run firefox. tsch couldn't.
 The command firefox was /cvs/cds/caltech/apps/linux/bin/firefox for tsch, because of the source /cvs/cds/caltech/cshrc.40m.
 I did this to zita which had the same symptom, too.

Next work:

 Farfalla wakes up on the wrong side of the bed. This has to be fixed.

  15209   Thu Feb 13 01:47:39 2020 gautamUpdateALSFast ALS - delay line prep

A few years ago, Koji and I setup a delay line phase shifter, which can be used to impart a (switchable) delay to a signal path. Since we talked about reviving the fast (= high bandwidth) ALS control scheme at the meeting, I reminded myself of the infrastructure available.

  • Schematic
  • Comprehensive note on theory of operation / performance.
  • Past elog threads - #11603 and #11604.
  • Attachment #1 - my modification to the ALS screen to add a slider that controls the channel C1:LSC-BO_1_0_SET. The label is a bit misleading for now - elog11604 tells you the conversion between this slider value and the actual delay in nanoseconds, but I couldn't get a soft channel set up that correctly FLNKed to this record. In the process of trying to do so, I edited the C1_ISC-AUX_ALS.db file, and also restarted the modbus and latch processes on c1iscaux a few times.
  • Attachment #2 - frequency dependent loss for some representative delays. At ~200 MHz, I find the measured loss to be > 8dB, which is ~2dB more than what the D. Sigg note tells me to expect. This is rather a lot of loss, but I guess it's okay. Measurement cable loss was calibrated out with the AG4395A.
  • Attachment #3 - confirmation of constantness of delay as a function of frequency, for some representative delays. The "undelayed" setting corresponds to a fixed delay of ~4 nsec, which is consistent with what the D. Sigg note tells me to expect. Once again, I calibrated out the delay of the measurement setup using the AG4395A.

For a beat note in the regime 10-100 MHz, we should have plenty of range in this module to add a delay such that we zero one quadrature of the ALS DFD output (for a linear error signal). 

I then proceeded to connect the single-ended front panel BNC corresponding to the ALS_X_I DFD channel to the IN2 input of the CM board (this would be what we use for high bandwidth ALS feedback). The conventional ALS system uses the differential output from a rear-panel D-sub, so in principle, both systems could run in parallel. I confirmed that I could see a signal when the IN2 path on the CM board was engaged (monitored using ndscope at the CM_Slow output), and that this signal stabilized when the green laser was locked to the X-arm length, which itself was slaved to the PSL frequency using the usual POX locking scheme. I have not yet routed the LO leg of the ALS_X beat through the delay line phase shifter - see next elog for details.

Update about the ALS MEDM screen slider: the trick was to change the OMSL field of the C1:LSC-BO_1_0 channel to "closed_loop" instead of "supervisory". Once this is done, the DOL value of the same channel can be set to the soft channel C1:ALS-DelayCalc, which sets the 16 bit binary string that controls the delay. Because arbitrary delays are not possible, I think it's more natural for the user to interact with this 16-bit binary string rather than the actual delay itself. So the MEDM screen has been slightly modified from what is shown in Attachment #1.

Attachment 1: delaySlider.png
delaySlider.png
Attachment 2: delayLineLosses.pdf
delayLineLosses.pdf
Attachment 3: delayLineCal.pdf
delayLineCal.pdf
  15212   Fri Feb 14 00:53:50 2020 gautamUpdateALSFast ALS - more setup

In the process of setting up some cabling at 1Y2, I must've bumped a cable to the c1lsc expansion chassis. Anyways, the c1lsc models crashed. I ran the reboot script around 530pm PDT. Usual locking behavior was recovered after this. The work at 1Y2 was:

  • Ran a cable from X Beat power splitter ("LO" leg of the analog delay line) to variable delay line. 
  • Ran cable from delay line to demodulator's LO input.
  • Set up the SR785 for some CM board TF measurements.

The IN2 to CM board was already connected to I single ended output of the ALS X demodulator. The ~100 Hz UGF digital locking using the CM_SLOW path is straightforward but I didn't have any success with the AO path tonight. I wonder how high BW this lock can be made without injecting a ton of noise into the IMC loop, given that the EX uPDH only has ~ 10 kHz UGF.

Attachment #1 shows the spectra of the ALS signal 

  • The two "CM Slow" traces are the digitized "SLOW" output of the common mode board, whose IN2 is connected to the demodulated I output of the analog delay line.
  • The delay in the LO line of the analog delay line is adjusted to zero the DC value of this signal to best effort.
  • These spectra are measured with the arm cavities POX/POY locked, and the EX laser locked to the arm cavity using the end PDH box.
  • I simultaneously monitor the output of the digital phase tracker servo, and scale the CM Slow signal such that the spectra line up. The scaling factor required was to multiply the CM_SLOW signal x10 (CM board IN2 gain was set to +6dB, to account for the x2 gain in going from single ended to differential inside the ALS demodulator box).
  • One puzzline feature is why switching on the ADC whitening makes the ALS spectrum noisier (even though it clearly changes the digitization noise floor). There is a peak that appears at ~ 8 kHz with the whitening on, and it may also be downconverted noise from some peak at higher frequencies I guess (if the AA isn't sharp enough). 

Attachment #2 is an OLTF measurement.

  • In the blue trace, the arm length is controlled by using the CM Slow signal as an error signal, applying feedback to IMC length via MC2.
  • In the red trace, I turned the digital MC2 violin notches off, and added upped the IMC IN2 gain to -12 dB (AO gain slider = 0dB).
  • This was as high as I could go before the PC drive RMS began to go crazy.
  • But still, there isn't any significant phase advance.
  • It is possible I need to tack on a low-pass filter to prevent noise injection at higher frequencies...
Attachment 1: CMSlow_ALSnoise.pdf
CMSlow_ALSnoise.pdf
Attachment 2: OLTFmeas.pdf
OLTFmeas.pdf
  11686   Tue Oct 13 16:28:21 2015 ericqUpdateLSCFast ALS pomona

I've made a cascaded passive 2-pole pomona box for fast ALS use, using LISO to check that it'll give the right shape when hooked up to the CM board's input stage. 

First stage is a 133Ohm + 10uF cap for ~120Hz LP, second is 1.15kOhm + 47nF cap for ~3.8kHz LP. The DC gain is ~0.75, which is much better than what I was doing before. The second stage would normally make a 2.9kHz LPF on its own, but the loading of the input stage moves the corner up. 

It seems the 133 Ohm resistor is a reasonable load on the output AD829 of the ALS demod board (short-circuit output current of 32mA and a series output resistor of 499Ohm). To be able to use the digitized ALSX I and the lowpassed analog version simultaneously, I had to buffer the signal with a SR560 before the pomona box, otherwise the signals looked distorted. This isn't a good long-term solution. Maybe I can used the further-buffered differential output to drive the LPF+CM board. 

The LISO files used to model the filter and CM board input stage, and fit the pole frequencies are attached. 

I made some attempts to get the AO path going today, but I suspect this daytime noise is just too much; the PC drive seems too irritable

Attachment 1: liso_lp.zip
Attachment 2: 2LPfit.pdf
2LPfit.pdf
ELOG V3.1.3-