40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 320 of 357  Not logged in ELOG logo
ID Date Author Type Category Subject
  1886   Tue Aug 11 14:15:28 2009 StephanieUpdateGeneralMultiply Resonant EOM Update

I was able to observe the three sets of modulation sidebands created by the EOM + triply resonant circuit yesterday. Quantitative results will be posted later.

  1885   Tue Aug 11 02:15:20 2009 ClaraUpdatePEMGuralp breakout box circuit diagram

While writing my progress report, I redrew the Guralp breakout box circuit diagram with all the changes marked. Since only one hard copy exists, I thought it might be useful to post my drawing up in case it is needed for any reason. The two drawings are the same - the second has just been broken into two parts to make it easier to fit on a normal 8.5 x 11 or A4 sheet of paper. The gains for each opamp have not been marked, but they could very easily be added in if necessary. The black resistances and capacitances are the originals. All changes have been indicated in blue.

Guralp_circuit_whole.png

Guralp_circuit_broken.png

  1884   Tue Aug 11 01:21:55 2009 robUpdatePSLMZ needs some attention

the servo needs some work. 

 

2 day trend

 

Attachment 1: badMZservo.png
badMZservo.png
  1883   Mon Aug 10 20:49:13 2009 Alberto, RanaUpdatePSLPMC Mode Matching Lenses Tuning

Rana, Alberto

This afternoon we tried to improve the mode matching of the beam to the PMC. To do that we tuned the positions of the two lenses on the PSL table that come before the PMC.

We moved the first lens back an forth the without noticing any improvement on the PMC transmitted and reflected power. Then we moved the first backwards by about one cm (the order is set according to how the beam propagates). That made the things worse so we moved also the second lens in the same direction so that the distance in between the two didn't change significantly. After that, and some more adjustments on the steering mirrors all we could gain was about 0.2V on the PMC transmission.

We suspect that after the problems with the laser chiller of two months ago, the beam size changed and so the mode matching optics is not adequate anymore.

We have to replace the mode matching lenses with other ones.

 

  1882   Mon Aug 10 18:12:25 2009 JenneUpdatePEM2nd set of Guralp channels plugged into ADCU

Quote:

The second set of Guralp channels is now plugged into the PEM ADCU, into channels which are confirmed to be working.  (Method: 1Vpp sine wave into channel, check with DataViewer).

 

Direction, Channel Name, .ini chnum, BNC plug # on ADCU

Vertical: C1:PEM-SEIS_GUR_VERT, 15023, #24

N/S (should be Y when the seismometer is put in place): C1:PEM-TEMP_2, 15001, #2

E/W (should be X when the seismometer is put in place): C1:PEM-TEMP_3, 15002, #3

 

There is IFO work going on, so I don't want to rename the channels / restart fb40m until a little later, so I'll just use the old TEMP channel names for now. 

 

There is something totally wrong with the E/W channel.  I can look at all 3 channels on a 'scope (while it's on battery, so the op-amps in the breakout box aren't grounded), and VERT and NS look fine, and when I jump around ("seismic testing"), they show spikes.  But the EW channel's signal on the 'scope is way smaller, and it doesn't show anything when I jump. 

 

I might use the handheld Guralp tester breakout box to check the seismometer.  Also, a suspicion I have is that whoever put the box back in on Friday night after our final noise measurements left the inputs shorted for this one channel.  It's the 3rd channel in the set, so it would be most likely to be stuck shorted...  Investigations will ensue.

 All the channels are now good, and all the names are back to making sense. 

The problem with EW2 was in fact that the alligator clip used to short the inputs during the noise test Friday night was left in the box.  Not great, but now it's taken care of, and we have recorded data of the noise of the breakout box, so we can include that in our plots to see if we're at the limit of how good we can do at subtracting noise.

 

The channels are now named thusly:

