40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 97 of 344  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  1986   Sat Sep 12 15:40:15 2009 ranaUpdatePSLRC response v. can temperature

I stepped the RC can temperature to see the response in the laser frequency. This gives a true measure of the thermal time constant of the RC. Its ~4 hours.

Since the RCPID screen now has a setpoint field, I can remotely type in 1 deg steps. The NPRO SLOW actuator locks the NPRO to the RC at long time scales and so we can use C1:PSL-FSS_SLOWDC to measure the RC length. By knowing what the step response time constant is, we can estimate the transfer function from can temperature to frequency noise and thereby make a better heater circuit.

 Does the observed temperature shift make any sense? Well, John Miller and I measured the SLOW calibration to be 1054 +/- 30 MHz / V.

We know that the thermal expansion coefficient of fused silica, alpha = 5.5 x 10-7 (dL/L)/deg. So the frequency shift ought to be alpha * c / lambda = 155 MHz / deg.

Instead we see something like 110 MHz / deg. We have to take more data to see if the frequency shift will actually asymptote to the right value or not. If it doesn't, one possibility is that we are seeing the effect of temperature on the reflection phase of the mirror coatings through the dn/dT and the thermal expansion of the dielectric layers. I don't know what these parameters are for the Ta2O5 layers.

A more useful measure of the frequency noise can be gotten by just looking at the derivative in the first 30 minutes of the step, since that short time scale is much more relevant for us. Its 0.04 V / hour / (2 deg) =>  860 (Hz/s)/deg.

In the frequency domain this comes out to be dnu/dT = 860 Hz/deg @ 0.16 Hz or dnu/dT = 137 *(1/f) Hz / deg.

Our goal for the reference cavity frequency noise is 0.01 * (1/f) Hz/rHz. So the temperature noise of the can needs to be < 0.1 mdeg / rHz.

Attachment 1: Picture_2.png
Picture_2.png
Attachment 2: Untitled.pdf
Untitled.pdf
  1987   Tue Sep 15 15:46:05 2009 steveUpdatePEMPEM and VAC

FSS_RMTEMP is moving up and  daily fluctuations  are  less . 120 and 16 days plots are below.

Attachment 1: 120dpem.jpg
120dpem.jpg
Attachment 2: 16dpem.jpg
16dpem.jpg
  1988   Wed Sep 16 11:58:11 2009 JenneUpdateAdaptive FilteringNew Filters for Adaptive Filtering

When Sanjit and I were looking at the adaptive filtering system on Monday and Friday, we noticed that turning on the Accelerometers (which had been used in the past) seemed to do good things, but that turning on the seismometers (which I just put into the system last week) made the OAF output integrate up.  Rana pointed out that this is an indication of a missing high pass filter.  And indeed, when I put the seismometers in, I neglected to copy the high pass filter at low frequencies, and the low pass at 64Hz from the accelerometer path to the seismometer path.  The accelerometers had a HP at 1Hz, which is okay since they don't really do useful things down to the mHz level.  I gave all of the seismometers HP at 1mHz.  These are now in the filter banks in the ASS_TOP_PEM screen.  The accelerometers are on channels 15, 16, 17, 18, 19, 20 and the seismometers are on channels 2, 3, 4, 10, 11, 12, 24.

I now need to modify the upass script to turn these filters on before doing adaptive filtering.

  1989   Thu Sep 17 14:17:04 2009 robUpdateComputersawgtpman on c1omc failing to start

[root@c1omc controls]# /opt/gds/awgtpman -2 &
[1] 16618
[root@c1omc controls]# mmapped address is 0x55577000
32 kHz system
Spawn testpoint manager
no test point service registered
Test point manager startup failed; -1

[1]+  Exit 1                  /opt/gds/awgtpman -2

 

 

 

  1990   Thu Sep 17 15:05:47 2009 robUpdateComputersawgtpman on c1omc failing to start

Quote:

[root@c1omc controls]# /opt/gds/awgtpman -2 &
[1] 16618
[root@c1omc controls]# mmapped address is 0x55577000
32 kHz system
Spawn testpoint manager
no test point service registered
Test point manager startup failed; -1

[1]+  Exit 1                  /opt/gds/awgtpman -2

 

 

 

 

 

 

This turned out to be fallout from the /cvs/cds transition.  Remounting and restarting fixed it.

  1995   Wed Sep 23 19:36:41 2009 ranaUpdatePSLRC temperature performance

This first plot shows the RC temperature channels' performance from 40 days ago, before we disabled the MINCO PID controller. Although RCTEMP is supposed to be the out of loop sensor, what we really care about is the cavity length and so I've plotted the SLOW. To get the SLOW on the same scale, I've multiplied the channel by 10 and then adjusted the offset to get it on the same scale.

 The second plot shows a period after that where there is no temperature control of the can at all. Same gain scaling has been applied to SLOW as above, so that instead of the usual 1 GHz/V this plot shows it in 0.1 GHz/V.

The third plot shows it after the new PID was setup.

