40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 50 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  8683   Wed Jun 5 17:37:10 2013 ranaUpdateGeneralfast 2004 qpd

Quote:

Thank you Ben Abbott forwarding this information:

 QPD Amplifier D990272 https://dcc.ligo.org/cgi-bin/private/DocDB/ShowDocument?.submit=Number&docid=D990272&version= at the X-end.  It plugs into a Generic QPD Interface, D990692, https://dcc.ligo.org/cgi-bin/private/DocDB/ShowDocument?.submit=Number&docid=D990692&version= according to my drawings, that should be in 1x4-2-2A.

 Wrong: this is not an interface.

  9899   Fri May 2 03:51:29 2014 ranaUpdateLSCfarther into CM

Rana, Q

After some more matlab loopology (see Qlog), we turned on the AO path successfully. The key was to turn on the 300:80 filter in the MCL path so that it could cross stably with the AO. Then we ramp up the AO gain via the newly AC coupled AO path into the MC servo board.

The POY11 signal looks nice and smooth. For the final smoothness after the overall common gain is ramped up, I turned on a FM7 pole at 300 Hz so that the MC path would keep falling like 1/f^2 and not interfere with the AO path around 1 kHz.

There's not enough gain yet to be able to turn on the Boost. PCDRIVE is ~3 V. Earlier tonight we were seeing the EOM saturation effect maybe, but we re-allocated the gain more to the front end and its all fine now. I think we can get another ~10-15 dB of gain by using the POY whitening gain slider + the CM AO slider. Then we can get the Boost on and take some TFs with the SR785 (as long GPIB allows).

Good Settings:

CM REFL1 = +31 dB, AO = +16 dB, MC IN2 = +16 dB. SUS-MC2_LSC = FM6, FM& ON

 

** Everything has been pretty stable tonight except some occasional MC/EOM locking oscillations. This means that its been easy to keep trying some different CM steps since the Y-Arm relocks using MCL within seconds.

Attachment 1: MCkicked.png
MCkicked.png
  9908   Sun May 4 22:28:54 2014 ericqUpdateLSCfarther into CM

 [Rana, ericq]

Today, we got a ~2kHz bandwidth lock of the YARM with the AO path. We weren't able to turn any boosts on, due to POY noise. 

Rana and Koji have written scripts (/scripts/PRFPMI/cm_step and cm_down) that work very reliably. 

Here is an OLTF. (Violin filter was off, the crap around 600Hz goes away with them on)

 OLTF.png

My MATLAB modeling was useful is predicting the features of the loop shape, and the dependence on AO gain/crossover. Still, I need to check it out, because there is nonzero discrepancy between reality and my model (this may be hiding in the non flat MC AO response, i.e. the bump at ~35kHz. Alternatively, the crossover frequency is a free parameter...)

In any case, we have confidence that the CM board is mostly working predictably. We presume that our current obstacle is the very noisy nature of POY, and thus it's not worth spending more time in this configuration. 

Upcoming plans:

  • Use the CM board to control the Y arm coupled with the PRM. ("PRY"?)
  • Determine the game plane for high BW control of CARM. 

Next steps:

  • Check CM board boosts turn on politely (Transients, TFs)
  • Use fast spectrum analyzer to check MC loop gain out to a few MHz. (The bump in the tens of kHz should be fixed / moved higher)
  • Think about noise performance of, say, REFLDC, ASDC, RF AS signals, etc. in the PRY case, figure out which one to use first. 
  • We may want to first focus on directly locking the arm on an RF signal, figure out gains etc. and then figure out how to do DC->RF handoff nicely, or if high bandwidth DC signal control is even feasible. 

RXA: we should also use AS45 instead of POY11. It has better SNR and I think our whole problem is too little light on POY.

  9913   Tue May 6 03:17:15 2014 ranaUpdateLSCfarther into CM

Yes, we still need to do these things, day team. Please tune up the MC loop first, before anything else.

Quote:

Next steps:

  • Check CM board boosts turn on politely (Transients, TFs)
  • Use fast spectrum analyzer to check MC loop gain out to a few MHz. (The bump in the tens of kHz should be fixed / moved higher)
  • Think about noise performance of, say, REFLDC, ASDC, RF AS signals, etc. in the PRY case, figure out which one to use first. 
  • We may want to first focus on directly locking the arm on an RF signal, figure out gains etc. and then figure out how to do DC->RF handoff nicely, or if high bandwidth DC signal control is even feasible.  

  9917   Tue May 6 17:58:44 2014 ericqUpdateLSCfarther into CM

 I took a look at the MC OLTF and AO path TFs with the fast agilent analyzer. 

I played with the relative gain of the EOM and PZT, but couldn't really change the MC OLTF shape much without making the PC Drive RMS angry. 

However, it turns out we have plenty of phase headroom to up the MC UGF from ~100kHz to ~180, with about 40 degrees of phase margin and ~7dB of gain margin. As I write this, PC drive RMS is around 1.1, and FSS Fast at 5.6, so I think the extra gain is fine for now. 

This pushes up and smoothens out the gain peaking in the AO path; see this figure:

AOTFs.pdf

(why does ELOG hate my python plots?! argggg)

Rana's rule of thumb was "We need at least +3dB MC loop gain at our CM servo UGF," so it looks like high tens of kHz bandwidth may be doable from the AO standpoint.

RXA: No, no, no, no, no, noooo. Rana said we need a gain of 3-10 at the CM UGF, not +3 dB.

  9822   Thu Apr 17 11:00:54 2014 jamieUpdateCDSfailed attempt to get Dolphin working on c1ioo

I've been trying to get c1ioo on the Dolphin network, but have not yet been successful.

Background: if we can put the c1ioo machine on the fast Dolphin IPC network, we can essentially eliminate latencies between the c1als model and the c1lsc model, which are currently connected via a rube goldberg-esq c1lsc->dolphin->c1sus->rfm->c1ioo configuration.

