40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 297 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  2133   Thu Oct 22 15:44:16 2009 ZachUpdateWIKI-40M UpdateMOPA diagram

 I have updated the PSL Diagram wiki page to include MOPA. As with the PSL diagram, clicking the photo on the main page takes you to a larger image. The inventory is pretty meager as I didn't have time to sit and read labels (if indeed there are any). I will look through the documentation at the 40m to see if there is a record of what is there. Again, if you know something, please amend the list!!

http://lhocds.ligo-wa.caltech.edu:8000/40m/PSL_Table_Diagram

  2132   Thu Oct 22 08:45:58 2009 steveUpdateIOOIP ang & pos recentered

Quote:

Pointing stability of 4 days. Initial pointing does not go through suspended optics. It is launched  right after the Piezo Jena steering mirrors in the BS chamber.

IP-ANG on epics screen is  C1:ASC-IBQPD_X and Y in dataviewer  were recentered. This beam is clipping a bit in ETMX chamber  pick off mirror.

IP-POS pick  off is in the BS chamber and it's qpd on the BS_ISCT This beam is also clipping just a little bit. This is easy to fix. We'll have to remove an iris from the BS optical levers table.

note: arms were not locked when I recentered

 IP-ANG clipping can be traced back to our last vent of Aug. 18, 2008  See elog entry #845

This was an after earth quake - sus repair vent

  2131   Wed Oct 21 17:12:30 2009 AlbertoUpdateelogBrowser context menu enabled on the Elog under HTM editing mode

On behalf of Steve and of the rest of the not-native-English community at the 40m willing to have their browser's spell checker working while editing the Elog, I fixed the Elog's feature that prevented Firefox' context menu (that one which pops up with a mouse right click) to work when using the HTML editing interface (FCKeditor).

That let also Firefox spell checker to get enabled.

To get the browser context menu just press CTRL right-clicking.

To make sure that the features works properly on your browser, you might have to fully clear the browser's cache.

Basically I modified the FCKeditor config file (/cvs/cds/caltech/elog/elog-2.7.5/scripts/fckeditor/fckconfig.js). I added this also to the elog section on our Wiki.

  2130   Wed Oct 21 16:18:12 2009 SteveSummarySAFETYLIGO Safety Officers visited the 40m

David Nolting, chief LIGO Safety Officer and his lieutenants from LLO and LHO paid homage to the 40m lab this morning.

They give us a few recommendation: update safety documents, move optical table from the front of ETMX-rack and label-identify absorbent plastics on enclosure windows-doors.

We'll correct these short comings ASAP

 

  2129   Wed Oct 21 15:07:45 2009 AlbertoUpdateWIKI-40M UpdatePhotodiodes' configuration for the Upgrade

I uploaded on the Wiki (here) the results of an inventory over our current PDs, a list of the new ones that we're going to need for the new control scheme.

  2128   Wed Oct 21 13:07:54 2009 KojiUpdateWIKI-40M UpdatePSL Table Diagram wiki entry

http://lhocds.ligo-wa.caltech.edu:8000/40m/PSL_Table_Diagram

Thanks. I love this. Could you also put the original file that is editable for future modification by anyone?

Quote:

 I made a wiki entry for the PSL table diagram under the PSL directory on the 40mHomePage. I tried to use the ImageLink macro to use a resized (smaller) version of the diagram as a link to the full image, which it is designed to do if there is no target given, but it didn't seem to work. Instead, I had to create a second page that had the full-sized diagram, and I used ImageLink with a smaller version to link to that page.

The inventory that is shown is clearly incomplete. Part of this is due to the fact that many labels were either missing or impossible to read without touching stuff. For those components with labels missing, I tried to infer what they were to the best of my knowledge, but I wasn't able to for all of them. In true wiki spirit, everyone is encouraged to fill in any additional information they might have on these components. 

 

  2127   Wed Oct 21 11:41:29 2009 ZachUpdateWIKI-40M UpdatePSL Table Diagram wiki entry

 I made a wiki entry for the PSL table diagram under the PSL directory on the 40mHomePage. I tried to use the ImageLink macro to use a resized (smaller) version of the diagram as a link to the full image, which it is designed to do if there is no target given, but it didn't seem to work. Instead, I had to create a second page that had the full-sized diagram, and I used ImageLink with a smaller version to link to that page.

