40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 335 of 337  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  1611   Wed May 20 01:53:48 2009 rob, peteUpdateLockingviolin mode filters in drstep_bang

Recently the watch script was having difficulty grabbing a lock for more than a few seconds.  Rob discovered that the violin notch filters which were activated in the script were causing the instability.  We're not sure why yet.  The script seems significantly more stable with that step commented out.

  3875   Sat Nov 6 01:54:15 2010 FrankSummaryComputersvirus definition file update on laptop for dinocam

i took some pictures with the dinocam this afternoon. I used the laptop computer next to it using wireless lan connection to the caltech network to send the pictures to me.

The installed anti virus software was bitching about the old database and wanted to update that. As the installed virus definition database was from mid last year i agreed and started downloading the update. As the file was huge (~100MB) it wasn't finished when i left. computer is still running and probably waiting for instructions.

Will come back on the weekend to finalize the new virus definition file database installation.

  4447   Mon Mar 28 16:19:23 2011 steveFrogsPhotosvisithing 5th graders

Suresh is captivating his audience with gravity waves on last Friday, March 25

Attachment 1: P1070475.JPG
P1070475.JPG
  3682   Fri Oct 8 17:36:16 2010 steveFrogsPhotosvisiting undergrads

Prof Alan Weistein guided the 24 student through the 40m. His performance was rated as  an enthusiastic 9.5

Attachment 1: P1060916.JPG
P1060916.JPG
Attachment 2: P1060921.JPG
P1060921.JPG
Attachment 3: P1060922.JPG
P1060922.JPG
Attachment 4: P1060915.JPG
P1060915.JPG
  5434   Fri Sep 16 16:07:28 2011 steveUpdateSAFETYvisitors safety training

Paul, Mirko and Katrin visiting grad students received the 40m basic safety training.

Attachment 1: P1080241.JPG
P1080241.JPG
  12810   Tue Feb 7 19:14:59 2017 JohannesUpdateCDSvme crate backplane adapter board layout

After fighting with Altium for what seems like an eternity I have finished putting my vision of the vme crate backplane adapter board into an electronic format. It is dimensioned to fill the back space of the crate exactly. The connectors are panel mount and the PCB attaches to the connectors with screws, such that the whole thing will be mechanically much more stable than the current configuration. A mounting bracket will attach to horizontal struts that need to be installed in the crates, mechanical drawings to follow.

Attachment 1: vme_backplane.pdf
vme_backplane.pdf
  12781   Tue Jan 31 22:15:02 2017 JohannesUpdateCDSvme crate backplane adapter boards

I made a crude sketch for how Lydia and I envision the connector situation on the back of the vme crates to be solved. Essentially the side panels of each crate extend about 2" (52 mm) beyond the edge of the DIN connectors. This is plenty of space for a simple PCB board. The connector of choice is D-Sub. We can split the 64 used pins into 2x 37 D-Sub OR (2x25 pin + 1x15pin). The former has fewer cables, but a few excess unused leads. A quick google search showed me that it is much cheaper to get twisted pair cables for 15 and 25 pin D-Subs. From what I remember, the used pins on the DIN connectors are concentrated on the low numbers end and the high numbers end, so might not need the 'middle' connector in many cases if we decide to break it up into three. I have to check this with Lydia though.

The D-Sub connectors would be panel mounted, for which we need a narrow panel piece with dsub cutouts. We can run horizontal struts across the vme crate from side panel to side panel. This way the force upon cable (dis)connection is mostly on the panel which is attached to the struts which are attached to the crate. This will also prevent gravitational sag or cable strain from pulling on the DIN connection, and we can use twisted pair cables with backshell, screws, and strain reliefs.

I was lookng into getting started with the PCB when Altium complained that the license is expired and to renew it. This is a relatively simple board layout so some free software out there is probably enough.

Attachment 1: vme_backplane_conn_sketch.jpg
vme_backplane_conn_sketch.jpg
  6305   Wed Feb 22 16:55:16 2012 JamieUpdateSUSwacky state of SUS input matrices

While Kiwamu and I were trying to investigate the the vertex glitches we were noticing excess noise in ITMX, which Kiwamu blamed on some sort of bad diagonalization.  Sure enough, the ITMX input matrix is in the default state [0], not a properly diagonalized state.  Looking through the rest of the suspensions, I found PRM also in the default state, not diagonalized.

We should do another round of suspension diagonalization.

Kiwamu (or whoever is here last tonight): please run the free-swing/kick script (/opt/rtcds/caltech/c1/scripts/SUS/freeswing) before you leave, and I'll check the matrices and update the suspensions tomorrow morning.

