40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 303 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  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.

 


  1835   Wed Aug 5 15:18:12 2009 StephanieUpdateGeneralMultiply Resonant EOM Update

Quote:

I have spent the past couple of days gathering optics and mounts so that I can observe the modulation of the EOM attached to the circuit I built using the optical spectrum analyzer (OSA). A rough diagram of the planned layout is attached.

I also built a short SMA cable so that the EOM did not have to be connected directly to the circuit box. The cable is shown attached to the EOM and circuit box in the attached photo. After checking to make sure that all of the connections in the cable were sound, I remeasured the input impedance of the circuit; the impedance measurement (black) is shown in the attached plot with the impedance before the SMA cable was added with and without the box (green and blue, respectively--these two are almost identical). The new impedance has a strange shape compared to the original measurements; I'd like to understand this a little better, since adding extra inductance in LTSpice doesn't seem to have that effect. Since I had already taken apart the setup used for the previous impedance measurements, I had to rebuild and recalibrate the setup; I guess the difference could be something about the new calibration, but I don't really think that that's the case.

 

After investigating this a bit further, I discovered that some of the components in the circuit were pressed firmly up against the inside of the box, and when they were moved, the impedance plot changed shape dramatically. I think that originally, the components were not pressed against the box, but the box's SMA joint was rather loose; when I connected this to the SMA cable, I tightened it, and this seems to have twisted the circuit around inside the box, pushing the components up against the side. I have fixed the twisting, and since the SMA joint is now tight, the circuit should no longer have any twisting problems.

A new plot is attached, showing the impedance of the circuit with nothing attached (blue), with the SMA cable and EOM attached (green), and with the EOM attached directly to it taken last friday with the old calibration of the setup (red). All three curves look roughly the same; the center peak is shifted slightly between the three curves, but the circuit with SMA and EOM is the version we'll be using, and it's central peak is close to the correct value.

Attachment 1: SMA.png
SMA.png
  1834   Wed Aug 5 11:49:49 2009 StephanieUpdateGeneralMultiply Resonant EOM Update

I have spent the past couple of days gathering optics and mounts so that I can observe the modulation of the EOM attached to the circuit I built using the optical spectrum analyzer (OSA). A rough diagram of the planned layout is attached.

I also built a short SMA cable so that the EOM did not have to be connected directly to the circuit box. The cable is shown attached to the EOM and circuit box in the attached photo. After checking to make sure that all of the connections in the cable were sound, I remeasured the input impedance of the circuit; the impedance measurement (black) is shown in the attached plot with the impedance before the SMA cable was added with and without the box (green and blue, respectively--these two are almost identical). The new impedance has a strange shape compared to the original measurements; I'd like to understand this a little better, since adding extra inductance in LTSpice doesn't seem to have that effect. Since I had already taken apart the setup used for the previous impedance measurements, I had to rebuild and recalibrate the setup; I guess the difference could be something about the new calibration, but I don't really think that that's the case.

Attachment 1: OSASetup.png
OSASetup.png
Attachment 2: SMAPic.png
SMAPic.png
Attachment 3: WithSMA.png
WithSMA.png
  1833   Wed Aug 5 09:48:05 2009 albertoUpdateLockingIFO Alignment

Quote:

After the mini boot fest that Jenne did today, I checked whether that fixed the overflow issues we yesterday prevented the alignemnt of the arms. 

I ran the alignment script for the arms getting 0.85 for TRX and 0.75 for TRY: low values.

After I ran the script ,C1SUSVME1 and C1SUSVME2 started having problems with the FE SYNC (counter at 16378). I rebooted those two and fix the sync problem but the transmitted powers didn't improve.

Are we still having problem due to MC misalignment?

I also noticed that the FSS transmitted power has been constantly decaying for the last 6 months. Only in the last month tt dropped by 15%. The laser power hasn't decayed as much, so it's probably not the cause.
Maybe this is one reason why lately of less power going to the IFO.
 