Summary: Even though the PID loop has more gain, the true limit to the daily fluctuations in the cavity temperature and the laser frequency are due to the in-loop sensors measuring the wrong thing. i.e. the out-of-loop temperature is too different from the in-loop sensor. This can possibly be cured with better foam and better placement of the temperature sensors. Its possible that we're now just limited by the temperature gradients on the can.

Attachment 1: Untitled.png
Untitled.png
Attachment 2: Untitled.png
Untitled.png
Attachment 3: e.png
e.png
  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.

  2000   Thu Sep 24 21:04:15 2009 JenneUpdateMOPAIncreasing the power from the MOPA

[Jenne, Rana, Koji]

Since the MOPA has been having a bad few weeks (and got even more significantly worse in the last day or so), we opened up the MOPA box to increase the power.  This involved some adjusting of the NPRO, and some adjusting of the alignment between the NPRO and the Amplifier.  Afterward, the power out of the MOPA box was increased.  Hooray! 

Steps taken:

0.  Before we touched anything, the AMPMON was 2.26, PMC_Trans was 2.23, PSL-126MOPA_126MON was 152 (and when the photodiode was blocked, it's dark reading was 23).

1.  We took off the side panel of the MOPA box nearest the NPRO, to gain access to the potentiometers that control the NPRO settings.  We selectively changed some of the pots while watching PSL-126MOPA_126MON on Striptool.

2.  We adjusted the pot labeled "DTEMP" first. (You have to use a dental mirror to see the labels on the PCB, but they're there). We went 3.25 turns clockwise, and got the 126MON to 158. 

3. To give us some elbow room, we changed the PSL-126MOPA_126CURADJ from +10.000 to 0.000 so that we have some space to move around on the slider.  This changed 126MON to 142. The 126MOPA_CURMON was at 2.308.

4.  We tried adjusting the "USR_CUR" pot, which is labeled "POWER" on the back panel of the NPRO (you reach this pot through a hole in the back of the NPRO, not through the side which we took off, like all the other pots today).  This pot did nothing at all, so we left it in its original position.  This may have been disabled since we use the slider.

5.  We adjusted the CUR_SET pot, and got the 126MON up to 185.  This changed the 126MOPA_CURMON to 2. 772 and the AMPMON to 2.45

We decided that that was enough fiddling with the NPRO, and moved on to adjusting the alignment into the Amplifier.

6.  We teed off of the AMPMON photodiode so that we could see the DC values on a DMM.  When we used a T to connect both the DMM and the regular DAQ cable, the DMM read a value a factor of 2 smaller than when the DMM was connected directly to the PD.  This shouldn't happen.....it's something on the to-fix-someday list.

7.  Rana adjusted the 2 steering mirrors immediately in front of the amplifier, inside the MOPA box.  This changed the DMM reading from its original 0.204 to 0.210, and the AMPMON reading from 2.45 to 2.55. While this did help increase the power, the mirrors weren't really moved very much.

8.  We then noticed that the beam wasn't really well aligned onto the AMPMON PD.  When Rana leaned on the MOPA box, the PD's reading changed.  So we moved the PD a little bit to maximize its readings.  After this, the AMPMON read 2.68, and the DMM read 0.220.

9.  Then Rana adjusted the 2 waveplates in the path from the NPRO to the Amplifier.  The first waveplate in the path didn't really change anything.  Adjusting the 2nd waveplate gave us an AMPMON of 2.72, and a DMM reading of 0.222.

10.  We closed up the MOPA box, and locked the PMC.  Unfortunately, the PMC_Trans was only 1.78, down from the 2.26 when we began our activities.  Not so great, considering that in the end, the MOPA power went up from 2.26 to 2.72.

11.  Koji and I adjusted the steering mirrors in front of the PMC, but we could not get a transmission higher than 1.78.

12.  We came back to the control room, and changed the 126MOPA_126CURADJ slider to -2.263 which gives a 126MOPA_CURMON to 2.503.  This increased PMC_TRANS up to 2.1. 

13.  Koji did a bit more steering mirror adjustment, but didn't get any more improvement.

14.  Koji then did a scan of the FSS SLOW actuator, and found a better temperature place (~ -5.0)for the laser to sit in.  This place (presumably with less mode hopping) lets the PMC_TRANS get up to 2.3, almost 2.4.  We leave things at this place, with the 126MOPA_126CURADJ slider at -2.263. 

Now that the MOPA is putting out more power, we can adjust the waveplate before the PBS to determine how much power we dump, so that we have ~constant power all the time.

 

Also, the PMCR view on the Quad TVs in the Control Room has been changed so it actually is PMCR, not PMCT like it has been for a long time.

  2001   Fri Sep 25 16:10:17 2009 JenneUpdateAdaptive FilteringSome progress on OAF, but more still to be done

[Jenne, Sanjit]

It seems now that we are able to get the OAF system to do a pretty good job of approximating the MC_L signal, but we can't get it to actually do any subtracting.  I think that we're not correctly setting the phase delay between the witness and the MC_L channels or something (I'm not sure though why we get a good filter match if the delay is set incorrectly, but we do get a good filter match for very different delay settings: 1, 5, 100, 1000 all seem to do equally well at adjusting the filter to match MC_L). 

The Matt Evans document in elog 395 suggests measuring the phase at the Nyquist frequency, and calculating the appropriate delay from that.  The sticking point with this is that we can't get test points for any channel which starts with C1:ASS.  I've emailed Alex to see what he can do about this.  Elog 1982 has a few words about how we're perhaps using a different awgtpman on the ass machine than we used to, which may be part of the problem. 

The golden plan, which in my head will work perfectly, is as follows: Alex will fix the testpoint problem, then Sanjit and I will be able to measure the phase between our OAF signal and the incoming MC_L signal, we will be able to match them as prescribed in the Matt Evans document, and then suddenly the Adaptive Filtering system will do some actual subtracting!

The plot below shows the Reference MC_L without any OAF system (black), the output of the OAF (green), and the 'reduced' MC_L (red).  As you can see, the green trace is doing a pretty good job of matching the black one, but the red trace isn't getting reduced at all.

Attachment 1: OAF_Running_25Sept2009.jpg
OAF_Running_25Sept2009.jpg
  2002   Fri Sep 25 16:45:29 2009 JenneUpdateMOPATotal MOPA power is constant, but the NPRO's power has decreased after last night's activities?

[Koji, Jenne]

Steve pointed this out to me today, and Koji and I just took a look at it together:  The total power coming out of the MOPA box is constant, about 2.7W.  However, the NPRO power (as measured by 126MOPA_126MON) has decreased from where we left it last night.  It's an exponential decay, and Koji and I aren't sure what is causing it.  This may be some misalignment on the PD which actually measures 126MON or something though, because 126MOPA_LMON, which measures the NPRO power inside the NPRO box (that's how it looks on the MEDM screen at least...) has stayed constant.  I'm hesitant to be sure that it's a misalignment issue since the decay is gradual, rather than a jump. 

Koji and I are going to keep an eye on the 126MON value.  Perhaps on Monday we'll take a look at maybe aligning the beam onto this PD, and look at the impedance of both this PD, and the AMPMON PD to see why the reading on the DMM changed last night when we had the DAQ cable T-ed in, and not T-ed in. 

Attachment 1: AMPMONconstant_126MONdown.jpg
AMPMONconstant_126MONdown.jpg
  2003   Fri Sep 25 17:51:51 2009 KojiUpdateMOPASolved (Re: Total MOPA power is constant, but the NPRO's power has decreased after last night's activities?)

Jenne, Koji

The cause of the decrease was found and the problem was solved. We found this entry, which says

Yoich> We opened the MOPA box and installed a mirror to direct a picked off NPRO beam to the outside of the box through an unused hole.
Yoich> We set up a lens and a PD outside of the MOPA box to receive this beam. The output from the PD is connected to the 126MON cable.

We went to the PSL table and found the dc power cable for 126MOPA_AMPMON was clipping the 126MON beam.
We also made a cable stay with a pole and a cable tie.

After the work, 126MON went up to 161 which was the value we saw last night.


We also found that the cause of the AMPMON signal change by the DAQ connection, mentioned in this entry:

Jenne> 6.  We teed off of the AMPMON photodiode so that we could see the DC values on a DMM. 
Jenne> When we used a T to connect both the DMM and the regular DAQ cable, the DMM read
Jenne> a value a factor of 2 smaller than when the DMM was connected directly to the PD.

We found a 30dB attenuator is connected after the PD. It explains missing factor of 2.

Quote:

[Koji, Jenne]

Steve pointed this out to me today, and Koji and I just took a look at it together:  The total power coming out of the MOPA box is constant, about 2.7W.  However, the NPRO power (as measured by 126MOPA_126MON) has decreased from where we left it last night.  It's an exponential decay, and Koji and I aren't sure what is causing it.  This may be some misalignment on the PD which actually measures 126MON or something though, because 126MOPA_LMON, which measures the NPRO power inside the NPRO box (that's how it looks on the MEDM screen at least...) has stayed constant.  I'm hesitant to be sure that it's a misalignment issue since the decay is gradual, rather than a jump. 

Koji and I are going to keep an eye on the 126MON value.  Perhaps on Monday we'll take a look at maybe aligning the beam onto this PD, and look at the impedance of both this PD, and the AMPMON PD to see why the reading on the DMM changed last night when we had the DAQ cable T-ed in, and not T-ed in. 

 

  2004   Fri Sep 25 19:55:59 2009 JenneUpdateAdaptive FilteringSubtraction of the microseism using Adaptive Filtering!

[Rana, Jenne]

The OAF system did something useful today!  Attached is a plot.  Black is the reference (13 averages) with the OAF off.  Blue is the output of the OAF, and red is the reduced MC_L signal (13 averages).  If you turn tau and mu both to 0, it "pauses" the filter, but keeps the feedforward system working, so that you can take a long average to get a better idea of how well things are working. If you ramp down the output of the CORR filter bank, that lets you take a long average with the OAF "off", but doesn't mess up your nicely adapted filter.  The cyan and gold traces in the upper plot are 2 of the Guralp channels, so you can see the real seismic motion.

In the lower plot, you can see that the cyan and light green seismic channels have good coherence with IOO-MC_L (the names don't really mean anything right now...these 2 seismometer channels are the 2 Guralps' channels, one per end of the MC, which are aligned with the MC.)  The dark blue trace is the coherence between IOO-MC_L and the output of the OAF.

500 taps, delay=5, 2 Guralp channels (the ones aligned with the MC), tau~0.00001 (probably), and mu~0.01 or 0.005

Attachment 1: OAF_running_WORKING_25Sept2009.png
OAF_running_WORKING_25Sept2009.png
  2006   Sat Sep 26 13:55:20 2009 JenneUpdateMZMZ was locked in a bad place

I found the MZ locked in a bad place earlier today.  It was locked in a similarly bad spot yesterday after we fixed the cable situation for 126MOPA_126MON, with reflection of ~0.8, rather than the nominal 0.305.  It's good now though. 

  2007   Sun Sep 27 12:52:56 2009 ranaUpdateMOPAIncreasing the power from the MOPA

This is a trend of the last 20 days. After our work with the NPRO, we have recovered only 5% in PMC trans power, although there's an apparent 15% increase in AMPMON.

The AMPMON increase is partly fake; the AMPMON PD has too much of an ND filter in front of it and it has a strong angle dependence. In the future, we should not use this filter in a permanent setup. This is not a humidity dependence.

The recovery of the refcav power mainly came from tweaking the two steering mirrors just before and just after the 21.5 MHz PC. I used those knobs because that is the part of the refcav path closest to the initial disturbance (NPRO).

BTW, the cost of a 1W Innolight NPRO is $35k and a 2W Innolight NPRO is $53k. Since Jenne is on fellowship this year, we can afford the 2W laser, but she has to be given priority in naming the laser.

Attachment 1: Picture_3.png
Picture_3.png
  2008   Sun Sep 27 14:45:45 2009 KojiUpdatePSLSLOWscan result

I ran (script dir)/PSL/FSS/SLOWscan on op440m from 11:30 to 12:30 on 27th. Although Rana and later I myself set "timed bombs" for the scan, they did not work as they have probably been ran on Linux. After the scan I relocked PMC, FSS, and MZ . MC locked automatically.

Observation:

1. To keep away from the mode hop, FSS_SLOWDC is to be at around 0. The values -5 ~ -6 is the place for the power, which is my preference for now. BTW, the mode hop only appears to the PSL output (=AMPMON) is this normal?

2. The PSL output looks dependent on the NPRO wavelength. The NPRO output and the PSL output tends to be high when the FSS_SLOWDC is low (= LTMP: Laser Crystal Temp is low). Also there is a step at the LTMP where we think the mode hop is present. This may cause the daily PSL output variation which induced by the daily change of the reference cavity length.

My naive speculation is that the NPRO wavelength is too long (= hot side) for the MOPA absorption as the MOPA heads are cooled to 19deg.

3. Scanning of -10 to +10 changes the LTMP from 42-49deg. This is almost 1/10 of the NPRO capability. The manual told us that we should be able to scan the crystal temperature +/-16deg (about 30deg to 60deg).

What I like to try:
a) Change the NPRO temp to more cold side.
b) Change the MOPA head temp to a bit hot side.
c) Tweak the MOPA current (is it difficult?)

Attachment 1: SLOWscan_090927.png
SLOWscan_090927.png
Attachment 2: Pages_from_miser_126_manual.png
Pages_from_miser_126_manual.png
  2009   Sun Sep 27 15:25:58 2009 KojiUpdatePSLSLOWscan result
Oh, AMPMON dependence could be an artifact of the ND filter???
For my case, it should be real dependence on the NPRO wavelength,
as the other PDs like the PMC reflection (PMC_RFPDDC) and the RC reflection (FSS_RFPDDC) show the same dependence.
Attachment 1: power_dependence.png
power_dependence.png
  2010   Sun Sep 27 23:21:14 2009 ranaUpdatePSLSLOWscan result

Quote:

What I like to try:
a) Change the NPRO temp to more cold side.
b) Change the MOPA head temp to a bit hot side.
c) Tweak the MOPA current (is it difficult?)

 I think that the AMPMON ND problem was just that the responsivity changes with angle. So when I aligned it a little we got some few% improvement in the signal which is not a real power increase.

