40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 118 of 330  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  12691   Thu Dec 29 21:48:32 2016 ranaUpdateIOOMC AutoLocker hung because c1iool0 asleep again

MC unlocked, Autolocker waiting for c1iool0 EPICS channels to respond. c1iool0 was responding to ping, but not to telnet. Keyed the crate and its coming back now.

There's many mentions of c1iool0 in the recent past, so it seems like its demise must be imminent. Good thing we have an Acromag team on top of things!

Also, the beam on WFS2 is too high and the autolocker is tickling the Input switch on the servo board too much: this is redundant / conflicting with the MC2 tickler.

  12818   Fri Feb 10 13:04:32 2017 ranaUpdateIOOMC AutoLocker hung because c1iool0 asleep again

c1iool0 was down again. Rather than key the crate, this time I just pushed the reset button on the front and it came back.

As move towards the wonderfulness of AcroMag, we also have to buy a computer  to handle all of these IOCs. Let's install the new c1iool0 over by the SUS computer.

  3345   Sun Aug 1 21:04:45 2010 ranaSummaryComputer Scripts / ProgramsMC Autolocker fixed

Someone had left a typo in the MC autolocker script recently while trying to set the lock threshold to 0.09. As a result, the autlocker wouldn't run.

I repaired it, made a few readability improvements, and checked in the new version to the SVN. If you make script changes, check them in. If you think its too minor of a change for a SVN checkin, don't do it at all.

  11773   Tue Nov 17 15:49:23 2015 KojiConfigurationIOOMC Autolocker modified

/opt/rtcds/caltech/c1/scripts/MC/AutoLockMC.csh  was modified last night.

1. Autolocker sometimes forget to turn off the MC2Tickle. I added the following lines to make sure to turn it off.

    echo autolockMCmain: MC locked, nothing for me to do >> ${lfnam}
    echo just in case turn off MC2 tickle >> ${lfnam}
    ${SCRIPTS}/MC/MC2tickleOFF

2. During the lock acquisition, Autolocker frequently stuck on a weak mode. So the following lines were added
so that the Autolocker toggles the servo switch while waiting for the lock.

    echo autolockMCmain: Mon=$mclockstatus, Waiting for MC to lock .. >> ${lfnam}
    # Turn off MC Servo Input button
    ezcawrite C1:IOO-MC_SW1 1
    date >> ${lfnam}
    sleep 0.5;
    # Turn on MC Servo Input button
    ezcawrite C1:IOO-MC_SW1 0
    sleep 0.5;

  10116   Tue Jul 1 13:57:33 2014 ericqUpdateComputer Scripts / ProgramsMC Autolocker on Megatron

 Just a quick update on the status of the auto locker:

The auto locker now runs and respawns automatically on megatron, through ubuntu's "upstart" init system, instead of cron. 

  • The autolocker script itself is:/opt/rtcds/caltech/c1/scripts/MC/AutoLockMC.csh
  • The startup script called by the upstart system is: /opt/rtcds/caltech/c1/scripts/MC/AutoLockMC.init
  • The upstart configuration is: /etc/init/MCautolocker.conf
  • The auto locker is started by executing this command on megatron: sudo initctl start MCautolocker

This was pretty simple to set up, once I figured out how to provide the necessary environment variables in AutoLockMC.init 

  7264   Thu Aug 23 22:41:04 2012 KojiUpdateIOOMC Autolocker update

[Koji Rana]

MC Autolocker was updated. (i.e. mcup and mcdown were updated)

mcup:

  • Turn on the MCL input and output switches
  • Change the MCL gain from 0 to -300 with nominal ramp time of 5sec
  • Turn on FM2, FM5, MF7 after a sleep of 5sec. Note: FM1 FM8 FM9 are always on.
  • Set the offset of 42 counts
  • Turn on the offset

# Turn on MCL servo loop
echo mcup: Turning on MCL servo loop...
date
ezcaswitch C1:SUS-MC2_MCL INPUT OUTPUT ON
ezcawrite C1:SUS-MC2_MCL_GAIN -300
sleep 5
ezcaswitch C1:SUS-MC2_MCL FM2 FM5 FM7 ON
# Offset to take off the ADC offset of MC_F
ezcawrite C1:SUS-MC2_MCL_OFFSET 42
ezcaswitch C1:SUS-MC2_MCL OFFSET ON


This offset of 42 count is applied in order to compensate the ADC offset of MC_F channel.
The MCL servo squishes the MC_F signal. i.e. The DC component of MC_F goes to zero.
However, if the ADC of MC_F has an offset, the actual analog MC_F signal, which is fed to FSS BOX,
still keep some offset. This analog offset causes deviation from the operating point of the FSS (i.e. 5V).

mcdown:

  • Basically the revese process of mcup.
  • This script keeps FM1 FM8 FM9 turned on.