We call it FSS Transmission, but I guess we mean power transmitted TO the IFO, that is it measures the power reflected from reference cavity, right?
 
Still on the front of the FSS, the reflected power has dropped from -0.5 to -1.2. Here I also wonder about the reason of negative values for that.
 

See attachments

Attachment 1: 2009-08-09_FSStransPD.png
2009-08-09_FSStransPD.png
Attachment 2: 2009-08-09_FSreflPD.png
2009-08-09_FSreflPD.png
  1832   Wed Aug 5 09:25:57 2009 AlbertoDAQComputersfb40m is up

FB40m up and running again after restarting the DAQ.

  1831   Wed Aug 5 07:33:04 2009 steveDAQComputersfb40m is down
  1830   Tue Aug 4 23:03:56 2009 albertoUpdateLockingIFO Alignment

After the mini boot fest that Jenne did today, I checked whether that fixed the overflow issues we yesterday prevented the alignemnt of the arms. 

I ran the alignment script for the arms getting 0.85 for TRX and 0.75 for TRY: low values.

After I ran the script ,C1SUSVME1 and C1SUSVME2 started having problems with the FE SYNC (counter at 16378). I rebooted those two and fix the sync problem but the transmitted powers didn't improve.

Are we still having problem due to MC misalignment?

  1829   Tue Aug 4 17:51:25 2009 peteUpdateComputersRCG work

Koji, Peter

 

We put a simple pendulum into the MDP model, and everything communicates.  We're still having some kind of TP or daq problem, so we're still in debugging mode.  We went back to 32K in the .adl's, and when driving MDP,  the MDC-ETMX_POS_OUT is nasty, it follows the sine wave envelope but goes to zero 16 times per second.

 

The breakout boards have arrived.  The plan is to fix this daq problem, then demonstrate the model MDC/MDP system.  Then we'll switch to the "external" system (called SAM) and match control TF to the model.  Then we'd like to hook up ETMX, and run the system isolated from the rest of the IFO.  Finally we'd like to tie it into the IFO using reflective memory.

  1828   Tue Aug 4 16:12:27 2009 robUpdateComputersmini boot fest

Quote:

Last night Rana noticed that the overflows on the ITM and ETM coils were a crazy huge number.  Today I rebooted c1dcuepics, c1iovme, c1sosvme, c1susvme1 and c1susvme2 (in that order).  Rob helped me burt restore losepics and iscepics, which needs to be done whenever you reboot the epics computer.

Unfortunately this didn't help the overflow problem at all.  I don't know what to do about that.

 

Just start by re-setting them to zero.  Then you have to figure out what's causing them to saturate by watching time series and looking at spectra.

  1827   Tue Aug 4 15:48:25 2009 JenneUpdateComputersmini boot fest

Last night Rana noticed that the overflows on the ITM and ETM coils were a crazy huge number.  Today I rebooted c1dcuepics, c1iovme, c1sosvme, c1susvme1 and c1susvme2 (in that order).  Rob helped me burt restore losepics and iscepics, which needs to be done whenever you reboot the epics computer.

Unfortunately this didn't help the overflow problem at all.  I don't know what to do about that.

  1826   Tue Aug 4 13:40:17 2009 peteUpdateComputersRCG work - rate

Koji, Pete

 

Yesterday we found that the channel C1:MDP-POS_EXC looked distorted and had what appeared to be doubled frequency componenets, in the dataviewer.  This was because the dcu_rate in the file /caltech/target/fb/daqdrc was set to 16K while the adl file was set to 32K.  When daqdrc was corrected it was fixed.  I am going to recompile and run all these models at 16K.  Once the 40 m moves over to the new front end system, we may find it advantageous to take advantage of the faster speeds, but maybe it's a good idea to get everything working at 16K first.

  1825   Tue Aug 4 11:54:20 2009 JenneUpdateIOOMC_trans readout on LOCK_MC screen now normalized