Rolf gave us a Dolpin host adapter card, and we purchased a Dolphin fiber cable to run from the 1X2 rack to the 1X4 rack where the Dolphin switch is.

Yesterday I installed the dolphin card into c1ioo.  Unfortunately, c1ioo, which is Sun Fire X4600, and therefore different than the rest of the front end machines, doesn't seem to be recognizing the card.  The /etc/dolphin_present.sh script, which is supposed to detect the presence of the card by grep'ing for the string 'Stargen' in the lspci output, returns null.

I've tried moving the card to different PCIe slots, as well as swapping it out with another Dolphin host adapter that we have.  Neither worked.

I looked at the Dolphin host adapter installed in c1lsc and it's quite different, presumably a newer or older model.  Not sure if that has anything to do with anything.

I'm contacting Rolf to see if he has any other ideas.

  4719   Sun May 15 12:42:29 2011 kiwamuUpdateSUSf2p ratio adjutment done for all the suspensions

The f2p adjustment for all the suspensions are done (except for MC1,2,3)

Attachment 1: f2p_summary.pdf
f2p_summary.pdf f2p_summary.pdf f2p_summary.pdf f2p_summary.pdf f2p_summary.pdf f2p_summary.pdf f2p_summary.pdf
  4762   Mon May 23 18:10:41 2011 kiwamuUpdateLSCf2p filters on PRM : not good

During the DRMI trial I noticed that the f2p filters on PRM is not quite effective (i.e. pushing PRM in POS direction makes misalignments).

I checked the f2p filters in an easy way. I pushed POS at 0.01 Hz with an amplitude of 1000 counts and looked at the oplev error signals with / without the f2p filters.

The picture below is a time series of the POS excitation, the oplev's PITCH and YAW error signals.

You can see there still is a big coupling from POS to YAW after the f2p filters were enabled. (Its supposed to be like this)

I will redo the f2p measurement on PRM.

f2p_PRM.png

  4688   Wed May 11 11:44:52 2011 kiwamuUpdateSUSf2p filters installed on ITMY

New f2p filters were installed on ITMY this morning. The statistical error of the coil gain setttigs are about 0.6 % at high frequency.

NEXT : PRM, SRM, BS, ITMX and ETMX.

 

f2p_itmy.png

 Pendulum mode = 0.988 Hz, Q = 1

C1:SUS-ITMY_ULCOIL_GAIN = 1.02482

C1:SUS-ITMY_URCOIL_GAIN = -1.06831

C1:SUS-ITMY_LLCOIL_GAIN = -0.996671

C1:SUS-ITMY_LRCOIL_GAIN = 0.91079

UL: fz = 1.014824 Hz, Q = 1.027150

UR: fz = 0.975038 Hz, Q = 0.98688

LL: fz = 1.000229 Hz, Q = 1.012378

LR: fz = 0.972688 Hz, Q = 0.946116

Quote from #4682

New f2p filters were installed on ETMY. 

The coil imbalances are now about 0.8% at high frequency (i.e. above the resonant freq of the pendulum mode)

  4682   Tue May 10 22:56:17 2011 kiwamuUpdateSUSf2p filters installed on ETMY

New f2p filters were installed on ETMY. 

The statistical error of the coil gain settings are now about 0.8% at high frequency (i.e. above the resonant freq of the pendulum mode)

 What I did :

 -   measured and corrected the coil imbalances on ETMY using a script called F2P_LOCKIN.py

 -   made the new f2p filters based on the measurements and installed them.

  Next step :

 -  do the same adjustment for all the suspensions including PRM, SRM, BS, ITMs and ETMs

 


(Notes on F2P_LOCKIN.py)

 F2P_LOCKIN.py is a script that I've made in python. This is basically the same as the old script, f2pratio, but uses the realtime LOCKINs instead of ezcademods.

The script automatically measures the coil imbalances on an optics of interest by driving the local LOCKIN oscillators.

In the first step the script automatically balances the coil gains at high frequency (8.5Hz).

In the next step it gives some coefficients, which basically represent the coil imbalances at low frequency (0.01Hz)

Then with those coefficients one will be able to design the f2p filters.

It is not well polished yet, so I will spend some more times to make it user-friendly and readable.

Example usage : F2P_LCKIN.py -o ETMX

It currently resides in /cvs/cds/rtcds/caltech/c1/scriptss/SUS/

 

(new f2p filters)

The plot below shows the new f2p filters. Note that they are already installed.

f2p_etmy.png

Pendulum mode = 0.982 Hz (according to the wiki)
Q of the pendulum mode = 1 (to avoid ringing of IIR filters)
C1:SUS-ETMY_ULCOIL_GAIN = -0.793435
C1:SUS-ETMY_URCOIL_GAIN = 1.16877
C1:SUS-ETMY_LLCOIL_GAIN = 1.25028
C1:SUS-ETMY_LRCOIL_GAIN = -0.730704
UL_fz = 0.965125
UR_fz = 1.029517
LL_fz = 0.934231
LR_fz = 0.996562
UL_Qz = 0.982816
UR_Qz = 1.048388
LL_Qz = 0.951356
LR_Qz = 1.014829
  4326   Fri Feb 18 18:46:08 2011 kiwamuSummarySUSf2p done on ETMX and ITMX

The f2p measurements are done on ETMX and ITMX with the real time lockin systems.

I don't explain what is the f2p measurement in this entry, but people who are interested in it can find some details on an old elog entry here or somewhere on DCC.

So far the resultant filters looked reasonable compared with the previous SRM f2p filters.

 

- backgrounds -

  Some times ago I found that the coils on ETMX had not  been nicely balanced, and it made a POS to angle coupling when I tried green locking (see here).