[0]

0.25 0.25 0.25 0.25 0
1.66 1.66 -1.66 1.66 0
1.66 -1.66 -1.66 1.66 0
0 0 0 0 1

  6307   Thu Feb 23 02:20:07 2012 ZachUpdateSUSwacky state of SUS input matrices

This reminds me that the whole Dr. SUS situation never got taken care of. Where I left off, I was having issues pulling 40m data with NDS2 (which is what all the diagonalization scripts use).

What is the deal with 40m+NDS2? If it is till no-go, can we have a consensus on whether this is too important to wait for? If so, I will rewrite the scripts to use NDS and we can upgrade to NDS2 once we can prove we know how to use it.

 

Quote:

While Kiwamu and I were trying to investigate the the vertex glitches we were noticing excess noise in ITMX, which Kiwamu blamed on some sort of bad diagonalization.  Sure enough, the ITMX input matrix is in the default state [0], not a properly diagonalized state.  Looking through the rest of the suspensions, I found PRM also in the default state, not diagonalized.

We should do another round of suspension diagonalization.

Kiwamu (or whoever is here last tonight): please run the free-swing/kick script (/opt/rtcds/caltech/c1/scripts/SUS/freeswing) before you leave, and I'll check the matrices and update the suspensions tomorrow morning.

[0]

0.25 0.25 0.25 0.25 0
1.66 1.66 -1.66 1.66 0
1.66 -1.66 -1.66 1.66 0
0 0 0 0 1

 

  2823   Wed Apr 21 10:09:23 2010 kiwamuUpdateGreen Lockingwaist positon of Gaussian beam in PPKTP crystals

Theoretically the waist position of a Gaussian beam (1064) in our PPKTP crystal differs by ~6.7 mm from that of the incident Gaussian beam.

So far I have neglected such position change of the beam waist in optical layouts because it is tiny compared with the entire optical path.

But from the point of view of practical experiments, it is better to think about it.

In fact the result suggests the rough positioning of our PPKTP crystals;

we should put our PPKTP crystal so that the center of the crystal is 6.7 mm far from the waist of a Gaussian beam in free space.


(How to)

The calculation is very very simple.

The waist position of a Gaussian beam propagating in a dielectric material should change by a factor of n, where n is the refractive index of the material.

In our case, PPKTP has  n=1.8, so that the waist position from the surface of the crystal becomes longer by n.

Now remember the fact that the maximum conversion efficiency can be achieved if the waist locates at exact center of a crystal.

Therefore the waist position in the crystal should be satisfied this relation; z*n=15 mm, where z is the waist position of the incident beam from the surface and 15 mm is half length of our crystal.

Then we can find z must be ~8.3 mm, which is 6.7 mm shorter than the position in crystal.

The attached figure shows the relation clearly. Note that the waist radius doesn't change.

Attachment 1: focal_positin_edit.png
focal_positin_edit.png
  2850   Tue Apr 27 14:18:53 2010 kiwamuUpdateGreen Lockingwaist positon of Gaussian beam in PPKTP crystals

The mode profile of Gaussian beams in our PPKTP crystals was calculated.

I confirmed that the Rayleigh range of the incoming beam (1064 nm) and that of the outgoing beam (532 nm) is the same.

And it turned out that the waist postion for the incoming beam and the outgoing beam should be different by 13.4 mm toward the direction of propagation.

These facts will help us making optical layouts precisely for our green locking.


(detail)

The result is shown in the attached figure, which is essentially the same as the previous one (see the entry).

The horizontal axis is the length of the propagation direction, the vertical axis is the waist size of Gaussian beams.

Here I put x=0 as the entering surface of the crystal, and x=30 mm as the other surface.

The red and green solid curve represent the incoming beam and the outgoing beam respectively. They are supposed to  propagate in free space.

And the dashed curve represents the beams inside the crystal.

A trick in this calculation is that: we can assume that  the waist size of 532 nm is equal to that of 1064 nm divided by sqrt(2) . 

If you want to know about this treatment in detail,  you can find some descriptions in this paper;

"Third-harmonic generation by use of focused Gaussian beams in an optical super lattice" J.Opt.Soc.Am.B 20,360 (2003)"

Attachment 1: mode_in_PPKTP.png
mode_in_PPKTP.png
  3325   Thu Jul 29 21:13:39 2010 DmassUpdateGreen Lockingwaist positon of Gaussian beam in PPKTP crystals

Quote:

The mode profile of Gaussian beams in our PPKTP crystals was calculated.

I confirmed that the Rayleigh range of the incoming beam (1064 nm) and that of the outgoing beam (532 nm) is the same.