The MC_trans QPD Pitch and Yaw readout on the Lock_MC screen are now normalized by the trans_sum. I used the method described in my entry elog 1488

/caltech/target/c1iool0/ioo.db now includes:

grecord(calc, "C1:IOO-MC_TRANS_P")
{
        field(INPA, "C1:IOO-MC_TRANS_VERT")
        field(INPB, "C1:IOO-MC_TRANS_SUM")
        field(SCAN, ".1 second")
        field(PREC, "3")
        field(CALC, "A/B")
}

grecord(calc, "C1:IOO-MC_TRANS_Y")
{
        field(INPA, "C1:IOO-MC_TRANS_HOR")
        field(INPB, "C1:IOO-MC_TRANS_SUM")
        field(SCAN, ".1 second")
        field(PREC, "3")
        field(CALC, "A/B")
}

 

The Lock_MC screen was changed to show these new P and Y channels. 

  1824   Tue Aug 4 11:45:29 2009 ZachUpdateCamerasGigE Phase Camera

The camera wasn't working because the router has no built-in dhcp server.  We had to manually start the server after rebooting the computer.

  1823   Mon Aug 3 22:54:53 2009 Jenne, Koji, ranaUpdateIOOMC_trans is now better, but not best

Jenne, Koji, Rana

After fixing up the Mode Cleaner a bit more (fiddling more with the MC_align sliders to get the alignment before locking, making sure that it is able to lock), we noticed that the MC Trans path could use some help. To align the MC, we put MC1 and MC3 back into the position where Rob left it on Thursday and then maximized the transmission with MC2. Then we went back and maximized with MC1/3 keeping in mind the Faraday. We got a good transmission and the X-arm had a transmission of 0.8 without us touching its alignment.

Upon looking at the AP table portion of the MC_trans path, we decided that it was all pretty bad.  The light travels around the edge of the AP table, then out the corner of the table toward the PSL table.  A periscope brings it down to the level of the PSL table, and then it travels through a few optics to the MC_trans QPD. 

The light was clipping on the way through the periscope, and so the MC_trans QPD was totally unreliable as a method of fine-tuning the alignment of the Mode Cleaner.  Ideally we'd like to be able to maximize MC_trans, and say that that's a good MC alignment, but that doesn't work when the beam is clipped.

 

Things done:

1. The first turning mirror on the AP table after the beam comes out of the vacuum was changed from a 1" optic to a 2" optic, because the spot size is ~4-6mm.  We were careful to avoid clipping the OMCT beam, by using a nifty U200 mount (C-shaped instead of ring-shaped). 

2.  We placed a lens with a RoC of 1m (focal length for 1064nm is ~2m), a 2" optic, between the first two mirrors, to help keep the beam small-ish when it gets to the periscope, to help avoid clipping.

3. Rana adjusted the angle of the upper periscope mirror, because even when the beam was centered on the steering mirror directly in front of the periscope and the spot was centered on the first periscope mirror, the beam wouldn't hit the bottom periscope mirror. 

4. We noticed that the bottom periscope mirror was mounted much too low.  It was mounted as if the optics after it were 3" high, which is true for all of the input optics on the PSL table.  However, for the MC_trans stuff, all the optics are 4".  We moved the periscope up one hole, which made it the correct height.

5. We removed the skinny beam tube which guided/protected the beam coming off the periscope after a steering mirror since it (a) wasn't necessary and (b) was clipping the beam. We cannot use such skinny tubes anymore Steve.

6. There was a lens just before the 2nd steering mirror on the PSL table portion, which we removed since we had placed the other lens earlier in the path.  2 lenses made the beam too skinny at the QPD.

7.  After this 2nd steering mirror, there had been a pickoff, to send a bit of beam at a crazy angle over to the RFAM mon, which we removed.  This results in a much brighter beam at the MC_trans QPD, and at the camera.  The QPDs readouts are now a factor of ~3.5 higher than they used to be.  These (especially the camera) could use some ND-filtering action.