The inventory that is shown is clearly incomplete. Part of this is due to the fact that many labels were either missing or impossible to read without touching stuff. For those components with labels missing, I tried to infer what they were to the best of my knowledge, but I wasn't able to for all of them. In true wiki spirit, everyone is encouraged to fill in any additional information they might have on these components. 

  2126   Tue Oct 20 16:35:24 2009 robConfigurationLSC33MHz Mod depth

The 33MHz mod depth is now controlled by the OMC (C1:OMC-SPARE_DAC_CH_15).  The setting to give us the same modulation depth as before is 14000 (in the offset field).

  2125   Tue Oct 20 11:38:10 2009 rana, rolfUpdateAdaptive Filteringextra delay and noise in PEM -> ASS/OAF system

An email from Rolf about the delay in the 110Bs:

"...we do take the ~2msec pipeline delay into account when we send the data to DAQ. If I remember correctly, the delay is about 39 samples. On startup, the first 39 samples are 'thrown away', such that, from then on, data lines up with the correct time (just read 2msec later then Penteks)."

  2124   Tue Oct 20 10:46:18 2009 steveUpdateIOOclipping IP-ANG beam at ETMX chamber

Initial pointing beam is clearly clipping on 2" pick off mirror in  ETMX vacuum chamber.

Atm. 1  The pick off mirror is just north west of the ETMX test mass

Atm. 2 The camera is looking in from the north view port of ETMX chamber. The back side of pick off mirror is visible now with the face view of the "IP-ANG-OUT" mirror.

 

  2123   Tue Oct 20 02:14:29 2009 robUpdateIOOMC2 alignment bias changed

the mode cleaner was having trouble locking in a 00 mode, needing several tries.  I changed the MC2 coil biases, and it seems better for now.

  2122   Mon Oct 19 23:14:32 2009 kiwamuUpdateLSCLSC timing issue

I measured the noise spectrum of LSC_DARM_IN1 and OMC-LSC_DRIVE_EXC by using DTT,

while injecting the sin-wave into the OMC-LSC_DRIVE by AWG.

The attached are the results.

No significant differences appears between OMC and LSC in this measurement.

It means, in this measurement we can not figure out any timing noise which might be in LSC-clock.

In addition there are the noise floor, whose level does not change in each 3-figures. The level is about ~4*10^{-8} count/sqrt[Hz]

(The source of the noise floor is still under research.)

  2121   Mon Oct 19 19:37:39 2009 Sanjit, JenneUpdateAdaptive Filteringextra delay and noise in PEM -> ASS/OAF system

Rana pointed out that the delay may be caused by the 110B DAQ, as it integrates over 2ms (5 clock cycles at 2048Hz on the fe computer), to make low noise measurement. However, the C0DCU knows about this delay and corrects it by fudging the time stamp, before sending it to the frame builder, so that the time stamps match the actual measurement time. But, the ASS computer is not aware of such an integration time, so it does not adjust the time. We verified that it is indeed the case. This is what we did (as suggested by Rana):

We split the signal from the MODE cleaner board "OUT" port using a T-splitter to the original PENTEK board (C1:SUS-MC2-MCL-IN) and the PEM ADCU channel #2. Then measured the mutual delays between the signals that are processed by C0DCU and the ASS computer for both the MC_L signal and the corresponding output through the PEM channel. We clearly see the same delay (compare red and brown in the bottom panel) between the signals that are going through 110B and the PENTEK DAQ. This delay is a bit noisy, possibly because the PENTEK is not as low noise as the 110B is.

There is some delay (pink curve in the bottom panel) between the PENTEK DAQ and the frame builder corrected 110B output, much smaller than 2ms, could be ~200-400 u sec. Which should correspond to the 1 or 1/2 cycle delay caused by the PENTEK DAQ.

