40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 41 of 339  Not logged in ELOG logo
IDup Date Author Type Category Subject
  2016   Tue Sep 29 01:50:10 2009 robConfigurationLSCnew modulation frequencies

Mode cleaner length measured tonight.

 

33196198

132784792

165980990

199177188

[Tag by KA: modulation frequency, MC length]

  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!

  2019   Tue Sep 29 16:14:44 2009 robConfigurationElectronicsRob is breaking stuff....

Quote:

Koji and I were looking for an extender card to aid with MZ board testing.  Rob went off on a quest to find one.  He found 2 (in addition to the one in the drawer near the electronics bench which says "15V shorted"), and put them in some empty slots in 1X1 to test them out.  Somehow, this burned a few pins on each board (1 pin on one of them, and 3 pins on the other). We now have 0 functioning extender cards: unfortunately, both extender cards now need fixing.  The 2 slots that were used in 1X1 now have yellow electrical tape covering the connectors so that they do not get used, because the ends of the burnt-off pins may still be in there. 

In other, not-Rob's-fault news, the Martian network is down...we're going to try to reset it so that we have use of the laptops again.

 

This happened when I plugged the cards into a crate with computers, which apparently is a no-no.  The extender cards only go in VME crates full of in-house, LIGO-designed electronics.

  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
  2025   Tue Sep 29 23:43:49 2009 ranaAoGall down cond.Cosmic

Actel1.jpg

cosmic rays in cars

  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
  2043   Fri Oct 2 15:24:29 2009 sanjit, ranaSummaryIOOmcwfs centered

we set the offsets for the MCWFS DC and for the MCWFS demod outputs and then turned off the lights put the MZ at half fringe and then centered the spots on the MCWFS heads.

The MCREFL beam looks symmetric again and the MC REFL power is low. 

Attachment 1: Untitled.png
Untitled.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
  2046   Fri Oct 2 18:26:32 2009 robAoGEnvironmentearthquake

quake coming through.  I've re-enabled optic damping (except ETMY), and left off the oplevs for now.  We can do a resonant-f  check over the weekend.

Looks like it was a magnitude 5 near Olancha, where they sell really good fresh jerky.  quake

Earthquake Details

Magnitude 5.2
Date-Time
  • Saturday, October 03, 2009 at 01:15:59 UTC
  • Friday, October 02, 2009 at 06:15:59 PM at epicenter
Location 36.393°N, 117.877°W
Depth 0 km (~0 mile) (poorly constrained)
Region CENTRAL CALIFORNIA
Distances
  • 11 km (7 miles) S (182°) from Keeler, CA
  • 16 km (10 miles) ENE (59°) from Cartago, CA
  • 18 km (11 miles) NE (37°) from Olancha, CA
  • 28 km (17 miles) SE (141°) from Lone Pine, CA
  • 239 km (148 miles) W (276°) from Las Vegas, NV
Location Uncertainty horizontal +/- 0.6 km (0.4 miles); depth +/- 2.2 km (1.4 miles)
Parameters Nph=030, Dmin=19 km, Rmss=0.28 sec, Gp= 79°,
M-type=local magnitude (ML), Version=C
Source
Event ID ci14519780
  • This event has been reviewed by a seismologist.

latest news: there's actually been about a dozen earthquakes in Keeler in the last couple hours:   http://earthquake.usgs.gov/eqcenter/recenteqsus/Maps/special/California_Nevada_eqs.php

California_Nevada.gif-Rana

  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.

  2049   Mon Oct 5 09:31:05 2009 AlbertoFrogsPSLPSL laser accidentally turned off

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.

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

  2052   Mon Oct 5 14:18:41 2009 ZachUpdatePSLPSL table photos

Quote:

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

All done (for now). That wasn't so bad, was it?

  2053   Mon Oct 5 14:37:29 2009 AlbertoUpdateABSLAbsolute Length Meaasurement NPRO is on

In the revival of the experiement length measurement for the recycling cavities, I turned the auxiliary NPRO back on. The shutter is closed.

I also recollected all the equipment of the experiment after that during the summer it had been scattered around the lab to be used for other purposes (Joe and Zach's cameras and Stephanie and Koji's work with the new EOM).

  2054   Mon Oct 5 18:34:26 2009 JenneUpdateAdaptive FilteringAttempts to take a TF of the OAF system