# Turn off MCL servo loop
echo mcdown: Turning off MCL servo loop...
date
ezcawrite C1:SUS-MC2_MCL_GAIN 0
ezcaswitch C1:SUS-MC2_MCL INPUT OUTPUT OFFSET FMALL OFF FM1 FM8 FM9 ON
# Remove Offset to take off the ADC offset of MC_F
ezcawrite C1:SUS-MC2_MCL_OFFSET 0

  10940   Mon Jan 26 17:43:52 2015 ericqConfigurationIOOMC Autolocker update

The MC autolocker hasn't been so snappy recently, and has been especially fussy today. Previously, the mcup script was triggered immediately once the transmission was above a certain threshold. However, this could waste time if it was just an errant flash. Hence, I've added a 0.5 second delay and a second threshold check before mcup is triggered. 

After breaking the lock 5ish times, it does seem to come back quicker.

  10039   Sat Jun 14 18:43:15 2014 ranaUpdateIOOMC Autolocker upgrades

 Somehow the caget/caput commands are really slow. I'm not sure if this is new behavior or not, but after changing values, it takes ~1-2 seconds to move on to the next command.

On op340m, once I ran autolockMCmain40m in the foreground, I could see that there were a lot of error messages that weren't being caught in the log file. On Solaris, the TDS and EZCA binaries work well, but the caget/pu stuff is missing a lot of the new flags and the new CDSUTILS python scripts are not there. So I decided to stop running on there and move over to running the MC autolocker on megatron. I also changes the mcup and mcdown scripts to BASH from CSH. There are still some PERL commands in there from Rob/Matt/Sam, so I also added the proper commands so that the pick up the scripts/general/perlmodules/ directory.

Yes, yes, I know. You would all feel warm in your tummy if we did everything in python because its the best language ever, but how about we lock the interferometer first and then we can rewrite all the last decades worth of scripts?

Looked at the trend from the last time the MCWFS were one (2 weeks ago!) and aligned the MC suspension back to that point. After that the WFS come on fine and MC looks good. I fixed the nameserver/DNS/fstab stuff on megatron, asia, and belladonna.

I've left AutoLockMC.csh (too painful to convert to BASH) running on megatron via an open terminal on pianosa. If it looks OK for the weekend, Q should move the crontab line from op340m over to megatron and then update the Wiki appropriately.

CDSUTILS is also gone from the path on all the workstations, so we need Jamie to tell us by ELOG how to set it up, or else we have to use ezcaread / ezcawrite forever.

  577   Thu Jun 26 18:29:44 2008 JenneUpdate MC Back online
Jenne, Rob, Yoichi

I was playing with the Mode Cleaner earlier today, working on measuring the effect of the new filter (see next post for loop gain measurements etc.), and bumped something which made it so the Mode Cleaner would not lock.

After much poking around by Rob and Yoichi, we found that the TNC-to-2 pin LEMO from Out1 of the MC Servo Board to Ch1 of the Pentek Generic board to the right of the MC Servo Board was bad. If we touched the cable, the MC would lock, but as soon as we let go, the MC would fall out of lock. The LEMO end of the cable was not heat shrink wrapped, so the 2 wires could have been touching. I replaced the cable, and the MC locked immediately after plugging it in, so I think that has fixed the problem.
  496   Sun May 25 19:33:16 2008 ranaUpdateIOOMC Bad after Re-alignment
The MC pointing was off and the transmitted power was down after John and Andrey brought it back after the bootfest.

I tried getting it back on Friday but was unsuccessful. Today, after the Phoenix Landing, I got it back to someplace
reasonable, but it still seems to be far off. I will check with Rob before we recenter and of the QPDs.

I had to move all of the MC SUS and also align the beam using the IOO periscope. The attached PDF shows some trends
over the last 80 days. You can see that the drop in MC TRANS is about the same as the drop in PMC TRANS.
Attachment 1: e.pdf
e.pdf
Attachment 2: pmc.png
pmc.png
  1345   Mon Mar 2 16:27:40 2009 AlbertoConfigurationElectronicsMC Drum Mode SR560 Preamplifier Replaced

Today I checked out the SR560 around the lab. I confirmed that the one with the label "channel A noisy" is effectively mulfuctioning.

It was coonected to the lock-in amplifier set up for the drum mode peak readout.

I repleaced that with a working one.

  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
  1322   Wed Feb 18 21:10:21 2009 ranaUpdateIOOMC Drumhead mode lost again
In early December, Caryn and I noticed that the MC Drumhead mode was visible at the Qmon point of
the MC demod board using a spectrum analyzer and no external excitation of the MC mirrors. We then
started tracking the MC Drumhead modes.

Today I found that it is gone again. It also wasn't there when I looked for it in 2007. Mad

I looked at the MC error point spectrum and it seemed reasonable. Changing the gains in the MZ, ISS, PMC, & FSS
had no good effect on the noise spectrum.