8.  The steering optic directly in front of the MC_trans QPD is a beamsplitter, and instead of dumping the light which doesn't go to the MC_trans QPD, we used this to go over to the RFAM mon (instead of the pickoff which we had removed). 

9.  Koji fixed up the optics directly in front of the RFAM mon, accomodating the new position of the input light (now at a much more reasonable angle, and about 15cm farther back from the PD). Note the beam dump which is preventing the cables from the FSS board from entering the beam path. This included removing an ND filter wheel, so the RFAM mon values will all be higher now.  Koji also has the beam going to the PD going at a slight angle, so that the beam isn't directly reflected on itself, so that it can be dumped.

10. We aligned the beam onto the MC_trans QPD using the first steering mirror on the PSL table.

11. We also removed the giant wall of beam dumps separating the squeezing section of the table from the rest of the table.

Alberto will elog things about the RFAM mon, including different values of the PD output, etc.

 

Still on the to-do list:

A.  Replace the second steering mirror on the AP table after the MC_trans light leaves the vacuum with a 2" optic, since the lens we placed isn't tight enough to make the spot small there yet.  Us a U200A mount if possible, because they are really nice mounts.

B.  Put an ND filter in front of the MC_trans camera, because the image is too bright.

C.  Normalize the MC_trans QPD - the horz and vert are pretty much direct voltage readouts, with no normalization.  They should be divided by the DC value.  This lack of normalization results in higher sensitivity to input pointing.

D.  Long term, next time someone wants to optimize the MC_trans path, move all the optics, including the MC_trans QPD and the camera closer to the periscope on the PSL table.  There's no reason for the beam to be traveling nearly the full width of the PSL table when we're not manuvering around squeezing stuff.

E. Never, ever purchase these horrible U100 or U200 mounts with the full ring and the little plastic clips. They are the "AC28" version. Bad, bad, bad.

 

Image 1:  The new setup of the AP table, Mc_trans portion. 

Image 2:  New setup of the MC_trans part of the PSL table.

Attachment 1: P8030099_copy.JPG
P8030099_copy.JPG
Attachment 2: P8030102_copy.JPG
P8030102_copy.JPG
  1822   Mon Aug 3 18:56:59 2009 ZachUpdateCamerasGigE Phase Camera

While aligning the optics, we tried to start up the CCD.  Although nothing should have changed since the last time I used it, the code claimed it could not find the camera.  All the right leds are lit up.  The only indication that something is awry is that the yellow led on the camera isn't blinking as it does when there is ethernet activity.  

  1821   Mon Aug 3 14:47:53 2009 JenneUpdateIOOMC locks again

The mode cleaner seems to be locking again.  I've manually unlocked it a few times in the past 20min, and most of the time it catches lock again (maybe about 80% of the time).  Other times, it starts to lock in a bad mode, and can't fix itself, so I unlock it, and let it restart and it usually does fine the second time around. 

 

I'd like it to be a little more robust, but I'm having a bit of trouble zeroing in on the optimal alignment for quickest, most durable lock aquisition of the MC.  Right now I'm going to leave it for a little while to make sure it doesn't fall apart.

  1820   Mon Aug 3 14:15:50 2009 JenneUpdateIOOWFS recentered

I am (was) able to get the mode cleaner mostly locked, but because WFS2 wasn't centered, the MC would drift, then lose lock.  I recentered both the WFS (after unlocking the MC and the MZ), and am now about to commence relocking both of those.

 

/end{quick update}

 

Note to self:  WFS get centered based on the direct reflection from MC1.  Once the MC is close enough, the WFS are enabled, and they twiddle all 3 MC mirrors to minimize their error signal.  Moral of the story: make sure the WFS are centered.

  1819   Mon Aug 3 13:47:42 2009 peteUpdateComputersRCG work

Alex has firewalled megatron.  We have started a framebuilder there and added testpoints.  Now it is possible to take transfer functions with the shared memory MDC+MDP sandbox system.  I have also copied filters into MDC (the controller) and made a really ugly medm master screen for the system, which I will show to no one.

  1818   Mon Aug 3 12:57:09 2009 AlbertoUpdatePSLMC unlocked