So, once we have the planned advLIGO DAQ system, there should not be any long delay. Perhaps, to solve the problem and make OAF functional soon, we will upgrade the PEM DAQ asap, rather than waiting for the rest of the upgrades...

 

  2120   Mon Oct 19 18:14:28 2009 robUpdateCamerasvideo switch broken

The Chameleon HB (by Knox) video switch that we use for routing video signals into the control room monitors is broken.  Well, either it's broken, or something is wrong with the mv162 EPICS IOC which communicates with it via RS-232.  Multiple reboots/resets of both machines has not yet worked.  The CHHB has two RS-232 inputs--I switched to the second one, and there is now one signal coming through to a monitor but no switching yet. I've been unable to further debug it because we don't have anything in the lab (other than the omega iserver formerly used for the RGA logger) which can communicate with RS-232 ports.  I've been trying to get this thing (the iserver) working again, but can't communicate with it yet.  For now I'm just going to bypass the video switch entirely and use up all the BNC barrel connectors in the lab, so we can at least have the useful video displays back.

  2119   Mon Oct 19 17:12:54 2009 jenneUpdatePEMaccelerometers and seismomters are all good.

Quote:

Some of these channels are not like the others.

 All of the PEM channels seem to be okay right now.  The accelerometers didn't turn out to have any differences in the traces when we put both XYZ triplets right next to each other, so we put them back where they belong.  Gur2 seismometer was showing a few problems, especially with Gur2_X, as Rana posted in elog 2079.  This was solved by tightening the cable screws which hold the Dsub end of the Guralp cable to the front panel of the Guralp box.  All is now well.

  2118   Mon Oct 19 14:48:15 2009 rana, robSummaryElectronicspiezo jena measuring box
Attached is the schematic of the Piezo Jena driver measuring box made in a Pomona box:
                2.2 uF
In ----o-------- | | --------o-------- Out
       |                     |
       _                     |
       _  1uF                R  7.5 kOhms
       |                     |
       |                     |
      GND                   GND
The 1 uF cap is there to simulate the piezo and the 2.2 uF and 7.5k resistor ac couple the signal for the spectrum analyzer. They give a ~10 Hz corner frequency.
  2117   Mon Oct 19 13:00:53 2009 MottUpdateGeneralPhase Noise Measurement

Here is the result for the measurement of the phase noise.  We used the marconi function generator and compared it with an Isomet AOM driver (model 232A-1), so this is really a measure of the relative phase between them.  We used a 5x gain and a frequency response of 13 Hz/V for the modulation.  In all the attached plots, the blue is the data and the red is the measurement limit (as determined by the noise in the SRS785).  Also note that the units on the yaxis of the Phase noise plot are incorrect, they should be dB/Sqrt(Hz), I will fix this and edit as soon as possible.

  2116   Mon Oct 19 11:31:55 2009 JenneUpdateAdaptive Filteringextra delay and noise in PEM -> ASS/OAF system

Quote:

[Rana, Jenne]

There is some craziness going on with the delay in the PEM path for the OAF.  We plot the difference between the C1:PEM-SEIS_GUR1_X and C1:ASS-TOP_PEM_10.  These are physically the same channel, plugged into the PEM ADCU, and then the signal is used as a regular PEM channel, and is also sent to the ASS computer and used there for the OAF system.  As you can see in the blue trace on the bottom plot, there is a huge amount of delay, and it's very noisy.  We also plot the _GUR2_X / ASS-TOP_PEM_2 pair (red), and it has a similar amount of delay, but it is not nearly as fuzzy and noisy.  For comparison, we plot the SUS-MC2_MCL (which is identical to IOO-MC_L) and ASS-TOP_ERR_MCL pair (green), and they don't have any big overall delay problems, so it's not totally a problem with the signals getting to the ASS computer.

This problem was present during/after all of the following attempts to fix it:

* The sample rate on the ASS computer is 2048.  The PEM channels were being acquired the ADCU at 512.  We changed the ADCU sampling rate to 2048 to match.

* We soft rebooted the ASS computer, in case it was a timing problem.

* Doing a "sudo shutdown -r now" while logged in as controls.

We might also try resetting/power cycling c0dcu in the morning.  Alex has been emailed to help us try to figure this out.

 