The voltage noise above 10 kHz in the MC error point is increasing like ~f. I think that this means that
the leftover is the noise from the FSS. Below 10 kHz it is the noise of the VCO (10 mHz/rHz).

One possibility is that the high frequency noise changes with the mood of the NPRO. There should be no
frequency noise induced by the decay of the PA diode power. We can do an NPRO SLOW scan to see if there
is some kind of mode hop noise happening.
  10826   Sun Dec 21 18:46:06 2014 diegoUpdateIOOMC Error Spectra

The error spectra I took so far are not that informative, I'm afraid. The first three posted here refer to Wed 17 in the afternoon, where things were quiet, the LSC control was off and the MC was reliably locked. The last two plots refer to Wed night, while Q and I were doing some locking work; in particular, these were taken just after one of the locklosses described in elog 10814. Sadly, they aren't much different from the "quiet" ones.

I can add some considerations though: Q and I saw some weird effects during that night, using a live reading of such spectra, which couldn't be saved though; such effects were quite fast both in appearance and disapperance, therefore difficult to save using the snapshot measurement, which is the only one that can save the data as of now; moreover, these effects were certainly seen during the locklosses, but sometimes also in normal circumstances. What we saw was a broad peak in the range 5e4-1e5 Hz with peak value ~1e-5 V/rtHz, just after the main peak shown in the attached spectra.

Attachment 1: SPAG4395_17-12-2014_170951.pdf
SPAG4395_17-12-2014_170951.pdf
Attachment 2: SPAG4395_17-12-2014_172846.pdf
SPAG4395_17-12-2014_172846.pdf
Attachment 3: SPAG4395_17-12-2014_175147.pdf
SPAG4395_17-12-2014_175147.pdf
Attachment 4: SPAG4395_18-12-2014_003414.pdf
SPAG4395_18-12-2014_003414.pdf
Attachment 5: SPAG4395_18-12-2014_003506.pdf
SPAG4395_18-12-2014_003506.pdf
  10828   Mon Dec 22 15:11:08 2014 ranaUpdateIOOMC Error Spectra

che tristezza  

What we want is to have the high and low noise spectra on the same plot. The high noise one should be triggered by a high PC DRIVE signal.

  15573   Tue Sep 15 17:19:09 2020 gautamUpdateIOOMC F spectrum

There was an abrupt change in the MC_F spectrum between August 4 and August 5, judging by the summary pages - the 1 and 3 Hz resonances are no longer visible in the spectrum. Possibly, this indicates some electronics failure on the MC servo board / whitening board, the CDS settings don't seem to have changed. There is no record of any activity in the elog around those dates that would explain such a change. I'll poke around at 1X2 to see if anything looks different.