Quote:

Friday afternoon the mode cleaner got unlocked. Then some adjustment of the MC1 bias sliders locked it again. The driftmon showed the excursion for pitch and yaw of MC1 becasue it wasn't updated after the change.

Tonight Rana found the MC unlocked and simply touched the sliders to bring the OSEMs back to the driftmon values.

MC1 Yaw remains different from the driftmon. If brught back to htat value, the MC would get unlocked.

More investigation is needed to understand why the MC lock hasn't been stable for the last few days.

 

 The mode cleaner is still unlocked. I played with the cable at the MC2 satellite to enusre they were all plugged in.

Then I tweaked the the mirrors alignment by the sliders and eventually I could get it locked stably with 1.3 reflection. Then I rebooted C1IOO because the WFS wouldn't engage. After that the cavity wasn't locked anymore. Trying to adjust the mirrors around their position didn't restore the lock.

More work is necessary.

I'll be back on it in a while.

  1817   Mon Aug 3 01:08:20 2009 AlbertoUpdatePSLMC unlocked

Friday afternoon the mode cleaner got unlocked. Then some adjustment of the MC1 bias sliders locked it again. The driftmon showed the excursion for pitch and yaw of MC1 becasue it wasn't updated after the change.

Tonight Rana found the MC unlocked and simply touched the sliders to bring the OSEMs back to the driftmon values.

MC1 Yaw remains different from the driftmon. If brught back to htat value, the MC would get unlocked.

More investigation is needed to understand why the MC lock hasn't been stable for the last few days.

 

  1816   Fri Jul 31 11:04:42 2009 StephanieUpdateGeneralMultiply Resonant EOM Update

I put the flying-component circuit in a box; a photo is attached. I also measured the impedance; it looks exactly the same as it looked before I put the circuit in the box.

Attachment 1: BoxPic.png
BoxPic.png
Attachment 2: BoxPic2.png
BoxPic2.png
  1815   Fri Jul 31 09:52:38 2009 StephanieUpdateGeneralMultiply Resonant EOM Update

I was able to make an impedance measurement of the flying-component circuit using Koji's method for impedance measurement. I first measured the impedance of the circuit with a 10 pF capacitor in the place of the EOM (as shown in the circuit diagram). This impedance plot is attached. I then added resistance to adjust the impedance slightly, attached the circuit to a New Focus KTP 4064 EOM, and took another impedance measurement (circuit diagram and impedance plot attached). The peaks are relatively close to 50 Ohms; they are at least the same order of magnitude.

Attachment 1: BuiltCkt2_Simplified_EOM.png
BuiltCkt2_Simplified_EOM.png
Attachment 2: ImpedanceAG4395A_with10pF.png
ImpedanceAG4395A_with10pF.png
Attachment 3: BuiltCkt2_Simplified_EOM_R.png
BuiltCkt2_Simplified_EOM_R.png
Attachment 4: ImpedanceAG4395A_withEOM.png
ImpedanceAG4395A_withEOM.png
  1814   Thu Jul 30 21:26:16 2009 ranaUpdateIOOMC Drumhead mode
I used COMSOL 3.5a to do a FEA of one of the MC flat mirrors. Should be close to the same for all the mirrors.

The model is very simple- it includes just the cylindrical shape (no magnets, curvature, or coating or bevels).
This is good enough, since we don't really know all of the material properties at the 1% level.

The attached plot shows the MC drumhead mode. The color scale shows the displacement along the optic axis.
The model predicts 28.855 kHz and the measured value was 28.2 kHz.