In other news, the time delay that we measure from the plot gives us 180degrees in ~210Hz.  This corresponds to a little more than 2msec of delay, with the C1:ASS version lagging behind the C1:PEM version.  (2 samples at 840Hz) Converting to the 2048 sampling rate, we have a delay of 4.8, so 5 front-end cycles.  Since Rana measured this morning that the delay indicated by the transfer function is 10 cycles, and this delay shows that the ASS lags the actual seismometer signal by 5 cycles, we should subtract this 5 from the 10 from the transfer function, giving us a final sample-and-hold delay of 5.  Coincidentally(?), 5 is the delay that was found in the C1:ASS-TOP screen, after it's one year of dormancy.  The point of the delay feature in the code is to help match the delay in the two signal paths: the PEM path and the output path of the filter.  Since the output has a lag of 10, and the PEM path has a lag of 5, to make them match, we artificially put in a delay of 5.

 Alex came in a week ago Friday to help figure this timing problem out, and some progress was made, although there's more to be done. 

Here are the (meager) notes that I took while he was working:

we can rename the tpchn_C1_new back to tpchn_C1, but the _new one works right now, so why change it?

need to find dcuDma.c source code...this is (?) what sends the PEM channels over to ASS.  Found:  source code is dcu.c, th
en the binary is dcuDma.o  Trying to recompile/remake dcuDma to make everything (maybe) good again.

Possibility: maybe having so many channels written to the RFM takes too long? shouldn't be  a problem, but maybe it is.  I
n the startup.cmd (or similar?) change the number of ISC modules to 1, instead of 2, since we only have one physical board
 to plug BNCs into, even though we have 2 isc boards.  c0dcu1 rebooted fine with the one isc board.  now can't get ass tes
tpoints to try the DTT timing measurement again.  rebooting fb40m to see if that helps.  fb40m is back, but we still don't
 have ASS testpoints.  Alex had to leave suddenly, so maybe more later.

Also, next possibility is that c0dcu and c1ass are not synched together properly....we should look at the timing of the AS
S machine.

 

After these adventures, the noisy trace in the timing delay (in the plot in elog 2066) has become quiet, as shown below (The blue trace, which was noisy in 2066 is now hiding behind the red trace).  However, the overall timing delay problem still exists, and we don't quite understand it.  Alex and I are meeting tomorrow morning at the 40m to try and suss this out.  Our first plan of attack is to look at the ASS code, to see if it puts any weird delays in.

  2115   Mon Oct 19 11:00:52 2009 steveHowToSAFETY40m safety training

Kiwamu, Alex and Zach are practicing mandatory IR-safety scan at the 40m-PSL

40m specific safety indoctrination were completed.

  2114   Mon Oct 19 10:00:52 2009 kiwamuUpdateLSCRE: LSC timing issue

Of course I know there is a downconversion in OMC signal from 32k to 16k.

But I was just wondering if the delay comes from only downconversion.

And I can not find any significant noise in both signals because I use the triangular, which cause the higer harmonics and can hide the timing noise in frequency domain.

So I'm going to make the same measurement by using sinusoidal instead of triangular, then can see the noise in frequency domain.

 

Quote:

You yourself told me that tdsdata uses some downconversion from 32k to 16k!

So, how does the downconversion appears in the measurement?
How does the difference of the sampling rate appears in the measurement?
If you like to understand the delay, you have to dig into the downconversion
issue until you get the EXACT mechanism including the filter coefficients.

AND, is the transfer function the matter now?

As far as the LSC and OMC have some firm relationship, whichever this is phase delay or advance or any kind of filering,
this will not introduce any noise. If so, this is just OK.

In my understanding, the additional noise caused by the clock jitter is the essential problem.
So, did you observe any noise from the data?

Quote:

*preliminary result

The measured data are shown in attached fig.1 and 2.

In the fig.1 it looks like they are the same signal.

However in fig.2 which is just magnified plot of fig.1, it shows a time-delay apparently between them.

The delay time is roughly ~50 micro sec.

The surprising is that the LSC signal is going beyond the OMC signal, although the OMC signal drives the LSC !!

We can say it is "negative delay"...

