ADC noise is not a limiting noise source in a current ALS setup.
Below is the calibrated spectrum of C1:ALS-COARSE_I_ERR when
Y arm swinging with just damping (red; taken last night)
terminated before AA (green)
blocked PSL green beam (blue)
Blue and green curve tells us that noise from the beat PD to ADC is not contributing to the Y arm length sensing noise.
Interesting. It seems for me that there is a dependence of the noisiness as the beat frequency is scanned.
As you increase (or decrease?) the offset, C1:ALS-BEATY-COARSE_I_IN1 becomes bigger and more crisp.
The resulting out-of-loop stability also seems to be improved as you can see from the crispness of the PDH signal.
Do you find why this happens? Is this because the beat S/N depends on the beat frequency due to the PD noise?
I scanned Y arm for 5FSR (below).
I could done this after I put a whitening filter.
Currently, whitening filter between the beatbox and AA filter is made of
Ponoma blue box(passive filter with zero at 1 Hz, pole at 10 Hz) + SR560(flat gain 100)
I couldn't do more than 5FSR because SR560 overloads. I checked it by staring at the indicator during the scan.
Reason why we kept loosing lock last night was the overload of SR560. Mystery solved!
Anyway, 5FSR is enough.
Our next step is to reduce residual arm length fluctuation.
Also, I increased the alingnment of IR. So, the higher order modes are less than the last scan.
We couldn't scan the Y arm for 1FSR last night because the ALS servo breaks while sweeping.
We thought this might be from the amplitude fluctuation of the beat signal. The amplitude of the beat signal goes into the beatbox was about -5 dBm, which is not so enough for the beatbox to get good LO. So, we put an amplifier (and attenuators) and the amplitude became +1 dBm. The range beatbox can handle is about -3 dBm to +3 dBm, according to our calculation.
This increased stability of the lock, and we could scan the arm for 1FSR. Below is the plot of scanned ALS error signal (blue), Y arm IR PDH signal (green) and TRY (red).
For each slope, we can see two TEM00 peaks, some higer order modes(may be 01, 02, 02) and sidebands (large 11MHz, small 55MHz?).
We couldn't scan for more. This is still a mystery.
Also, we need to reduce residual Y arm length fluctuation more because we get funny TRY peak shape.
For C1:ALS-BEATY_COARSE_I_IN1, 1 count stands for 0.21 nm(see elog #6817). We sweeped 4000 peak to peak in 50 sec. So, the scan speed is about 17 nm/sec.
This means it takes about 0.06 sec to cross resonant peak.
Cavity build up time is about 2LF/(pi*c) ~ 40 usec. So, the scan is quasi-static enough.
Characteristic time scale for the Y end temperature control is about 10 sec, so Y end frequency is following the Y arm length change with temperature control.
Currently, sampling frequency of DQ channels are 2048 Hz. This means we have 100 points in a TRY peak. I think this is enough to get a peak height.
- Reduce RMS. We are trying to use a whitening filter.
- Find why we can't scan more. Why??
- ETMY coil gains may have some unbalance. We need to check
- Characterize Y end green frequency control. Koji and I changed them last week (see elog #6776).
- Calculate positions of RF SBs and HOMs and compare with this result.
Arm cavity FWHM for IR is
FWHM = FSR / F = c/(2LF) = 8 kHz.
In cavity length, this is
L/f * FWHM = 40m/(c/1064nm) = 1.2 nm
So, to do mode scan nicely, arm length fluctuation during resonant peak crossing should be much less than 1.2 nm.
Let's consider only ADC noise and seismic noise.
* S: conversion from Y arm length to the beat frequency
dL/L = df/f
S = df/dL = f/L = c/532nm/40m = 1.4e7 MHz/m
* W: whitening filter
We set it to flat gain 50. So,
W = 50
* D: AD conversion of voltage to counts
D = 2^16counts/20V = 3300 counts/V
* B: frequency to voltage conversion of the beatbox.
We measured BWD(elog #6815). When we measured this, W was 10. So, the calibration factor at 0 crossing point(~ 50 MHz) is
B = 1400*0.048/10/D = 0.0021 V/MHz
* A: actuator transferfunction
I didn't measure this, but this should look like a simple pendulum with ~ 1 Hz resonant frequency.
* n_ADC: ADC noise
ADC noise is about
n_ADC = sqrt(2*LSB^2*Ts) = sqrt(2*(20V/2^14)**2*1/64KHz) = 1.6 uV/rtHz
* n_seis: seismic noise
We measured this by measuring C1:ALS-BEATY_COARSE_I_IN1. This is actually measuring
D(WBSn_seis + n_ADC)
Calibrated plot is the red spectrum below.
* F: servo filter (basically C1:ALS-YARM)
We need to design this. Stabilized arm length fluctuation is
x_stab = 1/(1+G)*n_seis + G/(1+G)*n_ADC/(WBS)
where openloop transferfunction G = SBWDFA.
Below ~ 50 Hz, n_seis is bigger than n_ADC/(WBS). We don't want to introduce ADC noise to the arm. So, UGF should be around 50 Hz. So, we need phase margin around 50 Hz.
We also need about 10^3 DC gain to get the first term comparable to the second term.
Considering these things, openloop transferfunction should look like the below left. Expected error signal when ALS on is the below right. I put some resonant gain to get rid of the peaks which contribute to the RMS (stack at 3.2Hz, bounce at 16.5 Hz).
Inloop RMS we get is about 0.3 nm, which is only 4 times smaller than FWHM.
We need to reduce RMS more by factor of ~ 30 to get resolusion 1% of FWHM.
Most contributing factor to the RMS is power line noise. We might want comb filters, but it's difficult because UGF is at around this region.
So, I think we need more fancy whitening filters. Currently, we can't increase the gain of the whitening filter because SR560 is almost over loading. Whitening filter with zero at 1 Hz might help.
[Jenne, Koji, Yuta]
We tried to scan of the Y arm but we couldn't scan for more than 1FSR.
In principle, we can do that because the error signal we are using, C1:ALS-BEATY_COARSE_I_IN1, has the range of ~ 40 MHz, which is about 10FSR (see elog http://nodus.ligo.caltech.edu:8080/40m/6815).
ALS stays for more than 10 min when we don't do the scan. If we put some offset gradually from C1ALS-OFFSETTER2, the lock breaks.
We monitored PZT output of the Y end laser, C1:GCY-SLOW_SERVO1_IN1, but it stayed in the range when scanning. So, there must be something wrong in the ALS loop.
Current in-loop arm length fluctuation is about 0.1 nm RMS (0.5 counts RMS).
Below is the spectrum of the error signal when the ALS is off(green) and on (pink,red). Below ~ 50 Hz, the measurement of the Y arm length is limited by ADC noise (~ 2uV/rtHz).
We put 0 dBm sine wave to the RF input of the beatbox and linear-sweeped frequency of the sine wave from 0 to 200 MHz using network analyzer (Aligent 4395A).
(We first tried to use 11 MHz EOM marconi)
Whlile the sweep, we recorded the output of the beatbox, C1:ALS-BEATY_(FINE|COARSE)_(I|Q)_IN1_DQ. We made them DQ channels today. Also, we put gain 10 after the beatbox before ADC for temporal whitening filter using SR560s.
We fitted the signals with sine wave using least squares fit(scipy.optimize.leastsq).
Transision time of the frequency from 200 MHz to 0 Hz can be seen from the discontinuity in the time series. We can convert time to frequency using this and supposing linear sweep of the network analyzer is perfect.
Plots below are time series data of each signal(top) and expansion of the fitted region with x axis calibrated in frequency (bottom).
C1:ALS-BEATY_COARSE_I_IN1_DQ = -1400 sin(0.048 freq + 1.17pi) - 410
C1:ALS-BEATY_COARSE_Q_IN1_DQ = 1900 sin(0.045 freq + 0.80pi) - 95
C1:ALS-BEATY_FINE_I_IN1_DQ = 1400 sin(0.89 freq + 0.74pi) + 15
C1:ALS-BEATY_FINE_Q_IN1_DQ = 1400 sin(0.89 freq + 1.24pi) - 3.4
(freq in MHz)
The delay line length calculated from this fitted value (supposing speed of signal in cable is 0.7c) is;
D_coarse = 0.7c * 0.048/(2*pi*1MHz) = 1.6 m
D_fine = 0.7c * 0.89/(2*pi*1MHz) = 30 m
So, the measurement look quite reasonable.
FINE signals looks nice because we have similar response with 0.5pi phase difference.
For COARSE, maybe we need to do the measurement again because the frequency discontinuity may affected the shape of the signal.
The MC_ IDC 64 pin cables from sat. amplifiers to junction-interface-board towards whitening - dewhitening at the back of rack 1 X 5 are finally clamped with
All other sus cables of the same kind have the correct short latch arm to lock them in for reliable contact.
You can easily calculate whether or not the coarse readout will work by thinking about the scan resolution you need given the ADC dynamic range and the whitening filter that you use.
Linear range df of the delay line technique is about df ~ c/(2D). So, the linear range for the fine signal(delay line length D=30m) is about 5 MHz.
Arm cavity FSR = c/(2L) = 3.7 MHz.
So, I think we need phase shifting to do mode scan for more than 2 FSRs by holding the arm length finely with fine servo.
For the coarse (D=1.5m), the linear range is about 100 MHz, so if we can do mode scan using coarse servo, it is OK.
In any case, I think it is nice to have linear signal with fixed slope even if we don't adjust the phase every time.
That sounds goofy.
With the delay line technique, you can get a linear signal over 50 MHz with no phase shifting. What is with all this I/Q stuff?
I stabilized Y arm length by using only I phase coarse signal from the beat(C1:ALS-BEATY_COARSE_I_ERR).
I sweeped the arm length by injecting 0.05Hz sine wave from C1:ALS_OFFSETTER2_EXC.
Below is the plot of TRY and the error signal(ideally, Y arm length) while the sweep.
I couldn't hold the arm length tight, so you can see multiple peaks close to each other.
We need to
- adjust offsets
- adjust rotation phase of I-Q mixing
- adjust servo filters
to hold the length tighter.
Also, I couldn't sweep the Y arm length very much. I need to calibrate, but to do the modescan for many FSRs, we need to
- introduce automatic phase optimizing system
There were sin/cos function in the CDS_PARTS, so I think we can feedback I_ERR to control rotation phase of I-Q mixing.
Yes!! We have I-Q signals for the beat!!
What we did:
1. Aligned Y arm to the Y end green incident beam. The transmission to the PSL was about 195 uW.
2. Aligned IR beam to the Y arm by adjusting PZTs and got the transmission, C1:LSC-TRY_OUT ~ 0.86.
3. Aligned green optics on the PSL table to get the beat signal. The beat was found when;
PSL laser temperature on display: 31.41 deg C
C1:PSL-FSS_SLOWDC = 1.43
Y end laser "T+": 34.049 deg C
Y end laser "ADJ": 0
Y end laser measured temperature: 34.14 deg C
C1:GCY-SLOW_SERVO2_OFFSET = 29950
Y end slow servo: off (was on)
4. Connected the beat PD output to the beatbox.
5. Kicked ETMY position to change the cavity length and while the ringdown, we run pynds to get data. We plotted C1:ALS-BEATY_FINE_I_ERR vs C1:ALS-BEATY_FINE_Q_ERR, and C1:ALS-BEATY_COARSE_I_ERR vs C1:ALS-BEATY_COARSE_Q_ERR (below). We got nice circle as expected.
Only AA filers are put between the output of the beatbox and the ADC.
We recompiled c1gcv because the order of the channels were confusing. We found some change in the phase rotation module when we did this.
I did some cabling and checked each signals are actually going to the right channel. I labeled all the cables I know, which go into the AA chasis for ADC1 of c1ioo machine.
Below is the list of the channels. If you know anything about "unknown" channels, please let me know.
Current channel assignments for ADC1 of c1ioo machine:
Red ones were added today. Green ones existed in the past, but channel assignment were changed.
Memorandum for me:
rtcds make c1gcv
rtcds install c1gcv
rtcds start c1gcv
We can't compile any changes to the LSC or the GCV models since Jamie's new script / program isn't found. I don't know where it is (I can't find it either), so I can't do the compiling by hand, or point explicitly to the script. The old way of compiling models in the wiki is obsolete, and didn't work :(
Sorry about that. I had modified the path environment that pointed to the rtcds util. The rtcds util is now in /opt/rtcds/caltech/c1/scripts/rtcds, which is in the path. Starting a new shell should make it available again.
Added TRX and TRY and POY11_I_ERR and POX11_I_ERR to the c1lsc.mdl using a new-style DAQ Channels block, recompiled, installed, started the model, all good. Restarted the daqd on the framebuilder, and everything is green. I can go back and get recorded data using dataviewer (for the last few minutes since I started fb), so it all looks good.
Note on the new DAQ Channels block: Put the text block (from CDS_PARTS) at the same level as the channel you want to save, and name it exactly as it is in the model. The code-generator will add the _DQ for you. i.e. if you define a channel "TRY_OUT_DQ" in the lsc model, you'll end up with a channel "C1:LSC-TRY_OUT_DQ_DQ".
All PEM and IOO DQ channels disappeared. These channels were commented in C1???.ini files though I've uncommented them a few weeks ago. It happened after these models were rebuild, C1???.ini files also changed. Why?
I added the channels back. mx_stream died on c1sus after I pressed DAQ reload on medm screen. For IOO model it is even worse. After pressing DAQ Reload for C1IOO model DACQ process dies on the FB and IOO machine suspends.
I rebooted IOO, restarted models and fb. Models work now, but there might be an easier way to add channels without rebooting machines and demons.
Yuta claims he fixed the PRM oplev by centering it the other day, but no one has left it on and watched it for a long while, to make sure it's okay. We watched it now for ~2 min, and it was good, but we're leaving the oplevs off anyway for the night. Tomorrow we should restore PRM (it's currently restored), turn on the oplevs, and let it sit to make sure it doesn't go crazy.
PRM oplev servo was turned on with PITgain 0.5 and YAWgain -0.7
Note: gain settings were PIT 1.0 and YAW --0.5 on Jun 1, 2012 that I measured Feb 23, 2012
It is still oscillating. Gains turned down to zero.
A nicer, better maintained version of tconvert is now supplied by the lalapps package. It's called lalapps_tconvert. I installed lalapps on all the workstations and aliased tconvert to point to lalapps_tconvert.
Yuta added channels so we can get the Q phase of all the beat PDs to the c1gcv model. I showed him how to recompile/install/start.
During the install, it couldn't find: Unable to find the following file in CDS_MEDM_PATH: LOCKIN_FILTER.adl
Unable to find the following file in CDS_MEDM_PATH: LOCKIN_FILTER.adl
On all the screens (ALS and SUS), lockin parts are white. Someone changed something, then didn't go back to fix the screens.
Otherwise, things look to be working fine.
I'm starting to feel like a wine-o here. Yuta wanted to glance at the PRM oplev dataviewer, and lo and behold, the fb lost connection just as he decided to do that. We had checked the front end status screen not 1 minute beforehand, and everything was green. Lame.
We aligned Y arm to the Y end green incident beam.
We noticed two TEM00, bright and dim, so we decreased Y end laser temperature to 34.13 deg C.
It doubled the transmission of the green, and now the transmission to the PSL table is 178 uW, which is close to the maximum(197 uW) we got so far.
Current settings for Y end laser is;
Y end laser "T+": 34.049 deg C
Y end laser "ADJ": 0
Y end laser measured temperature: 34.13 deg C
C1:GCY-SLOW_SERVO2_OFFSET = 31025
Y end slow servo: on (was off)
We aligned IR beam to the Y arm by mostly adjusting PZTs and got the transmission, C1:LSC-TRY_OUT ~ 0.9.
We tried to calculate the mode-matching ratio for IR by taking TRY data while ITMY and ETMY are swinging (without ALS), but it was difficult because we see too many higher order modes.
Tomorrow, we will (1) connect the beatbox to ADC, (2) edit c1gcv model, (3) scan the arm using I-Q signals.
As usual, we noticed the frame builder wasn't connecting happily with the rest of the computers just as we were about to lock some stuff (we never notice it being bad when we're not trying to use the frame builder....)
All the big rectangles by each computer were white. I restarted daqd, and that brought most things back. c1lsc and c1sus needed their mx_streams restarted manually to get everything green again.
I've had about enough whine with my computers for tonight.
This means we can't (a) record TRY or (b) add the Q quadrature of the beat PD to the real time system tonight.
We're going to try just using Yuta's pynds script to capture data in real time, so we can keep working for tonight.
tdsavg isn't working:
controls@rossa:/opt/rtcds/caltech/c1/scripts/LSC 6$ tdsavg 10 C1:LSC-ASDC_IN1
ERROR: LDAQ - Unable to find NDS host "fb0"
ERROR: LDAQ - Unable to find NDS host "fb1"
ERROR: LDAQ - Unable to open socket to NDS.
When this command is executed inside a script, it doesn't return anything. eg:
set offset = `tdsavg 10 C1:LSC_ASDC_IN1`
returns a blank line.
Past elog research said lots of things about test points. I didn't suspect that, since there aren't many test points occupied (according to the CDS status screens), but I cleared the test points anyway (elog 6319). Didn't change anything, still broken.
LSCoffsets script, and any others depending on tdsavg will not work until this is fixed.
We need I-Q frequency deiscriminator to control the arm length fine and continuously.
I checked the beatbox (LIGO-D1102241-v4; see elog #6302) and it was working.
What I did:
1. Measured some transferfunctions with a network analyzer (Aligent 4395A) and checked the cabling is correct.
2. Put 30 m/1.5 m delay line and checked I-Q outputs are actually orthogonal. I did this by sweeping the frequency of RF input to the beatbox. See attached picture. You can see nice circle on the oscilloscope.
Some measurement results:
- Gains of the transferfunctions(@ 10-100MHz) between;
RF in -> RF mon: -25 to -20 dB
RF in -> fine delay out: -50 to -40 dB
RF in -> coarse delay out: -50 to -40 dB
RF in -> LO of mixer RMS-1: ~ +4 dB (RMS-1 needs +7 dB LO)
- 30m delay line(RG-142B/U) had -2 dB loss.
- RF input must be larger than about -3 dBm to get enough LO to the mixer. Otherwise, you won't get I-Q outputs.
- The comparator, whitening filter and differential DAQ outputs are not installed in the current beatbox.
- Current beatbox only has electronics for the one arm.
- The print on the board D1102241 says +15V and -15V, but they are actually opposite. Cabling is swapped in order to supply correct power to the ICs.
There is an intermittent rattling sound coming from the HEPA in the NE corner of the PSL table (right above the PMC, all of our input optics).
Steve says it might be a bad bearing, but he'll check it out in the morning and get it fixed.
MC was having a hard time staying locked, with no discernable reason from the control room (i.e. no big seismic, no PMC PZT railing). The HEPA was on 100%, so I turned it down to 50% to hopefully reduce the rattling, if that was what was wrong.
IOO Angle & IOO Position QPDs centered.
PMC trend of 400 and 1200 days
The Innolight 2W based PSL- IOO was implemented in the ~ summer of 2010
The PMC was locked and the MC followed intantly
We tried not to open chambers above 10,000 particles of 0.5 micron cf/min
New items going in: 2 rasor beam traps, 5 badly oxidized old silver plated setscrew with spring loaded tips......to be replaced in the future, viton tips for eq screws....some are lose, gold plated allen wrench installed at ITMX bottom, reglued magnet on ITMX
Bad hardware things found: nylon ball "locking elements" on OSEM locking set screws with screwdriver slot, lose 1064 nm filter on OSEM pd
40m - pumpdown 71- maglev pumping speed - at day 276........all normal
Laser temperature settings for Y arm green work today are;
PSL laser temperature on display: 31.38 deg C (PSL HEPA 100%)
C1:PSL-FSS_SLOWDC = 1.68
Y end laser "T+": 34.049 deg C
Y end laser "ADJ": 0
Y end laser measured temperature: 34.13 deg C (*)
C1:GCY-SLOW_SERVO2_OFFSET = 29845
Green transmission from Y end and PSL green power on the beat PD are;
P_Y = 28 uW
P_PSL = 96 uW
P_Y decrease from its maximum we got (75 uW, see elog #6777) is because the alignment for Y arm green is decreased. I can see the decrease from the green reflection on ETMT camera, but I will leave it because we already have enough beat.
I aligned PSL optics, including the mode-matching lens to maximize the beat note. The beat note I got is about 26dBm.
The calculated value is -14 dBm, so we have about 75 % loss.
I measured the reflection from the PD window and its reflectivity was about 30%. We still have unknown 45% loss.
PRM oplev beam was not hitting on the QPD since Jun 1, so I centered it. I reverted the oplev servo gains and now oplev servo looks fine.
C1:SUS-PRM_OLPIT_GAIN = 1.0
C1:SUS-PRM_OLYAW_GAIN = -0.7
There's SIDE to UL/UR/LL/LR coil element in PRM TO_COIL matrix. They were 0 until Mar 31, 2012, but someone changed them to -0.160. I couldn't find elog about it.
Same thing happened to BS on Mar 13, 2012 (see elog #6409), so I think somebody did the same thing to PRM.
Somehow c1sus was in a very strange state. It was running models, but EPICS was slow to respond. We could not log into it via ssh, and we could not bring up test points. Since we didn't know what else to do we just gave it a hard reset.
Once it came it, none of the models were running. I think this is a separate problem with the model startup scripts that I need to debug. I logged on to c1sus and ran:
rtcds restart all
(which handles proper order of restarts) and everything came up fine.
Have no idea what happened there to make c1sus freeze like that. Will keep an eye out.
C1:SUS-PRM_OLPIT_GAIN 1.0 -> 0
C1:SUS-PRM_OLYAW_GAIN -0.7 -> 0
Set the PRM OL servo gains to zero until someone can take care of this. Turning off the buttons doesn't help anything if people run the alignment scripts.
Added zita to the martian host table, and configured his network accordingly:
zita A 192.168.113.217
I decided to remove what I thought was the problematic extra nVidia video card, since there are already two DVI outputs build-in. The card turned out to not even be nVidia, so I don't know what was going on there.
I futzed with the BIOS to configure the primary video card, which is some new Intel card. The lucid (10.04) support for it is lacking, but it was easy enough to pull in new drivers from the appropriate Ubuntu PPA repository:
controls@pianosa:~ 0$ sudo apt-add-repository ppa:f-hackenberger/x220-intel-mesa
controls@pianosa:~ 0$ sudo apt-add-repository ppa:glasen/intel-driver
controls@pianosa:~ 0$ sudo apt-get update
controls@pianosa:~ 0$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
libdrm-intel1 libdrm-nouveau1 libdrm-radeon1 libdrm2 libgl1-mesa-dri libgl1-mesa-glx libglu1-mesa xserver-xorg-video-intel
8 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 3,212kB of archives.
After this operation, 25.2MB disk space will be freed.
Do you want to continue [Y/n]?
After a reboot, both monitors came up fine.
Air conditioning maintenance is scheduled for tomorrow from 8 to 11am
Jeff checked and replaced filters as needed. Job completed this morning.
What not to do:
The PRM oplev servo was left on and it was driving this oscillation overnight.
Oplev servo turned off and sus damping restored. What is kicking up the PRM?
The PRM oscillation stopped by turnig off oplev servo.
Do not turn Oplev Servo on when PRM is missaligned !
Yes. The end PDH servo should be checked more carefully.
The end PDH seems to have insufficient gain at around 100Hz.
The attached is the ALS noise budget calculated with the simulink model for the green locking paper.
The residual error of the end AUX laser (green) is contributing to the final ALS signal (black).
In particular, the residual AUX frequency noise, which is shown as the blue, is contributing to the noise above 100Hz.
In the model I also confirmed that the servo still has a room for improvement.
By having more suppression of the AUX frequency noise, we will be able to increase the ALS servo bandwidth
without increasing the ALS residual RMS by a servo bump. This will give us the improvement of the seismic
noise suppression at 10Hz (i.e. more suppression of red).
I coarsely stabilized Y arm length to off resonance point for IR using ALS.
Currently, ASL servo loop is unstable and oscillates so much that I can't hold the length to the resonance point.
We need more investigation on the servo loop before doing the mode scan.
Below is a snapshot of ALS medm screens and time series data of the error signal for ALS coarse loop (C1:ALS-BEATY_COARSE_I_ERR) and IR transmission for the Y arm (C1:LSC-TRY_OUT) when I turned the servo on.
I took off amplifiers right after the beat PD on PSL table.
Also, I reverted the gain change Jenne made last night (elog #6750), because they no longer show overload lights.
c1lsc and c1ioo computers had FB net statuses all red. So, I restarted mx_stream on each computer.
sudo /etc/init.d/mx_stream restart
I found the big green beat note for the Y arm. The alignment of the green optics on the PSL table was crappy.
What I did:
1. By adjusting PSL laser temperature, I found tiny beat note when
PSL laser temperature on display: 31.35 deg C (PSL HEPA 100%)
C1:PSL-FSS_SLOWDC = 1.75
PSL laser temperature on display: 33.21 deg C (PSL HEPA 100%)
C1:PSL-FSS_SLOWDC = -6.82
Y end laser temperature settings are fixed as follows during the measurement.
Y end laser "T+": 34.049 deg C
Y end laser "ADJ": 0
Y end laser measured temperature: 34.13 deg C (*)
C1:GCY-SLOW_SERVO2_OFFSET = 29845
Bryan's formula (swapped one; see elog #6746), suggests the paring
(Yend laser temp, PSL laser temp) = (34.13 deg C, 31.09 deg C).
2. Checked that beat PD is working by swapping the beat PDs for Y arm and X arm.
3. Checked that the mode-matching of the two beams, one from Y arm and the other from PSL, is OK by moving mode-matching lens and measuring the beam spot size at near/far field are the same.
4. When checking the beam spot size at far field(~ 1 m from the BS), I noticed the relative beam tilt by ~ 1 mrad. We aligned them few days ago, but I think the green beam from the Y arm has shifted. Of course we align IR to the Y arm first, but we difinitely need dither servo or A2L for the arm, too.
5. As soon as aligning the PSL green optics near the BS, I found a large beat note. The measured amplitude was ~ -26 dBm, without any amplifiers after the PD.
Currently the measured green beam power onto the beat PD from Y end is 75 uW and from PSL is 92 uW. So the calculated beat amplitude will be ~ -10 dBm (see calculation in elog #6746). So there is about 84% loss. Anyway, I will go on to the mode scan.
We improved the Y arm green transmission to the PSL table. It is now 197 uW.
The improvement was done mainly by adjusting the Y arm green servo gain.
What we did:
1. Fine-adjusted steering mirrors after the faraday on Y end table by monitoring Y arm green transmission (used Thorlabs PDA36A as a PD, C1:GCV-GREEN_TRY as a channel). We decided which way to adjust the mirrors by just pushing/pulling its mount.
2. The output of the reflection PD on the oscilloscope seemed like the Y end frequency servo was oscillating. So, we reduced the amplitude of the frequency modulation from 2.83 V to 0.13 V.
3. We noticed there were two TEM00, one is brighter and the other is dim. We thought this came from a mode-hopping or something. So, we changed the Y end laser temperature from 34.68 deg C to 34.13 deg C (measured). This reduced dim TEM00 and the main one got brighter. C1:GCY-SLOW_SERVO2_OFFSET was changed from 29425 to 29845.
4. Fine-adjusted the position of the mode-matching lens by reduing LG modes.
Current green power:
Current measured green power values are as follows.
Calculated value for the Y arm green transmission is ~ 600 uW, but we think we are almost at the maximum we can get. So, we have about 70% loss from the Y end table to the PSL table. There may be large loss in windows. The beam shape of the transmitted beam seems OK, but there may be some clipping.
- Fine tune the Y end frequency servo loop. Reducing the amplitude of the frequency modulation for reducing the gain is not a very good idea.
I found the big big Y green beat. Details will be posted later.
I'll finish the rest of the config to turn it into a full-fledged workstation tomorrow.
I managed to get pianosa working again with just a single monitor. I'm done trying to configure it for dual, though.
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.