I don't think we can adjust any of the MOPA parameters because the controller is broken, but we can try the NPRO crystal temperature.

  2011   Mon Sep 28 02:24:05 2009 ranaUpdateLockingMC1/3 Dewhitening found OFF: Turned back ON

While trying to make the OAF work, I found that the XYCOM switches for MC1/3 have been set in the bad way for awhile. This means that the hardware filters were bypassed and that MC1 & MC3 were moving around too much at high frequency and possibly causing trouble with the locking. I have put them back into the default position.

On Friday, Jenne and I were playing around with turning the dewhitening off/on to see if it efffected the OAF stability. At the time, I didn't pay too much attention to what the state was. Looks like it was in the wrong state (hardware bypassed) when we found it. For the OAF work, we generally want it in that bypassed state, but its bad because it makes noise in the interferometer. The bits in question are bits 16-23 on the XYCOM screen.

I have updated the snapshot and set the screen in the appropriate settings. I used a swept sine measurement to verify the filter state. In the attached plot, green corresponds to XYCOM green and red corresponds to red.

Attachment 1: C1SUS_SRM_XYCOM1.png
C1SUS_SRM_XYCOM1.png
Attachment 2: Untitled.png
Untitled.png
  2012   Mon Sep 28 11:52:23 2009 JenneUpdateTreasureOAF screen added to the screenshots webpage