In addition to that, accuracy of A2L kind of measurement including the dithering techniques depend on how well the coils are balanced.  Therefore we need to balance the coils basically at all the suspended optics.

There used to be a script for this particular purpose, called f2praio.sh. This script does measure the imbalances and then balance the coils.

However this time I used the realtime lockin system to measure the imbalances instead of using the old f2p script.

One of the reasons using the real time system is that,  some of the ezca and tds commands for the old script don't work for some reasons.

Therefore we decided to move on to the real time system like Yuta did for the A2L measurement a couple of months ago.

The f2p measurement finally gives us parameters to generate a proper set of filters for POS and also the coil gains. We apply those filters and the gains in order to eliminate the POS to angle coupling and to balance the coils.

 

- results -

The followers are the resultant filters and coil gains.

The plots below show new f2p filters according to the measurement.

f2p_ITMX.png       f2p_ETMX.png

 

ITMX (assuming pendulum POS has f0 = 1 Hz and Q = 1)

ULPOS  fz = 1.009612   Qz = 1.009612 

URPOS fz = 1.125965   Qz = 1.125965  

LLPOS  fz = 0.873725   Qz = 0.873725    

LRPOS  fz = 0.974418   Qz = 0.974418  

C1:SUS-ITMY_ULCOIL_GAIN      -1.103044

C1:SUS-ITMY_URCOIL_GAIN      0.884970

C1:SUS-ITMY_LLCOIL_GAIN      0.950650

C1:SUS-ITMY_LRCOIL_GAIN      -1.060326

 

 

ETMX (assuming pendulum POS has f0 = 1 Hz and Q = 1)

ULPOS  fz = 1.055445   Qz = 1.055445   

URPOS  fz = 1.052735   Qz = 1.052735   

LLPOS  fz = 0.944023   Qz = 0.944023   

LRPOS  fz = 0.941600   Qz = 0.941600   

C1:SUS-ETMX_ULCOIL_GAIN      -0.887550

C1:SUS-ETMX_URCOIL_GAIN      1.106585

C1:SUS-ETMX_LLCOIL_GAIN = 1.07233

C1:SUS-ETMX_LRCOIL_GAIN      -0.931013

  

The precision of the coil gains looked something like 1% because every time I ran the measurement script, the measured imbalances fluctuated at this level.

The precision of the filter gain at DC (0.01 Hz) could be worse, because the integration cycles for the measurement are fewer than that of the coil gains done at high frequency (8.5 Hz).

Of course we can make the precisions by increasing the integration cycles and the excitation amplitudes, if we want to.

  5435   Fri Sep 16 16:29:05 2011 kiwamuUpdateSUSf2a filters on SRM

New f2a filters were installed on SRM.

The lock of DRMI should be more stable than last night.

Quote from #5417

Once the SRM oplev project settles down, I will adjust the f2a filters on SRM too.

 

Attachment 1: F2ASRM_Sep16.png
F2ASRM_Sep16.png
  5452   Mon Sep 19 01:07:32 2011 kiwamuUpdateSUSf2a filters on ITMs and ETMX

The f2a filters were installed on ITMs and ETMX.

Now all of the suspensions has the f2a filters.

Attachment 1: f2a_ITMX.png
f2a_ITMX.png
Attachment 2: f2aITMY.png
f2aITMY.png
Attachment 3: f2a_ETMX.png
f2a_ETMX.png
  5417   Thu Sep 15 15:11:38 2011 kiwamuUpdateSUSf2a filters on BS and PRM

The f2a filters were newly designed and installed on BS and PRM.

So the lock of PRMI will be more stable .

Once the SRM oplev project settles down, I will adjust the f2a filters on SRM too.

Attachment 1: PRMf2a.png
PRMf2a.png
Attachment 2: BS_f2a.png
BS_f2a.png
  2273   Mon Nov 16 15:13:25 2009 josephbUpdateComputersezcaread updated to Yoichi style ezcawrite

In order to get the gige camera code running robustly here at the 40m, I created a "Yoichi style" ezcaread, which is now the default, while the original ezcaread is located in ezcaread.bin.  This tries 5 times before failing out of a read attempt.

  2734   Tue Mar 30 11:16:05 2010 josephbHowToComputersezca update information (CDS SVN)

I'd like to try installing an updated multi-threaded ezca extension later this week, allowing for 64-bit builds of GDS ezca tools, provided by Keith Thorne.  The code can be found in the LDAS CVS under gds, as well as in CDS subversion repository, located at 

https://redoubt.ligo-wa.caltech.edu/websvn/

Its under gds/epics/ in that repository.  The directions are fairly simple:

1) to install ezca with mult-threading in an existing EPICS installation
-copy ezca_2010mt.tar.gz (EPICS_DIR)/extensions/src
-cd (EPICS_DIR)/extensions/src
-tar -C -xzf ezca_2010mt
-modify (EPICS_DIR)/extensions/Makefile to point 'ezca' at 'ezca_2010mt'
-cd ezca_2010mt
-set EPICS_HOST_ARCH appropriately
-make


 

 

  1356   Wed Mar 4 17:59:14 2009 YoichiConfigurationComputersezca tools and tds tools work around
Some of ezca commands and tds commands sporadically fail with a segmentation fault on linux machines.
As far as I know, ezcawrite, ezcastep, ezcaswitch, and tdswrite have this problem.
These are commands to write values into epics channels. So usually people do not check the exit status of those commands in their scripts.
This could cause incomplete execution of, for example, down scripts.
Ideally, this problem should be fixed in the source codes of the problematic commands.
However, I don't have a patience to wait it to happen, and I needed to fix these problems immediately for the lock acquisition.
So I resorted to a hacky solution.
I renamed those commands to *.bin, e.g. ezcawrite -> ezcawrite.bin.
Then wrote wrapper scripts to repeatedly call those commands until it succeeds.
For example, ezcawrite now looks like,
#!/bin/csh -f
setenv POSIXLY_CORRECT
while (! { ezcawrite.bin $* })
      echo "Retry $0 $*"