And it turned out that the waist postion for the incoming beam and the outgoing beam should be different by 13.4 mm toward the direction of propagation.

These facts will help us making optical layouts precisely for our green locking.


(detail)

The result is shown in the attached figure, which is essentially the same as the previous one (see the entry).

The horizontal axis is the length of the propagation direction, the vertical axis is the waist size of Gaussian beams.

Here I put x=0 as the entering surface of the crystal, and x=30 mm as the other surface.

The red and green solid curve represent the incoming beam and the outgoing beam respectively. They are supposed to  propagate in free space.

And the dashed curve represents the beams inside the crystal.

A trick in this calculation is that: we can assume that  the waist size of 532 nm is equal to that of 1064 nm divided by sqrt(2) . 

If you want to know about this treatment in detail,  you can find some descriptions in this paper;

"Third-harmonic generation by use of focused Gaussian beams in an optical super lattice" J.Opt.Soc.Am.B 20,360 (2003)"

If I understand your elog, you are just calculating the the offset in position space that you get by having a refractive index.

Did you end up changing the mode matching so that the rayleigh range (which changes with refractive index) was confocally focused inside the crystal (e.g. Zr = 15 mm?

 

  3327   Thu Jul 29 22:58:25 2010 kiwamuUpdateGreen Lockingwaist positon of Gaussian beam in PPKTP crystals

- As you said, I just calculated the waist position in the crystal because the speed of light changes in a medium and eventually the waist position also changes.

- Yes, I did. Once you get a beam with the right waist size, you just put your crystal at the waist position with the offset.

  In fact you don't have to think about the rayleigh range inside of the crystal because what we care is the waist size and it doesn't change.

Quote:

 If I understand your elog, you are just calculating the the offset in position space that you get by having a refractive index.

Did you end up changing the mode matching so that the rayleigh range (which changes with refractive index) was confocally focused inside the crystal (e.g. Zr = 15 mm?

  3328   Fri Jul 30 00:02:15 2010 DmassUpdateGreen Lockingwaist positon of Gaussian beam in PPKTP crystals

Quote:

- As you said, I just calculated the waist position in the crystal because the speed of light changes in a medium and eventually the waist position also changes.

- Yes, I did. Once you get a beam with the right waist size, you just put your crystal at the waist position with the offset.

  In fact you don't have to think about the rayleigh range inside of the crystal because what we care is the waist size and it doesn't change.

Quote:

 If I understand your elog, you are just calculating the the offset in position space that you get by having a refractive index.

Did you end up changing the mode matching so that the rayleigh range (which changes with refractive index) was confocally focused inside the crystal (e.g. Zr = 15 mm?

 I thought we cared about satisfying the confocal focusing parameter, that is to say we want to set Zr = 2L_crystal. If Zr changes inside the crystal, this is the number we care about..isn't it NOT the waist size, but the rayleigh range we care about? I am not entirely sure what youre response is saying you did...

  1. Calculate Zr = pi * wo^2/(lamba/n)
  2. Do mode matching to get this wo in free space
  3. Calculate the offset you need to move the oven by using n
  4. Move hte ovens

OR

  1. Calculate Zr = pi*wo^2/(lamba)
  2. Do mode matching to get this in free space
  3. Calculate the offset you need to move your ovens using n
  4. Move your ovens

I guess the waist size would also let me know - are you using 69 um or 53 um waist size?

  15566   Wed Sep 9 20:52:45 2020 ranaSummaryIOOwandering line in IMC

since the summary pages are working again, I was clicking through and noticed that there's a wandering peak in the whitened IMC spectrogram that goes from 10-30 Hz over the course of a day.

https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20200909/ioo/

anyone know what this is ?

  11487   Mon Aug 10 15:25:05 2015 SteveUpdatePEMwasp nest

The wasp nest will be removed tomorrow from from the out side of the east arm window.

The resonant frequency of the newly arrived gravity bee detector is not known.
 

Attachment 1: waspN.jpg
waspN.jpg
  2309   Fri Nov 20 16:18:56 2009 robConfigurationSUSwatchdog rampdown

I've changed the watchdog rampdown script so it brings the SUS watchdogs to 220, instead of the 150 it previously targeted.  This is to make tripping less likely with the jackhammering going on next door.  I've also turned off all the oplev damping.

  2372   Wed Dec 9 17:51:03 2009 kiwamuUpdateSUSwatchdogs

Please do not touch the watchdogs for all SUSs except for MCs,

because I am going to measure the free swinging spectra for ITMs, ETMs, BS, PRM, SRM tonight.

Today, it is good chance to summarize those data under atmospheric pressure.

thank you.

 

  6060   Thu Dec 1 17:33:18 2011 kiwamuUpdateSUSwatchdogs fixed

The watchdogs' issue has been solved and they are now working fine.

It was just because one of the Sorensens had been off.

The Sorensen is the one supplying +5 V in the 1X5 rack.
This +5 V is actually used as a pull-up-current to properly drive the MAX333As (CMOS analog switch) in the coil drivers (D010001).
So this was it.

Quote from #6010

Tonight we noticed that, in fact, the watchdogs don't work for any of the corner optics (I confirmed that they do work for the ETMs).

  3456   Mon Aug 23 15:24:24 2010 kiwamuConfigurationSUSwatchdogs off

For the new CDS test, I turned off the watchdogs for PRM, SRM, BS, ITMs and MCs.

I will restore these watchdogs after several hours from now.

 

  4024   Tue Dec 7 20:38:17 2010 kiwamuUpdateSUSwatchdogs off at ITMX and ETMX

I am leaving ITMX and ETMX freely swinging, so that later I can take the spectra and diagonalize the input matrices.

Please don't restore the watchdogs until tomorrow morning.

  4031   Wed Dec 8 22:47:09 2010 kiwamuUpdateSUSwatchdogs off at ITMX and ETMX

Tonight, swing again.

Please do not restore the watchdogs until tomorrow (Dec.9) morning.

Quote: #4024

I am leaving ITMX and ETMX freely swinging, so that later I can take the spectra and diagonalize the input matrices.

Please don't restore the watchdogs until tomorrow morning.

 

  11767   Mon Nov 16 16:18:34 2015 gautamUpdateGeneralwater leak along Y-arm?

A Caltech maintenance staff dropped by at around noon today, and told me that he had seen a small puddle of water on the other side of the door along the Y-arm that is kept locked (about 10m from the end-table, on the south side of the arm). He suspected a leak in the lab. Koji and I went down to the said door and observed that there was indeed a small puddle of water accumulated there. There isn't any obvious source of a leak on our side of the door, although the walls tiles in the area suggest that there could be a leak in one of the pipes running through the wall/under the floor. In any case, the leak doesn't seem too dramatic, and we have decided to consult Steve as to what is to be done about this once he is back on Wednesday.

  11771   Tue Nov 17 10:06:53 2015 SteveUpdateGeneralwater leak in east arm
Quote:

A Caltech maintenance staff dropped by at around noon today, and told me that he had seen a small puddle of water on the other side of the door along the Y-arm that is kept locked (about 10m from the end-table, on the south side of the arm). He suspected a leak in the lab. Koji and I went down to the said door and observed that there was indeed a small puddle of water accumulated there. There isn't any obvious source of a leak on our side of the door, although the walls tiles in the area suggest that there could be a leak in one of the pipes running through the wall/under the floor. In any case, the leak doesn't seem too dramatic, and we have decided to consult Steve as to what is to be done about this once he is back on Wednesday.

The leak was found inside the wall. Fortunately the plumbers were able to access it from CES room 108

This has been leaking for sometimes. The damaged wall area is about 18 ft long and 1 ft high.

Attachment 1: eastArmLeakyPipeInsideWall.jpg
eastArmLeakyPipeInsideWall.jpg
Attachment 2: wd18ft.jpg
wd18ft.jpg
  1991   Fri Sep 18 14:25:00 2009 robOmnistructurePSLwater under the laser chiller

rob, koji, steve

We noticed some water (about a cup) on the floor under the NESLAB chiller today.  We put the chiller up on blocks and took off the side panel for a cursory inspection, but found no obvious leaks.  We'll keep an eye on it.

  1992   Fri Sep 18 16:05:08 2009 JenneOmnistructurePSLwater under the laser chiller

Quote:

rob, koji, steve

We noticed some water (about a cup) on the floor under the NESLAB chiller today.  We put the chiller up on blocks and took off the side panel for a cursory inspection, but found no obvious leaks.  We'll keep an eye on it.

 The culprit has been found:  One of the bottles of chiller water had a tiny leak in it, and apparently the floor is sloped just right to make it look like the water had been coming from under the chiller.  All is well again in the world of chilled water.

  2297   Thu Nov 19 09:25:19 2009 steveUpdateMOPAwater was added to the laser chiller

I added ~500 cc of distilled water to the laser chiller yesterday.

Attachment 1: htempwtr.png
htempwtr.png
  8099   Mon Feb 18 18:28:01 2013 yutaBureaucracyAlignmentwe are going to pump down

We will start preparing for pumping down. Main goal for this is to demonstrate PRFPMI using ALS.
Here are to-dos before we pump down.

Feb 18 eveing
- check input beam and Y arm alignment again
- IPPOS/IPANG alignment
- check all oplevs

Feb 19 morning
- open ETMX chamber heavy door
- align BS to X end
- adjust OSEM values (added by YM)
- center beam on all AS optics
- make sure AS/REFL is clear
- take picture of flipped PR2 (added by YM)
- make sure green is not clipped by new PRM oplev mirrors  (added by YM)
- center all oplevs

Feb 19 afternoon - Feb 20 morning
- close PSL shutter
- close all heavy doors and put the access connector back
- start pumping down

Feb 20 evening
- start aligning IFO

  13475   Thu Dec 14 08:59:17 2017 SteveUpdateGeneralwe are here
Attachment 1: 8_days.png
8_days.png
  1627   Wed May 27 10:54:09 2009 robUpdatePSLwe don't understand the chiller (broken)

Quote:

Quote:

steve, rob, alberto

 

Steve installed two rotary flow meters into the MOPA chiller system--one at the chiller flow output and one in the NPRO cooling line.  After some hijinks, we discovered that the long, insulated chiller lines have the same labels at each end.  This means that if you match up the labels at the chiller end, at the MOPA end you need switch labels: out goes to in and vice-versa.  This means that, indubitably, we have at some point had the flow going backwards through the MOPA, though I'm not sure if that would make much of a difference. 

Steve also installed a new needle valve in the NPRO cooling line, which works as expected as confirmed by the flow meter. 

We also re-discovered that the 40m procedures manual contains an error.  To turn on the chiller in the MOPA start-up process, you have to press ON, then RS-232, then ENTER.  The proc man says ON, RS-232, RUN/STOP.

The laser power is at 1.5W and climbing.

 Rob, Alberto

The chiller HT alarm started blinking, as the water temperature had reached 40 degrees C, and was still rising.  We turned off the MOPA and the chiller.  Maybe we need to open the needle valve a bit more?  Or maybe the flow needs to be reversed?  The labels on the MOPA are backwards?

 The chiller appears to be broken.  We currently have it on, with both the SENSOR and RS-232 unplugged.  It's running, circulating water, and the COOL led is illuminated.  But the temperature is not going down.  The exhaust out the back is not particularly warm.  We think this means the refrigeration unit has broken, or the chiller computer is not communicating with the refrigerator/heat exchanger.  Regardless, we may need a new chiller and a new laser.

  1628   Wed May 27 15:59:44 2009 robUpdatePSLwe don't understand the chiller (broken)

steve, alberto, rob

After some futzing around with the chiller, we have come to the tentative conclusion that the refrigeration unit is not working.  Steve called facilities to try to get them to recharge the refrigerant (R-404a) tomorrow, and we're also calling around for a spare chiller somewhere in the project (without luck so far).

  7693   Fri Nov 9 11:38:38 2012 jamieUpdateGeneralwe're closing up

After a brief look this morning, I called it and declared that we were ok to close up.  The access connector is almost all buttoned up, and both ETM doors are on.

Basically nothing moved since last night, which is good.  Jenne and I were a little bit worried about how the input pointing might have been effected by our moving of the green periscope in the MC chamber.

First thing this morning I went into the BS chamber to check out the alignment situation there.  I put the targets on the PRM and BS cages.  We were basically clear through the PRM aperture, and in retro-reflection.

The BS was not quite so clear.  There is a little bit of clipping through the exit aperture on the X arm side.  However, it didn't seem to me like it was enough to warrant retouching all the input alignment again, as that would have set us back another couple of days at least.

Both arm green beams are cleaning coming out, and are nicely overlapping with the IR beams at the BS (we even have a clean ~04 mode from the Y arm).  The AS and REFL spots look good.  IPANG and IPPOS are centered and haven't moved much since last night.  We're ready to go.

The rest of the vertex doors will go on after lunch.

  152   Fri Nov 30 21:27:24 2007 ranaDAQPEMweather / stacis / c1pem1
I was trying to add some Seis BLRMS channels to the c1pem1 processor so that we could have DMT trends.

Then I found that none of the Weather channels have been working for a year or so. I could also not
telnet into it. I tried resetting it but no luck. There was no entry in the Wiki for it so I added
a place holder.

Have the weather channels ever worked? Do we have those sensors? I think I've never actually looked
for this. Seems like a fine ugrad job.
  189   Wed Dec 12 22:24:48 2007 tobinFrogsPEMweather station
I poked at the weather station briefly this evening.

* There's almost nothing in the elog about it.
* It exists. It is located on the North wall, just north of the beam splitter.
* It seems to be displaying reasonable data for the indoors, but nothing for the outdoor sensors.
* c1pem didn't seem to be starting up (couldn't telnet into it, etc). I altered its startup file and reset it several times, and eventually it came to life.
* the weather station has a serial cable that goes all the way to c1pem. I plugged it in.
* however, the Weather.st program complains "NO COMM"--it gets no data from the weather station
* The next thing to do is to plug in a laptop to that serial cable and see if the weather station can be convinced to talk.
  11291   Thu May 14 17:41:10 2015 ranaUpdatePEMweather station and Guralp maintenance

Today Steve and I tried to recenter the Guralps. The breakout box technique didn't work for us, so we just turned the leveling screws until we got the mass position outputs within +/-50 mV for all DoF as read out by the breakout box.

Some points:

  1. GUR1 is at the ETMY (E/W arm) and GUR2 is at the X-end (South arm)
  2. The SS containers are good and make a good seal.
  3. We had to replace the screws on the granite slab interface plate. The heads were too big to allow the connector to snap into place.
  4. The Guralps had been left way, way off level and the brass locking screws were all the way up. We locked them down after leveling today. Steve was blaming Cathy(?).
  5. The GUR1_Z channel now looks good - see the summary pages for the before and after behavior. My mistake; the low frequency is still as bad as before.
  6. GUR2 X/Y still look like there is no whitening or if the masses are stuck or the interface box is broken.
  7. When we first powered them up, a few of the channels of both seismometers showed 100-200 Hz oscillations. This has settled down after several minutes.

 

The attachment shows the 6 channels after our work. You can see that GUR2_X/Y still look deadish. I tried wiggling the cables at the interface box and powering on/off, but no luck. Next, we swap cables.

Tried to bring the weather station back to life, but no luck. The unit on the wall is alive and so is the EPICS IOC (c1pem1). But there is apparently no communication between them. telnet into c1pem and the error message repeating at the prompt is:

Weather Monitor Output: NO COMM

Might be related to the flaky connector situation that Liz and I found there a couple summers ago, but I tried jiggling and reseating that one with no luck. Looks like it stopped working around 8 PM on March 24, 2014. That's the same time as a ~30s power outage, so perhaps we just need some more power cycling? Tried hitting the reset button on the VME card for c1pem1, but didn't change anything.

Let's try power cycling that crate (which has c1pem1, c0daqawg, and some GPS receiver)...nope - no luck.

Also tried power cycling the weather box which is near the BS chamber on the wall. This didn't change the error message at the c1pem1 telnet prompt.

Attachment 1: GurPost_150514.png
GurPost_150514.png
Attachment 2: secretWeatherTrends.png
secretWeatherTrends.png
  418   Tue Apr 8 09:08:54 2008 steveConfigurationPEMweather station disconnected
We can not leave cables in the walkways and go on vacation.
I disconnected the weather station from the DAQ
Every Tuesday is janitor day in the 40m.
We have to give him free space for doing a good job.

Burned toast award goes to Andrey.
Attachment 1: toast.jpg
toast.jpg
  516   Wed Jun 4 10:18:52 2008 steveUpdatePSLwedged SS beam trap
I moved the SS trap over to the psl table.
Texas super # 8 was used from the large shipment.
TXs#8 scattering measured as before, meaning the polishing is good.

Go's squeezing power pick up 350 mW was used.
I made two ~30 degrees wedge traps using 6" x 4" and 12" x 4" SS 0.039" thick
with copper backing of similar size.

There was too much scattering and I could not minimize them all.
It is very helpful to have so much space on the psl table.
It shows more of the weakness of this kind of trap.
I did not dare to turn up the power.
Attachment 1: trap1.png
trap1.png
Attachment 2: trap2.png
trap2.png
  2027   Wed Sep 30 02:01:28 2009 robUpdateLockingweek

It's been a miserable week for lock acquisition, with each night worst than the last.  The nadir was around Sunday night, when I couldn't even get a PRM to lock stably, which meant that the auto-alignment scripts could not finish successfully.  It now appears that was due to some XYCOM mis-settings. 

We've also been having problems with timing for c1susvme2.  Attached is a one-hour plot of timing data for this cpu, known as SRM.  Each spike is an instance of lateness, and a potential cause of lock loss.  This has been going on for a quite a while.

Tonight we also encountered a large peak in the frequency noise around 485 Hz.  Changing the MZ lock point (the spot in the PZT range) solved this.

 

Attachment 1: srmcpu.png
srmcpu.png
  5151   Tue Aug 9 03:05:05 2011 kiwamuSummaryGeneralweekly report

Summary of the week ending Aug 8th.  Number of elog entries = 56


- VAC
 + The vent started Wednesday morning
 + Repositioning of the green periscopes and associated mirrors are done.
 + Got both of the green beams coming out from  the chambers
 + Moved the ETMX suspension tower by -8.09 inch (away from vertex)
 + Fixed the alignment of the ETMX CCD mirrors
 + Recovered the X green beam axis for the latest ETMX position

- SUS
 + oplev centered prior to the vent

- LSC
 + ETMY_TRANS_QPD didn't respond at all, needs to be fixed
 + Old MZ PD (InGaAs 2mm, @29.5MHz) has been modified for REFL33.
  The 11MHz notch circuit is at the amp side instead of the diode side. This is ready for the installation
 + REFL165 PD has been made from the old 166MHz PD.

- IOO
 + IPPOS has been sick since 19th of July, 2011
 + IPANG is clipped on a pick-up mirror on the ETMY table. QPD itself is healthy.
 + The spot positions on the MC mirrors were measured prior to the vent.
   The results are almost the same as before within a few percent difference expect for the MC2 yaw.
 + An attenuator, consisting of two HWPs and a PBS, has been installed on the PSL table for the MC low power state.
 + a 10% BS in front of the MCREFL_RFPD was replaced by a perfect reflector for the low power mode.
 + The incident power for MC was decreased to 20 mW
 + The beam axis going to MC was misalgned due to the attenutor.
    Then the beam was aligned by touching two steering mirrors on the PSL table
 + MC is able to be locked in air. The reflection DC goes from 1.4 to 0.13 V when the MC is locked.

- ABSL
 + With the mass-kicking technique, the arm lengths were measured.
   Xarm =  37.5918 m, Yarm = 37.5425 m.

- Green locking
 + Y green beam is aligned to the Y arm
 + Locking of the Y green is not robust, it needs to be revisited

- OAF
 + Wiener Filtering was applied on the data collected from the X-arm for a duration of 1500 seconds.

- Misc.
 + The hazardous waste people are moving chemicals around outside our door, and have roped off our regular front door.
 + The horizontal trolley drive of the east end crane stopped working. It will be fixed.

  764   Wed Jul 30 12:03:44 2008 MashaSummaryAuxiliary lockingweekly summary
I've been learning about mode matching/beam propagation, so I can work on getting more
light into the fiber and increase the phase noise signal. I am also looking into phase
lock loops and noise in the fiber stabilization system to understand the noise sources
and figure out what our goals are in fiber stabilization.

In the lab, I've reproduced the Mach Zehnder interferometer that I had at the 40m, now
with a 50m fiber in one arm. I have done some preliminary fiber noise measurements
and revised estimations of noise sources (see attached plots). Once the digital
acquisition system is back up, I will be able to better manipulate the signals to cancel
laser amplitude noise and amplitude noise from variation in the amount of coupling into
the fiber. Some improvements in progress are more stable mounts for the fiber couplings,
faraday isolator, and better mode matching with the fiber.

Also working on my progress report.
Attachment 1: mz_fiber_noise0730.png
mz_fiber_noise0730.png
Attachment 2: setup0730.JPG
setup0730.JPG
Attachment 3: MZnoise_sources0727.png
MZnoise_sources0727.png
  804   Wed Aug 6 13:57:44 2008 MashaSummaryAuxiliary lockingweekly summary
Finished second progress report.

Working on improving the sensitivity of the Mach Zehnder to more accurately measure the fiber noise. Making more stable mounts that have fewer degrees of freedom/springs and are more solid should get rid of their vibrational modes and help with the noise. I found a good mount for the Faraday Isolator, and John and Aidan helped me to make the solid aluminum blocks to mount the fiber couplers. I'll also replace the laser feet with a similar solid mount. I will also get a plastic box to block out acoustic noise/air currents/etc. Am starting to couple into the fiber again; now I am using polarization maintaining fiber.

I am starting to plan the fiber noise cancellation setup, and thinking about the noise sources and their effects.
  3145   Wed Jun 30 12:13:39 2010 Sharmila, KatharineUpdateWIKI-40M Updateweekly update

Weekly Project Update:

We are studying Haixing's circuit diagram for the quadrant maglev control circuit.  We have analyzed several of the sub-circuits and plotted transfer functions for these in MatLab.  To check the circuit, we will compare the calculated transfer functions with those obtained from the HP control systems analyzer.

To learn how to use the control systems analyzer, we are reading App Note 243 as well as an online manual (477 pages in the first volume).  We are beginning with a simple test circuit, and are comparing its measured frequencyresponse with calculated transfer functions.  We currently have obtained a response graph beginning at 100 Hz (which we have not yet figured out how to print), and we are planning to investigate behavior at lower frequencies.

We also have been continuing our reading on control systems after a failed attempt at magnetic levitation. 

  3256   Wed Jul 21 12:03:14 2010 Katharine, SharmilaUpdateWIKI-40M Updateweekly update

This past week, we levitated our small cylindrical magnet (with the flag made from heat shrink).  Though the levitated magnet didn't appear very jittery to the eye, we looked at the PD current on the scope and could see oscillations that corresponded to the flag hitting the sides of the OSEM.  The oscillations were more pronounced as we gently hit/vibrated the lab bench, and by pounding on the bench Rana knocked the levitated magnet completely out of the setup.  So, we're currently working on building a new, stabler mount.  The biggest challenge here is fixing the OSEM in place, but we're experimenting with different optics pieces to see which is the most stable for our purposes.   Jenne taught us how to make through holes using the drill press so we can add slats of aluminum to adjust the height of the OSEM mount.  We also plan to fix some heavy plates to the bottom of our system to decrease its vibration frequency.

We also calculated the transfer function of our circuit, which seems to match the measured frequency response to within a small factor.  We're playing with Rana's Simulink models and are currently modeling our own system to determine what gains we would expect to use and get a better understanding of our circuit.


Once our system is successfully mounted stably, we plan to experimentally observe the effects of changing the gain and integrator by looking at time series measurements of the PD current, as well as using the spectrum analyzer to compare the frequency response of our system at different gain settings.

  1780   Wed Jul 22 18:04:14 2009 robOmnistructureComputersweird noise coming from Gigabit switch

in the rack next to the printer.  It sounds like a fan is hitting something.

  4704   Thu May 12 18:21:19 2011 kiwamuUpdateIOOwelcome back IP_POS

IP_POS is back. 

I reconnected the cable to an interface card : D030238-A which has been labeled as "IP POS".

The card currently resides on the third crate rack from the top at the very right side in 1Y2. Also a rear side connection was modified a little bit.

I will clean up some cables because I tried some cables to see which was which.

Hopefully I will make a simple wiring diagram such that we will never forget the connections.

Quote from #4700

Quote from #4799

A cable for IP_POS has been disconnected at the LSC rack, 1Y2. Due to it currently no IP_POS signal shows up on the digital side.

I will check how it used to be and reconnect it.

 I found the disconnected cable, but I do not see the interface board at the LSC rack

  3808   Thu Oct 28 09:16:17 2010 steveUpdatePEMwelding in the vertex area

Fire-smoke sensors in the vertex area #2-31, 2-30 east, 2-32 south/MC2 and 2-37 old control room area are turned off to accommodate the welding

activity of folding crane. These sensors will be reactivated at 3:30pm today.

Stay out of the 40m lab: IFO room till 6 pm today.

  3654   Tue Oct 5 17:39:21 2010 steveConfigurationVACwest access connector removed

Kiwamu, Koji, Yutah, Rana, Jan and Steve

We removed the west access connector this afternoon.

  Draft   Mon Aug 5 16:28:41 2019 yehonathanUpdateLoss Measurementwhat is going on with the loss measurements ?

We hypothesize that the systematic error in the loss measurement can come from the fact that the requirement on the alignment of the cavity mirrors is not stringent enough.

We repeat the loss measurement with 50 measurements. This time we change the thresholds for the error signals of the dither-align in the measureArmLoss.py file from 0.5 to 0.3.

We repeat the analysis done before:

We plot the reflected power of the two states on top of each other:

This  time it appears there was no drift. The histogram of the loss measurement:

The mean is 104ppm and the variation is 27%.

What I notice this time is that the PD readings in the aligned and misaligned states are anti-correlated. This is also true in the previous run (where there was drift) when looking in the short time scales. I plot several time series to demonstrate:

I wonder what can cause this behaviour.

  5083   Mon Aug 1 17:47:37 2011 steveUpdateASCwhat is not working

SUS-ETMY_QPD is not responding. It is reading zero in dataviewer and 4,400 counts on QPD MEDM screen.......must be wrong cable connected

IP-POS is sick. Last time alive 7-19-2011

IP-ANG beam is clipping on pick-up mirror at ETMY chamber. This will have to be fixed at the vent. The qpd itself is responding to light.

  8184   Wed Feb 27 14:53:02 2013 SteveUpdateLSCwhat is the Fibox ?

Fibox FBAI-M 20bit units were connected with multimode fibre.  This pair of fiber is not protected in the cable tray.

ELOG V3.1.3-