I used Kakeru's instructions in elog 1221 to add the C1OAF screen (still called C1ASS_TOP) to the medm screenshots webpage.  The tricky part of this is figuring out that the file that needs editing is in fact in /cvs/cds/projects/statScreen, not /cvs/cds/caltech/statScreen, as claimed in the entry. 

  2013   Mon Sep 28 17:39:34 2009 robUpdatePSLproblems

The PSL/IOO combo has not been behaving responsibly recently. 

The first attachment is a 15 day trend of the MZ REFL, ISS INMON, and MC REFL power.  These show two separate problems--recurring MZ flakiness, which may actually be a loose cable somewhere which makes the servo disengage.  Such disengagement is not as obvious with the MZ as it is with other systems, because the MZ is relatively stable on its own.  The second problem is more recent, just starting in the last few days.  The MC is drifting off the fringe, either in alignment, length, or both.  This is unacceptable.

The second attachment is a two-day trend of the MC REFL power.  Last night I carefully put the beam on the center of the MC-WFS quads.  This appears to have lessened the problem, but it has not eliminated it. 

It's probably worth trying to re-measure the MCWFS system to make sure the control matrix is not degenerate. 

Attachment 1: problems.png
problems.png
Attachment 2: problems2.png
problems2.png
  2017   Tue Sep 29 10:44:29 2009 KojiUpdateMZMZ investigation