end
So, when ezcawrite.bin fails, the command retries it and show a message "Retry ....".

If you need to call the original commands, you can always do so by adding ".bin" at the end of the command name.
Currently the following commands are wrapped.
ezcawrite, ezcaservo, ezcastep, ezcaswitch, tdswrite, tdssine.

Please let me know if you have any trouble with this.
  1368   Fri Mar 6 18:26:37 2009 YoichiConfigurationComputersezca tools and tds tools work around
I updated the wrapper scripts so that they do not retry more than 6 times.
Otherwise, the wrapper scripts loop over infinitely when you give wrong arguments.



Quote:
Some of ezca commands and tds commands sporadically fail with a segmentation fault on linux machines.
As far as I know, ezcawrite, ezcastep, ezcaswitch, and tdswrite have this problem.
These are commands to write values into epics channels. So usually people do not check the exit status of those commands in their scripts.
This could cause incomplete execution of, for example, down scripts.
Ideally, this problem should be fixed in the source codes of the problematic commands.
However, I don't have a patience to wait it to happen, and I needed to fix these problems immediately for the lock acquisition.
So I resorted to a hacky solution.
I renamed those commands to *.bin, e.g. ezcawrite -> ezcawrite.bin.
Then wrote wrapper scripts to repeatedly call those commands until it succeeds.
For example, ezcawrite now looks like,
#!/bin/csh -f
setenv POSIXLY_CORRECT
while (! { ezcawrite.bin $* })
      echo "Retry $0 $*"
end
So, when ezcawrite.bin fails, the command retries it and show a message "Retry ....".

If you need to call the original commands, you can always do so by adding ".bin" at the end of the command name.
Currently the following commands are wrapped.
ezcawrite, ezcaservo, ezcastep, ezcaswitch, tdswrite, tdssine.

Please let me know if you have any trouble with this.
  274   Sat Jan 26 18:12:45 2008 ranaHowToComputersextra processes and crashes
There were a load of extra processes on op440m; they were all related to rogue DV processes (frameMemRead, framer4, xmgrace, etc.)

You can check this by running top. IF there's lots of them you can kill them by using 'pkill'.

I'm attaching the screen cap of a 'top' session. You can also see that the cron of updatedb is running and taking upp all the CCPU. Thee result is that the delay puts misspellings and doouble characters intoo my elog entry. Clearly wwe'll have to fix the cron setup.
  2066   Wed Oct 7 20:32:21 2009 ranaUpdateAdaptive Filteringextra delay and noise in PEM -> ASS/OAF system

[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.

Attachment 1: a.gif
a.gif
  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.

Attachment 1: PEM-timing_19Oct2009.png
PEM-timing_19Oct2009.png
  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...

 

Attachment 1: PEM_timingDealy_19OCT09_MCL2PEM2.png
PEM_timingDealy_19OCT09_MCL2PEM2.png
  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)."

  6695   Sun May 27 23:15:22 2012 DenUpdatePEMexperiments with seismometers

I wondered if linoleum is a reason of high Guralp noise. I measured Guralp noise in 3 cases: they stand on a very soft piece of paper, linulium and stone.

DSC_4309.JPG               DSC_4310.JPG                  DSC_4311.JPG

I've calibrated the noise to units m/s/sqrt(Hz). Using soft paper we get the worst noise, stone - the best, but noises do not differ that much and still much worse then declared noise in the manual.

loc_noise.png

  6692   Sat May 26 20:40:48 2012 DenUpdatePEMexperiments with seismic noise

I measured relative motion of 2 seismometers separated by 4, 18 and 38 feet.

DSC_4307.JPG         DSC_4308.JPG

Relative motion for difference distances between seismometers is presented below.

    psd_distance.png        ratio.png

 

Al frequencies f < fcrit relative motion becomes smaller then motion of each point. At these frequencies, the ratio relative / absolute motion can be approximated as ratio = C fa . The following table summarizes fcrit, C and a for different length between seismometers.

 

L, ft fcrit, Hz
C a
4 45 0.0074 1.30
18 30 0.0057 1.52
38 15 0.0208 1.43

Using this approximation we can estimate the desired noise floor of the seismometer to subtract seismic noise from MC_F

sim_delta.png

Desired seismometer noise should be 100 times less then Guralp's. ADC noise is still less then this level, so this will not be a problem.

Note: for longer cavities condition for seismometer noise becomes more week as fcrit decreases with length.

  6445   Mon Mar 26 16:25:44 2012 kiwamuUpdateIOOexpected v.s. measured beam profile of PRM reflection

[Suresh / Kiwamu]

 We did the 2nd round of the PRM reflection mode scan on Friday.

It seems that the PRM curvature maybe correct if we look at the vertical mode, however but the horizontal mode doesn't seem to agree with any of the expected lines.

In order to increase the reliability of the measurement, we need to confirm the beam profile of the incident beam by looking at the IP-POS beam.

Right now Suresh and Keiko are mode-scanning the IP-POS beam.

 

 