[Jenne, Sanjit]

As per Matt's instructions in his OAF document (elog 395) in the Tuning section, Sanjit and I took a transfer function measurement from the output of the OAF system, to the input.  i.e. we're trying to measure what happens out in the real world when we push on MC1, and how that is fed back to the input of our filter as MC_L.  The game plan is to measure this transfer function, and read off the phase at the nyquist frequency, and use this value to calculate the appropriate sample-and-hold delay to be used in the OAF.  The downsample rate for the OAF is 32, so that we're running at 64Hz instead of the 2048Hz of the front-end.  Thus, our Nyquist frequency is 32Hz.

                            DownSampleRate

Phase@Nyquist * ------------------------

                                    180

In the attached figure we do a swept sine from CORR_EXC to ERR_EMPH_OUT to determine the transfer function.  Here, we turn off all of the filters in both the CORR and EXC banks, because those are already matched/taken into account in the PEM filter banks. 

Using the cursor on DTT, we find that the phase at 29.85Hz is -228.8deg, and at 37.06Hz is -246.0deg.  Extrapolating, this means that at 32Hz, we expect about -234deg phase.  Using our handy-dandy formula, this means that we should try a delay of 41 or 42 (41.6 is between these two...) 

We'll give this a shot!

Attachment 1: OAF_TF_CORRexc_EMPHout_2.png
OAF_TF_CORRexc_EMPHout_2.png
  2055   Mon Oct 5 19:39:26 2009 KojiUpdatePSLPSL laser accidentally turned off

I set the FSS slow actuator adj to -5.6 at the lunch time. It gave a little help at that time. Now max of the MC Trans is comming back somehow. I hope the MC Trans level is as good as before, if the HEPA is slowed down.

Quote:

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.

 

 

  2056   Tue Oct 6 01:41:20 2009 robUpdateLockingDC Readout

Lock acquisition working well tonight.  Was able to engage CM boost (not superboost) with bandwidth of ~10kHz.  Also succeeded once in handing off DARM to DC readout.

  2057   Tue Oct 6 10:09:55 2009 ZachUpdatePSLMore pictures

I'm back to terrorize the PSL table again. The pictures I took yesterday were rubbish--today I'm using a clamp that Steve was nice enough to loan me. I'm starting now, at 10:09 am.

  2058   Tue Oct 6 11:13:53 2009 JenneUpdateAdaptive FilteringAttempts to take a TF of the OAF system

Quote:

[Jenne, Sanjit]

As per Matt's instructions in his OAF document (elog 395) in the Tuning section, Sanjit and I took a transfer function measurement from the output of the OAF system, to the input.  i.e. we're trying to measure what happens out in the real world when we push on MC1, and how that is fed back to the input of our filter as MC_L.  The game plan is to measure this transfer function, and read off the phase at the nyquist frequency, and use this value to calculate the appropriate sample-and-hold delay to be used in the OAF.  The downsample rate for the OAF is 32, so that we're running at 64Hz instead of the 2048Hz of the front-end.  Thus, our Nyquist frequency is 32Hz.

                            DownSampleRate

Phase@Nyquist * ------------------------  =  Delay

                                    180

In the attached figure we do a swept sine from CORR_EXC to ERR_EMPH_OUT to determine the transfer function.  Here, we turn off all of the filters in both the CORR and EXC banks, because those are already matched/taken into account in the PEM filter banks. 

Using the cursor on DTT, we find that the phase at 29.85Hz is -228.8deg, and at 37.06Hz is -246.0deg.  Extrapolating, this means that at 32Hz, we expect about -234deg phase.  Using our handy-dandy formula, this means that we should try a delay of 41 or 42 (41.6 is between these two...) 

We'll give this a shot!

 As Rana pointed out to me last night, I was using continuous phase, which is not good.  When using regular phase, I find: (29.85Hz, 131.216deg), (37.06Hz, 113.963deg), so extrapolating gives (32Hz, 126.07deg).  Plugging this in to our handy-dandy formula, we get a delay of 22.4, so we should try both 22 and 23.

  2059   Tue Oct 6 20:09:50 2009 JenneOmnistructureEnvironmentRF area is clean!

I spent part of the afternoon cleaning up the area next to the Mode Cleaner where we keep all of our RF stuff:  Attenuators, BNC/SMA/LEMO adapters, Mini-Circuits items, and all sorts of other things which are useful while looking at our electronics/RF stuff.