Rana, Jenne, Koji

Last night we checked MZ. The apparent thing we found was the gain slider does not work.
The slider actually changes the voltage at the cross connection of 1Y2 (31 pin4?), the gain does not change.
The error spectrum didn't change at all even when the slider was moved.

Rana poked the flat cable at the bottom of 1Y2, we had no imporvement.

We coudn't find the VME extender board, so we just replaced AD602 (=VGA) and LT1125 (=Buffer for the ctrl voltage).
Even after the replacement, the gain slider is not working yet.

Today, I will put a lead or probe to the board to see whether the slider changes the voltage on the board or not.

Somehow the gain is sitting at a intermediate place that is not to low not to high. So I still don't know the gain slider
is the cause of the MZ instability or not.

  2018   Tue Sep 29 12:47:08 2009 KojiUpdateMZMZ unlocked

12:45 I started the work on MZ. Thus the MZ was unlocked.

Found the bad connection on the FLKM 64pin cross connection board. We need a replacement.

I went to Wilson and got the replacement, two VME extender boards, three 7815, and three 7915. Thanks, Ben!

  2020   Tue Sep 29 18:21:41 2009 KojiUpdateMZMZ work done

The MZ work completed. I replaced the bad cross connection terminal. The gain slider is working now.

I looked at the error spectrum on an FFT analyzer. I could see the lock was more tight.

Then I proceeded to the MZ epics panel.

1) C1:PSL-MZ_MZTRANSPD has no meaning (not connected). So I put  C1:PSL-ISS_INMONPD as the MZ trans monitor.

2) The EPICS setting for the MZ gain slider was totaly wrong.
    Today I learned from the circuit, the full scale of the gain slider C1:PSL-MZ_GAIN gave us +/-10V at the DAC.
    This yield +/-1V to V_ctrl of the AD602 after the internal 1/10 attenuation stage.
    This +/-1V didn't correspond to -10dB~+30dB, but does -22dB~+42dB and is beyond the spec of the chip.

    The gain of AD602 is calculated by

G [dB] = 32 V_crtl + 10,  for -0.625 [V]< V_ctrl < +0.625 [V].

    In order to fix this I used the following commands which overrode the EPICS parameters.
    The tip of EGUF/EGUL is to know how much the gain (virtually) goes for the full scale of the DAC output. 

ezcawrite C1:PSL-MZ_GAIN.EGUF 42
ezcawrite C1:PSL-MZ_GAIN.EGUL -22
ezcawrite C1:PSL-MZ_GAIN.DRVH 30
ezcawrite C1:PSL-MZ_GAIN.DRVL -10
ezcawrite C1:PSL-MZ_GAIN.HOPR 30
ezcawrite C1:PSL-MZ_GAIN.LOPR -10

   and for the permanent change I modified the db file /cvs/cds/caltech/target/c1iool0/c1iooMZservo.db
   This will be active when cliool0 is rebooted.