I used COMSOL in the multiphysics mode which includes the Structural Mechanics and Heat Transfer modules at the
same time. For the material I used the built in properties of Corning 7940 (fused silica). In reality we have
7980 (I don't know all of the material differences). In any case, this model includes the temperature dependence
of the Young's modulus, so it should be possible to use this to predict the absorption numbers.

The model file (mc2.mph) has been added to our COMSOL SVN directory.
Attachment 1: mc2drum.png
mc2drum.png
  1813   Thu Jul 30 19:55:23 2009 KojiUpdateGeneralMultiply Resonant EOM Update

Quote:

For the past couple of days I have been trying to understand and perform Koji's method for impedance measurement using the Agilent 4395A Network Analyzer (without the impedance testing kit). I have made some headway, but I don't completely understand what's going on; here's what I've done so far.

I have made several transfer function measurements using the attached physical setup (ImpedanceTestingPhysicalSetup.png), after calibrating the setup by placing a 50 Ohm resistor in the place of the Z in the diagram. The responses of the various impedances I've measured are shown in the attached plot (ImpResponses.png). However, I'm having trouble figuring out how to convert these responses to impedances, so I tried to derive the relationship between the measured transfer function and the impedance by simplifying the diagram Koji drew on the board for me (attached, ImpedanceTestingSetup.png) to the attached circuit diagram (ImpedanceTestingCktDiagram.png), and finding the expected value of VA/VR. For the circuit diagram shown, the equation should be VA/VR = 2Z/(50+Z). 50 Ohms is good to use for calibration because the expected value of the transfer function for this impedance is 1 (0 dB).

So I used this relationship to find the expected response for the various impedances, and I also calculated the impedance from the actual measured responses. I've attached a plot of the measured (red) and expected (black) response (top) and impedance (bottom) for a 1 nF capacitor (1nF.png). The expected and measured plots don't really match up very well; if I add extra inductance (7.6 nH, plots shown in blue), the two plots match up a little better, but still don't match very well. I suspect that the difference may come from the fact that for my analysis, I treated the power splitter as if it were a simple node, and I think that's probably not very accurate.

Anyway, the point of all this is to eventually measure the impedance of the circuit I created on Friday, but I don't think I can really do that until I understand what is going on a little better.

 I checked the setup and found RF reflection at the load was the cause of the unreasonable response in the impedance measurement.
So, I have put a total 22dB attenuation (10+6+6 dB) between the power splitter and the load to be measured. See the picture.
This kind of attenuators, called as PADs, is generally used in order to improve the impedance matching, sacrificing the signal amplitude at the load.

Then, It looks the measurements got reasonable up to 100MHz (at least) and |Z|<1kOhm.
For the measurements, I just followed the procedure that Stephanie described.
Stephanie has measured the impedance of her resonant circuit.


As a test of the method, I measured impedances of various discrete devices. i.e. 50Ohm, 10-1000pF Cap, Inductances, circuit opened.

a) 50Ohm (marine-blue) was calibrated to be recognized as 50Ohm.

b) The mica capacitances (orange 10pF, yellow 100pF, green 1000pF) appeared as the impedances f^-1 in the low freq region. It's nice.
At high frequency, the impedances deviate from f^-1, which could be caused by the lead inductance. (Self Resonance)
So 1000pF mica is not capacitance at 50MHz already.

c) Open BNC connector (Red) looks have something like 5pF. (i.e. 300Ohm at 100MHz)

d) I could not get good measurements with the inductors as I had 200nH (and some C of ~5pF) for a Pomona clip (blue).
This is just because of my laziness such that I avoid soldering the Ls to an RF connector!

Attachment 1: imepedance.png
imepedance.png
Attachment 2: impedance_meas.jpg
impedance_meas.jpg
  1812   Thu Jul 30 03:10:18 2009 robUpdateIOOMC tweaked further

I tilted the periscope beam and aligned the MC.  Now the spot at the Faraday entrance is near the center of the aperture in up/down space.  The arm powers are only going up to ~0.8, though.  Maybe we should try a little bit of left/right. 

I looked at the IP POS spot with a viewer card, and it looked round, so no obvious egregious clipping in the Faraday.  Someone might take a picture with one of the GigE camera and get us a beam profile there.