Anyway we can guess that the time stamp or something is wrong.

 

*next plan

Tomorrow I'm going to measure the transfer-function between them to see the delay more clearly.

( And I would like to fix the delay. )

 

 

  2113   Sun Oct 18 23:02:03 2009 KojiUpdateLSCLSC timing issue

You yourself told me that tdsdata uses some downconversion from 32k to 16k!

So, how does the downconversion appears in the measurement?
How does the difference of the sampling rate appears in the measurement?
If you like to understand the delay, you have to dig into the downconversion
issue until you get the EXACT mechanism including the filter coefficients.

AND, is the transfer function the matter now?

As far as the LSC and OMC have some firm relationship, whichever this is phase delay or advance or any kind of filering,
this will not introduce any noise. If so, this is just OK.

In my understanding, the additional noise caused by the clock jitter is the essential problem.
So, did you observe any noise from the data?

Quote:

*preliminary result

The measured data are shown in attached fig.1 and 2.

In the fig.1 it looks like they are the same signal.

However in fig.2 which is just magnified plot of fig.1, it shows a time-delay apparently between them.

The delay time is roughly ~50 micro sec.

The surprising is that the LSC signal is going beyond the OMC signal, although the OMC signal drives the LSC !!

We can say it is "negative delay"...

Anyway we can guess that the time stamp or something is wrong.

 

*next plan

Tomorrow I'm going to measure the transfer-function between them to see the delay more clearly.

( And I would like to fix the delay. )

 

  2112   Sun Oct 18 22:06:15 2009 ranaConfigurationElectronicsIP POS is back: ND filter gone, new resistors in

I tried to compare the IP_POS time series with the IPANG and MC_TRANS but was foiled at first:

1) The IPANG scan rate was set to 0.5 second, so it doesn't resolve the pendulum motions well. Fixed in the .db file.

2) Someone had used a Windows/DOS editor to edit the .db file and it was filled with "^M" characters. I have removed them all using this command:   tr -d "\r" <ETMXaux.db > new.db

3) The MC_TRANS P/Y channels were on the MC Lock screen but had never been added to the DAQ. Remember, if there's a useful readback on an EPICS screen. its not necessarily in the frames unless you add it to the C0EDCU file. I have done that now and restarted the fb daqd. Channels now exist.

4) Changed the PREC of the IPPOS channels to 3 from 2.

5) changed the sign for the IBQPD (aka IPANG) so that bigger signal is positive on the EPICS screen.

  2111   Sun Oct 18 22:05:40 2009 kiwamuUpdateLSCLSC timing issue

Today I made a measurement to research the LSC timitng issue as mentioned on Oct.16th.

*method

I put the triangular-wave into the OMC side (OMC-LSC_DRIVER_EXT) by AWG,

then looked at the transferred same signal at the LSC side (LSC_DARM_IN1) by using tdsdata.

I have compared these two signals in time domain to check whether they are the same or not.

In the ideal case it is expected that they are exactly the same.

 

*preliminary result

The measured data are shown in attached fig.1 and 2.

In the fig.1 it looks like they are the same signal.

However in fig.2 which is just magnified plot of fig.1, it shows a time-delay apparently between them.

The delay time is roughly ~50 micro sec.

The surprising is that the LSC signal is going beyond the OMC signal, although the OMC signal drives the LSC !!

We can say it is "negative delay"...

Anyway we can guess that the time stamp or something is wrong.

 

*next plan

Tomorrow I'm going to measure the transfer-function between them to see the delay more clearly.

( And I would like to fix the delay. )

  2110   Sun Oct 18 19:55:45 2009 ranaConfigurationElectronicsIP POS is back: ND filter gone, new resistors in

Its back in and re-centered. Our next move on IPPOS should be to replace its steering mirror with something bigger and more rigid.

Electronics changes:

20K -> 3.65 K  (R6, R20, R42, R31) (unused)

20K -> 3.65 K  (R7, R21, R32, R43, R11, R24, R35, R46)

If you look in the schematic (D990272), you see that its an AD797 transimpedance stage with a couple of LT1125 stages set to give some switchable gain. It looks like some of these

