This is a ratio of PD1_I to PD1_Q (so a ratio of the two quadratures of AS166), measured in an anti-spring state.  It's not flat because our set up has single sideband RF heterodyne detection, and using a single RF sideband as a local oscillator allows one to detect different quadratures by using different RF demodulation phases.   So the variation in frequency is actually a measure of how the frequency response of DARM changes when you vary the detection quadrature.  This measure is imperfect because it doesn't account for the effect of the DARM loop.

Even though you can choose your detection quadrature with this setup, you can't get squeezed quantum noise with a single RF sideband.  The quantum noise around the other (zero-amplitude) RF sideband still gets mixed in, and negates any squeezing benefits.

tdsresp is broken on our linux control room machines.  I made a little perl replacement which uses the DiagTools.pm perl module, called pzresp.  It's in the $SCRIPTS/general directory, and so in the path of all the machines.  I also edited the cshrc.40m file so that on linux machines tdsresp points to this perl replacement.

I've patched DiagTools.pm to circumnavigate the tdsdmd bug described here.  I also added a function to DiagTools.pm called diagRespNoLog, which is just like diagResp but without that pesky log file.

 




Here's the output from the tdsresp binary on CentOS:

allegra:~>tdsresp 941.54 10000 100 10 C1:LSC-ITMX_EXC C1:LSC-PD1_Q C1:LSC-PD1_I
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
*** glibc detected *** tdsresp: free(): invalid next size (fast): 0x089483e8 ***
======= Backtrace: =========
/lib/libc.so.6[0xa800f1]
/lib/libc.so.6(cfree+0x90)[0xa83bc0]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xf7f36571]
tdsresp[0x8057fbb]
tdsresp[0x805b394]
/lib/libc.so.6(__libc_start_main+0xdc)[0xa2ce8c]
tdsresp(__gxx_personality_v0+0x169)[0x804ddd1]
======= Memory map: ========
00242000-00249000 r-xp 00000000 fd:00 15400987                           /lib/librt-2.5.so
00249000-0024a000 r--p 00006000 fd:00 15400987                           /lib/librt-2.5.so
0024a000-0024b000 rw-p 00007000 fd:00 15400987                           /lib/librt-2.5.so
009f9000-00a13000 r-xp 00000000 fd:00 15400963                           /lib/ld-2.5.so
00a13000-00a14000 r--p 00019000 fd:00 15400963                           /lib/ld-2.5.so
00a14000-00a15000 rw-p 0001a000 fd:00 15400963                           /lib/ld-2.5.so
00a17000-00b55000 r-xp 00000000 fd:00 15400974                           /lib/libc-2.5.so
00b55000-00b57000 r--p 0013e000 fd:00 15400974                           /lib/libc-2.5.so
00b57000-00b58000 rw-p 00140000 fd:00 15400974                           /lib/libc-2.5.so
00b58000-00b5b000 rw-p 00b58000 00:00 0 
00b5d000-00b70000 r-xp 00000000 fd:00 15400984                           /lib/libpthread-2.5.so
00b70000-00b71000 r--p 00012000 fd:00 15400984                           /lib/libpthread-2.5.so
00b71000-00b72000 rw-p 00013000 fd:00 15400984                           /lib/libpthread-2.5.so
00b72000-00b74000 rw-p 00b72000 00:00 0 
00b76000-00b78000 r-xp 00000000 fd:00 15400981                           /lib/libdl-2.5.so
00b78000-00b79000 r--p 00001000 fd:00 15400981                           /lib/libdl-2.5.so
00b79000-00b7a000 rw-p 00002000 fd:00 15400981                           /lib/libdl-2.5.so
00b7c000-00ba1000 r-xp 00000000 fd:00 15400975                           /lib/libm-2.5.so
00ba1000-00ba2000 r--p 00024000 fd:00 15400975                           /lib/libm-2.5.so
00ba2000-00ba3000 rw-p 00025000 fd:00 15400975                           /lib/libm-2.5.so
00bca000-00bdd000 r-xp 00000000 fd:00 15401011                           /lib/libnsl-2.5.so
00bdd000-00bde000 r--p 00012000 fd:00 15401011                           /lib/libnsl-2.5.so
00bde000-00bdf000 rw-p 00013000 fd:00 15401011                           /lib/libnsl-2.5.so
00bdf000-00be1000 rw-p 00bdf000 00:00 0 
00dca000-00dd5000 r-xp 00000000 fd:00 15400986                           /lib/libgcc_s-4.1.2-20080825.so.1
00dd5000-00dd6000 rw-p 0000a000 fd:00 15400986                           /lib/libgcc_s-4.1.2-20080825.so.1
08048000-080b7000 r-xp 00000000 00:17 6455328                            /cvs/cds/caltech/apps/linux/tds/bin/tdsresp
080b7000-080ba000 rw-p 0006e000 00:17 6455328                            /cvs/cds/caltech/apps/linux/tds/bin/tdsresp
080ba000-080bb000 rw-p 080ba000 00:00 0 
0893d000-0896b000 rw-p 0893d000 00:00 0                                  [heap]
f5e73000-f5e74000 ---p f5e73000 00:00 0 
f5e74000-f6874000 rw-p f5e74000 00:00 0 
f692d000-f6931000 r-xp 00000000 fd:00 15400995                           /lib/libnss_dns-2.5.so
f6931000-f6932000 r--p 00003000 fd:00 15400995                           /lib/libnss_dns-2.5.so
f6932000-f6933000 rw-p 00004000 fd:00 15400995                           /lib/libnss_dns-2.5.so
f6956000-f6a12000 rw-p f6a31000 00:00 0 
f6a74000-f6a7d000 r-xp 00000000 fd:00 15400997                           /lib/libnss_files-2.5.so
f6a7d000-f6a7e000 r--p 00008000 fd:00 15400997                           /lib/libnss_files-2.5.so
f6a7e000-f6a7f000 rw-p 00009000 fd:00 15400997                           /lib/libnss_files-2.5.so
f6a7f000-f6a80000 ---p f6a7f000 00:00 0 
f6a80000-f7480000 rw-p f6a80000 00:00 0 
f7480000-f7481000 ---p f7480000 00:00 0 
f7481000-f7e83000 rw-p f7481000 00:00 0 
f7e83000-f7f63000 r-xp 00000000 fd:00 6236924                            /usr/lib/libstdc++.so.6.0.8
f7f63000-f7f67000 r--p 000df000 fd:00 6236924                            /usr/libAbort

 