We no longer have an MC1 and MC3 camera view.

I can see a bright scatterer that can be seen from the east viewport of the BSC, but I can't tell what it is.  It could be a ghost beam. 

It would be nice to get an image looking into the north viewport of the IOO chamber.  I can't see in there because the BS oplev table is in the way. 

  1811   Wed Jul 29 19:46:04 2009 rana, albertoUpdatePEMDents = Bad??
It looks like the MC2 chamber and/or stack has been jarred and shifted. Please be careful and use much less force and speed around the MC2 chamber.

My guess is that the work with the accelerometers around there had made the MC2 angle and
position change last night. The reason that we don't see it in the OSEMs so much is that its
a change in the actual stack position and tilt.

To recover, we changed the MC2 alignment bias to get the beam through the Faraday. This did NOT get
the beam back onto the right place on the MC TRANS QPD. For tonight we decided to not recenter that
since Rob might not like this position. We did, however, zero out the MC WFS and the PSL POS/ANG.

If the interferometer locking is OK tonight, then we (Steve and whoever else is here at 7 AM)
should recenter IP POS and IP ANG and also fix up the PSL POS and PSL ANG QPDs. You can see
in the attached picture that there are two problems to fix:
1) The knobs (circled in red and blue) are wrapped in foil. Why???
2) The handedness of the mirror mount with the orange arrow is wrong. This should be unmounted and clocked
by 90 deg. Right now the beam is nearly clipping on the mount. Also, we need to change the channel names
on the PSL POS (or maybe its ANG). It has the horizontal/vertical channels misnamed.
  1810   Wed Jul 29 19:41:58 2009 ChrisConfigurationGeneralEUCLID-setup configuration change