switches are on and some are not, but I am not sure where it would be controlled from. I've attached a snapshot of one quadrant of the schematic below.

The schematic shows the switches in the so-called 'normally closed' configuration. This is what the switches do with zero volts applied to the control inputs. As the schematic also shows,

just disconnecting the 'switch' inputs cause the switch's control inputs to go high (normally open configuration, i.e. pins 2-3 connected, pin4 open). For the record, the default positions of the IPPOS switches are:

switch1   high

switch2   low

switch3   low

switch4   high

 


** EDIT (Nov 2, 2009): I forgot to attach the before and after images; here they are:

IMG_0068.JPGIMG_0072.JPG

  2109   Sun Oct 18 16:09:34 2009 ranaConfigurationASCloop opened on PZT2 YAW at 3:40 pm

 

I wanted to see how long our IP POS beam has been badly clipped - turns out its since April 1, 2007.

Steve's April Fool's joke is chronicled then. The attached trend shows that the drop in IP POS is coincident with that event.

In trying to align IPPOS, I noticed that someone has placed a ND2.0 filter (factor of 100 attenuation) in front of it. This is kind of a waste - I have removed IPPOS to fix its resistors and avoid this bad optic. Also the beam coming onto the table is too big for the 1" diameter optics being used; we need to replace it with a 2" diamter optic (Y1-2037-45P).

 

IP ANG dropped by a factor of 2 back in early August of '08.

We need this guy on the investigation:

 

  2108   Sun Oct 18 15:46:08 2009 AlbertoConfigurationGeneralAntique, unused QPD removed from the AS table

Inspecting the AS table to make an inventory of the photodiodes in use around the interferometer, I found a mysterious photodetector hiding behind PD1 (AS166).

It turned out the detector was an old type of QPD from the Squeezing Experiment a few years ago.

We removed the box and the cable to which it was connected from the table. We stored it in the optics cabinet along the X arm.

  2107   Fri Oct 16 18:46:36 2009 ranaConfigurationASCloop opened on PZT2 YAW at 3:40 pm

Quote:

I pushed the "closed loop" button on PZT2 YAW around 3:40 pm today, then roughly recentered it using the DC Offset knob on the PiezoJena controller and the IP ANG QPD readbacks.  There was a large DC shift.    We'll watch and see how much it drifts in this state.

 Here's the trend.

The transient at ~22:40 is Rob switching to 'Open Loop' on the Piezo Jena PZTs. I don't see any qualitative change in the drift after this event.

At 05:55 UTC, I removed an iris that was blocking the IP POS beam (the sum goes up from 2 to 6.5) without disturbing the mirrors who's oplev beam are on that table. Steve has conceded one sugar Napoleon after betting against my ninja-like iris skills.

We should recenter the beam on IP POS now that its unclipped - I'll let it sit this way overnight just to get more drift data.

  2106   Fri Oct 16 16:44:39 2009 Alberto, SanjitUpdateComputerselog restarted

This afternoon the elog crashed. We just restarted it.

  2105   Fri Oct 16 16:08:00 2009 robConfigurationASCloop opened on PZT2 YAW at 3:40 pm

I pushed the "closed loop" button on PZT2 YAW around 3:40 pm today, then roughly recentered it using the DC Offset knob on the PiezoJena controller and the IP ANG QPD readbacks.  There was a large DC shift.    We'll watch and see how much it drifts in this state.

  2104   Fri Oct 16 13:25:18 2009 KojiSummaryLSCfunny timing setup on the LSC

Could be this.

http://ilog.ligo-la.caltech.edu/ilog/pub/ilog.cgi?group=detector&task=view&date_to_view=10/02/2009&anchor_to_scroll_to=2009:10:02:13:33:49-waldman

Quote:

We should be able to diagnose timing noise between the OMC and the LSC by putting in a signal in the OMC and looking at the signal on the LSC side. Should be a matlab script that we can run whenever we are suspicious of this. This is an excellent task for a new visiting grad student to help learn how to debug the digital control system.

 

  2103   Fri Oct 16 12:40:59 2009 KojiConfigurationGeneralSome questions

Some questions came arise to me:

