||Tue Oct 30 16:55:40 2007
||tobin||Routine|| ||Drag-wiping perfected|
Steve procured an assortment of syringes from the bio storeroom and we practiced drag-wiping the SOS in the flow bench. Using a 50 microliter Hamilton syringe to deliver 16 microliters of methanol seems perfect for drag-wiping the small optics. Drag-wiping in the downward direction seems to work very well, since we can squirt the optic directly in the center, and the (half) piece of kodak lens tissue fits easily between the bottom two earthquake stops.
||Thu Nov 15 18:36:48 2007
||John||Summary|| ||PSL table work|
|I've rotated the lambda/2 plate to 340deg (from 6 deg) and blocked one arm of the Mach-Zender. Undo both if you need to.|
||Wed Nov 28 12:43:53 2007
||Andrey||Bureaucracy|| ||Here was the PDF-file of my presentation|
I was making a report with powerpoint presentation during that Wednesday's 40-m meeting.
Here was the pdf-file, but LATER IN THE EVENING I CREATED A WIKI-40M-page describing the algorithm, and now the pdf-file is ON THAT WIKI-40M PAGE.
NOTE ADDED AFTER THE PRESENTATION: I double checked, I am indeed taking the root-mean-square of a difference, as we discussed during my talk.
My slide #17 "Calculation of differential length" was wrong, but now I corrected it.
||Thu Dec 27 12:12:02 2007
||pkp||Update|| ||Update on GigE Camera|
|So I finally got the linux software to compile on mafalda. I got the software to dump all the information regarding the camera onto a file. I tried to take a tiff snap and came up empty. So I looked at the configuration file and realized that the camera thinks that the frame-rate is a nan. Am reading up the manual to fix the frame-rate manually and then will attempt to take another snap.|
All the files are in a folder called Prosilica in /home/controls/ on mafalda. All the executables are in /home/controls/Prosilica/bin-pc/x86/* . On another note, I am looking for a name for the camera. Any suggestions are welcome.
||Wed Jan 23 09:27:55 2008
||steve||Update|| ||etmy sus damping restored|
|Seismis event trips etmy|
||Fri Jun 20 02:20:33 2008
||Yoichi||Update|| ||PMC transmittance degradation|
|The PMC transmitted light power has been degrading constantly for last two weeks (see the attachment 1).|
I went down to 2.55V.
The output of the MOPA is constant during this period. More strangely, the reflected power from the PMC is also constant.
One possible explanation is the contamination of the PMC mirrors. But I don't know why it started two weeks ago.
I tweaked the alignment of PMC and was able to recover the transmitted power to above 2.7V (attachment 2).
I will keep eye on this issue.
||Wed Jun 25 09:46:45 2008
||Sharon||Update|| ||Adaptive Filters|
|I have been learning about different methods for applying adaptive filters to improve the Mode Cleaner lock in specific, and other LIGO systems in general.|
Finding the exact number of coeffs we would like to apply for our FIR adaptive filter is very important to the efficiency of the filter. Getting this number higher might improve the accuracy of the filter, but costs time we do not have. Another important number to find is the step size. The step size is the variable that controls how far back we want to look into our data for finding the new coeffs. To understand more about the step size it is necessary to learn about the standard deviation of our input and output signals. By getting the step size too big, we are considering long term behavior, but might be missing out on a short term one.
In the near future I will be learning about the meanings of these variables and their contribution to the over all accuracy of our filters.
Results will be posted.
||Thu Jun 26 18:29:44 2008
||Jenne||Update|| ||MC Back online|
|Jenne, Rob, Yoichi|
I was playing with the Mode Cleaner earlier today, working on measuring the effect of the new filter (see next post for loop gain measurements etc.), and bumped something which made it so the Mode Cleaner would not lock.
After much poking around by Rob and Yoichi, we found that the TNC-to-2 pin LEMO from Out1 of the MC Servo Board to Ch1 of the Pentek Generic board to the right of the MC Servo Board was bad. If we touched the cable, the MC would lock, but as soon as we let go, the MC would fall out of lock. The LEMO end of the cable was not heat shrink wrapped, so the 2 wires could have been touching. I replaced the cable, and the MC locked immediately after plugging it in, so I think that has fixed the problem.
||Wed Jul 16 11:26:47 2008
||Max Jones||Update|| ||This Week|
I got a battery for the magnetometer today which is slightly too large (~2 mm) in one dimension. Not sure what I'm going to do.
I'm attempting to calibrate the magnetometer but I'm having a hard time calibrating the axis that I cannot simply put through a coil parallel to the coils length. I have attempted to use the end fields of the solenoid but the measurements from the magnetometer are significantly different from the theoretical calculations.
I would appreciate suggestions. - Max.
||Mon Jul 21 09:52:05 2008
||Sharon||Update|| ||Adaptive code changes|
|Thanks to Alex, we now save the coefficients of the adaptive filter every cycle. When we choose ENABLE: OFF on the MEDM screen, suppressing the signal to the MC1, we stop and save the last coefficients. When enabling it again, it starts from the last coefficients saved. I will take some measurements today to check how this contributes to the adaptation rate. If you change the number of taps or the number of AUX channels, the coefficients are again set to zero. |
||Mon Jul 21 19:48:57 2008
||Sharon||Update|| ||how tp restart C1ASS|
|How to restart C1ASS:|
2. as root: caltech/target/c1ass:> ./startass
3. no need for root: burtgooey
||Wed Jul 23 10:47:05 2008
||Sharon||Update|| ||Weekly update|
|This week I spent some time with Alex who updated the adaptive code to save the filter's coeffs all the time, stop when I open the loop, and reload the latest coeffs. when I start it again.|
The point was to minimize the adaptation rate. Unfortunately, seems it is making some filters go wild, so it is not in use yet.
After taking some more measurements with the adaptive filter running, I have noticed a new peak in the signal around 22-23 Hz. My first assumption was that this is caused due to internal resonance of MC1 (which is driven when the adaptive code is running, and not when it's not). Therefore, I drove MC1 without the adaptive filter looking for the same peak... which wasn't there.
This sent me back to the adaptive code... Seems there is a matrix in the simulink file of the adaptive filter which doesn't have an MEDM screen. I am now working on making this screen. Once I am done with that, and make sure there is correlation between simulink and MEDM, I'll keep on chasing the peak in the code.
||Wed Jul 23 13:52:26 2008
||Sharon||Update|| ||MEDM changes|
|There is a new MEDM screen now when you go from c1ass>top>pem.|
Instead of having 12 "mini filters" screens go to 8 outputs (with the wrong correlation impression from the table), we have a 24X8 matrix.
This matrix is there so you could choose which noise signals you want to send to the adaptive code. When you indicate the number of noise channels you are going to use
on the nAUX option on the screen top, you are choosing the channels 1 to nAUX. Channels 15-22 are the seismic and accelerometers we are now using. (you can see the order in Jenne's post 673).
Hope this will make things clearer.
||Fri Jul 25 13:30:53 2008
||Sharon||Update|| ||Changes in ASS computer|
|I editted the simulink diagram of the ASS computer so it now has 2 more channels reading 2 sets of the FIR coefficients to match Alex's changes in the C code.|
The new simulink has already been compiled and can be found in /cvs/cds/caltech/users/alex/cds/advLigo/src/epics/simLink/ass.mdl
I backed up the old file and it's also in that folder under ass_BAK_24_jul.mdl
There is also a backup of the old ASS.ini file in caltech/chans/daq/C1ASS_BAK_24_jul.ini
Will update once it's all set and running
||Fri Jul 25 17:32:46 2008
||Sharon||Update|| ||ASS computer|
|So, it seems a bit too complicated getting the coefficients the way I wanted it to happen (simulink-.ini...). |
I returned everything to the way it was and it's all working. The new plan is to choose the specific channel I want to find its instantanous coefficients, let the adaptive code run for a while, setting mu and tau to zero (freezing the coefficients), and exciting the noise signal channel taking the transfer function. This way I can find the filter I want to simulate with an IIR filter.
Once I have the mode cleaner to myself, I'll start posting results.
||Mon Jul 28 12:02:32 2008
||Sharon||Update|| ||accelerometers settings|
We looked again at the channels of the accelerometers and there are some updates. Last time when we reported, we crossed the ADAP channels and the accelerometer. Now that there is a new MEDM screen, with which you can control which channels goes to which adaptive channels, this has no meaning...
Therefore, the channels that go with the noise source channels are:
PEM 15 MC1_X
PEM 16 MC1_Y
PEM 17 MC1_Z
PEM 18 MC2_X
PEM 19 MC2_Y
PEM 20 MC2_Z
PEM 21 SEIS
disregard the last post regarding these channels by Jenne, since I am changing the ADAP channels all the time...
||Mon Jul 28 17:58:05 2008
||Sharon||Update|| ||TOP screen changes|
|I wanted to test the adaptive code with a downsampling rate of 32 instead of 16. To do this I entered a 32 Hz ((2048/32)/2 - match Nyquist Freq.) low pass filter on the ERROR EMPH, MC1 and the relevant PEM channels.|
||Tue Jul 29 21:04:55 2008
||Sharon||Update|| ||OSEM's Power Spectrum|
|From 16:30 this afternoon|
||Wed Jul 30 12:36:19 2008
||Sharon||Update|| ||Weekly update|
|This week included many computer's issues. I tested Alex's new C code (the one that saves the FIR coefficients and restores them when you start running the code again). Seems there is an improvement in the adaptation time, but not a significant one (more details on the coming report). I had to recompile simulink and the FB whenever I wanted to find a solution for taking the record of those coefficients. This is so I could simulate the adaptive filter with a regular IIR filter and compare the two. |
After Rob tried to help and it seems to be an impossible to a huge hassle mission, we thought of a different method to do this. I re-compiled the old simulink file and restored the .ini file and all should be back in place. Instead of finding the FIR coefficients, I am going to use one noise source in the adaptive filter, stop the adaptation (by setting mu and tau to 0), and put excitation instead of the noise signal. The transfer function I will get between the exc. and MC1_IN1 is the filter I am looking for.
Also seems that whenever I get the MC unstable, and the adaptive code stops itself, it doesn't come back. Setting the reset flag to a different number (anything other than 0) and pressing the reset button will get it working again, but the CPU will always flip and the ASS computer needed a restart. Still haven't found a problem in the C code, but that's the plan. Moreover, I want to change Alex's code, so that instead of starting from zero like in Matt's code, or starting from the old coefficients like in Alex's, it is going to calculate a Wiener Filter as the first set of coefficients. This will hopefully reduce the adaptation time.
I have also been working on my progress report, and stood in line for the MC... Still standing...
||Fri Aug 8 11:04:34 2008
||Sharon||Update|| ||MCL Wiener filter|
|I took some old data from Rana and converted the units of the Weiner filter to m/m so to make the effect of the seismometer and accelerometers more obvious.|
The data is in counts, and so to convert to m this is what I did:
%%% MC_L calibration
v_per_counts = 5/32768;
v_per_v = 3;
amp_per_N = 1/0.064;
%%% Accelerometers calibration
v_per_counts_acc = 61.045e-6;
g_per_v = 9.8/100;
%%% Seismometer calibration
v_per_counts_seis = 61.045e-6;
m_per_s_per_s_per_volt = 9.8/100;
m_per_v_per_s = 1/345;
hfmatm(:,jj)=hfmat(:,jj).*(v_per_counts.*v_per_v.*amp_per_N.*f)./(v_per_counts_acc*g_per_v); %%% accelerometers' data
hfmatm(:,7)=hfmat(:,7).*(v_per_counts.*v_per_v.*amp_per_N)./(v_per_counts_seis*m_per_v_per_s); %%% Seismometer data
||Fri Aug 15 16:45:43 2008
||Sharon||Update|| ||Converting from FIR to IIR|
|I have been looking into different techniques to convert from FIR to IIR. This is so we can see how effective the adaptive FIR filter is in comparison to an IIR one with fewer taps.|
For now I tried 2 matlab functions: Prony and stmcb (which works on LMS method).
I used the FIR wiener code, MC1_X, (c1wino) and applied the FIR to IIR algorithm.
Seems like the stmcb one works a bit better, and that there isn't much effect for having 1000 and not 400 taps.
Will keep updating on more results I have, and hopefully have the MC in time to actually check this live.
||Tue Aug 19 10:36:34 2008
||Sharon||Update|| ||Calibrating accelerometers|
|I took apart the accelerometers near MC1 and MC2.|
The 2 sets of 3 accelerometers are now covered by a box on the floor. Please try not to move them... I will place it all back once I am done calibrating.
||Tue Aug 19 17:00:19 2008
||Sharon||Update|| ||Wiener TF calibration - update|
|This is an update for post 814|
I added the calibration gains I got for the accelerometers (I realize I am just calibrating the accelerometers to themselves and this is not m/m exactly since we don't really know which accelerometer is doing exactly what we want it to do. However, since we are talking on relative small numbers, this shouldn't really change much).
I also added another missing gain for the seismometer. Rana has previously installed a 4300 ohm resistor in the seismometer, which changed the gain to 4300/(4300+5000) = 0.46 (this is from the manual). Moreover, there is a gain of 100 on the SR560. This comes up to an extra gain of 46, meaning multiplying the seismometer's counts by 1/46.
||Tue Aug 19 17:15:34 2008
|I plugged in the gains I got for the accelerometers in the accelerometers' filters in the PEM screen of the adaptive filter|
||Wed Aug 20 17:02:01 2008
||Sharon||Update|| ||More FIR to IIR |
|I tested another method for converting from FIR to IIR other than the 2 mentioned in post 841.|
I got this one from Yoichi, called poles fitting, you can read about it more if you want at: http://www.rssd.esa.int/SP/LISAPATHFINDER/docs/Data_Analysis/DA_Six/Heinzel.pdf.
Seems it's not doing much good for us though.
I am attaching a PDF file with the plots, which have N=50,100,600,1000, respectivaly.
||Fri Aug 22 13:58:39 2008
||Sharon||Summary|| ||Trend of the Wiener TF|
|In order to understand if we really need an adaptive filter, I used old data of MC_L and the accelerometers and seismometer to see if the Wiener (ideal) TF between MC_L and the others really changes all the time. |
Two tests I made:
- Compare the TF after different segments of time, starting from the same point. Meaning, measuring the TF after 5,10,15,20... minutes, looking when and if the TF stablizes (stops changing).
- Compare the TF between same-length segments, from different times. Meaning, comparing for example 2 segments of 10 minutes taken from different times.
- As you can see in the attached PDF, the changes start being minor after 200,000 data points, which correspont to 200,000/256 s, which is approximately 13 minutes.
If you look at the PDF file, it is arranged from shorter times to longer in the order of: 3, 6, 13, 26 and 39 minutes.
- As expected, the TF between different segmants of the same length is not completely the same. Again, you can look at the attached PDF.
Sorry the titles are the same. Each 2 consecutive pages represent the same length of segment in different times. The order of segment's lengths is: 3, 13, 26 and 39 minutes
How do I explain what's going on?
Since the Wiener filter finds the correlation matrix between the data and the noise signals, it will maintain some kind of familiar shape when we don't add a significant amount of unusual data. I am assuming that if I had looked at longer time periods, we could see a more significant change in the TF in time. When looking at different times, the average noise is likely to be different which can explain the change in the correlation matrix and the TF.
To sum up
I think we should give adaptive filtering a go.
||Wed Sep 3 18:45:01 2008
||Alberto||Configuration|| ||PD3 gain|
We found that the PD3 servo was unstable with a gain of 1, so we switched it to 0.5
||Mon Mar 30 12:29:17 2009
||Yoichi||Configuration|| ||MC1 glitches not seen during the weekend|
|The attached is the MC trend for the past 12 hours.|
There is no MC1 glitches in the OSEM signals. Moreover, the total amplitude of the drift is smaller than it used to be (now the amplitude is less than 100 but it used to be a few hundreds).
There still is a small step in the OSEM signals at around 6AM this morning, but the amount of the jump is very insignificant.
The cause of the glitch in the TMP1, DRUM1 and APTEMP (LL, UL and UR coils respectively) at 7AM is not known.
Since the MC1 has been behaving OK during the weekend, I removed the probes from the MC1 coil driver board and locked the MC.
Hopefully the replacement of the broken connector fixed the problem, but I'm not sure.
||Thu May 7 17:59:23 2009
||Alberto||Configuration|| ||MC WFS|
This afternoon the MC could not get locked.
I first checked the Osems values at the MC mirrors and compared them to the trend of the last few hours. That showed that the alignment of the mirrors had slightly changed. I then brought each mirror back to its old alignment state.
That let the LSC loop lock the MC, although the reflected power was still high (1.5V) and the WFS control wouldn't engage.
Since earlier during the day I was working on the AS table, it is possible that I inadvertently hit the MC REFL beam splitter misaligning the beam to the MC WFS.
To exclude that there was a problem in the suspensions, before touching the WFS, I checked that the cables at the MC's ends and those going to the ADC in the rack were well pushed in.
Then I proceeded in centering the beam on both the WFS, balancing the power over the QPDs.
In the end the MC could lock again properly.
||Mon Jul 13 16:59:10 2009
||Zach||Update|| ||GigE Phase Camera|
Today, I moved the router from on top of the PSL into the control room in order to perform dark field tests on the GC650 (which I also moved). The GC750 along with the lens that was on it and the mount it was on has been lent to Ricardo's lab for the time being. I successfully triggered the GC650 externally and I also characterized the average electronic noise. For exposure times less than 1 microsecond, the average noise contribution appears to be a constant 15 on a 12-bit scale.
||Mon Jul 27 14:43:34 2009
I found two ThorLabs PDA55 Si photodetectors that says detect visible light from DC to 10MHz that I'm going to use from now on. I don't know how low of a frequency they will actually be good to.
||Fri Aug 14 18:33:02 2009
||Clara||Update|| ||Record of Accelerometer and Seismometer Movements|
Rather than make a new elog post every time I move something, I'm going to just keep updating this Google spreadsheet, which ought to republish every time I change it. It's already got everything I've done for the past week-ish. The spreadsheet can be accessed here, as a website, or here, as a pdf. I will still post something nightly so that you don't have to search for this post, but I wanted to be able to provide more-or-less real-time information on where things are without carpet-bombing the elog.
||Tue May 25 17:04:37 2010
||Kevin||Update|| ||Beam Profile After Mode Cleaner|
I fit the data from the beam profile that Jenne measured on 5/21/2010. The distances are measured from halfway between MC1 and MC3 to the beam scanner. The fits give the following where w0 is the waist size and z0 is the distance from the waist to halfway between MC1 and MC3.
For the horizontal profile:
reduced chi^2 = 0.88
z0 = (1 ±
w0 = (1.51 ±
For the vertical profile:
reduced chi^2 = 0.94
z0 = (
w0 = (1.59 ±
I calculated the radius of curvature of MC2 using these values of w0:
vertical: (17.66 ±
For this calculation, I used the value of (13.546 ± .0005) m for the length of the mode cleaner measured on 6/10/2009. The specification for the radius of curvature of MC2 is (18.4 ± 0.1) m.
In the following plots, the blue curve is the fit to the vertical beam radius, the purple curve is the fit to the horizontal beam radius, * denotes a data point from the vertical data, and + denotes a data point from the horizontal data.
||Tue Jun 1 18:39:59 2010
||Nancy||Update|| ||Lead spheres for the seismographs|
the lead spheres that were placed below the granite slab have been flattened by hammering to have lesser degree of wobbling of the slab.
the height of each piece, and the flatness of their surfaces was checked by placing another slab over them and checking by the spirit level.
||Wed Jul 7 12:45:00 2010
||nancy||Update|| ||Weekly Update|
Wednesday after the meeting - Started report, learnt mode cleaner locking from Kiwamu and Rana, saw how to move optics on the tables with Rana and kiwamu.
Thursday - Made the report
Tuesday - report.
Today - am trying locking the MC with kiwamu's help to see the WFS signals and also to start characterizing the QPD.
||Sun Sep 12 23:02:53 2010
||valera||Update|| ||PMC mode matching|
Kiwamu and I found that the first lens in the PMC mode matching telescope was mislabeled. It is supposed to be PLCX-25.4-77.3-C and was labeled as such but in fact it was PLCX-25.4-103.0-C. This is why the PMC mode matching was bad. We swapped the lens for the correct one and got the PMC visibility of 82%. The attached plot shows the beam scans before and after the PMC. The data were taken with the wrong lens. The ABCD model shown in the plot uses the lens that was there at the time - PLCX-25.4-103.0-C. The model for the PMC is just the waist of 0.371 mm at the nominal location. The snap shot of the ABCD file is attached. The calculation includes the KTP for FI and LiNb for EOM with 4 cm length. The distances are as measured on the table.
||Sun Sep 12 23:16:52 2010
||valera||Update|| ||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.
||Mon Sep 13 00:19:32 2010
||rana||Update|| ||VCO Driver Output power v. slider control voltage|
I measured the RF power output of the VCO Driver box as a function of slider value. I measured using the Gigatronics Handheld power meter and connected to the AOM side of the cable after the white Pasternak DC block.
* at low power levels, I believe the waveform is too crappy to get an accurate reading - that's probably why it looks non-monotonic.
* the meter has a sticker label on it saying 'max +20 dBm'. I went above +20 dBm, but I wonder if maybe the thing isn't linear up there...
||Wed Sep 15 19:29:13 2010
||valera||Summary|| ||PSL power budget|
|| Power (mW)
| NPRO - after HWP
| Rejected by input FI polarizer
| After output FI polarizer
| Into PMC
| PMC reflected
| PMC transmitted
| PMC leakage
| After PMC TRANS PD/Camera BS
| After RefCav EOM
| Into RefCav
- NPRO injection current 1.0 A
- PMC losses ~32%
- FSS AOM diffraction efficiency ~52%
||Fri Sep 17 01:36:14 2010
||valera||Update|| ||PMC line width|
The attached plots show the PMC cavity line width measurement with 1 mW and 160 mW into the PMC. The two curves on each plot are the PMC transmitted power and the ramp of the fast input of the NPRO. The two measurements are consistent within errors - a few %. The PMC line width 3.5 ms (FWHM) x 4 V / 20 ms (slope of the ramp) x 1.1 MHz / V (NPRO fast actuator calibration from Innolight spec sheet) = 0.77 MHz.
Here is the output of the calculation using Malik Rakhmanov code:
modematching = 8.4121e-01
transmission1 = 2.4341e-03
transmission2 = 2.4341e-03
transmission3 = 5.1280e-05
averageLosses = 6.1963e-04
visibility = 7.7439e-01
Here are the inputs for the calculation in the param.m:
fw = 0.77e6; % width of resonance (FWHM) in Hz
Plas = 0.164; % power into the PMC in W
% the following number refer to the in-lock cavity state
Pref = 0.037; % reflected power in W
Ptr = 0.0712; % transmitted power in W
Pleak = 0.0015; % power leaking from back of PMC in W
||Thu Nov 11 15:27:43 2010
||valera, steve||Configuration|| ||ISS AOM installed|
We installed the ISS AOM in the PSL. The AOM was placed right after the EOM. The beam diameter is ~600 um at the AOM. The AOM aperture is 3 mm.
We monitored the beam size by scanning the leakage beam through the turning mirror after the AOM. The beam diameter changed from 525 um to 515 um at a fixed point. We decided that the AOM thermal lensing is not large enough to require a new scan of the mode going into the PMC and we can proceed with PMC mode matching using the scan that was taken without the AOM (to be posted).
||Thu Feb 17 22:51:04 2011
||josephb, valera||Summary|| ||dither alignment model|
We made a model for the dither angular stabilization system c1ass.mdl. The attached file shows the diagram.
The idea is to dither a combination of 6 optics (ETMs, ITMs, PZTs) at different frequencies and demodulate three PDs (TRX, TRY, REFL11I). Then form the DOFs from demodulted signals, filter, and send each DOF to a combination of optics.
This is enough to get started with arm cavities alignment (we may need to add the BS for the Y arm). More optics and PD can be added as they become available and/or needed.
The DAC for the fast PZT are not connected and have to be commissioned.
||Tue Feb 22 00:18:47 2011
||valera||Configuration|| ||c1ioo and c1ass work and related fb crashes/restarts|
I have been editing and reloading the c1ioo model last two days. I have restarted the frame builder several times. After one of the restarts on Sunday evening the fb started having problems which initially showed up as dtt reporting synchronization error. This morning Kiwamu and I tried to restart the fb again and it stopped working all together. We called Joe and he fixed the fb problem by fixing the time stamps (Joe will add details to describe the fix when he sees this elog).
The following changes were made to c1ioo model:
- The angular dither lockins were added for each optics to do the beam spot centering on MC mirrors. The MCL signal is demodulated digitally at 3 pitch and 3 yaw frequencies. (The MCL signal was reconnected to the first input of the ADC interface board).
- The outputs of the lockins go through the sensing matrix, DOF filters, and control matrix to the MC1,2,3 SUS-MC1(2,3)_ASCPIT(YAW) filter inputs where they sum with dither signals (CLOCK output of the oscillators).
- The MCL_TEST_FILT was removed
The arm cavity dither alignment (c1ass) status:
- The demodulated signals were minimized by moving the ETMX/ITMX optic biases and simultaneously keeping the arm buildup (TRX) high by using the BS and PZT2. The minimization of the TRX demodulated signals has not been successful for some reason.
- The next step is to close the servo loops REFL11I demodulated signals -> TMs and TRX demodulated signals -> combination of BS and PZTs.
The MC dither alignment (c1ioo) status:
- The demodulated signals were obtained and sensing matrix (MCs -> lockin outputs) was measured for pitch dof.
- The inversion of the matrix is in progress.
- The additional c1ass and c1ioo medm screens and up and down scripts are being made.
||Tue Feb 22 23:11:42 2011
||valera||Update|| ||new medm screens: C1ASS.adl and C1MCASS.adl|
||Wed Feb 23 16:34:42 2011
||valera||Configuration|| ||pmc lens staged|
I put the PMC last mode matching lens (one between the steering mirrors) on a translation stage to facilitate the PMC mode matching.
Currently 4% of incident power is reflected by the PMC. But the reflected beam does not look "very professional" on the camera to Rana - meaning there is too much TEM20 (bulls eye) mode in the reflected beam.
I locked the PMC on bulls eye mode and measured the ratio of the TEM20/TEM00 in transmission to be 1.3%. Thus the PMC mode matching is ~99% and the incident beam HOM content is ~3%.
While working on the PMC I found that the source of PMC "blinking" is not the frequency control signal from MC to the laser (the MC servo was turned off) but possibly some oscillation which could be affected even by a small change of the pump current 2.10 A to 2.08 A. I showed this behaviour to Kiwamu and we decided to leave the the current at 2.08 A for now where things look stable and investigate later.
||Wed May 4 13:51:51 2011
||valera||Configuration|| ||Intermittent MC3 UL PD signal|
The attached plot shows the 30 day trend of the MC3 UL PD signal. The signal dropped to zero at some point but now it is close to the level it was a few weeks ago. There still could be a problem with the cable.
The rest of the MC1,2,3 PD signals looked ok.
||Wed May 4 15:22:39 2011
||kiwamu||Update|| ||Re: Intermittent MC3 UL PD signal|
I went push all the possible connectors for the MC3 shadow sensors including the SCSIs, flat cables and satellite box.
Also I put screws on them so that they won't become loose any more.
As a result UL_PDMON dropped from 0.6 V to 0.490 V and it becomes stable so far.
I didn't strain relief the cables but we must do it at some point before going into the full locking test.
|Quote from #4625
The attached plot shows the 30 day trend of the MC3 UL PD signal. The signal dropped to zero at some point but now it is close to the level it was a few weeks ago. There still could be a problem with the cable.
The rest of the MC1,2,3 PD signals looked ok.
||Mon Jul 11 10:10:31 2011
||Ishwita||Configuration|| ||AA board |
The AA board shown in attachment 1 will be used in the seismometer hardware setup. A cartoon of this setup is shown in attachment 2.
BNC connectors are required for the seismometer breakout boxes. So the four-pin LEMO connectors present in the AA board were removed and panel mount BNC connectors were soldered to it. Red and blue colored wires were used to connect the BNC connectors to the board. Red wire connects the center of the BNC connector to a point on the board and that connection leads to the third leg (+IN) of the IC U### and the blue wire connects the shield of the BNC connector to the second leg (-IN) of the IC U###.
All the connections (including BNC to the AA board and in the AA board to all the filters) were tested using a multimeter by the beeping method and it was found that channel 10 (marked as C10) had a wrong connection from the point where the red wire (+ve) was connected to the third leg (+IN) of IC U91 and channel 32 (marked as C32) had opposite connections meaning the blue wire is connected to the third leg (+IN) of IC U311 and red wire is connected to the second leg (-IN) of IC U311.
||Wed Jul 20 11:42:47 2011
||Ishwita, Manuel||Update|| ||Weekly summary|
- We gave a white-board presentation on derivation of formula for optimum Wiener filter coefficients and wrote a latex document for the same. relevant elog entry
- We enjoyed drilling the cover of the AA board and fixing it.
- The AA board was fixed on rack 1X7 with Jenne's help. relevant elog entry
- We tried writing a simulation for the transfer function of the stacks in Matlab. Once we get some satisfying results, we will post it on the elog.
- We started reading the book 'Digital Signal Processing - Alan V. Oppenheim / Ronald W. Schafer' and are still reading it. We also tried watching lecture videos on z-transform...
||Thu Jul 21 23:36:51 2011
||Jenny||Update|| ||Fitting beam waist with MATLAB|
I am starting work on the PSL table at the 40m. My goal is to lock the laser coming from the nearby table to the FP cavity and get a measurement of the response to a temperature step on the surrounding can.
I have to mode match the beam to the cavity. Specifically, I have to mode match to the beam coming from the PMC through the EOM to the polarizing beam splitter. Yesterday David and I measured the beam width at various distances (from a particular lens through which the beam traveled), and I fit that data using MATLAB to find the beam's waist size and location. However, I'm not convinced that the fit is any good, since we only took measurements at five spots and they had large error bars.
Here is the fit I obtained using fminsearch. The horizontal beam width measurements were smaller than the vertical width measurements, suggesting that the incoming beam was elliptical. I fit the data for each set of measurements separately and got two waist locations. The red trace is the fit for the horizontal width and the blue represents the vertical width of the beam. Averaging the two fitted waist locations and sizes gives
vert z_0= -1760 mm (waist location)
horiz z_0= -1540 mm (waist location)
vert w_0 = 0.286 mm (waist size)
horiz w_0 = 0.275 mm (waist size)
avg z_0= -1650 mm
avg w_0 = 0.281 mm
Here is the code I used:
I defined the function spotsize.m and then made a function gaussbeam.m that called it with input parameters and returned the least squares error. I then wrote another function twobeamfits.m that ran fminsearch to minimize the least squares error and made the above plot. I've pasted the code below.
function omega = spotsize(z_0, w_0, z)
function sse = gaussbeam(params,xvals,yvals)
%This f'n takes as its inputs
%three parameters (w_0, z_0, and lambda),
%a vector of x-values (distances),
%and an associated vector of y-values (spotsizes),
%It then generates a vector of fitted y-values by applying
%an exponential approach function (single pole), with the given parameters,
%to the x-values.
%It then returns the sum of the squares of the entries of the difference
%between the fitted y-vector and the actual y-vector
fityvals=spotsize(z_0, w_0, xvals);
error=(fityvals - yvals);% .*xvals;
% sse stands for sum of squares error
function [outputs] = twobeamfits(guesses, dists, vert, horiz)
%This f'n takes as its inputs
%two starting guess parameters (w_0 and z_0),
%a vector of distances (x-values),
%and two associated vectors of measured beam radii,
%the radius measured along the vertical axis
%and the radius measured along a horizontal axis (y-values).
%It then calls the gaussbeam f'n for each set of y-values and minimizes its output (sum of squares error)
%using the fminsearch f'n. It outputs the fit parameters it settles on.
%It then plots the input data, the fitted curves, and the residuals
fitvert=spotsize(vertparams(1), vertparams(2), dists);
spoterror=[.1, .1, .1, .1, .1]; %uncertainties, all in mm
fithoriz=spotsize(horizparams(1), horizparams(2), dists);
errorbar(dists, vert, spoterror, 'x')
errorbar(dists, horiz, spoterror, 'r*');
plot(points,spotsize(vertparams(1), vertparams(2), points));
plot(points,spotsize(horizparams(1), horizparams(2), points),'r');
xlabel('Distance z (mm)')
title('Gaussian Beam Fits')
ylabel('Spotsize w (mm)')
legend('Vertical Spotsize','Horizontal Spotsize','Vertical Fit',...
legend('Vertical Fit Residuals','Horizontal Fit Residuals',...
Later on I may repeat some measurements and try to gain more certainty in my fit. In the mean time I will use this beam profile for mode matching.