David and I were thinking about changing the non-polarizing beam splitter in the EUCLID setup from 50/50 to 33/66 (ref picture).  It serves as a) a pickoff to sample the input power and b) a splitter to send the returning beam to a photodetector 2 (it then hits a polarizer and half of this is lost.  By changing the reflectivity to 66% then less (1/3 instead of 1/2) of the power coming into it would be "lost" at the ref photodetector 1, and on the return trip less would be lost at the polarizer (1/6 instead of 1/4).

 

 

Attachment 1: EUCLID.png
EUCLID.png
  1809   Wed Jul 29 19:31:17 2009 ranaConfigurationComputerselog restarted

Just now found it dead. Restarted it. Is our elog backed up in the daily backups?

  1808   Wed Jul 29 14:56:44 2009 JenneUpdatePEMMiniEarthquakes due to construction

The construction people next door seem to be getting pretty excited about pounding things lately.  At my desk the floor was shaking like a mini-earthquake, and all of the accelerometers were pretty much railed. Clara has the Guralp box out right now, so the Guralp is unplugged, but the Ranger didn't seem to be railed.

This either (a) is part of the reason the MC is being wonky lately, or (b) has nothing whatsoever to do with it.  The MC watchdogs haven't been tripping all the time, so maybe this isn't a primary cause of the wonky-ness.

In looking at a many-days/months trend to see how far back this has been going, it looks like the accelerometers are hitting their rails pretty much all day every day.  This may be significantly hindering Clara's Wiener filtering work.  I think the gain on the accelerometer's controler panel is already set to 1, but if it's set to 10, we may want to reduce that.  Alternatively, we may want to put in attenuators just as the signal is entering the PEM ADCU, to help reduce the amount of rail-hitting that's going on. I don't remember this from a couple of months ago, so this may be a problem that will go away once the construction / landscaping is done next door.

  1807   Wed Jul 29 14:22:33 2009 ZachUpdateCamerasGigE Phase Camera

This week, Joe and I have been setting up the laser and optics.  The mephisto laser is emitting a very ugly beam that we can hopefully remedy using an iris and a lens.  After scanning the beam width at a few different distances from the laser, I am currently trying to determine the appropriate lenses to use.

  1806   Wed Jul 29 13:15:35 2009 ClaraUpdatePEMDents = Bad??

I was in the lab last night accelerometerizing and noticed some dents on the tubes that stick out horizontally from the MC2 optical chamber (sorry, I don't know what they're called or what they do). One of them is pretty big... I don't know if this is a problem, but it probably isn't a good thing. Photos below:

big_dent1.png

big_dent2.png

small_dent.png

This last one is a little hard to see... I was having trouble getting a good angle on it, but it's there. Not quite as significant as the first one though. (The first two pictures are of the same dent.)

  1805   Wed Jul 29 12:14:40 2009 peteUpdateComputersRCG work

Koji, Pete 

Yesterday, Jay brought over the IO box for megatron, and got it working.  We plan to firewall megatron this afternoon, with the help of Jay and Alex, so we can set up GDS there and play without worrying about breaking things.  In the meantime, we went to Wilson House to get some breakout boards so we can take transfer functions with the 785, for an ETMX controller.  We put in a sine wave, and all looks good on the auto-generated epics screens, with an "empty" system (no filters on). Next we'll load in filters and take transfer functions.

Unfortunately we promised to return the breakout boards by 1pm today.  This is because, according to denizens of Wilson House, Osamu "borrowed" all their breakout boards and these were the last two!  If we can't locate Osamu's cache, they expect to have more in a day or two.

Here is the transfer function of the through filter working at 16KHz sampling. It looks fine except for the fact that the dc gain is ~0.8. Koji is going to characterize the digital down sampling filter in order to try to compare with the generated code and the filter coefficients.


Attachment 1: TF090729_1.png
TF090729_1.png
Attachment 2: TF090729_1.png
TF090729_1.png
  1804   Wed Jul 29 12:00:49 2009 StephanieUpdateGeneralMultiply Resonant EOM Update

For the past couple of days I have been trying to understand and perform Koji's method for impedance measurement using the Agilent 4395A Network Analyzer (without the impedance testing kit). I have made some headway, but I don't completely understand what's going on; here's what I've done so far.

I have made several transfer function measurements using the attached physical setup (ImpedanceTestingPhysicalSetup.png), after calibrating the setup by placing a 50 Ohm resistor in the place of the Z in the diagram. The responses of the various impedances I've measured are shown in the attached plot (ImpResponses.png). However, I'm having trouble figuring out how to convert these responses to impedances, so I tried to derive the relationship between the measured transfer function and the impedance by simplifying the diagram Koji drew on the board for me (attached, ImpedanceTestingSetup.png) to the attached circuit diagram (ImpedanceTestingCktDiagram.png), and finding the expected value of VA/VR. For the circuit diagram shown, the equation should be VA/VR = 2Z/(50+Z). 50 Ohms is good to use for calibration because the expected value of the transfer function for this impedance is 1 (0 dB).

So I used this relationship to find the expected response for the various impedances, and I also calculated the impedance from the actual measured responses. I've attached a plot of the measured (red) and expected (black) response (top) and impedance (bottom) for a 1 nF capacitor (1nF.png). The expected and measured plots don't really match up very well; if I add extra inductance (7.6 nH, plots shown in blue), the two plots match up a little better, but still don't match very well. I suspect that the difference may come from the fact that for my analysis, I treated the power splitter as if it were a simple node, and I think that's probably not very accurate.

Anyway, the point of all this is to eventually measure the impedance of the circuit I created on Friday, but I don't think I can really do that until I understand what is going on a little better.

Attachment 1: ImpedanceTestingPhysicalSetup.png
ImpedanceTestingPhysicalSetup.png
Attachment 2: ImpResponses.png
ImpResponses.png
Attachment 3: ImpedanceTestingSetup.png
ImpedanceTestingSetup.png
Attachment 4: ImpedanceTestingCktDiagram.png
ImpedanceTestingCktDiagram.png
Attachment 5: 1nF.png
1nF.png
ELOG V3.1.3-