A. How the green injection system should be? How the handing off between 532 and 1064 should be?

This is not new, though. It would be worth reminding.

B. Do we still need PMC if we use 2W innolight?

Innolight has low intensity noise at the detection freq. Also the spacial mode is clean.

C. Do we still need frequency prestabilization by RC?

Is the stabilization of the laser freq by the MC not enough?
What is the relationship with the green?

  2102   Fri Oct 16 10:15:02 2009 steveUpdateIOOIP ang & pos recentered

Pointing stability of 4 days. Initial pointing does not go through suspended optics. It is launched  right after the Piezo Jena steering mirrors in the BS chamber.

IP-ANG on epics screen is  C1:ASC-IBQPD_X and Y in dataviewer  were recentered. This beam is clipping a bit in ETMX chamber  pick off mirror.

IP-POS pick  off is in the BS chamber and it's qpd on the BS_ISCT This beam is also clipping just a little bit. This is easy to fix. We'll have to remove an iris from the BS optical levers table.

note: arms were not locked when I recentered

  2101   Fri Oct 16 03:16:50 2009 rana, robSummaryLSCfunny timing setup on the LSC

While measuring the Piezo Jena noise tonight we noticed that the LSC timing is setup strangely.

Instead of using the Fiber Optic Sander Liu Timing board, we are just using a long 4-pin LEMO cable which comes from somewhere in the cable tray. This is apparent in the rack pictures (1X3) that Kiwamu has recently posted in the Electronics Wiki. I think all of our front ends are supposed to use the fiber card for this. I will ask Jay and Alex what the deal is here - seems like to me that this can be a cause for timing noise on the LSC.

We should be able to diagnose timing noise between the OMC and the LSC by putting in a signal in the OMC and looking at the signal on the LSC side. Should be a matlab script that we can run whenever we are suspicious of this. This is an excellent task for a new visiting grad student to help learn how to debug the digital control system.

  2100   Thu Oct 15 17:12:00 2009 ranaSummaryLockingnever had it so good

 

  2099   Thu Oct 15 12:57:23 2009 ZachUpdatePSLinventory

Quote:

I'm at the PSL table taking inventory of the elements I don't have down yet.

 OK, I'm out--hopefully for good. HEPAs back at 20%.

  2098   Thu Oct 15 12:35:09 2009 ZachUpdatePSLinventory

I'm at the PSL table taking inventory of the elements I don't have down yet.

  2097   Thu Oct 15 09:23:07 2009 steveSummaryLockingnever had it so good

Awesome 5 hrs of locking  Rob!

  2096   Thu Oct 15 02:41:04 2009 ranaUpdateCOCChoice of folding mirrors in the RC cavities

In addition to the main mirrors (PRM, SRM) we will also have fold mirrors (called PR1, PR2, SR1, SR2). I am curious to see if we can get away with just using commercial optics; I think that the CVI Y1S coatings may do the trick.

Picture_9.png

The above plots show the reflectivities v. wavelength. I've asked the sales rep to give us specs on the reflectivity v. angle. I bet that we can guess what the answer will be from these plots.

  2095   Thu Oct 15 02:38:10 2009 rana, robUpdateOMCDark Port Mode Scan using the OMC

Bottom trace is proportional to the OMC PZT voltage - top trace is the transmitted light through the OMC. Interferometer is locked (DARM- RF) with arm powers = 80 / 100. The peaks marked by the cursors are the +(- ?) 166 MHz sidebands.

  2094   Thu Oct 15 01:21:31 2009 ranaSummaryCOCThermal Lensing in the ITM

Thermal lensing formula:

Untitled.png