C1:PEM-SEIS_GUR_VERT  (BNC input #24, .ini channel #15023)

C1:PEM-SEIS_GUR_EW     (BNC input #3, .ini channel #15002)

C1:PEM-SEIS_GUR_NS      (BNC input #2, .ini channel #15001)

C1:PEM-SEIS_MC1_X         (BNC input #11, .ini channel #15010)

C1:PEM-SEIS_MC1_Y        (BNC input #12, .ini channel #15011)

C1:PEM-SEIS_MC1_Z       (BNC input #10, .ini channel #15009)

C1:PEM-SEIS_MC2_Y (Ranger, which for the Huddle Test is oriented VERTICALLY)   (BNC input #4, .ini channel #15003)

 

Now we wait.....and tomorrow extract the noise of each of the seismometers from this!

 

 

  1881   Mon Aug 10 17:49:10 2009 peteUpdateComputersRCG work - plans

Pete, Koji

 

We discussed a preliminary game plan for this project.  The thing I really want to see is an ETMX RCG controller hooked into the existing frontend via reflective memory, and the 40 m behaving normally with this hybrid system, and my list is geared toward this.  I suspect the list may cause controversy.

+ copy the MDC filters into SAM, and make sure everything looks good there with DTT and SR785.

+ get interface / wiring boards from Wilson House, to go between megatron and the analog ETMX system

+ test tying the ETMX pendulum and bare-bones SAM together (use existing watchdogs, and "bare-bones" needs defining)

+ work some reflective memory magic and create the hybrid frontend

 

In parallel with the above, the following should also happen:

+ MEDM screen design

+ add non-linear bits to the ETMX MDP/MDC model system

+ make game plan for the rest of the RCG frontend

  1879   Mon Aug 10 17:36:32 2009 peteUpdateComputersRCG work. PIT, YAW, POS in MDP/MDC system

I've added the PIT and YAW dofs to the MDC and MDP systems.  The pendula frequencies in MDP are 0.8, 0.5, 0.6 Hz for POS, PIT, and YAW respectively.  The three dofs are linear and uncoupled, and stable, but there is no modeled noise in the system (yet) and some gains may need bumping up in the presence of noise.  The MDC filters are identical for each dof (3:0.0 and Cheby). The PIT and YAW transfer functions look pretty much like the one Rana recently took of POS, but of course with the different pendulum frequencies.  I've attached one for YAW.

Attachment 1: mdcmdpyaw.jpg
mdcmdpyaw.jpg
  1878   Mon Aug 10 17:27:47 2009 robConfigurationLSCTRX, TRY gain

 

These are the settings which determine the transmon (eg, TRX) amplitude, and which are updated by the matchTransMon scripts.

For the X arm

 

op440m:AutoDither>tdsread C1:LSC-TRX_GAIN C1:LSC-LA_PARAM_FLT_01 C1:LSC-LA_PARAM_FLT_00
0.0023
0.155
119.775

 

For the Y arm

op440m:AutoDither>tdsread C1:LSC-TRY_GAIN C1:LSC-LA_PARAM_FLT_04 C1:LSC-LA_PARAM_FLT_03
0.00237196
-0.116
19.9809


  1877   Mon Aug 10 16:41:31 2009 AlbertoConfigurationPSLPMC Visibility

Alberto, Rana

lately we've been trying to better understand what's preventing the arm power to get high again. Last week I tuned the MZ and the PMC but we didn't gain much, if nothing at all.
Yesterday I measured the transmissivity, the reflectivity and the visibility of the PMC.
 
From the voltages at the PMC-REFL PD when the PMC was locked and when it was out of lock I estimated the cavity visibility:
V_locked = 0.42V
V_unlocked = 1.64V -> V = (V_unlocked - V_locked) / V_unlocked = 75%

With the high power meter I measured the reflected power when the PMC was unlocked and used that to obtain the calibration of the PMC-REFL PD: 1.12V/W.

Since the locked-cavity reflected power can't be directly measured with a power meter (since that would use the cavity control signal), I estimated the reflected power by the calibration of the PMC-REFL PD. Then I measured the input and the transmitted power with a high-power meter.
Result:

P_in = 1.98W ; P_trans = 1.28W ; P_refl = 0.45W

From that I estimated that the losses account to 13% of the input power.

I checked both the new and the old elogs to see if such a measurement had ever been done but it doesn't seems so. I don't know if such a value for the visibility is "normal". It seems a little low. For instance, as a comparison, the MC visibility, is equal to a few percents.

Also Rana measured the transmitted power after locking the PMC on the TEM20-02: the photodiode on the MEDM screen read 0.325V. That means that a lot of power is going to that mode.

That makes us think that we're dealing with a mode matching problem with the PMC.

  1876   Mon Aug 10 16:37:27 2009 robUpdatePSLMZ alignment touched

I aligned the MZ.  The reflection went from .86 to .374

  1875   Mon Aug 10 15:56:12 2009 robSummaryPSLMZ bad redux

Quote:

I think the MZ pzt is broken/failing.  I'm not sure how else to explain this behavior.

 

The first bit of the time series is a triangle wave into the DC offset (output) field, over approximately the whole range (0-250V).   You can see the fringe visbility is quite small.  The triangle wave is stopped, and I then maxed out the offset slider to get to the "high" power point from the triangle wave sweep. Then for a little while with the PZT is held still, and the power still increases.  The MZ is then locked, and you can see the PZT voltage stay about the same but the power continues to rise over the next ~10 minutes or so.

 

 

 

This plot answers the previous question, and raises a new one--what the heck is MZTRANSPD?  I'd guess the pins are unconnected--it's just floating, and somehow picking up the MZ_PZT signal.

 

 

Attachment 1: badMZtrans.png
badMZtrans.png
  1874   Mon Aug 10 15:24:17 2009 robSummaryPSLMZ bad

I think the MZ pzt is broken/failing.  I'm not sure how else to explain this behavior.

The first bit of the time series is a triangle wave into the DC offset (output) field, over approximately the whole range (0-250V).   You can see the fringe visbility is quite small.  The triangle wave is stopped, and I then maxed out the offset slider to get to the "high" power point from the triangle wave sweep. Then for a little while with the PZT is held still, and the power still increases.  The MZ is then locked, and you can see the PZT voltage stay about the same but the power continues to rise over the next ~10 minutes or so.

Attachment 1: brokenMZpzt.png
brokenMZpzt.png
  1873   Mon Aug 10 15:21:15 2009 JenneUpdatePSLNon-Elogged Beam dump on the PSL table - BadBadBad

Quote:

Big thumbs down to whoever put a beam dump on the PSL table in front of the PMC yesterday afternoon without noting it in the elog

The offending beam dump has been removed, and the PMC relocked.

 Maybe it was Russell Crowe

  1872   Mon Aug 10 14:58:01 2009 JenneUpdatePEM2nd set of Guralp channels plugged into ADCU

The second set of Guralp channels is now plugged into the PEM ADCU, into channels which are confirmed to be working.  (Method: 1Vpp sine wave into channel, check with DataViewer).

 

Direction, Channel Name, .ini chnum, BNC plug # on ADCU

Vertical: C1:PEM-SEIS_GUR_VERT, 15023, #24

N/S (should be Y when the seismometer is put in place): C1:PEM-TEMP_2, 15001, #2

E/W (should be X when the seismometer is put in place): C1:PEM-TEMP_3, 15002, #3

 

There is IFO work going on, so I don't want to rename the channels / restart fb40m until a little later, so I'll just use the old TEMP channel names for now. 

 

There is something totally wrong with the E/W channel.  I can look at all 3 channels on a 'scope (while it's on battery, so the op-amps in the breakout box aren't grounded), and VERT and NS look fine, and when I jump around ("seismic testing"), they show spikes.  But the EW channel's signal on the 'scope is way smaller, and it doesn't show anything when I jump. 

 

I might use the handheld Guralp tester breakout box to check the seismometer.  Also, a suspicion I have is that whoever put the box back in on Friday night after our final noise measurements left the inputs shorted for this one channel.  It's the 3rd channel in the set, so it would be most likely to be stuck shorted...  Investigations will ensue.

  1871   Mon Aug 10 11:33:58 2009 JenneUpdatePSLNon-Elogged Beam dump on the PSL table - BadBadBad

Big thumbs down to whoever put a beam dump on the PSL table in front of the PMC yesterday afternoon without noting it in the elog

The offending beam dump has been removed, and the PMC relocked.

Attachment 1: commodusthumbsdown.jpg
commodusthumbsdown.jpg
  1870   Sun Aug 9 16:32:18 2009 ranaUpdateComputersRCG work. MDC MDP open loop transfer function

This is very nice. We have, for the first time, a real time plant with which we can test our changes of the control system. From my understanding, we have a control system with the usual POS/PIT/YAW matrices and filter banks. The outputs go to a separate real-time system which is running something similar and where we have loaded the pendulum TF as a filter. Cross-couplings, AA & AI filters, and saturations to come later.

The attached plot is just the same as what Peter posted earlier, but with more resolution. I drove at the input to the SUSPOS filter bank and measured the open loop with the loop closed. The loop wants an overall gain of -0.003 or so to be stable.

Attachment 1: a.png
a.png
  1869   Sat Aug 8 17:23:29 2009 ranaUpdatePEMoffensive 2 Hz sine wave removed

Friday, we were seeing a 2 Hz harmonic series in all of the PEM channels. Today I found that some bad person had put in a 4V (!) signal into one of the channels with a signal generator. The generator was also sneakily stuck way back inside the DCU rack. NO SECRET SIGNAL INJECTIONS!

Since the ADC has a 2Vpk range, this was saturating and putting in harmonics in all the adjacent channels. I disconnected it and turned off the function generator.

  1868   Sat Aug 8 17:19:07 2009 ranaUpdatePEMTwo Guralps plugged in, prepped for huddle test

 I found that several of the cables are unlabeled so I'm not sure what's plugged in. In the end, I found that the TEMP_2, _3, & _44 channels were working and so I plugged in anything that looked seismic into there.

TEMP_2 is now apparently the X channel of the 2nd Guralp. If someone can figure out which cable belongs to the Y channel, please plug it into TEMP_3 and then we can fix the channel names.

I also removed (gently) all of the accelerometers from MC2's chamber. This didn't break the lock, but I intentionally broke it to make sure it reacquired fine. It did and the MC TRANS QPD showed no significant shift afterwards.

Attachment 1: Untitled.png
Untitled.png
  1867   Sat Aug 8 15:08:14 2009 ranaConfigurationPSLSMOO settings updated in psl.db and SVN updated

I have added/modified SMOO settings to all of the records in psl.db appropriately. Changes checked in to SVN.

As a reminder, you should check in to the SVN all changes you make to any of the .db files or any of the .ini files in chans.

  1866   Fri Aug 7 20:43:35 2009 Clara, Jenne, Rana, JanUpdatePEMTwo Guralps plugged in, prepped for huddle test

Both Guralps and the Ranger have been placed in our nice new insulated foam box, complete with packing peanuts, in the corner between the x and y arms. The Guralp breakout box has been reinstalled and everything is plugged in in prepartion for the huddle test. However, we're having some issues with ADC channels, which will be worked out tomorrow (hopefully) so that data can be collected over the weekend.

Currently, one Guralp is plugged into the three SEIS-MC1 channels. We made new channels for the second Guralp (GUR-EW, GUR-NS, and GUR-VERT), but had issues with those. So, EW and NS have been plugged into PEM_AUDIO-MIC1 and MIC2 for the time being.

Attachment 1: Untitled.png
Untitled.png
  1865   Fri Aug 7 19:55:08 2009 steveSummaryVACopening V1 when PTP1 is broken

The swapped in 307 convectron gauge controller  is very likely to have the  RS232 connection  wired differently from the old one.

PRP gauge has now the same error message as the PTP1:  "no comm"  I would look at RS232 wiring of the PRP gauge on the broken

controller and adapt the swapped in one to communicate. The PRP was reading 620 Torr before the swap.

  1864   Fri Aug 7 19:34:40 2009 steveSummaryVACUPS failed

The Maglev is running on single phase 220V and that voltage  was not interrupted. TP1 was running undisturbed with V1 and V4 closed.

It is independent of the UPS 120V.

  1863   Fri Aug 7 18:06:24 2009 robOmnistructureVACopening V1 when PTP1 is broken

We've had a devil of a time getting V1 to open, due to the Interlock code. 

 

The short story is that if C1:Vac-PTP1_pressure > 1.0, the interlock code won't let you push the button to open V1 (but it won't close V1). 

 

PTP1 is broken, so the interlock was frustrating us.   It's been broken for a while, but this hasn't bitten us till now.

 

We tried swapping out the controller for PTP1 with one of Bob's from the Bake lab, but it didn't work. 

 

It said "NO COMM" in the C1:Vac-PTP1_status, so I figured it wouldn't update if we just used tdswrite to change C1:Vac-PTP1_pressure to 0.0.  This actually worked, and V1 is now open.  This is a temporary fix.

  1862   Fri Aug 7 17:51:50 2009 ZachUpdateCamerasCMOS vs. CCD

The images that I just posted were taken with the CMOS camera.  We switched from the CCD to the CMOS because the CCD was exhibiting much higher blooming effects.  Unlike the CCD, there is a slight background structure if you look carefully in the amplitude image, but I can correct for this consistent background by taking a uniformly exposed image by placing a convex lens in front of the CMOS.  I will then divide each frame taken of the laser wavefront by the background image. 

  1861   Fri Aug 7 17:46:21 2009 ZachUpdateCamerasThe phase camera is sort of working

Shown below are the plots of the amplitude and phase of the Mephisto laser light modulated with a chopper as a square wave at about 1 kHz.  The color bar for the phase should run from -pi to pi, and it does when I don't accidently comment out the color bar function.  Anyway, the phase is consistently pi/4 or pi/4 plus or minus pi.  Usually all three of these phases occur within the same image, as shown below.  Also, the amplitude is a factor of two or so higher than it should be where this phase jump occurs.  I think these problems are associated with the nature of the square wave.  However, there is a software bug that appears to be independent of the input data: there is a rounding error that causes the amplitude to jump to infinity at certain points.  This happened for only a dozen or so pixels so I deleted them from the amplitude plot shown below.  I am currently working on a more robust code that will use the Newton-Raphson method for nonlinear systems of equations. 

Attachment 1: ampAv.png
ampAv.png
Attachment 2: phaseAv.png
phaseAv.png
  1860   Fri Aug 7 17:05:34 2009 JenneUpdatePSLRef cav reflection PD is funky

Quote:

we have a tester cable, but you don't want it. Instead the problem is probably at the cross-connect. The D-cable goes to a cross-connect and you can probe there with a voltmeter. If the signal is good there, trace it to the ADC. Also trend for several years to see when this happened - Yoichi may know the history better.

Also, we still need to complete the FSS RFPD task list from last year.

 

 [Jenne, Ben]

I called in the reinforcements today.  Ben came over and we looked all around at all of the cross-connects and cables relating to the FSS.  Everything looks pretty much okey-dokey, except that we still weren't getting signal in the DataViewer channels.  Finally we looked at the psl.db file, which indicates that the C1:PSL-FSS_RFPDDC channel looks at channel 21 of the ADC cross connect thing.  We followed the cable which was plugged into this, and it led to a cable which was disconnected, but laying right next to the Ref Cav refl PD.  We plugged this into the DC out SMA connection of the photodiode (which had not been connected to anything), and suddenly everything was mostly golden again in dataviewer land.  RFPDDC_F now has a signal, but RFPDDC is still flat. 

 

Even though this seems to be working now, it's still not perfect.  Rob suggested that instead of having this SMA cable going from the photodiode's DC out, we should take the signal from the ribbon cable.  So I'm going to figure out which pin of the D-connector is the DC out, and take that from the cross connect to the ADC cross connect.  This will help avoid some persnickity ground loops. 

  1859   Fri Aug 7 16:53:35 2009 ClaraUpdatePEMGuralp breakout box noise, finally

After many issues, I finally have some Guralp box noise. I did not measure every single channel with high resolution at the low frequencies because that would have taken about 3 years, but I could perhaps take some faster measurements for all of them if necessary.

output_vallwr2_ns3_1.png

tp3gnd_vallwr2_ns3.png

  1858   Fri Aug 7 16:14:57 2009 robOmnistructureVACUPS failed

Steve, Rana, Ben, Jenne, Alberto, Rob

 

UPS in the vacuum rack failed this afternoon, cutting off power to the vacuum control system.  After plugging all the stuff that had been plugged into the UPS into the wall, everything came back up.  It appears that V1 closed appropriately, TP1 spun down gracefully on its own battery, and the pressure did not rise much above 3e-6 torr. 

 

The UPS fizzed and smelled burnt.  Rana will order a new, bigger, better, faster one.

 

  1857   Fri Aug 7 16:11:11 2009 steve, robConfigurationVACIFO pressure rose to 2.3 mTorr

Quote:

IFO pressure was 2.3 mTorr this morning,

The Maglev's foreline valve  V4 was closed so P2 rose to 4 Torr. The Maglev was running fine with V1 open.

This is a good example for V1 to be closed by interlock, because at 4 Torr foreline pressure the compression ratio for hydrocarbones goes down.

V4 was closed by interlock when TP2 lost it's drypump. The drypump's AC plug was lose.

To DO: set up  interlock  to close V1 if P2 exceeds 1 Torr

 

 

 

We added C1:Vac-CC1_pressure to the alarm handler, with the minor alarm at 5e-6 torr and the major alarm at 1e-5 torr.

  1856   Fri Aug 7 16:00:17 2009 peteUpdateComputersRCG work. MDC MDP open loop transfer function

Today I was able to make low frequency transfer function with DTT on megatron.  There seems to have been a timing problem, perhaps Alex fixed it or it is intermittent.

I have attached the open loop transfer function for the un-optimized system, which is at least stable to step impulses with the current filters and gains.  The next step is to optimize, transfer this knowledge to the ADC/DAC version, and hook it up to isolated ETMX.

Attachment 1: tf_au_natural.pdf
tf_au_natural.pdf tf_au_natural.pdf
  1855   Fri Aug 7 14:31:39 2009 AlbertoUpdatePSLDAQ REstarted

For some reason a few minutes ago the FB DAQ crashed and I had to restarted.

  1854   Fri Aug 7 13:42:12 2009 ajwOmnistructureComputersbackup of frames restored

Ever since July 22, the backup script that runs on fb40m has failed to ssh to ldas-cit.ligo.caltech.edu to back up our trend frames and /cvs/cds.

This was a new failure mode which the scripts didn't catch, so I only noticed it when fb40m was rebooted a couple of days ago.

Alex fixed the problem (RAID array was configured with the wrong IP address, conflicting with the outside world), and I modified the script ( /cvs/cds/caltech/scripts/backup/rsync.backup ) to handle the new directory structure Alex made.

Now the backup is current and the automated script should keep it so, at least until the next time fb40m is rebooted...

 

  1853   Fri Aug 7 11:39:13 2009 AlbertoUpdatePSLMZ Alignment
For the last couple of days we've been trying to find the cause that is preventing us to get more than 0.85 for the arm power.
After re-aligning the reference caivity yesterdau, today I went for the MZ. I slightly changed the alignment of the mirror in pitch. I was able to inrease the MZ-TRANPD to 4.8 (from about 3).
Unfortunately the same increase didn't show up at the MC transmission (that is IFO input) becasue changing the MZ also changed alignment to the MC cavity changed. A little tune of the MZ periscope was necessary to adjust the beam to the MC.
 
After all this MC-TRANS read 7.2 vs 7.0 before: no big of an improvement.
 
The arm power is still below 0.85.
 
Next step: measuring the MC length. Maybe changed a lot after the MC satellite was recently it by the people that were installing sesimometers and accelerometers on it.

 

  1852   Fri Aug 7 09:50:57 2009 steveConfigurationVACIFO pressure rose to 2.3 mTorr

IFO pressure was 2.3 mTorr this morning,

The Maglev's foreline valve  V4 was closed so P2 rose to 4 Torr. The Maglev was running fine with V1 open.

This is a good example for V1 to be closed by interlock, because at 4 Torr foreline pressure the compression ratio for hydrocarbones goes down.

V4 was closed by interlock when TP2 lost it's drypump. The drypump's AC plug was lose.

To DO: set up  interlock  to close V1 if P2 exceeds 1 Torr

Attachment 1: tp2fpfail.jpg
tp2fpfail.jpg
  1851   Fri Aug 7 00:10:14 2009 ranaUpdatePSLRef cav reflection PD is funky

we have a tester cable, but you don't want it. Instead the problem is probably at the cross-connect. The D-cable goes to a cross-connect and you can probe there with a voltmeter. If the signal is good there, trace it to the ADC. Also trend for several years to see when this happened - Yoichi may know the history better.

Also, we still need to complete the FSS RFPD task list from last year.

 

  1850   Thu Aug 6 23:29:47 2009 JenneUpdatePSLRef cav reflection PD is funky

After Alberto and I worked on aligning the reference cavity, Rob asked the important and useful question: what is the visibility of the reference cavity.  This helps tell us if we're optimally aligned or not even close.

I did a scan of the ref cav temperature, using /scripts/PSL/FSS/SLOWscan, but there seems to be no real signal is C1:PSL-FSS_RFPDDC.  As shown in Alberto's 200-day plot, it does change sometimes, but if you zoom in on the flat parts, it seems like it's not really reading anything meaningful.  I did a cursory check-out of it, but I'm not 100% sure where to go from here:  There are (as with all of these gold-box PDs) 3 outputs:  a ribbon cable (for ADC purposes I think), an SMA for the RF signal, and a BNC for the DC signal.  The photodiode is clearly working, since if you stick the Lollypop in front of the PD, the cavity unlocks.  I plugged a 'scope into the DC BNC, and it also behaves as expected: block the beam and the signal goes down; unblock the beam and the signal goes up.  Something of note is that this readout gives a positive voltage, which decreases when the beam is blocked.  However, looking at the dataviewer channel, nothing at all seems to happen when the beam is blocked/unblocked.  So the problem lies somewhere in the get-signal-to-DAQ path.  I unplugged and replugged in the ribbon cable, and the value at which the channel has been stuck changed.  Many days ago, the value was -0.5, for the last few days it's been -1.5, and after my unplug/replug, it's now back to ~ -0.5 . The other day Alberto mentioned, and made the point again today that it's a little weird that the PD reads out a negative voltage.  Hmm.

 

Do we have a tester-cable, so that instead of the ribbon cable, I can plug that connector (or pins thereof) into a 'scope?

  1849   Thu Aug 6 20:03:10 2009 KojiUpdateGeneralWe left two carts near PSL table.

Stephanie and Koji

We left two carts near the PSL table.
We are using them for characterization of the tripple resonant EOM.

  1848   Thu Aug 6 19:54:04 2009 StephanieUpdatePSLHEPAs back to normal

Quote:

Stephanie has needed the doors to the PSL open all day, and still has them open, so I just turned the HEPAs on high. 

 

 

I turned the HEPAs back down to ~50.

  1847   Thu Aug 6 18:26:26 2009 JenneUpdatePSLRef Cav and PMC aligned

[Alberto, Jenne]

We aligned both the reference cavity and the PMC, each by looking at their Trans PD on Davaviewer, and adjusting the two steering mirrors to maximize the transmission power.  We got a pretty good amount of improvement for the ref cav, but since the PMC hasn't decayed a whole lot, we got a much smaller amount of improvement.

  1846   Thu Aug 6 18:21:03 2009 ChrisUpdateGeneralDisplacement Sensor Update

Quote:

For the past week Dmass and I have been ordering parts and getting ready to construct our own modified version of EUCLID (figure).  Changes to the EUCLID design could include the removal of the first lens, the replacement of the cat's eye retroreflector with a lens focusing the beam waist on a mirror in that arm of the Michelson, and the removal of the linear polarizers.  A beam dump was added above the first polarizing beam splitter and the beam at Photodetector 2 was attenuated with an additional polarizing beam splitter and beam dump.  Another proposed alteration is to change the non-polarizing beam splitter from 50/50 to 33/66.  By changing the reflectivity to 66\%, less power coming into the non-polarizing beam splitter would be ``lost" at the reference detector (1/3 instead of 1/2), and on the return trip less power would be lost at the polarizing beam splitter (1/6 instead of 1/4).  Also, here's a noise plot comparing a few displacement sensors that are used to the shot noise levels for the three designs I've been looking at.

 I thought slightly harder and I think that the beamsplitter stays. We will lose too much power on the first PD if we do that:

33/66:  Pwr @ PD2 = 2/3*1/3*1/2 =  1/9 Pin

            Pwr @ PD3 = 2/3*2/3*1/2 = 2/9 Pin

 

50:50 Pwr @ PD2 = PWR @ PD3 = 1/8 Pin

balancing them is probably better.

  1845   Thu Aug 6 17:51:21 2009 ChrisUpdateGeneralDisplacement Sensor Update

For the past week Dmass and I have been ordering parts and getting ready to construct our own modified version of EUCLID (figure).  Changes to the EUCLID design could include the removal of the first lens, the replacement of the cat's eye retroreflector with a lens focusing the beam waist on a mirror in that arm of the Michelson, and the removal of the linear polarizers.  A beam dump was added above the first polarizing beam splitter and the beam at Photodetector 2 was attenuated with an additional polarizing beam splitter and beam dump.  Another proposed alteration is to change the non-polarizing beam splitter from 50/50 to 33/66.  By changing the reflectivity to 66\%, less power coming into the non-polarizing beam splitter would be ``lost" at the reference detector (1/3 instead of 1/2), and on the return trip less power would be lost at the polarizing beam splitter (1/6 instead of 1/4).  Also, here's a noise plot comparing a few displacement sensors that are used to the shot noise levels for the three designs I've been looking at.

Attachment 1: Actual_Sensor.png
Actual_Sensor.png
Attachment 2: Sensitivity.png
Sensitivity.png
  1844   Thu Aug 6 17:45:37 2009 JenneUpdatePSLHEPAs on high

Stephanie has needed the doors to the PSL open all day, and still has them open, so I just turned the HEPAs on high. 

  1843   Thu Aug 6 10:32:45 2009 alberto, robUpdateLockingMore PSL trends: NPRO, MOPA, FSS, PMC and MZ

 Here we trended also the PMC and the MZ. The drop in the PMC happens at the same rate as the MOPA's.

That let us think that the FSS transmitteed power has gone down because of the reference cavity progressive misalignment to the laser beam.

We need to adjust that alignment sometime.

The drop in the NPRO output power (upper row, 3rd plot: Ch10 C1:PSL_126MOPA_126MON) accompained an increase of "fuzziness" in PMCTRANSPD and both coincided in time with the day we tempoarirly removed the flap from the laser chiller's chiller (July 14 2009).

Attachment 1: 2009-08-06_PSLtrends.png
2009-08-06_PSLtrends.png
  1842   Thu Aug 6 09:33:08 2009 albertoUpdateLockingFSS Transmitted and Reflected Power Trends

 I've now also trended the MOPA output power for the last 200 days to check a possible correlation with the FSS reflected power. See attachment.

The trend shows that the laser power has decayed but it seems that the FSS reflected power has done it even faster: 30% drop in the FSS vs 7% for the MOPA in the last 60 days (attachment n.2).

Attachment 1: 2009-08-06_PSL_trends200days.png
2009-08-06_PSL_trends200days.png
Attachment 2: 2009-08-06_PSL_trends.png
2009-08-06_PSL_trends.png
  1841   Thu Aug 6 09:22:17 2009 AlbertoDAQGeneralcan't get trends

Quote:

We can't read minute trends from either Dataviewer or loadLIGOData from before 11am this morning. 

 

fb:/frames>du -skh minute-trend-frames/
 106G   minute-trend-frames

So the frames are still on the disk.  We just can't get them with our usual tools (NDS).

 

 Trying to read 60 days of minute trends from C1:PSL-PMC_TRANSPD yields:

Connecting to NDS Server fb40m (TCP port 8088)
Connecting.... done
258.0 minutes of trend displayed
read(); errno=9
read(); errno=9
T0=09-06-06-22-34-02; Length=5184000 (s)
No data output.

 

Trying to read 3 seconds of full data works.

Second trends are readable after about 4am UTC this morning, which is about 9 pm last night.

 


 Yesterday Alex started transferring the data records to the new storage unit. That prevented us from accessing the trends for a fe hours.

The process had been completed and now we can read the trends again.

  1840   Thu Aug 6 09:05:29 2009 steveUpdateVAClarge O-rings of vacuum envelope

The 40m-IFO vacuum envelope doors are sealed with dual viton O-rings and they are pumped through the annulos lines.

This allows easy access into the chambers. The compression of the o-rings are controlled by the o-ring grooves.

The OOC (output optic chamber)'s west side door has no such groove and it is sealed by just one single O-ring.

We have to protect this O-ring from total compression by 3 shims as shown below.

There were control shims in place before and they disappeared.

Let's remember that these shims are essential to keep our vacuum system in good condition.

 

Attachment 1: vacsor1.png
vacsor1.png
Attachment 2: vacsor2.png
vacsor2.png
  1839   Wed Aug 5 17:41:54 2009 peteUpdateComputersRCG work - daq fixed

The daq on megatron was nuts.  Alex and I discovered that there was no gds installation for site_letter=C (i.e. Caltech) so the default M was being used (for MIT).  Apparently we are the first Caltech installation.  We added the appropriate line to the RCG Makefile and recompiled and reinstalled (at 16K).  Now DV looks good on MDP and MDC, and I made a transfer function that replicates  bounce-roll filter.  So DTT works too.

  1838   Wed Aug 5 16:33:50 2009 steveConfigurationPSLnew PSL output iris

I installed an improvised version of PSL output beam iris at the output periscope last week.

Attachment 1: psliris.png
psliris.png
  1837   Wed Aug 5 15:57:05 2009 AlbertoConfigurationComputersPMC MEDM screen changed

I added a clock to the PMC medm screen.

I made a backup of the original file in the same directory and named it *.bk20090805

  1836   Wed Aug 5 15:33:05 2009 rob, albertoDAQGeneralcan't get trends

We can't read minute trends from either Dataviewer or loadLIGOData from before 11am this morning. 

 

fb:/frames>du -skh minute-trend-frames/
 106G   minute-trend-frames

So the frames are still on the disk.  We just can't get them with our usual tools (NDS).

 

 Trying to read 60 days of minute trends from C1:PSL-PMC_TRANSPD yields:

Connecting to NDS Server fb40m (TCP port 8088)
Connecting.... done
258.0 minutes of trend displayed
read(); errno=9
read(); errno=9
T0=09-06-06-22-34-02; Length=5184000 (s)
No data output.

 

Trying to read 3 seconds of full data works.

Second trends are readable after about 4am UTC this morning, which is about 9 pm last night.

 


ELOG V3.1.3-