The plot below shows both the expected beam profiles (see the detail in #6444) and the actual data. 

PRMreflection.png

This plot is the same as one shown in the previous entry (#6444) with newly added actual data.
The errorbar in each data point is the standard deviation obtained by 100 times of averaging.
In this plot I made the error bars 10 times bigger in order to let them visible in the plot, so the actual deviation is much lesser than they appear.
 

(Discussion)

 The vertical profile (shown in red) seems to be close to the curve for the correct PRM case.
However the horizontal profile has a bigger waist size of about  2 mm.
While measuring the waist size Suresh and I have noticed that the rotational angle of the scan head affects the measurement by 10% or so.
Of course in each data point we tried making the incident beam normal to the scan head by rotating the scan head.
But this 10% is not big enough to explain the discrepancy in the horizontal mode.
There are some possible scenario which can distort the beam shape in the horizontal direction:
  • Clipping at some optics. (Since the beam shape looked very Gaussian, the amount of the clipping could be very slight ?)
  • Astigmatism at some optics. (Possibly in the telescope ?)

(Some distances)

DSC_4001_small.jpg
 

(Some notes)

We did the following things prior to the measurement.

  • Put a boost filter in the PRM_OLYAW to suppress the beam jitter below 1 Hz.
  • Checked the MC WFS servo loop although it looked healthy.

Quote from #6444

I have estimated how the mode profile of the PRM reflection should be, as shown in the plot blow.

A conclusion here is :

   we should be able to constrain the PRM curvature situation if measurements are precise and accurate enough with a level of less than ~ 100 um 

 

  4154   Fri Jan 14 11:29:00 2011 kiwamuUpdateLSCexpected open loop TF of X arm locking

Here shows a plot of the expected open loop transfer function (TF) for the X arm locking.

xarm_oltf.png

I assume that the delay time of the digital system associated with the ADC/DAC and the digital filtering process is ~100 usec independently from the RFM delay according to Yuta's measurement (#3961).

Also I assume the MC2 pendulum has a pole at 1Hz with Q of ~5, and the X arm has its cavity pole at ~3kHz.

When the lock acquisition takes place, we used the red curve shown above in order to avoid a big DC feedback onto MC2.

Once the X arm became resonant at TEM00, we manually switched FM3 on, which is a boost filter containing a pole at  1Hz and a zero at 50Hz in order to suppress the residual motion below 1Hz.

The expected curve for the boosted state is drawn by the blue curve in the plot. 

With this open loop TF, the UGF can be realized only around 100-300 Hz due to the phase margin condition.

This expectation of the UGF is consistent with our measurement because we obtained the UGF around 200-300Hz.

In fact above 300Hz we observed that the control became unstable and started oscillating.

 

Quote:

 (some notes)

 unWhitening filter           pole:15Hz. pole:15Hz, zero:150Hz, zero:150Hz

 C1LSC_MC_FM1   pole:1kHz, zero:10Hz

 Gain in digital control       G ~ -1

measured UGF  ~  200-300 Hz

 measured RFM delay ~ 125 usec 

 

  6444   Mon Mar 26 15:15:16 2012 kiwamuUpdateIOOexpected beam profile of PRM reflection

I have estimated how the mode profile of the PRM reflection should be, as shown in the plot blow.

A conclusion here is :

   we should be able to constrain the PRM curvature situation if measurements are precise and accurate enough with a level of less than ~ 100 um

 

In the calculation two cases are considered :

      (1) PRM has the correct curvature of  +122 m. This is shown as solid curves in the plot.

      (2) PRM has a wrong curvature of - 122 m (mirror is flipped) This is shown as dashed curves in the plot. 

expected_edit.png

The plot above shows beam radii of the PRM reflections for vertical and horizontal profiles in each case.
The x-axis is distance from PRM in meter and the y-axis is the beam radii in mm.
As for the initial beam parameter, I used the measured values (see the wiki), which are that of after the beam exits from the mode matching telescope and before it goes to PRM.
 
(1) If PRM has the correct curvature, the reflection after it passes MMT1 will have ~ 1.6 mm beam radii.
This is intuitively correct because the beam profiles should match to that of the MC exiting beam  (see the wiki), which has waist size of 1.5 - 1.6 mm if everything is perfect.
(2) When PRM is flipped, the beam starts converging at the beginning as PRM act as a convex mirror, resulting in smaller beam sizes after it comes out from the telescope.
Roughly speaking the waist sizes will be different by ~ 5 mm between those two cases, so our measurement should be more precise and accurate than this number.

Note:

 I have omitted the effect from the PRM thickness. Therefore PRM is dealt as just a curved reflector with RoC of +/- 122 m in the calculation.

 

  7154   Sun Aug 12 01:21:26 2012 steveUpdateSAFETYexit door left unlocked

Caltech security called me at 1am Sunday. Control room emergency exit door was found unlocked!

It is your responsibility to lock door if you unlocked it !

 

  7155   Sun Aug 12 10:34:45 2012 KojiUpdateSAFETYexit door left unlocked

I unlocked the door on Tuesday in order to move the red cart.
After that I confirmed that the door was locked.

Quote:

Caltech security called me at 1am Sunday. Control room emergency exit door was found unlocked!

It is your responsibility to lock door if you unlocked it ! 

 

  7669   Mon Nov 5 10:34:48 2012 SteveUpdateVACexisting vacuum documents

Quote:

Quote:

Quote:

Quote:

Apparently all of the ION pump valves (VIPEE, VIPEV, VIPSV, VIPSE) opened, which vented the main volume up to 62 mTorr.  All of the annulus valves (VAVSE, VAVSV, VAVBS, VAVEV, VAVEE) also appeared to be open.  One of the roughing pumps was also turned on.  Other stuff we didn't notice?  Bad. 

 Several of the suspensions were kicked pretty hard (600+ mV on some sensors) as a result of this quick vent wind.  All of the suspensions are damped now, so it doesn't look like we suffered any damage to suspensions.

CLOSE CALL on the vacuum system:

Jamie and I disabled V1, VM2 and VM3 gate valves by disconnecting their 120V solenoid actuator before the swap of the VME crate.

The vacuum controller unexpectedly lost control over the swap as Jamie described it. We were lucky not to do any damage! The ion pumps were cold and clean. We have not used them for years so their outgassing possibly  accumulated to reach ~10-50 Torr

I disconnected_ immobilized and labelled the following 6 valves:  the 4 large ion pump gate valves and VC1,  VC2  of the cryo pump. Note: the valves on the cryo pump stayed closed. It is crucial that a warm cry pump is kept closed!

This will not allow the same thing to happen again and protect the IFO from warm cryo contamination.

The down side of this that the computer can not identify vacuum states any longer.

This vacuum system badly needs an upgrade. I will make a list.

 While I was doing the oil change of the roughing pumps I accidentally touched the 24 V adjustment knob on the power supply.

All valve closed to default condition. I realized that the current indicator was red at 0.2A  and the voltage fluctuated from 3-13V

Increased current limiter to 0.4A and set voltage to 24V     I think this was the reason for the caos of valve switching during the VME swap.

 

 I asked Jamie to read these docs so we can do some troubleshooting while at atmosphere. We have to have the all valve closed DEFAULT condition working-tested.

I'd like to reconnect all valves after this test so the state identification software could work, including interlocks.

Posted the following documents on 40m wiki.

 

http://www.ligo.caltech.edu/~ajw/40m/40mVaccum_T000054-00.pdf
http://www.ligo.caltech.edu/~ajw/40m/40mProcedures.doc 

https://dcc.ligo.org/DocDB/0015/D000338/000/D000338-00.pdf
  9489   Wed Dec 18 15:35:48 2013 SteveUpdatePEMexcess seismic noise

This is not a test. Life can be dangerous in the 40m Control  Room.

Attachment 1: seismicCar.jpg
seismicCar.jpg
  6405   Tue Mar 13 16:40:06 2012 kiwamuUpdateLSCevolution of the sensing matrix in PRMI as a function of time: details

Here I describe the measurement of the sensing matrix.

 

Motivations

  There were two reasons why I have been measuring the sensing matrix :

  1.  I wanted to know how much each element in the sensing matrix drifted as a function of time because the sensing matrix didn't agree with what Optickle predicted (#6283).
  2.  I needed to estimate the MICH responses in the 3f demodulated signals, so that I can decide which 3f signal I should use for holding MICH.

 I will report #2 later because it needs another careful noise estimation.

 

Measurement

 In order to measure the sensing matrix, the basic steps are something like this:

  1. Excite one of the DOF at a certain frequency, where a notch filter is applied in the LSC servos so that the servos won't suppress the excitation signal.
  2. Demodulate the LSC signals (e.g. C1:LSC-REFL11_I_ERR and etc.,) by the realtime LOCKINs (#6152) at the same frequency.
  3. Calibrate the obtained LOCKIN outputs to watts/meter.
In the actual measurement I choose the frequency of the excitation signal to be at 283.1 Hz,
at which any of the LSC servos don't have gains of more than 1 and there were no particular structures in the spectra.
For the amplitude of the excitation, I usually choose it to be 1000 - 2000 counts.
Because all the actuators have response functions of approximately 10-9 / f^2 meter/counts  (#5637), the actual displacement in the excited DOF should be about 10 pm level.
Therefore the excited displacements must be always in the linear ranges and also the amplitude in counts is reasonably smaller than the DAC range.
 

LOCKIN detection

The attached cartoon below shows how the LOCKIN system works for the MICH response measurement.
In the case of the PRCL response measurement, the setup is the same except that only PRM is shaken.
Here is some notes about the LOCKIN detection.
  • The LOCKIN oscillator excites ITMs differentially
    • In order to purely excites the MICH DOF, the actuation coefficients were precisely adjusted (#6398).
    • Currently ITMY has a gain of 1, and ITMX has a gain of -0.992 for the pure MICH excitation. Those numbers were put in the output matrix of the LOCKIN oscillator.
  • The demodulation phase of the LOCKIN system was adjusted to be -22 deg at the digital phase rotator.
    • This number maximizes the in-phase signals while the quadrature-phase signals give almost zero.
    • This number was adjusted when the simple MICH configuration was applied.
  • In the demodulations, the LO signals have amplitude of 100 counts to just make the demodulated signals readable numbers.

 

lockins_MICH.png

 

Calibration of the LOCKINs

  The calibration of the LOCKIN detectors is easy because all the processes takes place in the digital land, where we know all the parameters.
In this phase the goal is to calibrate the signals into counts / meter.
To calibrate the LOCKIN output signals, the following equation is used :
 
 [The obtained LOCKIN output in counts ] = H x ADOF x CLO x CEXC x 1/2  ,
 
 where H is the response of a sensor (e.g. AS55_I, AS55_Q and so on) against a particular DOF in unit of counts / m and this the quantity which we want to measure here,
ADOF is the actuator efficiency of the DOF at the excitation frequency in unit of m/counts,
CLO is the amplitude of the local oscillator signal for demodulating the sensor signals in unit of counts,
CEXC is the amplitude of the excitation signal in unit of counts,
the last 1/2 term comes from the fact there is a low pass filter in each demodulation path. 
Therefore once we measure the response of a sensor, dividing the obtained LOCKIN output by ADOF x CLO x CEXC x 1/2 gives the calibrated response in unit of counts/meter.
  ADOF are well known as they have been measured several times (#5637).
For the MICH actuator I assumed that AMICH = 2 x (ITMY response) since they are balanced through the actuation coefficients.
Note that a confirmation of this calibration has been done
when the configuration is in the simple Michelson, where we can easily estimate the response of a sensor by letting the MICH freely swing.
 

Calibration of the responses to watts/meter

  With the calibration process described above, we obtain the sensor responses in unit of counts/m.
 Then we need to do another calibration to make them into unit of W/m.
If we think about how the RFPD signal flows, we get the following gain chain.
 
[raw response in counts/m ] = Hopt x CADC x Ldemod x GWF x Ztrans x RPD
 
Hopt  is the optical gain at a sensor which we want to calibrate. It is in unit of W/m.
CADC  is the conversion factor of the ADCs and the value is CADC = 1638.4 counts/m because their resolution is 16 bit and the range is +/-20 V.
Ldemod is the conversion efficiency of the demodulation boards in unit of V/V. I used the values which Suresh measured yesterday (#6402).
GWF is the gain of the whitening filter in unit of V/V,
Ztrans is the transimpedance gain of an RFPD in unit of V/A and I used the values summarized in (the wiki),
and RPD is the responsivity of the photo diodes and I assumed RPD = 0.75 A/W for all the RFPDs.
 
Therefore the calibration can be done by dividing the raw response value by the entire gain chain of CADC x Ldemod x GWF x Ztrans x RPD.
 

Settings and parameters

  •  LSC RF demodulation phases
    •  AS55 = 17.05 deg (minimizing the PRCL sensitivity in the Q-phase)
    •  REFL11 = -41.05 deg (maximizing the PRCL sensitivity in the I-phase)
    • REFL33 = -25.85 deg (maximizing the PRCL sensitivity in the I-phase)
    • REFL55 = 4 deg (maximizing the PRCL sensitivity in the I-phase)
    • REFL165 = 39 deg (random number)
  •  Whitening filters
    • AS55 = 30 dB
    • REFL11 = 0 dB
    • REFL33 = 42 dB
    • REFL55 = 30 dB
    • REFL165 = 45 dB
  • MICH servo
    • AS55_Q for the sensor
    • G = -5 in the digital gain
    • FM2, FM3, FM5 and FM9 actiavted
    • UGF ~ 100 Hz
    • Feedback to ITMs differentially
  • PRCL servo
    • REFL33_I for the sensor
    • G = 1 in the digital gain
    • FM2, FM3, FM4, FM5 and FM9 activated
    • UGF ~ 100 Hz
    • Feedback to PRM

Quote from #6403

Tonight I measured the sensing matrix again but this time I recorded them as a function of time using the realtime LOCKINs in the LSC front end.

I will explain some more details about how I measured and calibrated the data in another elog entry.

  6403   Tue Mar 13 07:04:55 2012 kiwamuUpdateLSCevolution of the sensing matrix in PRMI as a function of time

The punch line is -- the sensing matrix still looks strange in the PRMI configuration.

 

I have been measuring the sensing matrix of the PRMI configuration because it didn't make sense (#6283).

One strange thing I have noticed before was that all the I-phase signals showed a weird behavior -- they fluctuate too much in time series.

Tonight I measured the sensing matrix again but this time I recorded them as a function of time using the realtime LOCKINs in the LSC front end.

The attached plots are the responses (optical gains) of PRCL and MICH in watts / meter at various sensors in time series.

I will explain some more details about how I measured and calibrated the data in another elog entry.

 

PRCL.png

 MICH.png

 

  6406   Tue Mar 13 16:56:19 2012 kiwamuUpdateLSCevolution of the sensing matrix in PRMI as a function of time

Next steps:

  • Compare the obtained sensing matrix with an Optickle model. Particularly I am interested in the absolute strengths in watts/meter
  • Noise estimation of the REFL33_Q as a MICH sensor to see if this sensor is usable for holding MICH.

Quote from #6403

Tonight I measured the sensing matrix again but this time I recorded them as a function of time using the realtime LOCKINs in the LSC front end.

The attached plots are the responses (optical gains) of PRCL and MICH in watts / meter at various sensors in time series.

  6419   Wed Mar 14 21:01:36 2012 keikoUpdateLSCevolution of the sensing matrix in PRMI as a function of time

This is the simulated signals to compare with the original post #6403

 

 

PRMI configuration, PRCL signal

[W/m] Simulation Measured
REFL11 575440

 

~10000

REFL33 4571 ~50
REFL55 288400 ~5000
REFL165 891 NA
AS55 71 70

 

PRMI configuration, MICH signal

[W/m] Simulation Measured
REFL11 2290

 

~600

REFL33 36 ~4
REFL55 5623 ~200
REFL165 17 NA
AS55 6456 ~200
 

Simulated DC REFL power is 9mW (before the attenuator). AS DC is 0.3mW.

They don't agree. I suspect the PR gain for the SBs are somehow different. It is about 40 (or a bit less) in the simulation for 11MHz.

 

 

 

 

  609   Tue Jul 1 10:15:22 2008 steveUpdatePSLeventfull two days
The laser recovered from a short temp rise. The MZ was aligned and realigned. The suspentions were kicked up accidentally.
Now the computers are down.
Attachment 1: 2d.jpg
2d.jpg
  6348   Fri Mar 2 18:11:50 2012 jamieSummarySUSevaluation of eLIGO tip-tilts from LLO

[Suresh, Jamie]

Suresh and I opened up and checked out the eLIGO tip-tilts assemblies we received from LLO. There are two, TT1 and TT2, which were used for aligning AS beam into the OMC on HAM6. The mirror assemblies hang from steel wires suspended from little, damped, vertical blade springs. The magnets are press fit into the edge of the mirror assemblies. The pointy flags magnetically attach to the magnets. BOSEMS are attached to the frame. The DCC numbers on the parts seem to all be entirely lies, but this document seems to be close to what we have, sans the vertical blade springs: T0900566

We noticed a couple of issues related to the magnets and flags. One of the magnets on each mirror assembly is chipped (see attached photos). Some of the magnets are also a bit loose in their press fits in the mirror assemblies. Some of the flags don't seat very well on the magnets. Some of the flag bases are made of some sort of crappy steel that has rusted (also see pictures). Overall some flags/magnets are too wobbly and mechanically unsound. I wouldn't want to use them without overhauling the magnets and flags on the mirror assemblies.

There are what appear to be DCC/SN numbers etched on some of the parts.  They seem to correspond to what's in the document above, but they appear to be lies since I can't find any DCC documents that correspond to these numbers:

TT1: D070176-00 SN001
  mirror assembly: D070183-00 SN003
TT2: D070176-00 SN002
  mirror assembly: D070183-00 SN006
  3311   Wed Jul 28 14:54:56 2010 steveUpdateSAFETYevacuation drill at the 40m

Head count at the evacuation drill today. I checked  alarms and flashers  at room 104,102,101, 103, 105 and 107. They were really loud and bright. 

Attachment 1: P1060520.JPG
P1060520.JPG
  6226   Thu Jan 26 08:36:38 2012 steveUpdateSAFETYevacuation drill

It started with fire alarm test yesterday at 14:50 All alarms are  functioning VERY loud and their flashers are bright. Evacuation drill followed. We assembled at north west corner of the 40m building and counted 6 heads.

Nobody was left sleeping inside. Bob carried the success report of the drill to PMA office immediately.

  220   Thu Jan 3 08:53:55 2008 steveUpdateSUSetmy vs etmx
Rana have corrected sus gain damping setting of ETMY 8 days ago

gain settings: pos, pit, yaw & sd
etmx: 4,2,2,& -16
etmy: 4,2,2,& 50
Attachment 1: sus.jpg
sus.jpg
  225   Fri Jan 4 08:42:03 2008 steveUpdateSUSetmy trips again
ETMY sus damping tripped at 6am this morning
It was reset. We should put an accelerometer to the south end to see
the garbage dumping effect.
Attachment 1: etmy20m.jpg
etmy20m.jpg
Attachment 2: etmy120s.jpg
etmy120s.jpg
Attachment 3: etmysenV.jpg
etmysenV.jpg
  237   Mon Jan 14 14:41:09 2008 steveUpdateSUSetmy sus damping restored & mz relocked
Tree days trend of MZ HV drift is typical these days.
So as the etmy sus inability to hold damping for longer then 2-3 days.
Attachment 1: etmysus&mzhvtrend.jpg
etmysus&mzhvtrend.jpg
  122   Mon Nov 26 10:17:31 2007 steveOmnistructureSUSetmy sus damping restored
20 days plot is showing etmy loosing damping 4 times.
I zoomed in with each event. Three of them could of been triggered
by garbage loading just outside. However attachment 2 plot demonstrating that small earthquake or seismic event
did not tripped etmy damping.
The fourth event was preceded by a 4-5 hrs of continous rise of the rms motion at C1:SUS-ETMY_LLPD_VAR
Attachment 1: etmyrms20d.jpg
etmyrms20d.jpg
Attachment 2: etmyrmseq.jpg
etmyrmseq.jpg
  222   Thu Jan 3 09:55:11 2008 steveUpdateSUSetmy sus damping restored
ETMY watch dog was lost at midnight
Attachment 1: etmy12h.jpg
etmy12h.jpg
  254   Wed Jan 23 09:27:55 2008 steveUpdate etmy sus damping restored
Seismis event trips etmy
Attachment 1: etmysus.jpg
etmysus.jpg
  1578   Tue May 12 17:26:56 2009 peteUpdateoplevsetmy oplev quad was bad

Pete, Rob

After looking at some oplev noise spectra in DTT, we discovered that the ETMY quad (serial number 115)  was noisy.  Particularly, in the XX_OUT and XX_IN1 channels, quadrants 2 (by a bit more than an order of magnitude over the ETMX ref) and 4 (by a bit less than an order of mag).  We went out and looked at the signals coming out of the oplev interface board; again, channels 2 and 4 were noise compared to 1 and 3 by about these same amounts.  I popped in the ETMX quad and everything looked fine.  I put the ETMX quad back at ETMX, and popped in Steve's scatterometer quad (serial number 121 or possibly 151, it's not terribly legible), and it looks fine.  We zeroed via the offsets in the control room, and I went out and centered both the ETMX and ETMY quads. 

Attached is a plot.  The reference curves are with the faulty quad (115).  The others are with the 121.

 

Attachment 1: bad_oplev_quad.pdf
bad_oplev_quad.pdf
  1580   Wed May 13 03:05:13 2009 peteUpdateoplevsetmy oplev quad was bad

Quote:

Pete, Rob

After looking at some oplev noise spectra in DTT, we discovered that the ETMY quad (serial number 115)  was noisy.  Particularly, in the XX_OUT and XX_IN1 channels, quadrants 2 (by a bit more than an order of magnitude over the ETMX ref) and 4 (by a bit less than an order of mag).  We went out and looked at the signals coming out of the oplev interface board; again, channels 2 and 4 were noise compared to 1 and 3 by about these same amounts.  I popped in the ETMX quad and everything looked fine.  I put the ETMX quad back at ETMX, and popped in Steve's scatterometer quad (serial number 121 or possibly 151, it's not terribly legible), and it looks fine.  We zeroed via the offsets in the control room, and I went out and centered both the ETMX and ETMY quads. 

Attached is a plot.  The reference curves are with the faulty quad (115).  The others are with the 121.

 

 I adjusted the ETMY quad gains up by a factor of 10 so that the SUM is similar to what it was before.

  487   Mon May 19 11:49:57 2008 steveUpdateSUSetmy oplev laser replaced
The 9 years old Uniphase HeNe was replaced by a new JDSU 1103P
Power output ~3.5 mW, reflected light back on qpd ~140 microW, 12,800 counts
Andrey will get the ~2.5 mm od spot on the qpd smaller by replacing
the f1000 lens
  504   Thu May 29 16:32:09 2008 steveUpdateSUSetmy oplev is back
I relayed the optics for ETMY-oplev as shown in pictures below.
The reflected beam goes directly to the qpd
Attachment 1: P1020417.png
P1020417.png
Attachment 2: P1020420.png
P1020420.png
ELOG V3.1.3-