from (T090018 by A. Abramovici (which references another doc).

In the above equation:

w        1/e^2 beam radius

k        thermal conductivity (not the wave vector) = 1.3 W / m/ K

alpha    absorption coefficient (~10 ppm/cm for our glass)

NP       power in the glass (alpha*NP = absorbed power)

dn/dT    index of refraction change per deg  (12 ppm/K)

d        mirror thickness (25 mm for all of our SOS)

I'm attaching a plot showing the focal length as a function of recycling cavity power for both our current MOS and future SOS designs.

I've assumed a 10 ppm/cm absorption here. It may actually be less for our current ITMs which are made of Heraeus low absorption glass - our new ITMs are Corning 7980-A (measured to have an absorption of 13 ppm/cm ala the iLIGO COC FDD). I expect that our thermal lens focal length will always be longer than 1 km and so I guess this isn't an issue.

  2093   Wed Oct 14 23:02:41 2009 ranaUpdateLockingdaytime locking

This is huge.    Five hours of lock only interrupted by intentional break from transfer function abuse.

  2092   Wed Oct 14 16:59:37 2009 robUpdateLockingdaytime locking

The IFO can now be locked during the daytime.  Well, it's locked now.

  2091   Wed Oct 14 15:48:26 2009 MottHowToGeneralPhase Noise measurement

I have gotten the hang of the procedure for measuring phase noise on the AOMs. 

Koji suggested I right up a short guide (wiki page?) on how to do this. 

I will finish up here, then go measure the AOMs at the other lab (may have to be tomorrow, after laser safety), and then write up the instructions.

  2090   Tue Oct 13 10:50:58 2009 ZachUpdatePSLone more time

Quote:

I am at the PSL table taking what is hopefully the last set of pictures for the diagram. Woohoo.

 I'm out, HEPAs are back at 20%.

  2089   Tue Oct 13 10:31:11 2009 ZachUpdatePSLone more time

I am at the PSL table taking what is hopefully the last set of pictures for the diagram. Woohoo.

  2088   Mon Oct 12 22:15:15 2009 ranaConfigurationPSLStray beam blocking

You can remove the RFAM measuring setup. Once we upgrade, we will no longer have a MZ or the related problems.

  2087   Mon Oct 12 20:01:13 2009 KojiConfigurationSAFETYStray beam blocking

OK! I saw the optics are redundant and some of the components are not in a right place.
I will talk with you when you are back such that we can keep the usefulness of the setup.

Quote:

 These components are from when Rana and I used the StochMon PD to do the RFAM tuning, documented in elog 1926.  This was a very handy measurement, but I'm not sure if whether or not we need it often enough to keep the optics there.

 

  2085   Mon Oct 12 19:53:44 2009 KojiConfigurationSAFETYStray beam blocking
I aligned the EOM and the beam to the PMC.
The beam is still hitting the bottom of the EOM aperture,
but the further lowering the EOM reduces the PMC transmission.
So I put my compromise.

The work restored the PMC transmission to over 2.4.

Finally I centered the beams on to the MC WFSs.
As a result, the MC Trans recovered 7.5.
  2084   Mon Oct 12 18:38:07 2009 JenneConfigurationSAFETYStray beam blocking

Quote:

Steve, Kiwamu, and Koji

We went through the PSL table to make sure any strong beam did not hit the wall.

We found that the reflection of Stephanie's OSA returned its path down to the beamsplitter.
This BS reflect that beam to the wall. That was fixed.

The surprising was that the relatively strong beam (~1mW?) went through the steering mirror
just before the PMC. We put thorlabs razor blades. I am still thinking what this indicates...
because the beam had been blocked if it was such from long time before.

During the work we found some stray optics such as a cube BS, a flipper mirror, and so on.
We can see them in the photo as those enclosed with yellow circles.
One of the beams was obtained from the reflection of the ND filter (...almost illeagal), and 
was even hittting a metal fixture for the BS cube.

If someone uses these components for useful purposes,
please let me(Koji) know. Otherwise, they are removed next week.

The other thing we found was the bright scatter from the EOM for the PMC.
As this scatter is so blight, I am going to align it.

 These components are from when Rana and I used the StochMon PD to do the RFAM tuning, documented in elog 1926.  This was a very handy measurement, but I'm not sure if whether or not we need it often enough to keep the optics there.

  2083   Mon Oct 12 18:37:55 2009 ZachUpdatePSLInventory

--Apologies for the late post--

I was at the PSL table taking an inventory of the components for a while after Koji, Steve, and Kiwamu were there. I set the HEPAs back to 20% when I left (assuming that they were turned up when the compartment was opened).

ELOG V3.1.3-