It's railed.  This is what halted locking progess on Monday night, as this channel is used for the offloadMCF script, which slowly feeds back a CARM signal to the ETMs to prevent the VCO from saturating.

Attached is a 5 day trend, which shows that the channel went dead a few days ago.  All the channels shown are being collected from the same ICS110B (I think), but only some are dead.  It looks like they went dead around the time of the "All computers down" from Sunday.

 Attached are the channels being recorded from the ICS110B in 1Y2 (the IOO rack).  Channels 12, 13, 16, 17, 22, 24, 25 appear to have gone dead after the computer problems on Sunday.

 This has been fixed by one of the two most powerful & useful IFO debugging techniques: rebooting.  I keyed the crate in 1Y2.

 Apparently I broke this when I added op540m to the webstatus page.  It's fixed now.

I found the alignment biases for the PRM and the SRM in a funny state.  It seemed like they had been "saved" in badly misaligned position, so the restore scripts on the IFO configure screen were not working.  I've manually put them into a better alignment.

 I've updated the slider twiddle script to include the MC alignment biases.  We should run this script whenever we reboot all the hardware, and add any new sticky sliders you find to the end of the script.  It's at

/cvs/cds/caltech/scripts/Admin/slider_twiddle

in the rack next to the printer.  It sounds like a fan is hitting something.

At least one problem is the mis-centering of the resonant spot on MC2, which can be viewed with the video monitors.  It's very far from the center of the optic, which causes length-to-angle coupling that makes the mulitple servos which actuate on MC2 (MCL, WFS, local damping) fight each other and go unstable.

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

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

We no longer have an MC1 and MC3 camera view.

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

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

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

Steve, Rana, Ben, Jenne, Alberto, Rob

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

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

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

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

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

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

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

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

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

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

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

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

For the X arm

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

For the Y arm

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

the servo needs some work. 

2 day trend

Spent a lot of time aligning tonight.  The BS is not staying put--sometimes after a lock loss it gets badly mis-aligned. 

DD handoff is working, after putting beam on REFL diodes and running senseDRM script.

I restarted the conlogger on op340m.  This needs to be done when op340m is rebooted--it wasn't done for some reason and so we've lost several days of controls records.

 I added a cronjob on op340m to check every half-hour if the conlog is running, and if not, restart it. 

Rob, Yoichi

The MC WFS have apparently been bad for a few days, causing the MC alignment to drift away at DC.  We tried a few things to fix it, including jiggling some EPICS settings in the WFS head & demod screens.  This seemed to work for WFS1 but not WFS2.  Confused, we decided to go stare at the rack 1Y2.  While doing that, we noticed that the top two Sorensens in 1Y1 (these are directly below the Guralp box) were at different voltages from nominal.  The 5V had dropped to 4.2V and the 24V was at 24.6V.  We adjusted the knobs until these were set correctly.  After this, the MC WFS appear to work again.

When working in a rack, you must be as careful about accidentally touching things as when working on an optical table.

locking work proceeding apace tonight.

diagonalized DRM with setDDphases & senseDRM. 

initial locks are fairly quick, aqstep script succeeds reliably.

first part of cm_step (handoff CARM-> MCL) usually works.

tuning up later parts of cm_step (presumably due to optical gain changes resulting from MOPA decline). 

got to arm powers ~60.

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

rob, koji, steve

We noticed some water (about a cup) on the floor under the NESLAB chiller today.  We put the chiller up on blocks and took off the side panel for a cursory inspection, but found no obvious leaks.  We'll keep an eye on it.

A cosmic ray struck the RFM in the framebuilder this afternoon, causing hours of consternation.  The whole FE system is just now coming back up, and it appears the mode cleaner is not coming back to the same place (alignment).

rob, jenne

I measured the mode cleaner open loop gain with the HP3563A. 

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

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. 

Mode cleaner length measured tonight.

33196198

132784792

165980990

199177188

[Tag by KA: modulation frequency, MC length]

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.

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.

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.

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.

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.

 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.

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.

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.

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.

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.

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

• 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

-Rana

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.

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.

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.

 Last week, Alex recompiled the c1susvme2 code without the decimation filters for the OUT16 channels, so these channels are now as aliased as the rest of them.  This appears to have helped with the timing issues: although it's not completely cured it is much better.  Attached is a five day trend.

Last night, 2+ hour lock, probably broken by me driving too hard (DARM_EXC).

The IFO can now be locked during the daytime.  Well, it's locked now.

I pushed the "closed loop" button on PZT2 YAW around 3:40 pm today, then roughly recentered it using the DC Offset knob on the PiezoJena controller and the IP ANG QPD readbacks.  There was a large DC shift.    We'll watch and see how much it drifts in this state.