We got another set of "Lyon" drawers, which aided in the organization process....Bob ordered 2, so we now have a 'spare' drawer set if anyone can think of something else to organize (unless this was premeditated for optics or something else?).

As you can see in the picture, (1) it's no longer a total disaster over there, and (2) some of the drawers have sub-divisions to make it faster and easier to find what you're looking for.  Please help out by putting things away in their proper place, and adding more labels or dividers to the drawers if there's something else which needs a 'spot'.

Attachment 1: DSC_0894.JPG
DSC_0894.JPG
  2060   Tue Oct 6 23:39:54 2009 KojiOmnistructureEnvironmentRF area is clean!

Awesome.

I propose that anyone who tries to do this kind of thoroughgoing cleaning should make an e-mail to call everyone available to join just for some hours
because every member has a responsibility to keep the lab organized.

And we have the list of things to do: Electronics (now it is halfway) / Cables / Optics / Screws / Tools ...

Quote:

I spent part of the afternoon cleaning up the area next to the Mode Cleaner where we keep all of our RF stuff:  Attenuators, BNC/SMA/LEMO adapters, Mini-Circuits items, and all sorts of other things which are useful while looking at our electronics/RF stuff.

We got another set of "Lyon" drawers, which aided in the organization process....Bob ordered 2, so we now have a 'spare' drawer set if anyone can think of something else to organize (unless this was premeditated for optics or something else?).

As you can see in the picture, (1) it's no longer a total disaster over there, and (2) some of the drawers have sub-divisions to make it faster and easier to find what you're looking for.  Please help out by putting things away in their proper place, and adding more labels or dividers to the drawers if there's something else which needs a 'spot'.

 

  2061   Wed Oct 7 03:49:49 2009 ranaUpdateAdaptive FilteringAttempts to take a TF of the OAF system

 Here's a plot of the spectra of the seismometers and MCL. The coherence shows which axes are aligned right now: MC1_X is coherent with GUR_NS which means that its mis-oriented.

I've now swapped the "MC1" cables: so the old "NS" now goes into EW and the old EW now goes into NS. VERT is unchanged.

Also fixed the channel names - the Guralp previously named MC1 is now GUR1 and the other one is GUR2. Also no more EW, NS, & VERT. Its all XYZ.

DAQD restarted with the new channel names.

Attachment 1: Untitled.png
Untitled.png
  2062   Wed Oct 7 06:26:09 2009 ranaHowToIOOMC_L calibration + some DTT lore

I drove MC2 in POS and used the resulting response in MC_F to calibrate the IOO-MC_L channel.

Yoichi did an excellent job of calibrating MC_F last year. I have used his calibration of MC_F (220 Hz/count @ DC) to get the MC_L calibration at DC as well as at high frequencies. The hardware dewhitening was OFF for all these measurements.

Method

1. For the DC measurement I excited C1:SUS-MC2_MCL_EXC at 0.0731 Hz. At these frequencies, the MC_L path has much more gain than the MC_F path. So this excitation at the error point makes the length path to drive itself to cancel the digital excitation. Since the overall MC servo gain is huge, this causes the MC_F path to compensate the residual MC_L motion. One can simply take the ratio of MC_L/MC_F to get the calibration of MC_L in Hz.

2. For the AC measurement, I engaged FM9 of the MC2_MCL filter bank. This guy is an elliptic LP with a notch at 660.38 Hz. I then drove MC2_LSC at 660.38 Hz with a sine wave of 500 counts amplitude. The notch makes the gain of the MC_L feedback zero at that frequency. So MC_F has to do all the work. We can simply measure the ratio of MC2_LSC/MC_F to get the AC calibration of MC2_MCL_OUT (aka IOO-MC_L) and MC2_LSC_OUT (aka LSC-MC_L).

 

Results:

MCF/MCL @ 0.0731 Hz = 569.4. So the MC_L calibration at DC is 220 x 569.4 = 125 kHz/count or 6.02 nm/count.

From this we would expect the AC calibration to be (6 nm/count)*(660.38/f_pend)^2 = 13.0 x10^-15 m/count.