# This yields the output limited to -6.25V ~ +6.25V, which corresponds to -10dB ~ +30dB
# modified by Koji Arai (29-Sept-2009)
grecord(ao,"C1:PSL-MZ_GAIN")
{
        field(DESC,"GAIN- overall pre-modecleaner servo loop gain")
        field(SCAN,"Passive")
        field(PINI,"YES")
        field(DISV,"1")
        field(DTYP,"VMIVME-4116")
        field(OUT,"#C3 S5 @")
        field(EGUF,"42")
        field(EGUL,"-22")
        field(PREC,"1")
        field(EGU,"dB")
        field(HOPR,"30")
        field(LOPR,"-10")
        field(DRVH,"30")
        field(DRVL,"-10")
        field(LINR,"LINEAR")
        field(OROC,"0")
        field(DOL,"0")
}

# previous code
grecord(ao,"C1:PSL-MZ_GAIN")
{
        field(DESC,"GAIN- overall pre-modecleaner servo loop gain")
        field(SCAN,"Passive")
        field(PINI,"YES")
        field(DISV,"1")
        field(DTYP,"VMIVME-4116")
        field(OUT,"#C3 S5 @")
        field(EGUF,"30")
        field(EGUL,"-10")
        field(PREC,"4")
        field(EGU,"Volts")
        field(HOPR,"30")
        field(LOPR,"-10")
        field(LINR,"LINEAR")
        field(OROC,"0")
        field(DOL,"0")
}

Quote:

12:45 I started the work on MZ. Thus the MZ was unlocked.

Fond the bad connection on the FLKM 64pin cross connection board. We need the replacement.

I went to Wilson and got the replacement, two VME extender boards, three 7815, and three 7915. Thanks, Ben!

 

  2021   Tue Sep 29 21:37:09 2009 ranaUpdateMZMZ work done : some noise checking

Since we used to run with a gain slider setting of +15 dB on the MZ, I wanted to check that the new setting of +30dB was OK. It is.

To check it I turned it up and looked for some excess noise in the ISS or in the MC. There was none. I also set the input offset slider by unlocking the PMC and zeroing the mixer monitor readback. The new slider setting is -6.5V.

I don't know why we would need more gain on the MZ loop, but we can have some if we want it by turning up the gain before the servo (optical or RF). The attached plot shows the MC_F and ISS signals with the ISS loop on and off. There was no change in either of these spectra with the MZ gain high or low.

Attachment 1: fsm.pdf
fsm.pdf
  2022   Tue Sep 29 21:51:32 2009 KojiUpdateMZMZ work done : some noise checking

The previous "+15" was Vctrl = 0.25 [V]. Which was +18 dB.

Quote:

Since we used to run with a gain slider setting of +15 dB on the MZ, I wanted to check that the new setting of +30dB was OK.

 

  2023   Tue Sep 29 22:51:20 2009 KojiUpdateMZPossible gain mis-calibration at other places (Re: MZ work done)

Probably there is the same mistake for the PMC gain slider. Possibly on the FSS slider, too???

Quote:

2) The EPICS setting for the MZ gain slider was totaly wrong.
    Today I learned from the circuit, the full scale of the gain slider C1:PSL-MZ_GAIN gave us +/-10V at the DAC.
    This yield +/-1V to V_ctrl of the AD602 after the internal 1/10 attenuation stage.
    This +/-1V didn't correspond to -10dB~+30dB, but does -22dB~+42dB and is beyond the spec of the chip.

  2024   Tue Sep 29 23:43:46 2009 robUpdateSUSITMY UL OSEM

We had a redo of elog entry 975 tonight.  The noisy OSEM was fixed by jiggling the rack end of the long cable.  Don't know exactly where--I also poked around the OSEM PD interface board.

In the attached PDF the reference trace is the noisy one.

Attachment 1: ITMYosemBAD.pdf
ITMYosemBAD.pdf
  2026   Wed Sep 30 01:04:56 2009 robUpdateComputersgrief

much grief.  somehow a burt restore of c1iscepics failed to work, and so the LSC XYCOM settings were not correct.  This meant that the LSC whitening filter states were not being correctly set and reported, making it difficult to lock for at least the last week or so.

Attachment 1: C1LSC_XYCOM.jpg
C1LSC_XYCOM.jpg
  2027   Wed Sep 30 02:01:28 2009 robUpdateLockingweek

It's been a miserable week for lock acquisition, with each night worst than the last.  The nadir was around Sunday night, when I couldn't even get a PRM to lock stably, which meant that the auto-alignment scripts could not finish successfully.  It now appears that was due to some XYCOM mis-settings. 

We've also been having problems with timing for c1susvme2.  Attached is a one-hour plot of timing data for this cpu, known as SRM.  Each spike is an instance of lateness, and a potential cause of lock loss.  This has been going on for a quite a while.

Tonight we also encountered a large peak in the frequency noise around 485 Hz.  Changing the MZ lock point (the spot in the PZT range) solved this.

 