Update 1740: I found that the MCL / MCF cables were disconnected. So since August 5, these channels were NOT recording any physical quantity. Because their inputs weren't terminated, I guess this isn't a clean measurement of the whitening + AA noise, but particularly for MC_F, I guess we could use more whitening (see Attachment #1). Probably also means that the wandering ~10-30Hz line in the spectrogram is a electronics feature. The connections have now been restored and things look nominal again.

Attachment 1: MCF_MCL.pdf
MCF_MCL.pdf
  15574   Tue Sep 15 19:17:30 2020 ranaUpdateIOOMC F spectrum

that's a very curious disconnection

the "Pentek" whitening board that carries the MC channels has jumpers to enable either 1 or 2 stages of 15:150 whitening. Looks lik MC_F has 2 and MC_L has 1.

I guess the MC_F signal is so low because of the high gain on the FSS board.  We could lower the FSS common gain and increase the IMC board's VCO gain to make up for this. Maybe 6 dB would be enough. IF that is risky, we could also up the analog gain on the whitening board.

  15576   Wed Sep 16 09:43:41 2020 gautamUpdateIOOMC F spectrum

This elog suggests that there is uniformly 1 stage engaged across all channels. I didn't look at the board to see what the jumper situation is, but only 1 stage of whitening is compensated digitally for both _F and _L. The Pomona box attached to the NPRO PZT input is also compensated digitally to convert counts to frequency.

I tried the gain re-allocation between VCO gain and FSS COMM (and also compensated for the cts to Hz conversion in MCF), but it doesn't seem to have the desired effect on the MCF SNR in the 5-50Hz band. Since the IMC stays locked, and I had already made the changes to mcup, I'll keep these gains for now. We can revert to the old settings if the IMC locking duty cycle is affected. Explicitly, the changes made were:

VCO gain: +7dB ---> +13 dB

FSS COMM: +6 ddB ---> +0 dB

The mcdown script wasn't modified, so the lock acquisition gains are the same as they've been. 

Quote:

the "Pentek" whitening board that carries the MC channels has jumpers to enable either 1 or 2 stages of 15:150 whitening. Looks lik MC_F has 2 and MC_L has 1.

Attachment 1: MCF_MCL.pdf
MCF_MCL.pdf
  10931   Thu Jan 22 18:36:11 2015 diegoUpdateIOOMC Flashes

I've been looking into the data of Jan 06 and Jan 15 taken during daytime, as the night before we left the PRC aligned in order to allow the IFO to flash; the purpose is to find out if some flashes from the IFO could propagate back to the IMC and cause it to lose lock; I will show here a sample plot, all of the others are in the archive attached.

My impression is that these locklosses of the IMC are not caused by these flashes: the signals MC_[F/L] seem quite stable until the lock loss, and I don't see any correlation with what happens to REFLDC that could cause the lockloss (apart from its drop as a consequence of the lockloss itself); in addition, in most occasions I noticed that the FSS started to go crazy just before the lock loss, and that suggests me that the lockloss source is internal to the IMC.

I can't see anything strange happen to MC_TRANS either as long as the IMC is locked, no fluctuations or weird behaviour. I also plotted the MC_REFL_SUM channel. but it is too slow to be useful for this kind of "hunt".

Attachment 1: 1104612646_zoom_1.png
1104612646_zoom_1.png
Attachment 2: elog.tar.bz2
  12857   Tue Feb 28 21:05:44 2017 ranaSummaryIOOMC Length offset changes MCWFS offsets

The input offset on the MC length servo board changes the lock point of the length loop (by how much? need to calibrate this slider into meters & Hz).

The SUM signal on the MC WFS is ~few 1000. This is several times larger than the pit/yaw signals. This is bad. it means that the TEM00 mode on the WFS (or what the WFS interperets as a TEM00) is larger than the TEM01/10 that its supposed to measure.

So if the beam moves on the WFS head it will convert this large common mode signal into a differential one.

We moved the MC Servo offset around from -3 to +3 V today and saw that it does affect the transmitted light level, but we need to think more to see how to put the offset at the real center of the resonance. This is complicated by the fact that the MCWFS loops seem to have some several minutes time constant so things are essentially always drifting.

  1. Characterize and juice up the WFS loops.
  2. Figure out how to set the MC length loop offset. Is this bad offset changing the zero point of the MC WFS loops?
  3. If so, it may be a source of excess jitter noise in the interferometer.

I changed the McREFL SMOO to make it easier to use this noisy channel to diagnose small alignment changes:

caput C1:IOO-MC_RFPD_DCMON.SMOO 0.1

  2236   Wed Nov 11 12:29:44 2009 AlbertoFrogsPSLMC Locked on the wrong mode?

This morning, after Steve pointed out that the readout RFAMPD_DC was zero, I thought of realigning the beam on the photodiode. Maybe I touched the lens or the beam splitter that send the beam on the diode when I installed an other beam splitter to make the measurement of the calibration between two ThorLabs PDA255 photodiodes.

After aligning the beam on the RFAMPD, the voltage of the DC readout was lower than it used to be (C1:IOO-RFAMPD_DC ~ 0.4 now vs. 4 as it was on November 4th).

I maximized the DC readout but the problem seems to be that the beam spot is not a round TEM00. In particular the spot looks like that of a TEM10 mode.

Since we're looking at the MC transmitted beam, is it possible that the MC is locked on the wrong mode?

Check out the attached picture.

Attachment 1: PB110184-1.JPG
PB110184-1.JPG
  4620   Tue May 3 18:46:06 2011 ranaUpdateIOOMC Locking not working

I found that the MC autolocker was OFF. Kiwamu says he turned it off because its slow. Suresh says that he has some feelings that maybe something is wrong. I'll let them describe what they know about the MC in an elog.

I checked the trend of the MC and PMC transmissions for the past 30 days:

Untitled.png

Looks like the alignment has been drifitng. PMC was corrected recently by Koji, but the alignment of the input beam to the MC or the MC itself has to be fixed. Has someone been twiddling the MC SUS alignment biases??

Attachment 1: Untitled.png
Untitled.png
  4621   Wed May 4 11:48:01 2011 SureshUpdateIOOMC Locking not working

[Valera, Suresh]

The first time I noticed that the MC was not locking was after I had finished switching the RF source installation.  Before this change the RF modulation frequency (for MC) was 29.485 MHz as read from the Marconi RF Source.  We replaced this with a Wenzel crystal source at 29.491 MHz.  This may have changed the loop gain. 

Today, I changed the MC alignment to optimise the MC lock.  Valera pointed out that this is not a desirable solution since it would shift the beam pointing for all components downstream.  However, since we are not sure what was the last stable configuration, we decided to stay with the current settings for now and see the trends of several parameters which would tell us if something is drifting and causing the autolocker to fail.

The MC Auto locker is now working okay.  However to obtain lock initially we reduced the loop gain by decreasing the VCO gain.  We then increased the gain after the autolocker had locked the MC.

 

 

 

  3049   Fri Jun 4 11:32:51 2010 Alberto, kiwamuUpdateIOOMC MMT1 Mirror Tests
[Alberto, Kiwamu]
Last Wednesday, we measured the beam profile after the MC mode matching telescope n.1 (MMT1). We found that the reflected beam had an irregular profile when observed with the beam scan. Fringes also appeared on an IR card.
We thought that such effect could be due to interference of the main reflected beam with the beam reflected by the back surface of the mirror.
 
To test the hypothesis we checked the transmitted and the reflected beams of a spare optic identical to MMT1. (This was the same optic that got dropped during the cleaning/baking process.)
 
We tested it on the PSL table, using a 200mW beam coming from the new 2W Innolight  laser. To maximize the separation between the two beams, we tested MMT1 at 45 degrees. The setup we used is shown here:
 
MCMMT1spareOpticsTestSetup.png
 
We looked at the beam reflected by MMT1 about 5 meters from the mirror. At that distance the beam spot had a size of about 1-2cm. it didn't look perfectly round, but it showed no fringes, as it had happened with original MMT1 inside the MC chamber.
At the transmission, the second ghost beam due to the back surface reflection (see picture above) was very week. In order to be able to see it on an IR card, we had to increase the laser pumping current from 1A to about 1.5A.
 
We are now thinking of a way to measure the relative power between the two. The problem is that they run very close to each other and it's not easy to resolve them with a power meter or a photodiode.
  1997   Thu Sep 24 15:45:27 2009 robUpdateIOOMC OLG

I measured the mode cleaner open loop gain with the HP3563A

The UGF is 64kHz, phase margin is 28 deg.

  2144   Mon Oct 26 18:15:57 2009 robUpdateIOOMC OLG

I measured the mode cleaner open loop gain.  It's around 60kHz with 29 degs of phase margin.

  4582   Thu Apr 28 15:31:36 2011 kiwamuUpdateIOOMC PDH lock : readjustment of demodulation phase

Since Suresh has installed the RF source box and changed the cable configuration somewhat,

the demodulation phase for the MC locking became off by about 10 degree.

I changed the length of some cables and obtained a good demodulation phase by the same technique as Suresh and Koji did before (see here for detail).

I maximized the Q signal. The lock of the MC looks healthy.

DSC_2975_ss.jpg

Quote from #4578

RF Source box has been mounted in the 1X2 rack. 

  1162   Tue Nov 25 18:38:03 2008 Alberto, RobUpdatePSLMC Periscope Alignment
This morning when I came in I found the MC cleaner unlocked and the autolocker script could not lock it. The reflected beam was quite off and showed in the bottom left corner of the IMCR camera. After turning off the WFS locking, I started slightly changing the alignment of the steering mirrors on the MC periscope, waiting for the LSC servo to lock the cavity. It didn't work. At some point I lost the beam from the IMCR camera and that is how someone might have found it when I left it for about one hour.

When I came back and tried again adjusting the steering mirrors, I noticed that the autolocker was working and was trying to lock the cavity. After just a bit of adjustment, the MC got easily locked.

After that, I spent a couple of hours trying to improve the alignment of the periscope to minimize the reflection and maximize the transmission. I started with a transmission of 0.4 V but, despite all the tweaking (I used the technique of turning both yaw knobs at the same time), I couldn't get more than 1.2 V (and 2.4 V at the reflection) if only the LSC servo was on. Looking at the camera, I moved the beam around to look for a more favorable spot but the MC wouldn't lock with the beam in other places. Maybe I could do better or maybe not because the cavity is not aligned. I'm going to try again tomorrow.
  8138   Fri Feb 22 17:33:25 2013 ManasaUpdateElectronicsMC REFL PD back from the dead

 

 [Yuta, Manasa]

We replaced the dead photodiode on MC REFL PD with a new one (GAP 2000). We measured the frequency response of the PD and tuned the resonant frequency using inductor L5 (in the circuit diagram) to be 29.575MHz - over an average of 10 measurements.

Riju is measuring the characteristics of the PD and will be posting an elog in detail.

  11237   Wed Apr 22 17:04:11 2015 ranaUpdateElectronicsMC REFL PD back from the dead

Just randomly found this old entry from 3 years ago. We should never have installed a GAP 2000 - they are an inferior type of InGaAs diode. We should add to our list replacing these with a 2 mm EG&G diode.

How many 2 mm EG&G InGaAs diodes do we have Steve? Can you please find a good clean diode case so that we can store them in the optics cabinet on the south arm?

Quote:

 [Yuta, Manasa]

We replaced the dead photodiode on MC REFL PD with a new one (GAP 2000). We measured the frequency response of the PD and tuned the resonant frequency using inductor L5 (in the circuit diagram) to be 29.575MHz - over an average of 10 measurements.

 

  877   Mon Aug 25 11:43:55 2008 YoichiFrogsIOOMC REFL PD cable had been disconnected through out the weekend
Most of my morning was wasted by the MC REFL PD cable, which was disconnected on the generic LSC PD interface board.
I know who did this. *ME*. When I pulled out the MC board, which is sitting next to the PD interface, on Friday, I must have
disconnected the PD cable accidentally. The connector of the PD cable (D-Sub) does not have screws to tighten and easily comes off.
I wrote this entry to warn other people of this potential problem.
  8137   Fri Feb 22 13:03:49 2013 ManasaUpdate MC REFL PD murder

 

[Yuta, Manasa]

We turned IFO power back to 1.25W by removing the attenuator and forgot that the Y1 mirror before the REFL PD must be replaced with BS 10% before getting to full power. The PD is dead  and now we are in the process of fixing it. Forgive us for all our sins!

On the other note, we have changed the mech shutter mode from N.O back to N.C. So the shutter now works as usual from the medm screen.

dead.jpg

  13712   Tue Mar 27 23:37:35 2018 gautamUpdateIOOMC REFL PD removed

I've removed the MC REFL PD unit from the AS table for investigation. So MC won't lock.

PSL shutter was closed and location of PD was marked with sharpie (placing guides to indicate position wasn't convenient). I also kapton taped the PD to minimize dust settling on the PD while I have it out in the electronics area. Johannes has the camera, and my cellphone image probably isn't really high-res enough for diagnostics but I'm posting it here anyways for what it's worth. More importantly - the board is a D980454 revision B judging by the board, but there is no schematic for this revision on the DCC. The closest I can find is a D980454 Rev D. But I can already see several differences in the component layout (though not all of them may be important). Making a marked up schematic is going to be a pain indecision. I'm also not sure what the specific make of the PD installed is.

The lid of the RF cage wasn't on.

More to follow tomorrow, PD is on the electronics workmench for now...


gautam 28 March 2018: Schematic has been found from secret Dale stash (which exists in addition to the secret Jay stash). It has also been added to the 40m electronics tree.

Attachment 1: IMG_6955.JPG
IMG_6955.JPG
  13715   Wed Mar 28 21:31:39 2018 gautamUpdateIOOMC REFL PD removed

I re-installed the MC REFL photodiode. Centered beam on the PD by adjusting steering mirror to maximize the DC signal level (on o'scope) at the DC monitoring port. Curiously, the DC level on the scope (high-Z) was ~2.66V DC, whereas the MEDM screen reports ~twice that value, at ~5.44 "V". We may want to fix this "calibration" (or better yet, use physical units like mW). Noise-eater On/Off comparison of MC error signals to follow.

  8038   Fri Feb 8 17:15:56 2013 JenneUpdateRF SystemMC REFL Photodiode transimpedance

This measurement was done already about a week ago, in elog 7984.  Can you please describe why the numbers for the last measurement were not believable, and what was done differently this time?

  8044   Fri Feb 8 20:27:56 2013 KojiUpdateRF SystemMC REFL Photodiode transimpedance

The comment itself was added by me.
The difference between the previous and new measurements should be described by Riju.

In the entry 7984, the description has several PDs mixed up. The measurement was done with the MCREFL PD.
But the DC transimpedance of the thorlabs PD (5e3) was used, according to the text.
I first wonder if this is only a mistake not in the calculation but only in the elog due to a sloppy copy-and-paste.
But the resulting shot-noise-intercept current was 50uA, which is way too small
compared with a realistic value of 0.1~1mA. I have never seen such a good value with
C30642 at the resonant freq ~30MHz. That's why I said "hard to believe". I guessed this wrong
DC transimpedance was actually used for the calculation. 


You may wonder why this 50uA is unreasonable number.
Basically this is just my feeling and probably is same as Rana's feeling.
But "my feeling" can't be a scientific explanation. Here is some estimation.

Looking at my note in 2010:
https://wiki-40m.ligo.caltech.edu/40m_Library (Comparisons of the PD circuits by KA)

The expected shot noise intercept current (idc) is

idc = 2 kB T / (e Rres),

where Rres is the impedance of the resonant circuit at the resonant freq.

This Rres is expressed as

Rres = 1/(4 pi^2 fres^2 Cd^2 Rs),

where Cd and Rs are the capacitance and series resistance of the diode.

If we input realistic numbers,

Cd = 100pF
Rs = 10 Ohm
fres = 30MHz

We obtain, Rres ~ 300Ohm, and idc = 0.2mA

In other words, Rs needs to be 2~3Ohm in order to have idc = 50uA.
This is too small from the previous measurements.
Test Results for C30642 LSC Diode Elements by Rich Abbott

  12485   Mon Sep 12 20:19:25 2016 LydiaUpdateGeneralMC REFL beam splitter not replaced

The beam splitter that directs light into the MC REFL photodiode has not been replaced; there is still a mirror there. Gautam suggested we wait to replace it until the PSL shutter is open so the beam can be aligned. However, this must be done before going to high power.

GV addendum: What I suggested was to try and recover the arm alignment using the current low power configuration after pumpdown - since we were well aligned just before pumpdown, we should be able to recover this alignment pretty easily at low power. After locking both arms and running the dither align (also center all Oplevs), we can go ahead do the following:

  • Replace mirror in MC Refl path with 10% reflection BS (Johannes, Lydia and I confirmed that this is on the AP table earlier today). Then align the reflected beam onto the PD using the tiny mirror
  • Replace HR mirror in Transmon path at the EY table
  • Replace ND filters on Transmon QPDs at EX and EY tables
  • Repalce ND filter on Transmon CCD at EY table
  • Revert MC autolocker to the nominal version instead of the low power version we have been using during the vent
  • Turn up MC to nominal power by rotating the wave plate on the PSL table - confirm that we have nominal levels by measuring with power meter
  • Recover single arm locks, green beatnotes etc at nominal operating conditions
     
  10064   Wed Jun 18 21:37:11 2014 KojiUpdateIOOMC REFL investigation

[Jenne Koji]

We decided to check the situation of the REFL MC beam path.

- No resolution of the weird MC REFL DC increase
- The reflection from the PD was adjusted to hit the beam dump
- The MC WFS paths were aligned again


Detail:

We found that the reflected beam from the PD was hitting the mount of the beam dump.
So the entire MC REFL path was steered down such that the last steering mirror does not neet to steer the beam.
When the alignment was adjusted so that the reflection from PD hit the beam dump, the beam spot on the small mirror right before the PD
got a bit marginal but it seemed still OK after some tweak.

Then we looked at the reflection value. It is still about 6.5. No change.

As we messed up the entire MC REFL path, we aligned the MC WFS paths again.
This was done with the unlocked MC REFL beam. Once the cavity was locked,
it turned out that it was enough for the WFS too keep the MC locked.

  12806   Tue Feb 7 10:18:58 2017 gautamUpdateIMCMC REFL weirdness

A few minutes back, I glanced up at the control room StripTool and noticed that the MCREFL PD DC level had gone up from ~0 to ~0.7, even though the PSL shutter was closed. This seemed bizzare to me. Strangely, simply cycling the shutter returned the value to the expected value of 0. I wonder if this is just a CDS problem to do with c1iool0 or c1psl? (both seem to be responding to telnet though...)

Since things look to be back to normal, I am going to start with my characterization of the various TFs in the IMC FSS loop...

  29   Tue Oct 30 00:47:29 2007 ranaOtherIOOMC Ringdowns
I did a bunch of MC ringdown measurements using the PD that Rob set up. The idea is to put a fast PD (PDA255)
looking at the transmission through MC2 after focusing by a fast lens. The input to the MC is turned off fast
by flipping the sign of the FSS (Andri Gretarsson's technique).

With the laptop sitting on the MC can, its easy to repeat many ringdowns fast:
- Turn off the MC autolocker. Relock the MC with only the acquisition settings; no boosts
  and no RGs. This makes it re-acquire fast. Turn the MC-WFS gain down to 0.001 so that
  it keeps it slowly aligned but does not drift off when you lose lock.

- Use low-ish gain on the FSS. 10 dB lower than nominal is fine.

- Setup the o'scope (100 MHz BW or greater) to do single shot trigger on the MC2 trans.

- Flip FSS sign.

- Quickly flip sign back and waggle common gain to get FSS to stop oscillating. MC
  should relock in seconds.

Clearly one can scriptify this all just by hooking up the scope to the ethernet port.


Attached are a bunch of PNG of the ringdowns as well as a tarball with the actual data. A sugar
napoleon to whomever can explain the 7 us period of the wiggle before the vent!
Attachment 1: tek00000.png
tek00000.png
Attachment 2: tek00001.png
tek00001.png
Attachment 3: tek00004.png
tek00004.png
Attachment 4: MC2ringdown.tar.gz
  30   Tue Oct 30 13:58:07 2007 ajwConfigurationIOOMC Ringdowns
Here's a quick fit-by-eye to the latter part of the data from tek00000.xls.

The prediction (blue) is eqn 41 of
http://www.ligo.caltech.edu/docs/P/P000017-A.pdf

T1 = T2 = 0.002. Loss1 = Loss2 = 150 ppm.
MC3 assumed perfectly reflecting.
Velocity = 320 um/s (assumed constant), 2 usec into the ringdown.

OK, there's one little fudge factor in the prediction:
I multiplied D by 2.
Attachment 1: CavityRingdown.png
CavityRingdown.png
Attachment 2: CavityRingdown.m
% CavityRingdown.m
% Eqn 41 of 
% "Doppler-induced dynamics of fields in Fabry–Perot
% cavities with suspended mirrors", Malik Rakhmanov (2000).
% http://www.ligo.caltech.edu/docs/P/P000017-A.pdf

clear all

% read in ringdown timeseries:
at = importdata('tek00000.csv');
... 121 more lines ...
  12904   Fri Mar 24 11:26:57 2017 gautamUpdateIMCMC SUS damping gains restored

I've restored the damping loop gains to their nominal values. Analysis of the coherence between MCL and seismometer channels under this reduced gain setting is underway, results to follow.

  12903   Thu Mar 23 23:38:58 2017 gautamUpdateIMCMC SUS damping gains stepped down

I've reduced the gains of the damping on all 3 MC SUS by a factor of 3 for overnight observation as part of the ongoing feedforward noise cancellation investigations. I will return them to the nominal values tomorrow morning.

  6244   Fri Feb 3 14:44:33 2012 JenneUpdateIOOMC SUS misalignment

The mode cleaner is a little misaligned in pitch, and is very misaligned in yaw.  The lowest order mode that is flashing is TEM11.

I had a look-see at the SUS sensors, to see if there were any big jumps.  There were moderately sized jumps on all 3 mode cleaner optics.

SUSjump_3Feb2012.png

The MC's lockloss was at ~8:22am this morning, and went along with a giganto kick to the optics.  Steve tells me that Den might have been kicking up optics while doing computer things this morning, before Steve reminded him to shut off the watchdogs.  However, Steve was also taking phots/measuring things near MC Refl, so maybe he's not totally absolved of blame.  But this really looks like the optics settled to different places after big kicks.

I'm going to try to align the MC mirrors to get back to the sensor numbers from early this morning before chaos began.

Reminder / Moral:  Everything cannot be considered to be "working fine" if the MC isn't locking.  See if you can figure out why, and especially if it's something that you screwed up, either fix it, or better yet, ask for help and learn how to fix what you broke.

  6246   Fri Feb 3 15:49:10 2012 JenneUpdateIOOMC SUS misalignment

[Jenne, Den]

We moved the MC approximately back to where the sensors for each optic used to be (mostly touching MC2, but a little bit of MC1 to help the refl get back to its max value).  MC is now locked, and with the help of the WFS it's back to nominal.  I forgot to disable the WFS, so I think we aren't perfectly aligned, but we're close enough for the WFS to get us the rest of the way.  We're heading over to JClub right now, so we're going to leave it as-is.

  6248   Fri Feb 3 17:17:47 2012 DenUpdateIOOMC SUS misalignment

Quote:

Reminder / Moral:  Everything cannot be considered to be "working fine" if the MC isn't locking.  See if you can figure out why, and especially if it's something that you screwed up, either fix it, or better yet, ask for help and learn how to fix what you broke.

When I left this morning, Steve was still working with the MC and it was unlocked anyway, I could not check it. By "fine" I meant only watchdogs. The thing is that before starting to work with c1lsc I turned off all the coils. Crazyness that Steve saw was after I turned them on back after reboot. This is a confusing thing - restarting models on c1lsc and burt restoring them is not enough. After I did it, everything at the STATUS MEDM screen was green, but the C1:SUS-???_??PD_VAR values went up after turning on coils. So sus and lsc communicated in a bad manner after the reboot. After restarting x02 model, the watchdogs were fine again.

  154   Sun Dec 2 21:02:12 2007 ranaConfigurationIOOMC SUS re-alignment
The spot on MC2 was not centered, so I put it back in the center:

  • Made sure MC trans was high with the WFS off.
  • Moved the Sliders on the MC Align screen until spot was centered (by eye)
  • Moved some more until power was maximized.
  • Unlock MC
  • Center spots on McWFS
  • Re-enable autolocker and McWFS loops.
  155   Sun Dec 2 21:07:39 2007 ranaConfigurationIOOMC SUS re-alignment
you asked for:   diff 2007/12/01,4:58:48 2007/12/03,4:58:48 utc 'MC.*COMM'
LIGO controls: differences, 2007 12/01 04:58:48 utc vs. 2007 12/03 04:58:48 utc
__Epics_Channel_Name______   __Description__________   __value1____     __value2____
C1:SUS-MC1_YAW_COMM                                    -0.273460        -0.503460
C1:SUS-MC2_PIT_COMM                                     3.624020         3.632020
C1:SUS-MC2_YAW_COMM                                    -0.936800        -1.038800
C1:SUS-MC3_YAW_COMM                                    -3.129000        -3.369000
  156   Sun Dec 2 21:13:16 2007 ranaConfigurationIOOMC SUS re-alignment
Attachment 1: e.png
e.png
  706   Mon Jul 21 11:54:00 2008 JenneUpdateGeneralMC Servo Board
I pulled the MC Servo Board again, to check the components that are on the board, and compare them with the schematics. The filters that I'm interested in on the Fast Path haven't been changed. The high pass filters on the Fast Path have been changed.
Component      Schematic      Actual
---------      ---------      ------
C140           10u            open
C144           10u            open
C149           open           a gray Cap.  value unknown
C141           10u            open
C145           10u            open
R97            1.58K          0
R99            open           1130
R103           open           1130
R100           open           0
R104           100            1130
R98            1.58K          open
R109           367            365

Board is back in, and MC locks.
ELOG V3.1.3-