40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 69 of 344 Not logged in
ID Date Author Type Category Subject
5298   Wed Aug 24 16:13:36 2011 kiwamuUpdateSUSbroke UL magnet on ITMX

I broke the UL magnet on ITMX

The ITMX tower was shipped into the Bob's clean room to put the magnet back on.

Since we found that all the magnets were relatively high (#5296) in the shadow sensors, we decided to slide the OSEM holder bar upward.

During the work, I haven't made the OSEMs far enough from the magnets.

So the magnets and OSEMs touched as I moved the holder.

Then the UL magnets were broken off and fell into the UL coil.

5978   Tue Nov 22 15:18:18 2011 kiwamuUpdateGreen Lockingbroad band noise depends on the gain of Y green PDH. and comaprator broken

 Quote from #5970 Here is a plot of the latest noise : high frequency noise is still unknown.

(The broad-band noise vs. gain of the Y end green PDH)

Last night I was trying to identify the broad band noise which is white and dominant above 20 Hz (#5970).

I found that the level of the noise depended on the servo gain of the Y end green PDH loop.

Decreasing the servo gain lowers the noise level by a factor of 2 or so. This was quite repeatable.

(I changed the gain knob of the PDH box from the minimum to a point where the servo starts oscillating)

(Malfunction in the comparator)

However I had to give up further investigations because the comparator signal suddenly became funny: sometimes it outputs signals and sometimes not.

It seems the comparator circuit became broken for some reason. I will fix it.

2420   Tue Dec 15 21:39:34 2009 AlbertoUpdateABSLbrief summary of this afternoon's measurements
I took measurements of the open loop gain of the AbsL PLL with the old Universal PDH Box.
I Also measured the filter shape of both the new and the old PDH box.
I'm going to plot the results in a nice form tomorrow morning.
For who's interested, the PLL UGF was at 10KHz.

I can't lock the PLL with the new PDH box. Measuring its filter's shape, as suggested by Koji, I found out that it differs from the old one. That despite the fact that the two boxes should share the same circuit schematic. O,r at least, that is what it looks like from the schematics in the DCC.
I need to understand whether that is intentional and, if that was the case, what kind of use  Rich Abbott designed it for.

Tomorrow I'm going to post in the elog the filter's transfer functions too.

Before leaving the lab I closed the auxiliary laser's mechanical shutter.
3832   Mon Nov 1 10:17:55 2010 steveUpdateGeneralbreakers relabelled

Pedro of the electrical shop helped to retrace wires from the racks to the breakers. Many wrong labels were replaced. These labels are  still representing                          the south arm as Y and  the east arm as X.

Racks: 1X1,2,3,4 and 1Y3,4,5,6,7 and 9 are connected through manual disconnect swithes to  AC power breaker PC-1 on the west wall of IFO room 104.

This panel PC-1 is connected to T1 isolation transformer in room 101 Panel L - # 38, 40, 42

Racks: 1Y1 & 2  psl and mc are connected through manual disconnect switches to AC power breaker PC-2 just west of the psl enclosure.

This panel is connected to T2 isolation transformer in room 101 Panel L - # 32, 34, 36

Attachment 1: P1060970.JPG
Attachment 2: P1060972.JPG
Attachment 3: P1060975.JPG
456   Sun Apr 27 18:11:58 2008 robDAQComputersbr40m?

The testpoint manager (which runs on fb40m) crashed this afternoon. Upon re-starting it, I found there was a rogue dtt process on op440m and also a daqd daemon running on br40m. One or both of these caused the tpman to crash. br40m is the frame broadcaster, which is never used here as we don't run DMT. I killed the daqd process there.

The way to find if there is a rogue process is to watch the output to the console from the tpman when you start it:

Allocate new TP handle 56 by 131.215.113.203
Allocate new TP handle 57 by 131.215.113.203
Allocate new TP handle 58 by 131.215.113.203
Allocate new TP handle 59 by 131.215.113.203
Allocate new TP handle 60 by 131.215.113.203
Allocate new TP handle 61 by 131.215.113.203
Allocate new TP handle 62 by 131.215.113.203
Allocate new TP handle 63 by 131.215.113.203
Allocate new TP handle 64 by 131.215.113.203
Allocate new TP handle 65 by 131.215.113.203
Allocate new TP handle 66 by 131.215.113.203
Allocate new TP handle 67 by 131.215.113.203
Allocate new TP handle 68 by 131.215.113.203

If you see something like this, with a new TP handle being allocated every few seconds, you need to log in to the corresponding host and kill whatever process has run away.
457   Sun Apr 27 22:57:15 2008 ajwDAQComputersbr40m?

 Quote: The testpoint manager (which runs on fb40m) crashed this afternoon. Upon re-starting it, I found there was a rogue dtt process on op440m and also a daqd daemon running on br40m. One or both of these caused the tpman to crash. br40m is the frame broadcaster, which is never used here as we don't run DMT. I killed the daqd process there. The way to find if there is a rogue process is to watch the output to the console from the tpman when you start it: Allocate new TP handle 56 by 131.215.113.203 Allocate new TP handle 57 by 131.215.113.203 Allocate new TP handle 58 by 131.215.113.203 Allocate new TP handle 59 by 131.215.113.203 Allocate new TP handle 60 by 131.215.113.203 Allocate new TP handle 61 by 131.215.113.203 Allocate new TP handle 62 by 131.215.113.203 Allocate new TP handle 63 by 131.215.113.203 Allocate new TP handle 64 by 131.215.113.203 Allocate new TP handle 65 by 131.215.113.203 Allocate new TP handle 66 by 131.215.113.203 Allocate new TP handle 67 by 131.215.113.203 Allocate new TP handle 68 by 131.215.113.203 If you see something like this, with a new TP handle being allocated every few seconds, you need to log in to the corresponding host and kill whatever process has run away.

I *think* Alex is responsible for the daqd daemon running on br40m (he set up some new stuff recently, a data concentrator and broadcaster); I'll make sure he sees this post.
12448   Fri Aug 26 17:48:14 2016 gautamUpdateSUSbounce mode coupling reduction

We worked on reducing the bounce mode coupling into the sensor signals today. After some trial and error, essentially following the procedure I had put up in my previous elog, we think we were successful in reducing the coupling. We have now left the optic free swinging, so that we can collect some data and look at a spectrum with finer bandwidth. But as per the methodology we followed, we saw that the peak height corresponding to the bounce mode increased when we rotated the OSEM either side of its current position (except for the side OSEM, which we felt was in a good enough position to warrant not touching it and messing it up - of course only the spectrum will tell us if we are right or not. I also took some pictures with the camera with the IR filter removed, but we couldn't get any real information from these photos. I also checked with Jenne and Jamie who both suggested that they didn't have any metric with which they judged if the rotation of the OSEM was good enough or not. So we will wait to have a look at the spectrum from later tonight, and if it looks reasonable enough, I vote we move on. As Eric suggested, perhaps we can repalce the UL OSEM coil and see if that solves the apparent UL coil problem. Then we should move on to putting the arm cavity together.

Addendum 11pm 26 Aug 2016: I've uploaded the spectra - looks like our tweaking has gained us a factor of ~2 on LL, LR and SD, and no significant improvement on UL and UR compared to yesterdays spectrum.

Attachment 1: ETMY_BounceSpectra_26Aug2016_1.pdf
8162   Mon Feb 25 21:25:14 2013 yutaUpdateAlignmentboth arms locked in IR

[Jenne, Evan, Yuta]

After Y alignment, X arm is aligned to IR and we got both arms locked in IR.
There's some dift (input pointing?) and this made aligning both arms tough. I will elog about it later.
Attached is ETMYF. ETMXF, ITMYF, ITMXF when both arms are locked by IR.

Alignment Procedure:
1. Algined BS/ITMX to get MI fringe in AS. We got X arm flashing at this point.
2. Use BS/ITMX/ETMX to get TRX maximized, without losing good MI fringe in AS. We reached 0.75.
3. There was clipping of TRX beam at Xend optics. Since whole IFO alignment is started from Y green, this clipping is because of poor Y green pointing. But we needed clear TRX for aligning Xarm, so we re-arranged Xend TRX path to avoid clipping.

X arm issues:
- Beam motion at TRX is larger than TRY. Turning off clean table air didn't help. Maybe we need BS oplev on or ETMX coil gain balancing.
- X green scatters into TRX PD and ETMXT camera. Fix them.

6840   Wed Jun 20 18:09:23 2012 yutaUpdateLockingboth arms aligned, ITMX oplev centered

[Jenne, Yuta]

We aligned FPMI. I also centered ITMX oplev because the light was not hitting on QPD.
Alignment procedure we took was;

1. Align Y arm to the Y end green(Y green trans to PSL is now 195 uW with Y end laser measured temperature 34.14 degC).
2. Aligned IR using PZT2 to Yarm(Now, TRY ~ 0.90).
3. Aligned ITMX monitoring AS spots.
4. Aligned X arm so that TRX maximize.
5. Fine adjusted both BS and X arm(Now, TRX ~ 0.82).

Beam spot position on ETMX looks a little too high & left (from ETMXF camera), but we will leave it until ASS scripts is fixed.

12389   Tue Aug 9 19:35:49 2016 ranaUpdateSEIboth Guralp seismometers are functioning and being acquired

After some cable swapping, we now have both Guralp seismometers running and the times series and spectra look similar to each other and motley healthy.

Bean and I took a look at the whole situation today. Ben had nicely fixed the Dsub end of the EX cable (the EY one is still just a sad joke), After installing this newly fixed cable, we still saw no signals. There was some confusion in the control room about using the MED displays to diagnose seismometers: flickering MEDM values cannot be used for this. It would be like checking a pizza box temperature to determine if the pizza is any good.

1. Although the +/- 12V LEDs on the front panel are dim, we confirmed that the produce 11.94V even when loaded with a seismometer. So its a LED circuit problem not a power problem.
2. We were able to inject signals into the front panel with a breakout board and see them in DV for Input 1, but not Input 2.
3. After Ben left, I kept poking around and found that the Guralp chassis output gets broken out into 3x3 BNC cables before going to the PEM BNC panel (and then on to the PEM ADC). This is where the problem was.
4. The Input #3 BNC cables were connected to the long cables going to the 'GUR2' channels of the PEM. The Input#2 BNC cables were connected to some short BNC cables that were just hanging from the rack. So, somewhere during the debugging of the past N months, someone plugged this in wrong and didn't notice or forgot to switch it back. So all of the tests using DV or DTT or MEDM since that time have been invalid.

Tomorrow, Lydia is going to change all of the labels and channel names. The new names will be EX & EY to prevent this kind of huge waste of time with channel name swapping. That means no more illegal names with the label maker, Steve.

From the spectrum you can see that the EX seismometer (GUR2) is still not centered or at least its oscillating at 245 Hz for some reason. This should go away after some power cycling or recentering using the magic wand.

I noticed some anomalies in the mechanical setups at the ends:

1. Some junk has been stored on top of the EX seismometer. Please never, even temporarily, store your power supplies, tools, or donuts on top of the vibration sensitive sensors. Just put it on the floor and improve your carma.
2. The EY seismometer has some fishy wires being fished between the can and the rubber seal. This is verboten. That seal must be flush to prevent pressure fluctuations and wires in there will ruin the smooth contact permanently. Temperature sensor wires must go through the grantie block feed-through or else its pointless.
3. The flimsy insulation on the EY seismo is waay toooo mickey mouse. Real thermal insulation should be done using the yellow foam that Jenne used for the seismo huddle test. This flimsy silvery stuff is OK for making hats and mittens and beer cozy's, but its not research grade foam.
Attachment 1: 1goodday.png
1184   Sun Dec 7 16:12:53 2008 ranaUpdateDAQbooted awg
because it was red
7545   Mon Oct 15 08:12:45 2012 SteveUpdateVACblank vac monitor

VME crate  blew its fuse and the fuse housing is hard to access.

Attachment 1: blankvac.png
11972   Wed Feb 3 08:39:17 2016 SteveUpdateCDSblank daily summary pages

Daily summary pages are blank today. Yesterday is ok

4597   Mon May 2 13:43:05 2011 steveFrogsPhotosbirthday boys

.....Happy.... Birthday.... to.... Joseph... and... Jamie...Happy....Birthday..... to.... You............sing with us........Happy Birthday.....to you

Attachment 1: P1070622.JPG
6748   Sun Jun 3 23:50:00 2012 DenUpdateCDSbiquad=1

From now all models calculate iir filters using biquad form. I've added biquad=1 to cdsParameters to all models except c1cal, built, installed and restarted them.

7041   Thu Jul 26 17:39:49 2012 DenUpdatedigital noisebiquad key is working

I've filtered a 1 Hz sin wave excitation with a notch filter inside c1sus and c1rfm models. The biquad key is switched on in the last one, c1sus uses DF2. The results are indeed different.

Still I do not like huge (2n+1) harmonics in the output of the biquad filter, I do not get them in the simulations. They are absent in the time series as well. So this is not a psd-estimation effect.

7045   Fri Jul 27 14:30:49 2012 JamieUpdatedigital noisebiquad key is working

What is "DQF"?  Is that the biquad?  And what is the difference between DF1 and DF2?  Why don't you just write out the name, so it's more clear.

7050   Mon Jul 30 14:24:25 2012 DenUpdatedigital noisebiquad key is working

 Quote: What is "DQF"?  Is that the biquad?  And what is the difference between DF1 and DF2?  Why don't you just write out the name, so it's more clear.

DF1 - direct form 1
DF2 - direct form 2
LNF - low-noise form

The difference between them is described in Matt's slides G0900928-v1. I think, LNF coefficients are incorrect in the presentation

6616   Mon May 7 21:05:38 2012 DenUpdateCDSbiquad filter form

I wanted to switch the implementation of IIR_FILTER from DIRECT FORM II to BIQUAD form in C1IOO and C1SUS models. I modified RCG file /opt/rtcds/rtscore/release/src/fe/controller.c by adding #define CORE_BIQUAD line:

#ifdef OVERSAMPLE #define CORE_BIQUAD       #if defined(CORE_BIQUAD)

C1IOO model compiled, installed and is running now. C1SUS model compiled, but during installation I've got an error:

controls@c1sus ~ 0\$ rtcds install c1sus

Installing system=c1sus site=caltech ifo=C1,c1
Installing /opt/rtcds/caltech/c1/chans/C1SUS.txt
Installing /opt/rtcds/caltech/c1/target/c1sus/c1susepics
Installing /opt/rtcds/caltech/c1/target/c1sus
Installing start and stop scripts
/opt/rtcds/caltech/c1/scripts/killc1sus
Performing install-daq
Updating testpoint.par config file
/opt/rtcds/caltech/c1/target/gds/param/testpoint.par
/opt/rtcds/rtscore/branches/branch-2.5/src/epics/util/updateTestpointPar.pl -par_file=/opt/rtcds/caltech/c1/target/gds/param/archive/testpoint_120507_205359.par -gds_node=21 -site_letter=C -system=c1sus -host=c1sus
Installing GDS node 21 configuration file
/opt/rtcds/caltech/c1/target/gds/param/tpchn_c1sus.par
Installing auto-generated DAQ configuration file
/opt/rtcds/caltech/c1/chans/daq/C1SUS.ini
Installing EDCU ini file
/opt/rtcds/caltech/c1/chans/daq/C1EDCU_SUS.ini
Installing Epics MEDM screens
Running post-build script

ERROR: Could not find file: test.py
Searched path: :/opt/rtcds/userapps/release/cds/c1/scripts:/opt/rtcds/userapps/release/cds/common/scripts:/opt/rtcds/userapps/release/isc/c1/scripts:/opt/rtcds/userapps/release/isc/common/scripts:/opt/rtcds/userapps/release/sus/c1/scripts:/opt/rtcds/userapps/release/sus/common/scripts:/opt/rtcds/userapps/release/psl/c1/scripts:/opt/rtcds/userapps/release/psl/common/scripts
Exiting
make: *** [install-c1sus] Error 1

Jamie, what is this test.py?

6622   Tue May 8 09:47:53 2012 JamieUpdateCDSbiquad filter form

 Quote: I wanted to switch the implementation of IIR_FILTER from DIRECT FORM II to BIQUAD form in C1IOO and C1SUS models. I modified RCG file /opt/rtcds/rtscore/release/src/fe/controller.c by adding #define CORE_BIQUAD line: #ifdef OVERSAMPLE #define CORE_BIQUAD       #if defined(CORE_BIQUAD)

I am really not ok with anyone modifying controller.c.  If we're going to be messing around with that we need to change procedure significantly.  This is the code that runs all the models, and we don't currently have any way to track changes in the code.

Did you change it back?  If not, do so immediately and stop messing with it.  Please consult with us first before embarking on these kinds of severe changes to our code.  This is the kind of shit that other people have done that has bit us in the ass in the past.

Futhermore, there is already a way to enable biquad filters in the new version with out modifying the RCG source.  All you need to do is set biquad=1 in the cdsParameters block for you model.

### DO NOT MESS WITH CONTROLLER.C!

6624   Tue May 8 10:43:42 2012 DenUpdateCDSbiquad filter form

Quote:

 Quote: I wanted to switch the implementation of IIR_FILTER from DIRECT FORM II to BIQUAD form in C1IOO and C1SUS models. I modified RCG file /opt/rtcds/rtscore/release/src/fe/controller.c by adding #define CORE_BIQUAD line: #ifdef OVERSAMPLE #define CORE_BIQUAD       #if defined(CORE_BIQUAD)

I am really not ok with anyone modifying controller.c.  If we're going to be messing around with that we need to change procedure significantly.  This is the code that runs all the models, and we don't currently have any way to track changes in the code.

Did you change it back?  If not, do so immediately and stop messing with it.  Please consult with us first before embarking on these kinds of severe changes to our code.  This is the kind of shit that other people have done that has bit us in the ass in the past.

Futhermore, there is already a way to enable biquad filters in the new version with out modifying the RCG source.  All you need to do is set biquad=1 in the cdsParameters block for you model.

### DO NOT MESS WITH CONTROLLER.C!

ok

3490   Mon Aug 30 22:45:49 2010 kiwamuUpdateCDSbinary outputs for the new CDS

{ Joe and Kiwamu }

Today we made some efforts to get the binary outputs (BOs) working.

They still are not working but the situation is getting better.

So far the BO cards were not recognized by any realtime codes when we ran the codes on the new front end machine C1SUS.

We put some printk commands in an initialization code like Yoichi did (see this entry) to confirm if the initialization of the BOs properly happens or not.

Then we found that we had to put the BO modules also in an IOP model file which controls all the ADCs and the DACs.

We put the BO modules in the IOP file and then BOs started being recognized by the IOP, however they still are not fully recognized by the realtime control process.

We continue this work...

[Some notes]

[front end code]

First of all we looked at the front end c-code c1sus.c living under /cvs/cds/calech/cds/advLigoRTS/src/fe/c1sus/.

It was okay because there was a proper BO statement like

CDS_CARDS cards_used[] = { {CON_32DO,0}, {CON_32DO,2}};

[initialization code]

There is an initialization code called map.c living under /cvs/cds/calech/cds/advLigoRTS/src/fe.

This code is complied when we do the make commands as described on the wiki.

Eventually the initialization code is executed only when the IOP starts up. This happens when we type startc1x02 at /cvs/cds/rtcs/caltech/c1/script/.

[printk statments]

We made a backup file named map_20100830.c.back for map.c. Then we added to map.c some pintk statements in a while loop which looks for available BOs.

After running the make commands for the IOP file and startc1x02, we basically can check the results of those printk statements by using dmesg.

We found that map.c was running correctly because  map.c went in the while loop 4 times which is exactly the same number as the BOs we put in the model file.

However the code failed to install the BOs each time.

[BO modules in IOP file]

Joe pointed out the failure in map.c was caused by lack of the BO modules in the IOP file c1x02.mdl.

Indeed putting the BO modules in the IOP fixed the problem.

Another thing we found at this time is that there is a maximum number of BOs we can put in a model file.

The maximum number is 4, which is not enough for us because we need to put 5 of them including a 16bit BIO and four 32bit BOs.

Anyway now the IOP can recognize the BO cards, this fact can be found if you look at the log file /cvs/cds/rtcds/caltech/c1/target/c1x02/logs/log.txt.

The log file saids "3 Contec 32ch PCIe DO cards found", which is a good sign.

[BO modules in realtime code]

Although the IOP started seeing the BO cards, the realtime code c1sus still didn't fully recognize the BO cards.

If we look at the log file log.txt at /cvs/cds/rtcds/caltech/c1/target/c1sus/logs/, there is an evidence that the code found some cards.

The log file saids

   Model 6 = 10

   Model 7 = 4

   Model 8 = 4

   Model 9 = 4

   Model 10 = 0.

It looks like these corresponds to the BO cards.

So the code found some cards, but doesn't know what they are.

We need few more debugging for the BOs...

513   Tue Jun 3 10:19:45 2008 tobinConfigurationComputersbig machine
Several of us transported the big new awesome Sun box from Bridge over to
the 40m last week. If I recall correctly, it's a SunFire X4600 with
something like sixteen 64-bit AMD processor cores at 2.8 GHz. It sounds
like a jet engine when it starts up (before the cooling fans are throttled
back) and has four power supplies (each with its own connection
to the wall). It has slick removable hard disks and fan units too. Our
working name for it is "megatron".

Anyway. It came with two hard disks, one with Solaris 10 installed. I took
the other hard disk over to Alex, who copied a Realtime Linux installation
onto it. Alex says it boots and runs fine.

It remains for you guys to install the machine onto rails and install the
whole thing into a rack. Before it goes into service as a realtime control
machine, you might as well install Matlab on it and do some heavy-duty
computation.

7923   Tue Jan 22 09:10:19 2013 SteveUpdatePEMbig foot is dirty

Please wipe, clean car wheels and wear booties entering the 40m lab.

Obviously this person has no idea about our clean room rules.

Attachment 1: IMG_1873.JPG
Attachment 2: IMG_1874.JPG
13731   Thu Apr 5 13:46:42 2018 gautamUpdateSUSbig earthquake

Seems like there was a 5.3 magnitude EQ ~10km from us (though I didn't feel it). All watchdogs were tripped so our mirrors definitely felt it. ITMX is stuck (but all the other optics are damping fine). I tried the usual jiggling of DC bias voltage but ITMX still seems stuck. Probably a good sign that the magnet hasn't come off, but not ideal that I can't shake it free..

edit: after a bit more vigorous shaking, ITMX was freed. I had to move the bias slider by +/-10,000 cts, whereas initially I was trying +/-2000 cts. There is a tendency for the optic to get stuck again once it has been freed (while the optic's free swinging motion damps out), so I had to keep an eye out and as soon as the optic was freed, I re-engaged the damping servos to damp out the optic motion quickly.

Attachment 1: EQ_April52018.png
894   Thu Aug 28 19:02:25 2008 rana, josephb, robSummaryComputersbig boot
This afternoon Joe did something with an .ini file (look for his detailed elog entry) and the computers went bad.
RFM network screen not active - filter modules not working.

We went around and booted every machine as has been done before. The correct order for a memory corruption
fixing big boot is the following:

[1] RESET the RFM switches near the FB racks.
[2] Power cycle c1dcuepics.
[3] Power cycle all other crates with real time CPUs:
c1iscey, daqctrl, daqawg, c1susvme1, c1susvme2, c1sosvme, c1iovme, c1lsc, c1asc, & c1iscex
[4] Start up all FEs as described in Wiki.
[5] Burt restore everyone (losepics, iscepics, assepics, omcepics?)
15680   Tue Nov 17 13:24:40 2020 ChubUpdateGeneralbig UPS on the way

Ordered 11/16 from CDW, on PO# S492940, the high voltage Tripp Lite SMART5000XFMRXL  for TP-1.  Should be arriving in about a week.

11040   Mon Feb 16 21:52:51 2015 ranaHowToTreasurebig Dataviewer windows

Following this entry, I have made the same change in the controls account on rossa:

In the ~/.grace/gracerc file (create one if it doesn't exist), put in a line which reads:

PAGE LAYOUT FREE

Now we can scale our dataviewer live and playback plots by stretching the window with our mouse. The attached screenshot shows how I filled up one of the vertical monitors with a DV window for arm locking.

Attachment 1: bigDV.png
2670   Fri Mar 12 17:08:22 2010 steveConfigurationVACbg-RGAscan at d18

RGA scan of rga-region only at day 18   This is the back ground of the rga with some calibration gas.

Attachment 1: bg-d18_20100312scan.png
7952   Tue Jan 29 10:59:37 2013 lazy personFrogsGeneralbetter plan

I propose we work around this problem with giant flip-flops.  These are in the vein of the take-off-your-shoes-and-put-on-Crocs, without the taking off your shoes part.  They're a little annoying on the sticky mats, but otherwise great.  They are also super easy to put on and take off without hands, so there's no excuse for wearing them around the control room.

I propose we buy many pairs of the smalls in green (since we already have one green small...they are big on me, so should be just right for most people), and a few mediums in, say, blue, and a few larges in black, and then maybe a few extra larges in green for people with extraordinarily large feet (they only have 3 colors).  Then we can keep a few pairs of each by each door to the lab, and have no more tracking dirty control room filth into the lab.

7342   Tue Sep 4 20:25:22 2012 jamieOmnistructureVACbetter in-air "lite" access connector needed

We really need something better to replace the access connector when we're at air.  This tin foil tunnel crap is dumb.  We can't do any locking in the evening after we've put on the light doors.  We need something that we can put in place of the access connector that allows us access to the OMC and IOO tables, while still allowing IMC locking, and can be left in place at night.

7343   Wed Sep 5 09:50:25 2012 SteveOmnistructureVACbetter in-air "lite" access connector needed

 Quote: We really need something better to replace the access connector when we're at air.  This tin foil tunnel crap is dumb.  We can't do any locking in the evening after we've put on the light doors.  We need something that we can put in place of the access connector that allows us access to the OMC and IOO tables, while still allowing IMC locking, and can be left in place at night.

It is in the shop. It will be ready for the next vent. Koji's dream comes through.

Attachment 1: IMG_1612.JPG
7344   Wed Sep 5 10:50:15 2012 jamieOmnistructureVACbetter in-air "lite" access connector needed

Quote:

 Quote: We really need something better to replace the access connector when we're at air.  This tin foil tunnel crap is dumb.  We can't do any locking in the evening after we've put on the light doors.  We need something that we can put in place of the access connector that allows us access to the OMC and IOO tables, while still allowing IMC locking, and can be left in place at night.

It is in the shop. It will be ready for the next vent. Koji's dream comes through.

Can we see the full design?  If we can't lock the mode cleaner with this thing on then it's really of no use.  We want it to be equivalent to the light doors, but allow us to keep the mode cleaner locked.  That's the most important aspect.

7345   Wed Sep 5 13:11:43 2012 jamieOmnistructureVACbetter in-air "lite" access connector needed

Quote:

Quote:

 Quote: We really need something better to replace the access connector when we're at air.  This tin foil tunnel crap is dumb.  We can't do any locking in the evening after we've put on the light doors.  We need something that we can put in place of the access connector that allows us access to the OMC and IOO tables, while still allowing IMC locking, and can be left in place at night.

It is in the shop. It will be ready for the next vent. Koji's dream comes through.

Can we see the full design?  If we can't lock the mode cleaner with this thing on then it's really of no use.  We want it to be equivalent to the light doors, but allow us to keep the mode cleaner locked.  That's the most important aspect.

It also needs to be wide enough that the MMT beam can go through, so that we can not only lock the MC, but also work on the rest of the IFO.

734   Thu Jul 24 11:49:07 2008 MashaSummaryAuxiliary lockingbelated weekly summary
I designed a high pass filter to whiten the spectrum from the Mach Zehnder to optimize the
input into the ADC. The swept sine response measurement and the effect of the filter on the
spectrum are attached. If I start using the digital system (it is currently down in Bridge),
I will decide if the filter needs to be improved/better matched to the ADC there.

I moved from the 40m to Rana's lab in bridge. I am making a new and improved Mach Zehnder
setup with a 50m fiber in one arm; currently the transmission through the fiber is 44%. I
am working out how to mode match the laser to the fiber to improve this number.
Attachment 1: filter_tr_function.pdf
Attachment 2: filtered_spectr0724.pdf
6794   Mon Jun 11 21:50:08 2012 yutaUpdateGreen Lockingbeatbox looks OK

Summary:
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.

Note:
- 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.

Attachment 1: CIMG1522.JPG
6302   Tue Feb 21 22:06:18 2012 jamieUpdateLSCbeatbox DFD installed in 1X2 rack

I have installed a proto version of the ALS beatbox delay-line frequency discriminator (DFD, formally known as MFD), in the 1X2 rack in the empty space above the RF generation box.

That empty space above the RF generation box had been intentionally left empty to provide needed ventilation airflow for the RF box, since it tends to get pretty hot.  I left 1U of space between the RF box and the beatbox, and so far the situation seems ok, ie. the RF box is not cooking the beatbox.  This is only a temporary arrangement, though, and we should be able to clean up the rack considerably once the beatbox is fully working.

For power I connected the beatbox to the two unused +/- 18 V Sorensen supplies in the OMC power rack next to the SP table.  I disconnected the OMC cable that was connected to those supplies originally.  Again, this is probably just temporary.

Right now the beatbox isn't fully functioning, but it should be enough to use for lock acquisition studies.  The beatbox is intended to have two multi-channel DFDs, one for each arm, each with coarse and fine outputs.  What's installed only has one DFD, but with both coarse and fine outputs.  It is also intended to have differential DAQ outputs for the mixer IF outputs, which are not installed in this version.

The intended design was also supposed to use a comparator in the initial amplification stages before the delay outputs.  The comparator was removed, though, since it was too slow and was limiting the bandwidth in the coarse channel.  I'll post an updated schematic tomorrow.

I made some initial noise measurements:  with a 21 MHz input, which corrseponds to a zero crossing for a minimal delay, the I output is at ~200 nVrms/\sqrt{Hz} at 5 Hz, falling down to ~30 nVrms about 100 Hz, after which it's mostly flat.  I'll make calibrated plots for all channels tomorrow.

The actual needed delay lines are installed/hooked up either.  Either Kiwamu will hook something up tonight, or I'll do it tomorrow.

4268   Thu Feb 10 05:06:35 2011 kiwamuUpdateGreen Lockingbeat noise : a little bit better, and 1Hz peak from amplitude noise coupling

I repeated the same measurement as that Koji did before (see here) with the mixer-based frequency discriminator.

The frequency fluctuation of the beat note is now 50 kHz in rms integrated down to 0.1 Hz, which is a bit better than before.

However there still is the same undesired structure in the spectrum below 10 Hz.

Fig.1 power spectra of the green beat note fluctuation in terms of frequency fluctuation.

Red curves were taken when the IR was locked to the MC, and the green was locked to the X arm.

Blue curves were taken when both the IR and the green were locked to the X arm.

Black curve was also the one taken when the IR and the green were locked to the X arm, but showing the lower noise level.

I have no idea what exactly was going on when I took the black curve, but this noise level sometimes showed up.

The discrepancy may come from a kind of calibration error although I kept using the same calibration factor to convert the data from count to frequency.

Need more investigations.

Additionally Koji and I took the coherence between the beat fluctuation and the transmitted lights of both the IR and the green.

It showed a strong coherence at 1 Hz, which is one of the dominant noise of the beat note.

This probably indicates that the 1 Hz peak is produced by a coupling from amplitude fluctuation.

For monitoring the green transmitted light, I used the Jenne's PD (see here)

4211   Thu Jan 27 11:04:27 2011 KojiUpdateGreen Lockingbeat freq scan

Experiment in the night of Jan 26.

o The arm was locked for the IR beam and was aligned for it.
o The green was aligned to the arm
o The beat freq was observed with the RF analyzer and the webcam.
o Engaged the ALS servo
o Compared the fluctuation of the beat freq with and without ALS
o Scanned the beat freq in order to find an IR resonance

The beat freq was scanned. A resonance for IR was found.
However, the residual motion of the arm was not within the line width of the IR resonance.

To Do
- Improve the ALS servo (==>Koji)
- VCO noise characterization (==>Suresh is on it)
- Calibrate the PLL feedback (i.e. ALS error) into Hz/rtHz (==>Suresh)
- Calibrate the end green PZT fb into Hz/rtHz (==>Osamu is on it)
- Tuning of the suspension filters to reduce the bounce mode coupling.

DETAILS

o How to lock the arm with IR

• Coarsely align the arm without lock. Transmittion was ~300 with MCTRANS ~40000
• REFL11I is the error signal. unWhiten filter (FM1) should be on.
• Unlock the MC and null the error and the arm trans offset by running the following commands

ezcaservo -g -0.1 -r C1:LSC-REFL11_I_OUTPUT C1:LSC-REFL11_I_OFFSET ezcaservo -g -0.1 -r C1:LSC-REFL11_Q_OUTPUT C1:LSC-REFL11_Q_OFFSET ezcaservo -g 0.1 -r C1:LSC-TRX_OUTPUT C1:LSC-TRX_OFFSET

• Confirm the input matrix to pass REFL11I to MC path (why don't we use XARM path...?)

ezcawrite C1:LSC-MTRX_81 1.0

• Servo configuration
• For acquisition: Gain of 2. Only FM1 (1000:10) has to be on.
• After the acquisition (TRX>200): The gain is to be changed to 1. FM2 and FM3 can be turned on for the LF boost.
• Actuator matrix: connect MC path to ETMX and MC2

ezcawrite C1:LSC-OM_MTRX_18 1.0 ezcawrite C1:LSC-OM_MTRX_78 1.0

o How to align the green beam

• After the alignment I went the end and aligned the last two steering mirrors.

o The beat freq monitor

• Put the RF analyzer at the RF splitter of the RFPD output.
• Used Zonet webcam (http://192.168.113.201:3037) for the remote monitoring

o How to engage the ALS servo

• Preparation:
• VCO PLL feedback comes to X_FINE path.
• Put an offset of -850 to cancel too big offset (when the VCO is unlocked)
• Use Y_FINE channel for the offset addtion. FM1 is 10mHz LPF in order to make the offset smooth.
• Add X_FINE and Y_FINE by the matrix.
• Control
• Turn off X_FINE out. Leave Y_FINE output turned on.
• Turn on ETMX ALS path.
• Servo setting: FM1 1000:30 ON, others OFF, gain1
• Wait for the beat comes in to the locking range at around 80MHz.
• If the peak is too far, sweep Y_FINE offset in order to . Or change GCV slow thermal offset to let the beat freq jump.
• You may have ambiguity of the feedback sign depending on which green has higher freq.
• After the capture of the ALS lock, increse the gain up to 20. Turn on 0.1:boost at FM3.

o Comparison of the stability of the beat freq (Attachment3)

• The spectra of the VCO PLL feedback was measured.
• First of all, the signal was measured without ALS (blue).
The PLL lost lock quite frequently, so the careful adjustment of the offset was necessary.Still I think there was slight saturation upconversion.
• Then, the ALS was turned on (red). The gain was 20. This is an in-loop evaluation of the servo. The suppression was ~1000 at 1Hz.

o Beat freq scanning

• The following command was used for the beat note scanning

ezcastep -- "C1:GCV-YARM_FINE_OFFSET" "5,500"

• Once the IR transmission was found, the scan was stopped.
• Because the resultant rms stability of the arm was not within the line width of the cavity, the smooth resonant curve was not obtained.
• From the shape of the error signal the peak-to-peak displacement (f>1Hz) was estimated to be +/-0.7nm. The dominant displacement
in the period is 16Hz component.

Attachment 1: arm_scan.pdf
Attachment 2: arm_cav_scan3.png
Attachment 3: 110126_ALS_inloop.pdf
5872   Fri Nov 11 12:32:45 2011 KatrinUpdateGreen Lockingbeat PSL - YARM laser

[Suresh, Katrin]

Measured frequency fluctuation of the beat between PSL and YARM lasers.

Yesterday, it was very tricky to adjust the voltage offset to the slow YARM laser input to achieve the appropriate beat frequency. Today, it was much easier. During measurement beat around 25 MHz. Calibration factor 40 mV per 10 MHz.

8087   Fri Feb 15 09:58:49 2013 SteveUpdateGeneralbeam traps ready to be installed

Black-green glass traps are ready for light in vacuum. I can assemble more if needed. These three sizes are available.

Attachment 1: IMG_0083.JPG
Attachment 2: IMG_0084.JPG
8089   Fri Feb 15 16:09:19 2013 KojiUpdateGeneralbeam traps ready to be installed

For the hexagonal one, insert one of the glass plate only half. Use a 1"x.5" piece if exists.

For the diamond one, you don't need the forth glass piece.

Attachment 1: HexBeamDump.pdf
Attachment 2: DiamondBeamDump2in.pdf
5047   Wed Jul 27 15:38:01 2011 steveUpdateVACbeam traps for vacuum

We have cleaned, baked, rga scaned traps for vacuum. Thorlabs LB1 on 1" OD ss posts and forks. The effective surface area is 43 x 18 mm of stacked razors.

Seven pieces are mounted on New Focus #9962  1" OD SS vented-  pedestrals to 5.5" center height and 5 pieces to 4.875"

Attachment 1: P1080095.JPG
6648   Thu May 17 15:31:22 2012 steveUpdateGeneralbeam trap posts & clamps for vacuum

Aluminum posts and SS clamps for green glass traps in vacuum will be out of the shops by June 6, 2012 the latest

Attachment 1: 05161201.PDF
Attachment 2: 05151201.PDF
528   Tue Jun 10 08:37:18 2008 steveUpdatePSLbeam 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
4110   Wed Jan 5 03:06:02 2011 kiwamuUpdateIOObeam spots on MC mirrors

I checked the spot positions on MC1 and MC3 by running Yuta's A2L script.

The amounts of the off-centering were good except for YAW of MC1.

So we have to adjust the YAW alignment of the beam axis by steering the mirrors at the PSL table.

- - - (measured off-centering) - - -

MC1_PIT  =  -0.711 mm

MC1_YAW =  1.62 mm

MC3_PIT  =   -0.0797 mm

MC3_YAW  =  - 0.223 mm

 Quote: We will check the spot positions more accurately by A2L technique.

7527   Thu Oct 11 11:20:05 2012 janoschUpdateGeneralbeam shape simulation, PRC

I started to create a Finesse model of the PRC cavity. We have the phase maps for the PRC and the two ITMs. I could not find anything for PR2,3 and BS. All files can be found in my SVN folder /janosch/PRC40m. I used the AutoCAD model to determine angles of incidence and distances. These numbers are largely inconsistent with numbers that you can find elsewhere on the 40m wiki, but this certainly depends on what accuracy is required for interferometer alignment and I don't understand anything about alignment.

The phase maps come in a format that needs to be modified before they can be used in Finesse. I have started with this work, but maybe someone else can take over. The phase maps show tilts and the PRC also has the curvature. These have to be subtracted out before the maps can be loaded into Finesse. I asked GariLynn for the code that they use. The Finesse model (MichPRC_40m.kat) does not load the phasemaps yet, and I just wrote some random parameter values for the TEM00 input beam to the PRC. So these Gauss parameters need to be corrected.

I will only go on with this work if Rana tells me that I should do so, otherwise it is on hold until we have a volunteer.

3570   Mon Sep 13 22:51:07 2010 tara,valeraConfigurationPSLbeam scan for RCAV

On Friday, Valera and I calculated the modematching for reference cavity from AOM.

We scan the beam profile where the spot should be.

The first beam waist in the AOM is 103 um, the lens (f= 183 mm, I'm not sure if I have the focal length right) is 280 mm away.

The data is attached. The first column is marking on the rail in inches,

the second column is distance from the lens, the third and fourth column are

vertical and horizontal spot radius in micron. Note that the beam is very elliptic because of the AOM.

Attachment 1: 2010_09_10_w.mat
4874   Fri Jun 24 00:13:24 2011 kiwamuUpdateABSLbeam profile measurement of LWE

The beam profile of the LWE (LightWave Electronics) NPRO was measured.

Mode matching telescopes will be designed and setup soon based on the result of the measurements.

Here is a plot of the measured beam profile.

(some notes)

The measurement was done by using Kevin's power attenuation technique (#3030).

An window was put just after the NPRO and the reflected beam was sampled for the measurement to avoid the beam scan saturated.

4039   Thu Dec 9 23:17:47 2010 kiwamuUpdateSUSbeam pointing has been done

[Koji, Osamu and Kiwamu]

We aligned the beam axis pointing down to both X and Y arm.

Now the beams are hitting the centers of both ETMX and ETMY.

Amazingly Osamu made X arm flashing by aligning the cavity.

(what we did)

- opened almost all the chambers except for the MC2 chamber.

- locked and aligned the MC.

We set Marconi to the right frequency, which had been set to the default values, probably due to the power outage in the last weekend.

Also we found a DAC cable disconnected from the IO chassis of c1sus. So we connected it in order to damp the MC suspensions.

- aligned MMT2 and PZT2 in order to let the beam go through the center of PRM.

- checked the beam centering at the two TTs (PR2, PR3).

- rotated PR3 to make the beam go through the centers of both ITMY and BS at the same time.

- tried finding the beam spot at the ETMY chamber, and successfully found it.

To see such faint beam spot, we used an IR viewer.

In addition to that, we put a large piece of aluminum foil as a screen in the chamber.

- aligned the beam to the center of ETMY by tweaking the PZT mirror (SM2).

- aligned the BS so that the reflected beam at the BS goes through the center of ITMX.

- tried finding the beam spot at the X end, and successfully found it hitting the wall in the chamber.

- aligned the BS in order to let the beam hit the center of ETMX.

- tried aligning ETMX and ITMX to the beam.

Eventually we made the X arm flashing.

However the flash was a bit too weak to completely align the cavity.

(plan for tomorrow)

- reinstall some steering mirrors into the BS chamber

- check and neutralize PZT1

- alignment of IP_ANG

ELOG V3.1.3-