Attachment 1: srmcpu.png
srmcpu.png
  2028   Wed Sep 30 12:21:08 2009 JenneUpdateComputersrestarted the elog

I'm blaming Zach on this one, for trying to upload a pic into the ATF elog (even though he claims it was small....)  Blame assigned: check.  Elog restarted: check.

  2029   Wed Sep 30 17:49:21 2009 JenneUpdateAdaptive FilteringNew UP/DOWN scripts for OAF

[Sanjit, Jenne]

The up and down scripts accessible from the OAF (still C1:ASS-TOP) screen are now totally functional and awesome.  They are under the blue ! button.  The up script can either be for the Seismometers, or the Accelerometers at this time.  The only difference between these 2 is which burt restore file they look at:  the seismometer version puts all 7 seismometer channels in the PEM selecting matrix, while the accelerometer version puts the 6 accelerometer channels in that matrix.  Both scripts also turn on HP_1mHz filters in the ERR_EMPH filter bank and all of the witness filter banks, and the AA32 and AI32 filters in ERR_EMPH, CORR and PEM filter banks.  This makes all of the starting filters the same between the witness paths and the error path.

If you want to use a different combination of sensors, run one of the up scripts, then change the PEM matrix by hand. 

The down script disables the output to the optics, and resets the adapted filter coefficients.  DO NOT use this script if you're trying to "pause" the filter to take some nice long averages.

  2030   Thu Oct 1 03:12:56 2009 robUpdateLockingsome progress

Good progress in IFO locking tonight, with the arm powers reaching about half the full resonant maximum. 

Still to do is check out some weirdness with the OMC DAC, fix the wireless network, and look at c1susvme2 timing.

  2031   Thu Oct 1 08:37:43 2009 steveUpdateSUSsuspention damping restored and MZ HV stuck

Earthquake  of magnitude 5.0  shakes ETMY loose.

MC2 lost it's damping later.

Attachment 1: eq5oct1.jpg
eq5oct1.jpg
  2032   Thu Oct 1 09:36:09 2009 KojiUpdateMZMZ relocked (Re:suspention damping restored and MZ HV stuck)

MZ stayed unlocked. Now It was relocked.

Quote:

Earthquake  of magnitude 5.0  shakes ETMY loose.

MC2 lost it's damping later.

 

  2033   Thu Oct 1 10:23:00 2009 steveUpdatePSLMC2 damping restored again

 The EQ did not change the input beam pointing. All back to normal, except MC2 wachdogs tripped again.

Attachment 1: mc2again.jpg
mc2again.jpg
  2034   Thu Oct 1 11:39:47 2009 JenneUpdateSUSMC2 damping restored again

Quote:

 The EQ did not change the input beam pointing. All back to normal, except MC2 wachdogs tripped again.

 Round 3 for the day of MC2 watchdogs tripping.

  2035   Thu Oct 1 13:12:41 2009 KojiUpdateMZMZ Work from 13:00-

I will investigate the MZ board. I will unlock MZ (and MC).

  2036   Thu Oct 1 14:22:28 2009 robUpdateSUSall suspensions undamped

Quote:

Quote:

 The EQ did not change the input beam pointing. All back to normal, except MC2 wachdogs tripped again.

 Round 3 for the day of MC2 watchdogs tripping.

 I've watchdogged all the suspensions while I mess around with computers.  If no one else is using the IFO, we can leave them undamped for a couple of hours to check the resonant frequencies, as long as I don't interrupt data streams with my computer hatcheting.

  2037   Thu Oct 1 15:42:55 2009 robUpdateLockingc1susvme2 timing problems update

Quote:

We've also been having problems with timing for c1susvme2.  Attached is a one-hour plot of timing data for this cpu, known as SRM.  Each spike is an instance of lateness, and a potential cause of lock loss.  This has been going on for a quite a while.

 

 

Attached is a 3 day trend of SRM CPU timing info.  It clearly gets better (though still problematic) at some point, but I don't know why as it doesn't correspond with any work done.  I've labeled a reboot, which was done to try to clear out the timing issues.  It can also be seen that it gets worse during locking work, but maybe that's a coincidence.

Attachment 1: srmcpu2.png
srmcpu2.png
  2038   Thu Oct 1 19:04:05 2009 KojiUpdateMZMZ work done (Re: MZ Work from 13:00-)

MZ work has been done. I did not change anything on the circuit.

Recently we observed that the MZ PZT output was sticking at a certain voltage. I found the reason.
Shortly to say "we must return the PZT Ramp offset to 0, after the lock"

I am going to write a MZ auto lock script someday, to do it automatically.


According to the resister values used in the circuit, the PZT HV output voltage is determined by the following formula:

V_PZT = 150 - 12 V_ctrl - 24 Vramp

Here the ramp voltage Vramp moves from -10V to +10V, the feedback control voltage V_ctrl moves from -13V to +13V.
The baseline offset of 150V is provided in the circuit board.

When V_ramp is 0, V_PZT runs from 0 to 300. This is just enough for the full scale of the actual V_PZT range,
that is 0V~280V.

