ID |
Date |
Author |
Type |
Category |
Subject |
571
|
Thu Jun 26 01:10:18 2008 |
rana | Update | PEM | Alarm Handler indicates that dust level is high |
In its first useful act, the Alarm Handler started beeping indicating that the dust particle
counts for particles of diameter less than 0.5 micron had exceeded 5000 /cu. ft. Here's the
80 day trend of particles, temperature and humidity: |
Attachment 1: Untitled.png
|
|
570
|
Thu Jun 26 01:08:22 2008 |
rana | Configuration | General | Alarm Handler Revived |
I have revived the Alarm Handler by turning it on on op540m and adjusting the levels of
several of the alarming channels to not alarm (like laser power). The alarm levels are now
set to something reasonable and people should start actually paying attention to them.
I also removed the EO Shutter and Stacis alarm stuff since we don't use them.
To really get in and edit it, you have to close the Alarm Handler and edit the file
in /cvs/cds/caltech/alh/. It allows you to add/subtract useful channels and put in
guidance information.
If the alarm handler beeps about something, don't just close it or silence it, Steve. Just
fix it somehow (either set the threshold better or find the real cause). |
Attachment 1: b.gif
|
|
569
|
Wed Jun 25 18:03:21 2008 |
Yoichi | Configuration | PSL | FSS Input Offset slider problem |
While working on the PMC scanning, I noticed that the FSS input offset slider is doing nothing.
I traced the signal flow and checked the cables/boards.
The slider changes the output voltage from a VMIVME4116 DAC in the PSL rack. This output voltage is confirmed to be correct at the FLKM64 connector. The signal is connected to the FSS servo interface box (D040423) trough a ribbon cable. However, the output from the interface box is always -27V regardless of the slider position.
Therefore, either the interface box (D040423) or the ribbon cable has a problem.
I will debug the interface box using an extension card when no one is working on the interferometer. |
568
|
Wed Jun 25 13:56:56 2008 |
John | Summary | Locking | Tuesday night locking |
Rob, John
Worked to try and reduce the CARM offset using the dc arm transmissions before changing to SPOB DC. This proved somewhat unsuccessful, the offset couldn't be reduced to more than five (arms storing 5x more power than single arm cavity lock). |
567
|
Wed Jun 25 13:38:22 2008 |
Koji | Update | General | Abs. Len. Meas. ~ Placement of the 700mW NPRO on the AP table |
This morning I have put the 700mW NPRO on the AP table for the abs length measurement.
The RF amplifier was moved (the cables were not changed). I cleaned up some cable arrangements. I was keen not to disturb any of the other optical path. Even so, please let me know if any suspicious behaviour is found on the AP table. |
Attachment 1: NPRO700mW_placement.jpg
|
|
566
|
Wed Jun 25 12:25:28 2008 |
Eric | Summary | Cameras | 2D Gaussian Fitting Code |
I initially wrote a script in MATLAB that takes pictures of the laser beam's profile and fits them to a two dimensional gaussian in order to determine the position and width of the beam. This code is now (mostly) ported to C so that it can be imbedded in the camera software package that Joe is writing. The fitting works fairly well for pictures with the beam directly incident on the camera, and less well for pictures of scatter off the end mirrors of the arms, since scatter from defects in the mirror have intensities much greater than the intensity of the beam's gaussian profile.
The next steps are to finish up porting the fitting code to C, and then modify it so it can better handle the images off the end mirror. Some thoughts on how to do this are to use a fourier transform and a low pass filter, or to simply use a center-of-mass calculation (with the defect peaks reduced in intensity), since position is more important than beam width in this calculation. The eventual goal is to include the edge of the optic in the picture and use the fit of the beam position in comparison to the optic's position to find the beam's location on the mirror. |
565
|
Wed Jun 25 11:36:14 2008 |
Max Jones | Update | Computer Scripts / Programs | First Week Update |
For the first week I have been modifying the noise budget script in caltech/NB to run with 40 m parameters and data. As per Rana's instructions, I have tried to run the script with only seismic and Darm sources. This involves identifying and changing channel names and altering paramter files (such as NB/ReferenceData/C1IFOparams.m). To supply the parameter files, I have copied the H1 files with (as yet only) slight modification. The channel name changes have been made to mirror the sites for the most part. Two figures are attached which show the current noise budget. The Day plot was taken 6/23/08 at ~10:30 am. The night plot was taken 6/22/08 at ~11:00 pm . Note that the SRD curve is for the sites and not for the 40 m (I hope to change that soon). Also in one of the plots the DARM noise signal is visible. Obviously this needs work. A list of current concerns is
1) I am using a seismic transfer function made by previous SURF student Ryan Kinney to operate with channels of the form C1:PEM_ACC-ETMY_Y (should I be using C1:DMF-IX_ACCY?) and the channels I am currently using are the acceleraometers for the mode cleaner with names of the form C1:PEM_ACC-MC1_X. Rana said that he thinks these may be the same but I need to be sure.
2) We don't have a DARM_CTRL channel but the code requires it, currently I am using DARM_ERR as a substitute which is probably partly responsible for the obvious error in DARM noise.
Any suggestions are appreciated. Max. |
Attachment 1: C1_NoiseBudgetPlot_Day.eps
|
|
Attachment 2: C1_NoiseBudgetPlot_Night.eps
|
|
564
|
Wed Jun 25 11:01:45 2008 |
Masha | Update | Auxiliary locking | fiber stabilization |
For the first week, I have been learning about fiber noise cancellation, auxiliary locking techniques, and other relevant helpful topics in more detail. I am now working on a setup (more detail in previous entry) to measure phase noise introduced by 25m(?) fiber, and then will proceed to try to cancel the noise. |
563
|
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. |
562
|
Wed Jun 25 01:30:19 2008 |
John | Summary | IOO | Frequency noise after the MC |
I made some (very) rough estimates of the contribution made to the noise after the mode cleaner by three sources.
Seismic noise - how much of the signal is due to the mode cleaner compenstaing for seismic disturbance of CARM.
Actuator noise - coil drivers and DAC noise.
MC_F - estimate of MC_F suppressed by the loop gain. |
Attachment 1: MC2noise080623.png
|
|
561
|
Wed Jun 25 00:35:40 2008 |
Koji | Summary | General | Optical Layout on the AP table |
I have visited the AP table in order to investigate where we are going to put the optical setup for the abs. length meas.
I have attached the PNG and PDF files to share the optical layout. It is not complete. Any comments or corrections are welcome. |
Attachment 1: optical_layout_ap_table.png
|
|
Attachment 2: optical_layout_ap_table.pdf
|
|
560
|
Tue Jun 24 22:43:23 2008 |
rana | Summary | SEI | Stack TF |
|
Attachment 1: Screenshot.png
|
|
559
|
Tue Jun 24 22:31:10 2008 |
Masha | Update | Auxiliary locking | my first step in fiber stabilization |
There is a new 1W INNOLIGHT NPRO laser at the Symmetric Port.
Set up an interferometer to measure difference in phase noise introduced by a fiber. Works as expected without the fiber! (balanced intensity, out of phase noise in the two outputs). |
558
|
Tue Jun 24 17:12:10 2008 |
josephb, Eric | Configuration | Cameras | GC750 setup, 1X4 Hub connected, ETMX images |
The GC750 camera has been setup to look at ETMX. In addition, the new 1X4 rack mounted switch (131.215.113.200) has been connected via new cat6 cable to the control room hub (131.215.113.1?), thanks to Eric. The camera is now plugged into 1X4 rack switch and now has a gigabit connection to the control room computers as well as Mafalda (131.215.113.23).
By using ssh -X mafalda or ssh -X 131.215.113.23, then typing:
target
cd Prosilica/bin-pc/x86/
./Sampleviewer
A viewer will be brought up. By clicking on the 3rd icon from the left (looks like an eye) will bring up a live view.
Closing the view, and then cd ../../40mCode, and then running ./Snap --help will tell you how to use a simple code for taking .tiff images as well as setting things such as exposure length and size of image (in pixels) to send.
When the interferometer was set to an X-arm only configuration, we took two series of 200 images each, with two different exposure lengths.
Attached are three pdf images. The first is just a black and white single image, the second is an average of 100 images, and the third is the standard deviation of the 100 images. |
Attachment 1: GC750_ETMX_E30000_single.pdf
|
|
Attachment 2: GC750_ETMX_E30000_avg.pdf
|
|
Attachment 3: GC750_ETMX_E30000_std.pdf
|
|
557
|
Tue Jun 24 15:15:09 2008 |
John | Summary | LSC | Locking efforts |
Rob, Rana, John
In the past week or so we've been working on reducing the CARM offset using a DC signal (SPOB DC).
We were able to get up to arm powers of around 30 (where a single arm cavity lock is a power of 1)
before instability set in and we would lose lock for, as yet, unknown reasons.
In recent nights locking efforts have taken a few backward steps.
Since last Thursday engaging the AO path has proved troublesome, i.e. engaging it would instantly
cause loss of lock. This seems to be related to problems with the mode cleaner servo. For the past
few nights it has been behaving strangely and could not be operated with the usual super boost stages.
Last night the situation was improved. MC boost stages could be used and the AO path engaged. The
cause of this problem and its spontaneous resolution are not understood.
Last night we were unable to switch CARM to SPOB DC. I've attached a spectrum of the MC2 length signal.
This path is being used for CARM and so gives an indication of the frequency noise after the mode
cleaner. At the moment the plot is calibrated in units of Rana's gut feeling. We already tested to see if
any of the excess noise was introduced by the WFS. No evidence was found. We'll try to make a useful
calibration soon and see if our problems are related to excess frequency noise.
Another realisation from last night was the effect of arm detuning on the analogue CARM path. When CARM is detuned
the coupled cavity pole removes an extra 90 degrees of phase. The digital path has the `moving zero' to compensate
for this. The analogue path has no such compensation and can therefore become unstable at moderate detunings.
We propose trying to reduce the CARM offset further before engaging the analogue path. This will give higher
gain and move the UGF to a region of increased phase margin. |
Attachment 1: mcl080623.png
|
|
556
|
Tue Jun 24 10:24:43 2008 |
Koji | Update | General | Abs. Len. Meas. ~ Cavity Swing Measurement (2) |
At the entry 555, Alberto reported the results of the cavity length measurement using cavity sweeping.
As expected, each result inevitably has an ambiguity depending on which resonance do we take as an upper sideband.
In order to exclude this ambiguity Steve and Koji performed a primitive non-optical measurement using a tape and photos:
This morning Steve and Koji did tape measurements to know the lengths between the ITM/ETM chambers.
Yesterday, Koji took photos of the optical tables in vacuum to know the actual positions of the suspensions.
The results are shown in the figures attached. From those non-optical measurements the lengths of the X/Y arm are known to be 38.48+-0.03 / 38.67+-/0.03 [m].
Then, we could exclude the shorter lengths of the values in the entry 555. i.e. The Y arm is longer than the X arm about 0.2 m.
These approximate lengths will be used in the further precise measurements which use precise scans of the FSR frequencies. |
Attachment 1: armlength.png
|
|
Attachment 2: armlength2.png
|
|
555
|
Mon Jun 23 21:51:19 2008 |
Alberto | Update | General | Arm Cavity Length Measurement |
We measured the arm cavity lengths sweeping the ETM mirror position and looking at the reflected demodulated output. We excited the mirror by a sine wave of 0.2 Hz and amplitude of 30000 counts. From the time series of the occurrences of the resonances of the sidebands and of the carrier we evaluated the free spectral range of the cavities and thus the lengths. The details of the procedure are explained in the attached document. As discussed in it, for each cavity we obtain two possible values of the length depending on which of the sideband resonances is that corresponding to the upper sideband and which corresponds to the lower one instead. The numbers are:
Lx=(38.30 +/- 0.08)m / (38.45 +/- 0.08)m
Ly=(38.16 +/- 0.08)m / (38.70 +/- 0.08)m
Since the difference between the two possibilities is quite large, we should be able to decide which one is correct by somehow measuring directly the cavity length. We want to try it tomorrow by a tape meter.
Alberto and Koji |
Attachment 1: 40mLengthMeasure.pdf
|
|
554
|
Mon Jun 23 19:48:28 2008 |
rana,alberto | Summary | IOO | StochMon trends (80 days) |
Here's a StochMon plot showing the RFAM after the MC. Remember that in these units, 2V means no RFAM
and 0 V means lots of RFAM. Alberto says "the calibration is in Tiramisu". So there you go. |
Attachment 1: e.png
|
|
553
|
Mon Jun 23 19:33:01 2008 |
rana, jenne | Update | IOO | MC_F Noise check |
We looked at the MC_F spectrum because Rob and Yoichi said that it had gone 'all crazy'. It
seemed fine as we looked at it (even with only one boost stage on) so we looked for things
that might be marginal and make it go nuts.
At the error point (Q mon on the demod board and TEST IN1) of the MC Servo board we saw the
old 3.7 MHz signal (comes from the 33 MHz RFAM getting demodulated by the 29.5 MHz MC LO)
and thought that this might cause some worries. So we installed Jenne's passive elliptic
low pass which has a 3.7 MHz zero.
This wiped out the 3.7 MHz noise but we were not able to re-create the extra frequency noise
so its unlikely to have fixed the main problem. However, we leave it in because its good. If
there is a need to revert it, we have left hanging on the side of the rack the old cable which
was a SMA->TNC making a direct, unfiltered connection between the MC Demod board and the MC
servo board.
More before and after results from Jenne tomorrow, but for now here is a calibrated MC_F spectrum
using the new MC_F-Reference.xml template file.
We also noticed that we could make some small effects on the MCF spec by adjusting the PMC gain so
there's probably more hay to be made there using a lead brick and a gain slider. More in Jenne's
entry. |
Attachment 1: mcf.png
|
|
552
|
Mon Jun 23 15:22:04 2008 |
rana | Bureaucracy | SAFETY | Laser Safety Walkthrough today |
|
Attachment 1: Walkthrough08.jpg
|
|
551
|
Sun Jun 22 21:38:49 2008 |
rob | HowTo | General | IFO CONFIGURE |
Now that we're getting back into locking, it's nice to have a stable alignment of the interferometer.
Thus, after you're done with your experiment using subsets of the interferometer (such as a single arm),
please use the IFO_CONFIGURE screen, and click "Restore last Auto-Alignment" in the yellow "Full IFO" section.
If you don't know what this means/how to do this, you shouldn't be using the interferometer on your own. |
550
|
Fri Jun 20 17:42:48 2008 |
steve | Update | PSL | SS trap scattering compared to black glass trap |
Circular SS304 trap was compared to wedged black glass trap.
The measurement set up of entry 529 was changed to define polarization.
CrystaLaser was remounted in horizontal position and half wave plate was placed after it.
These measurements were done in horizontal polarization.
atm1: the cSSt and wBGt was moved horizontally, ~90 degrees of the incident beam
atm2: traps were rotated around the incident beam, ~20 degrees each direction
atm3: set up
atm4: top view of traps
atm5: side view of trap |
Attachment 1: cSSt_1.png
|
|
Attachment 2: cSSt_2.png
|
|
Attachment 3: scatset_61908.png
|
|
Attachment 4: cSSt&wBGt.png
|
|
Attachment 5: cSStbeam.png
|
|
549
|
Fri Jun 20 08:30:27 2008 |
stiv | Update | Photos | 40m summer line up 2008 |
atm1: John, Alberto, Yoichi, Koji, Masha, and Sharon
atm2: surf students Max of CIT, Sharon of MIT, Masha of Harvard, Eric of CIT not shown |
Attachment 1: P1020559.png
|
|
Attachment 2: P1020560.png
|
|
548
|
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. |
Attachment 1: pmc_trans_long_trend.pdf
|
|
Attachment 2: pmc_trans_improvement.pdf
|
|
547
|
Fri Jun 20 01:38:55 2008 |
rana | Update | PEM | 20 day Weather |
Yoichi showed me that its possible to make PNG images from PS using GS:
gs -sDEVICE=png16m -sOutputFile=foo.png bar.ps |
Attachment 1: test.png
|
|
546
|
Thu Jun 19 20:22:03 2008 |
rana | Update | General | FE Computer Status |
I called Rolf (@LLO) who called Alex (@MIT) who suggested that we power cycle every crate
with an RFM connection as we did before (twice in the past year).
Rob and I followed Yoichi around the lab as he turned off and on everything. There
was no special order; he started at the Y-end and worked his way into the corner and
finishing at the X-End. Along the way we also reset the 2 RFM switches around fb0.
This cured the EPICS problem; the FEs could now boot and received the EPICS data.
However, there are still some residual channel hopping-ish issues which Rob and Yoichi are
now working on. |
545
|
Thu Jun 19 15:52:06 2008 |
Alberto | Configuration | Computers | Measure of the current absorbed by the new Megatron Computer |
Together with Rich Abbot, sam Abbot and I measured the current absorbed by the new Megatron computer that we installed yesterday in the 1Y3 rack. The computer alone absorbs 8.1A at the startup and then goes down to 5.9A at regime. The rest of the rack took 5.2A without the computer so the all rack needs 13.3 at the startup and the 11.1A.
We also measured the current for the 1Y6 rack where an other similar Sun machine has been installed as temporary frame builder and we get 6.5A.
Alberto, Rich and Sam Abbot |
544
|
Wed Jun 18 18:50:09 2008 |
rana | Update | Computers | It can only be attributable to human error. (HAL - 2001) |
There has been another one of "those" events and all of the front end machines are down.
We poked around and Rob determined that the FEs can't get the EPICS data from EPICS. The
dcuepics machine is hooked up and running and all of the epics binaries are running. We also
tried resetting its RFM switch as well as power cycling the box using the "poweroff" command.
Not a sausage.
Rob points out that although the Signal Detect lights are on on the cards, the 'Own Data' light
is not on on the dcuepics' card although it is on for some of the cards on the other boxes.
We have placed messages with the Russian. If anyone sees him, don't let him go without fixing things.
Also, make sure to follow him around with notepad and possibly a camera to record what it is that
he does. If he's muttering, maybe try to use a sensitive hidden sound recorder. |
542
|
Wed Jun 18 18:32:09 2008 |
Max Jones | Update | Computer Scripts / Programs | NB Update |
I am reconfiguring the the noisebudget code currently in use at the sights. To that end, I have done the following things (in addition to the elog I posted earlier)
In get_dtt_dataset.m - I added C1 specific cases for DARM_CTRL, SEIS, and ITMTRX changing the specific channels to make those in use at caltech
In LocalizeSite.m - I changed the NDS_PATH to match caltechs. I left NDS_HOST untouched.
Since I am trying to get SEIS and DARM to work initially I added C1 specific cases to both of these.
Better documentation may be found in /users/mjones/DailyProgressReport/06_18_08. Suggestions are appreciated. Max. |
541
|
Wed Jun 18 18:26:19 2008 |
Yoichi | Update | PSL | Finding the optimal operation temperature for the NPRO by the slow act scan |
Being suspicious of the temperature stabilization of the NPRO crystal, I ran the slow scan script written by Rana to find the suitable operation temperature.
The procedure is the same as the one explained in the entry below:
http://www.ldas-sw.ligo.caltech.edu/ilog/pub/ilog.cgi?group=40m&task=view&date_to_view=09/04/2006&anchor_to_scroll_to=2006:09:04:22:23:56-rana
The attached plots show the results. By looking at C1:PSL-126MOPA_126MON, I set the slow slider voltage to 0.
This time, it looks like the temperature control of the NPRO crystal is working fine.
Obviously, PMC picks up many higher order modes. I will try to mode match/align the PMC later. |
Attachment 1: FSS-slow-scan.pdf
|
|
540
|
Wed Jun 18 18:20:10 2008 |
Yoichi | Update | PSL | Investigation on the NPRO temperature stabilization glitches |
As Rob pointed out in http://dziban.ligo.caltech.edu:40/40m/537 the MOPA NPRO has been showing some glitchiness in the LTEC loop.
Following Rana's suggestion, Steve and I opened the MOPA and directed a heat gun for a minute to the NPRO hoping that we can see something in the LTEC loop.
The first attachment shows the behavior of LTMP and LTECH along with DTMP and DTECH at the time of the heat gun attack.
T=0 is the time when Steve directed the heat gun to the NPRO. There is no response neither in LTMP nor LTECH.
DTMP and DTECH look like responding.
Around the center, there is a dip in LTMP. This might be caused by removing the heat gun. But we are not sure. This kind of small glitches can be found in LTMP everywhere (see the attachment 2).
It looks like the LTMP sensor is not working, or the LTECH loop is actually working but the LTECH reading is broken.
However, the scan of the slow actuator (temperature) shows the LTECH loop is actually working. So it is a bit confusing.
More investigation is necessary.
See the next entry by me.
|
Attachment 1: LTEC-loop-HeatGun-Response.pdf
|
|
Attachment 2: LTMP-glitches.pdf
|
|
539
|
Wed Jun 18 16:37:54 2008 |
steve,rana | Update | SAFETY | CO2 test in the east arm |
The CO2 laser and table are in the east arm for characterization of the mechanics. We
will not be operating it until we have an SOP (which is being written). No worries. |
Attachment 1: co2.png
|
|
538
|
Wed Jun 18 16:07:57 2008 |
rob | Summary | Computers | RFM network down |
The RFM network tripped off around noon today. It's still down. The problem appears to be with the EPICS interface (c1dcuepics). Trying to restart one of the end stations yields the error: No response from EPICS.
Possible causes include (but not limited to): busted RFM card on c1dcuepics, busted PMC bus on c1dcuepics, busted fiber from c1dcuepics to the RFM switch. We need Alex. |
537
|
Wed Jun 18 00:19:29 2008 |
rob | Update | PSL | MOPA trend |
15 day trend of MOPA channels. The NPRO temperature fluctations are real, and causing the PMC to consistently run up against its rails. The cause of the temperature fluctations is unknown. This, combined with the MZ glitches and Miller kicking off DC power supplies is making locking rather tetchy tonight. Hopefully Yoichi will find the problem with the laser and fix it by tomorrow night. |
Attachment 1: MOPAtrend.png
|
|
536
|
Tue Jun 17 22:00:53 2008 |
John | HowTo | PSL | Problems turning MZ servo on/off |
We were unable to toggle the MZ servo on/off (Blank/Normal) from MEDM. Pushing on the Xycom board and cables changed the fault from constant to intermittent. At least one lock loss has been caused by a MZ glitch. |
535
|
Mon Jun 16 18:26:01 2008 |
Max Jones | Update | Computer Scripts / Programs | Noise Budget Changes |
In the directory cvs/cds/caltech/NB the following changes were made:
I created temporary files in ReferenceData for the C1 by copying and renaming the corresponding H1 files.
- C1_SRD_Disp.txt
- C1IFOparams.m
- C1_NoiseParams.m
In getmultichan.m I added a C1 case.
In NoiseBudget.m I added a C1 case with modified sources array to include only DARM and Seismic
I appreciate and suggestions. Max.
|
534
|
Fri Jun 13 11:17:25 2008 |
Yoichi | Update | PSL | PMC transmittance at high power |
We received a new cable for the Scientech calorimeter. So I measured the transmittance of the PMC at higher power.
Summary:
Input power = 2.298W
Output power = 1.364W
Transmittance = 59%
Detail:
The input power to the PMC was measured between the two mode matching lenses by the calorimeter.
2.298W looks a bit too low. Actually, the calibrated monitor PD on the MEDM screen shows about 3W output from MOPA.
So we (me and Steve) measured the power right after the PBS after the periscope from MOPA with the HWP set to maximize the transmission of the PBS.
It was 2.77W. According to Steve's previous measurement, the first mirror of the periscope transmits about 200mW of the incoming light to the monitor PD. So the actual output of the MOPA is about 2.97W, which is consistent with the monitor PD reading.
The aperture of the EOM for the PMC control is glowing a lot. We suspect this is the main cause of the loss (from 2.77W to 2.298W).
We may want to re-align the EOM.
The output light from the PMC was picked off by a glass slide. The reflectance of the glass slide was measured first at a lower power (input 98mW, reflected power 1.58mW). Assuming that the reflectance is the same for the higher power, I turned up the input power to the PMC. This time, the picked off power was 22.45mW. This means the actual output power is 98/1.58*22.45=1364mW. The glass slide was kept at the same angle through out the measurement.
The measurement of the output power was done by the Ophir power meter. So calibration difference between the Ophir and the calorimeter may introduce some error. |
533
|
Thu Jun 12 15:55:15 2008 |
rob | Update | Locking | report |
Quote: | Rob: Awesome figure. As you can imagine, I have lots of questions, and hope that you will consider this figure to be the beginning, leading to ever-more detailed versions. But for now, I just want to ask whether you understand *what* is twitchy, and what the twitchiness does to prevent you from taking this further? |
I definitely don't understand what's twitchy, but I have suspicions. Tonight we'll try to start by revisiting the other loops (the non-CARM loops) and see how they're dealing with the changing power levels. It may be that the DARM loop is going unstable due to gain variations (due to either increasing power or to rotation of demod phase) or it could be the PODD (or SPOB) saturating with increased power in the recycling cavity. I just hope the glitchiness doesn't have a digital origin. |
532
|
Thu Jun 12 15:09:33 2008 |
alan | Update | Locking | report |
Rob: Awesome figure. As you can imagine, I have lots of questions, and hope that you will consider this figure to be the beginning, leading to ever-more detailed versions. But for now, I just want to ask whether you understand *what* is twitchy, and what the twitchiness does to prevent you from taking this further? |
531
|
Thu Jun 12 01:51:23 2008 |
rob | Update | Locking | report |
rob, john
We've been working (nights) on getting the IFO locked this week. There's been fairly steady incremental progress each night, and tonight we managed to control CARM(MCL) using PO-DC, with the CARM(AO) path also on PO-DC. In the past, reaching this state has usually meant we're home free, as we could just crank the gain on the common mode servo and merrily reduce the CARM offset. Tonight, however, this state has been very twitchy, and efforts to ramp up the gain have been unsuccessful.
I've attached a diagram which I hope makes clear where we are in the stages of lock acquisition. |
Attachment 1: lock_control_sequence.png
|
|
530
|
Wed Jun 11 15:30:55 2008 |
josephb | Configuration | Cameras | GC1280 |
The trial use GC1280 has arrived. This is a higher resolution CMOS camera (similar to the GC750). Other than higher resolution, it has a piece of glass covering and protecting the sensor as opposed to a plastic piece as used in the GC750. This may explain the reduced sensitivity to 1064nm light that the camera seems to exhibit. For example, the image averages presented here required a 60,000 microsecond exposure time, compared to 1000-3000 microseconds for similar images from the GC750. This is an inexact comparison, and the actual sensitivity difference will be determined once we have identical beams on both cameras.
The attached pdfs (same image, different angles of view) are from 200 averaged images looking at 1064nm laser light scattering from a piece of paper. The important thing to note is there doesn't seem to be any definite structure, as was seen in the GC750 scatter images.
One possibility is that too much power is reaching the CMOS detector, penetrating, and then reflecting back to the back side of the detector. Lower power and higher exposure times may avoid this problem, and the glass of the GC1280 is simply cutting down on the amount passing through.
This theory will be tested either this evening or tomorrow morning, by reducing the power on the GC750 to the point at which it needs to be exposed for 60,000 microseconds to get a decent image.
The other possibility is that the GC750 was damaged at some point by too much incident power, although its unclear what kind of failure mode would generate the images we have seen recently from the GC750. |
Attachment 1: GC1280_60000E_scatter_2d.pdf
|
|
Attachment 2: GC1280_60000E_scatter_3d.pdf
|
|
529
|
Wed Jun 11 11:45:25 2008 |
steve | Update | PSL | ss trap works |
The trap works well at 3 W level. No back reflected beam coming out of the trap on low power
sensing card level. The back scattering was not measured. The trap is insensitive to small pointing variations.
The SS surface did not show any visible degradation after 16 hrs of 3w exposure at elliptical beam size 4x8 mm
It is ready to be placed into the 35 W beam. |
Attachment 1: P1020534.png
|
|
Attachment 2: P1020533.png
|
|
528
|
Tue Jun 10 08:37:18 2008 |
steve | Update | PSL | beam trap is being tested |
High power beam trap is being tested just west of FSS area on psl enclosure.
When the pmc is operating at low power that means that the rest of the 3W is going into the
circular SS trap.
Please beware of the high power beam trap test |
Attachment 1: trapss3w.png
|
|
527
|
Mon Jun 9 17:57:59 2008 |
Yoichi | Configuration | PSL | PMC input power backed to the original |
I rotated back the HWP before the PBS to restore the input laser power to the PMC.
Now the reading of PSL-PMC_PMCTRANSPD is 2.7. |
526
|
Mon Jun 9 17:32:14 2008 |
Yoichi | Configuration | PSL | PMC transmittance |
I checked the current PMC transmissivity at a low power.
The input laser power to the PMC was reduced to 75mW by rotating the HWP in front of the PBS.
In this configuration, the output power from the PMC was 50mW. So the transmittance is about 66%.
The reading of C1:PSL-PMC_PMCTRANSPD is now 0.1 whereas it was 2.7 before turning the power down.
I will check the transmittance at a higher power when I get the cable for the 35W calorie meter, which is missing now. |
525
|
Fri Jun 6 16:47:04 2008 |
josephb | Configuration | Cameras | GC650 scatter images of 1064nm light |
Took images similar to the scattered light images from earlier, except with the CCD GC650 camera. The first three attached plots are an average of all 200 images, an average of the first 100 and then an average of the last 100 images.
They show no definite structure. The big red blob which changes with time may be a brighter reflection, although it virtually the same type of setup as the GC750 images.
To do this properly, I should grab a short focal length lens and simply blow up the beam to a size greater than the detector area and simply fix both cameras looking into.
The last set of plots are mean and standard deviation plots from a previous set of runs on 5/29/08 with the GC750 and GC650 running at the same time. The GC650 was receiving approximately 33% of the total power and GC750 was receiving 66% (in otherwords a factor of 2 more). |
Attachment 1: GC650_scatter_200.pdf
|
|
Attachment 2: GC650_scatter_100a.pdf
|
|
Attachment 3: GC650_scatter_100b.pdf
|
|
524
|
Fri Jun 6 16:10:51 2008 |
steve | Update | PSL | HEPA filters are running at 100% |
The psl HEPA filters were turned up to run at 100% to accommodate beam trap work on Tuesday, June 3, 2008 |
523
|
Fri Jun 6 15:56:00 2008 |
steve | Bureaucracy | SAFETY | Yoichi received safety training |
Yoichi Aso received 40m specific safety training. |
522
|
Fri Jun 6 11:19:13 2008 |
Caryn | Summary | PEM | Filtering MC_L and MC_F with PEM:ACC and microphone |
Tried to filter MC_L and MC_F with acc/seis data and microphone data using wiener filter (levinson)
-Used get_mic_data.m and miso_filter_lev.m to make SISO filter for 2 minutes of IOO-MC_F data. Used PEM-AS_MIC signal as noise input data. Filters calculated at initial time were applied to later data in 1 hour intervals.
-microphone filter did not seem to filter MC_F very well in high frequency range using this filtering procedure.
-residual is larger than est (see MC_F pdf)
-Used do_all_time_lev.m to make graph of max(rms(residual)) to N(order) for different times.(note for each N, filter was calculated for initial time and then applied to data at other times).
-relation of max(rms(residual)) to N(order) is time sensitive (note-on graph, time interval is 1hour) (see MC_F pdf)
-Presumably, max(rms(residual)) should decrease as N increases and increase as time increases since the filter probably becomes worse with time. I think the reason this isn't always true in this case is that the max(rms(residual)) corresponds to a peak (possibly a 60Hz multiple) and the wiener filter isn't filtering out that peak very well.
-Used get_z_data.m and miso_filter_lev.m to make MISO filter for 2 minutes of IOO-MC_L used the following signals as noise input data
PEM-ACC_MC1_X
PEM-ACC_MC2_X
PEM-ACC_MC1_Y
PEM-ACC_MC2_Y
PEM-ACC_MC1_Z
PEM-ACC_MC2_Z
PEM-SEIS_MC1_Y
-Filter was applied to later data in 2hour intervals.
-Used do_all_time_lev.m to make graph of max(rms(residual)) to N(order) for different times.(note for each N, filter was calculated for initial time and then applied to data at other times).
-acc/seis filter seemed to filter MC_L OK for 128,256,512Hz srates. 64 Hz wasn't ok for certain N's after a period of time.
-residual is smaller than est for srates not 64Hz (see MC_L pdf)
-residual is larger than est for 64Hz at N=1448 for later times (see MC_L pdf)
-relation of max(rms(residual)) to N is not as time sensitive for higher sample rates (note-on graph, time interval is 2hours) (see MC_L pdf). Perhaps the levinson 64Hz sample rate filter doesn't do as well as time passes for these signals. When the filter didn't do well, the max(rms(residual)) seemed to increase with N.
-For 512Hz sample rate filter the max(rms(residual)) decreased with time. If the max(rms(residual)) were an indication of filter performance, it would mean that the 512Hz filter calculated at the initial time was performing better later as hours passed by! Perhaps max(rms(residual)) isn't always great at indicating filter performance.
Programming notes
-I had to modify values in do_all_time_lev.m to get the program to loop over the srates,N's,times I wanted
-do_all_time_lev.m is not as clean as do_all_lev.m
-for making the plots do_all_lev.m (which isn't really a procedure and is messy) has some examples of how to plot things from do_all_time_lev.m. |
Attachment 1: MC_F.pdf
|
|
Attachment 2: MC_L.pdf
|
|
Attachment 3: miso_filter_lev.m
|
function [s] = miso_filter_lev(N,srate,rat,z)
%MISO_FILTER_LEV(N,srate,z) uses miso_firlev to get levinson
% FIR Wiener filter of order N-1, using impulse response of
% N/srate. z is a structure gotten from the get_data function.
% z(end) is the signal which is filtered using z(i) for all i.
% 'rat' is the fraction of z which will be put into filter
% funtion. The data from z is downsampled using srate and
% detrended. Let rat=1. I don't have that part working yet.
... 107 more lines ...
|
Attachment 4: get_mic_data.m
|
function[z,t0,duration]=get_mic_data(t,d_t,d)
%get_mic_data gets data for'C1:IOO-MC_F', 'C1:PEM-AS_MIC,
% Example: z = get_mic_data('now',120,60)
% start time is 't- d_t' so d_t should be given in seconds. t should be given
% as a number like 893714452. d is duration in seconds. get_mic_data saves
% data to a file in current directory named 'temp_mic'. You will be asked to
% save file as 'mic_(start_time)_(duration)'.
duration = d;
... 32 more lines ...
|
Attachment 5: do_all_time_lev.m
|
function[r] = do_all_time_lev(n,t0,int,duration,N,srate,rat,order,time,MC_L,MC_F,sample_rate)
%do_all_time explores how filter performance changes with time, sample rate,
%and order of filter. Outputs data,noise estimate, structure of max
%rms error and other info. It uses get_data, miso_filter_lev, and miso_filter_int and retrives
%MC_Ldata or MC_Fdata for multiple times, calculates a miso_filter for initial-time data
%file, applies filter to the other data files, and keeps track of the...
%max(rms(residual)) for each filter. n+1 is number of data files. int is time interval between
%data files, t0 is start time, duration is duration of each data file, srate
%is the sample rate for which filter is calculated, n_N is number of orders
%of the filter you want the program to calculate,int_N is interval by which N
... 215 more lines ...
|
Attachment 6: do_all_lev.m
|
function[r] = do_all_lev(n,t0,int,duration,n_N,int_N,n_srate,int_srate,rat,MC_L,MC_F)
%do_all_lev explores how filter performance changes with time, sample rate,
%and order of filter. Outputs data,noise estimate, structure of max
%rms error and other info. It uses get_data, miso_filter_lev, and miso_filter_int and retrives
%MC_Ldata or MC_Fdata for multiple times, calculates a miso_filter for initial-time data
%file, applies filter to the other data files, and graphs the rms of the cost
%function vs time. n+1 is number of data files. int is time interval between
%data files, t0 is start time, duration is duration of each data file, srate
%is the sample rate for which filter is calculated, n_N is number of orders
%of the filter you want the program to calculate,int_N is interval by which N
... 283 more lines ...
|
Attachment 7: do_all_plot.m
|
function[r] = do_all_plot(r,x,v)
%do_all_plot plots variables contained in r(structure from
%do_all_time_lev).Plots error(r.B.y) vs x. x can be
%'s'(srate),'N'(order),'t'(time),'p'(impulse response). v can be 's','N','t'.
%example: do_all_plot(r,'s','t') makes a plot of error vs srate for
%different times.
kk=1
err_N_srate=0
... 388 more lines ...
|
Attachment 8: miso_filter_int.m
|
function [s] = miso_filter_int(s,y)
%miso_filter_int inputs a filter and a structure array of data sets y, applies filter to data, and
%outputs a structure with fields: ppos(signal frequ spectrum),perr(cost
%function frequ spectrum),pest(signal estimate frequency
%spectrum),f(frequency),target(signal),est_darm(noise estimate),t(time).
%data file for which filter has been calculated is s (obtained using miso_filter).
%y consists of data structures which will be filtered using
%filter from s. Then the power spectrum of the difference between signal and filtered-data is
%graphed for all the data files of y for comparison too see how well filter performs
%over time. Note if you want to create a y, take z1,z2,z3,etc. structures
... 120 more lines ...
|
521
|
Thu Jun 5 13:35:23 2008 |
josephb | Configuration | Cameras | GC750 looking at 1064nm scattered light |
I've taken 200 images of the GC750 (CMOS) camera while holding it by hand up to a beam card (also held by hand) in the path of ~5mW of beam power. I then averaged the images to produce the fourth attached plot.
Rob has pointed out the image looks a lot like PCB traces. So perhaps we're seeing the electronics behind the CMOS sensor?
I repeated the same experiment with HeNe laser light (again scattered off a card). These show none of the detailed structure (just what looks to be a large reflection from the card moving around depending on how steady my hand was). These are the first 3 attached plots. So only 1064nm light so far sees these features.
As a possible solution, I did a quick and dirty calibration by dividing a previous PSL output beam by the 1064 average scatter light values. These produce the last attached pdf (with multiple images). The original uncalibrated image is on top, while the very simply calibrated image is on the bottom of each plot.
It seems as the effect may be power dependent (which could still be calibrated properly, but would take a bit more effort than simply dividing), as determined by looking at the edges of the calibrated plot. |
Attachment 1: GC750_HeNe_scatter_avg.pdf
|
|
Attachment 2: GC750_HeNe_scatter_avg2.pdf
|
|
Attachment 3: GC750_HeNe_scatter_avg3.pdf
|
|
Attachment 4: GC750_scatter_avg.pdf
|
|
Attachment 5: GC750_nitrogen_white.pdf
|
|