The AC measurement gave 1445 counts_peak** of MC_F for the 500 counts (peak) excitation in MC2_LSC. From Yoichi's entry we get that the high frequency calibration of MC_F should be 0.089 Hz/count. So the MC_L calibration at 660 Hz is 0.089*1445/500 = 0.25 Hz / count or 12.3 x 10^-15 m/count. So the AC/DC ratio is close to 1.

Splitting the difference, the new official MC_L calibration is 5.87 nm/counts @ DC with a complex pole pair at 0.972 Hz.

 

** note:  To convert from the peak height observed in DTT with a 50% Overlap Hanning window you must use the following intuitive formula:  counts_peak = (counts / rHz) * sqrt(2 * BW). In this case, BW is the number that DTT reports as BW on the screen, NOT the BW that you asked for on the measurement tab.

*** note: when measuring peak heights in a DTT FFT, make sure to unclick the box for 'Bin' under the config tab. Bin suppresses peaks in a plot with a lot of points and is ON by default.

**** note: I have updated the MCF reference in the Templates directory with the Yoichi calibration - spectrum attached. This is probably the most accurate MCF spectrum we have ever put in the elog in the history of the 40m. The implication is that the VCO phase noise is ~5 mHz/rHz. Not bad.

***** note: with the OAF off, I drove a 1.55 Hz sine wave into MC1 and measured the ratio of MC1_MCL_OUT/IOO-MC_L. This gives the DC calibration of MC1_MCL_OUT = 7.98 nm/count.

Attachment 1: mcl-cal.png
mcl-cal.png
Attachment 2: a.png
a.png
  2063   Wed Oct 7 07:42:55 2009 ranaUpdateAdaptive FilteringAttempts to take a TF of the OAF system

I remeasured the OAF time delay using the OAF-TF template from the Templates/ directory.

Troublingly, I found the MC1 dewhitening switches set OFF - please make sure that the MC1 dewhitening is back ON after each OAF tuning so that the interferometer locking is not hosed.

The OAF-TF template had the excitation amplitude set ~20x too high. I reduced it and the coherence was still > 0.95. The phase at 32 Hz was still ~126 deg as Jenne had measured, but since the phase at DC is 180 deg, the overall phase lag is just 180-126 = 54 deg. So the delay should be 54/180 * 32 = 9.7 => 10. Luckily, Jenne is working on an instructional manual for OAF that will make all of this crystal clear.

  2064   Wed Oct 7 11:18:40 2009 kiwamuSummaryElectronicsracks of electronics

 

I took the pictures of all racks of electronics yesterday, and then uploaded these pictures on the wiki.

http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics

You can see them by clicking "pictures" in the wiki page.

 

  2065   Wed Oct 7 19:23:49 2009 JenneUpdateAdaptive Filtering(Final?) PEM cabling changes

Quote:

 Here's a plot of the spectra of the seismometers and MCL. The coherence shows which axes are aligned right now: MC1_X is coherent with GUR_NS which means that its mis-oriented.

I've now swapped the "MC1" cables: so the old "NS" now goes into EW and the old EW now goes into NS. VERT is unchanged.

Also fixed the channel names - the Guralp previously named MC1 is now GUR1 and the other one is GUR2. Also no more EW, NS, & VERT. Its all XYZ.

DAQD restarted with the new channel names.

 I spiffed up the order of the cables / sensors plugged into the PEM ADCU.  Now all of the seismometers are labeled as Rana left them, and the 2 Guralp's have their sets of 3 channels next to eachother in channel-number-land.  None of the accelerometer names/cabling have changed recently.  In the table, Cable-label refers to the physical tag tied to the end of the cables plugged into the ADCU...they are meant to be descriptive of what seismometer channels they are hooked up to, and then the names change to something useful for us when they come into the DAQ system.  Also, the labels of input channels on the ASS_TOP_PEM screen have been updated accordingly.

 

Channel Name Channel Number on ADCU and OAF PEM list Cable-label .ini channel number
C1:SEIS-GUR2_X 2 Gur2 EW 15001
C1:SEIS-GUR2_Y 3 Gur2 NS 15002
C1:SEIS-GUR2_Z 4 Gur2 Vert 15003
C1:SEIS-GUR1_X 10 Gur1 EW 15009
C1:SEIS-GUR1_Y 11 Gur1 NS 15010
C1:SEIS-GUR1_Z 12 Gur1 Vert 15011
C1:SEIS-RANGER_Y 24 Ranger

15023

 

ELOG V3.1.3-