If any Vramp offset is given, V_PZT rails at either side of the edges. This limits the actual range of the PZT out.

This is not nice, but is what happened recently.

Quote:

I will investigate the MZ board. I will unlock MZ (and MC).

 

Attachment 1: MZ_PZT.pdf
MZ_PZT.pdf
  2039   Thu Oct 1 19:18:24 2009 KojiUpdateSUSall suspensions undamped

Ops. I restored the damping of the suspensions at around 16:30.

Quote:

Quote:

Quote:

 The EQ did not change the input beam pointing. All back to normal, except MC2 wachdogs tripped again.

 Round 3 for the day of MC2 watchdogs tripping.

 I've watchdogged all the suspensions while I mess around with computers.  If no one else is using the IFO, we can leave them undamped for a couple of hours to check the resonant frequencies, as long as I don't interrupt data streams with my computer hatcheting.

 

  2040   Fri Oct 2 02:55:07 2009 robUpdateLockingmore progress

More progress with locking tonight, with initial acquisition and power ramps working.  The final handoff to RF CARM still needs work.

I found the wireless router was unplugged from the network--just plugging in the cable solved the problem.  For some reason that RJ45 connector doesn't actually latch, so the cable is prone to slipping out of the jack.

 

  2041   Fri Oct 2 14:52:55 2009 ranaUpdateComputersc1susvme2 timing problems update

The attached shows the 200 day '10-minute' trend of the CPU meters and also the room temperature.

To my eye there is no correlation between the signals. Its clear that c1susvme2 (SRM LOAD) is going up and no evidence that its temperature.

 

Attachment 1: Untitled.png
Untitled.png
  2042   Fri Oct 2 15:11:44 2009 robUpdateComputersc1susvme2 timing problems update update

It got worse again, starting with locking last night, but it has not recovered.  Attached is a 3-day trend of SRM cpu load showing the good spell.

Attachment 1: srmcpu3.png
srmcpu3.png
  2044   Fri Oct 2 17:00:06 2009 AlbertoUpdateGeneral40m Update - Requirements on the 5x Frequency Multiplier

Here's the gist of the requirements on the 5x frequency multiplier for the upgrade (see attachemnt - despite the preview down here in the elog, they're 3 pages).

An extended version is available on the wiki.

A more complete document is under work and will soon be available on the wiki as well.

Attachment 1: DesignOfTheMultiplier1-14-15.pdf
DesignOfTheMultiplier1-14-15.pdf DesignOfTheMultiplier1-14-15.pdf
  2045   Fri Oct 2 18:04:45 2009 robUpdateCDSDTT no good for OMC channels

I took the output of the OMC DAC and plugged it directly into an OMC ADC channel to see if I could isolate the OMC DAC weirdness I'd been seeing.  It looks like it may have something to do with DTT specifically.

Attachment 1 is a DTT transfer function of a BNC cable and some connectors (plus of course the AI and AA filters in the OMC system).  It looks like this on both linux and solaris.

Attachment 2 is a transfer function using sweepTDS (in mDV), which uses TDS tools as the driver for interfacing with testpoints and DAQ channels. 

Attachment 3 is a triggered time series, taken with DTT, of the same channels as used in the transfer functions, during a transfer function.  I think this shows that the problem lies not with awg or tpman, but with how DTT is computing transfer functions. 

 

I've tried soft reboots of the c1omc, which didn't work.   Since the TDS version appears to work, I suspect the problem may actually be with DTT.

Attachment 1: omc_dac_dtt.png
omc_dac_dtt.png
Attachment 2: omc_dac_sweepTDS.png
omc_dac_sweepTDS.png
Attachment 3: omc_dac_dtt_ts.png
omc_dac_dtt_ts.png
  2047   Sat Oct 3 14:53:24 2009 robUpdateLockingmore progress

Late last night after the ETMY settled down from the quake I made some more progress in locking, with the handoff to RF CARM succeeding once.  The final reduction of the CARM offset to zero didn't work, however.

  2048   Mon Oct 5 02:51:08 2009 robUpdateLockingalmost there

Working well tonight: the handoff of CARM to RF (REFL2I), successful reduction of CARM offset to zero, and transition control of MCL path to the OUT1 from the common mode board.  All that's left in lock acquisition is to try and get the common mode bandwidth up and the boost on.

  2050   Mon Oct 5 10:41:31 2009 KojiUpdatePSLPSL laser accidentally turned off

The PSL output looks smaller than the incident. Try to FSS Slow actuator adj of -5.6 (nominal), instead of -3.5.

Quote:

Alberto, Steve,

While I was moving a cart near by the PSL table I pushed the red emergency button that turns off the PSL laser. We had to unlock the button and then power cycle the laser driver to turn the laser back on.

I relocked MZ, FSS, PMC and I'm now waiting for the power to finish ramping up back to the previous value.

 

  2051   Mon Oct 5 13:43:37 2009 ZachUpdatePSLPSL table photos

I have been commissioned to take pictures of the PSL table so that it can be diagrammed. I am starting now (1:42 pm, 10/5/09).

ELOG V3.1.3-