ELOG 40m

Locking

24.5 Hz resonance

Work continues on trying to reduce the CARM offset using dc signals from PO_DC. Got up to arm powers of
~35 last night.

We found that progress was stymied by an oscillation around 24 Hz. This oscillation was clearly visible
in the intensity of the light at REFL, PO and TrX.

Initially we suspected that this oscillation was due to an instability in the CARM loop. We attempted to
solve the problem by tuning the crossover frequncy of the AO and MC_L paths and shaping the MC_L loop to
reduce the impact of the 24 Hz noise.

After some quick tests we found that the 24 Hz signal was present even when dc CARM was used. It appears
that the peak is in fact due to a SOS mechanical resonance. We currently suspect a roll mode.

We're going to check that PRC, MICH and DARM have filters to attenuate the 24 Hz line. We'll also look at the
SUS_POS bandstop filters to see where they are centred.

The ISS was behaving strangely again. Constantly saturated at 5dB of gain. Someone needs to look a this.

Attachment 1: locking080702.png

622

Wed Jul 2 10:35:02 2008

I finished up the 2D Gaussian fitting code, and, along with Joe, integrated into the Snap software so that it automatically does a fit to every 100th image. While the fitting works, it is too slow for use in any feedback to the servos. I put together a center of mass calculation to use instead that is somewhat less accurate but much faster (almost instantaneous versus 5-10 seconds). This has yet to be added to the Snap software, but doing so would not be difficult.

I put together a different fitting function for fitting the multiple lorentzian resonance peaks in a power spectrum that would result from sweeping the length of any of the mode cleaners. This simply doesn't work. I tested it on some of Josh Weiner's data collected on the OMC last year, and the data fits poorly. Attempting to fit it all at once requires fitting 80000 data points with 37 free parameters (12 peaks at 3 parameters per peak and 1 offset parameter), which cannot be done in any reasonable time period. Attempting to fit to one specific peak doesn't work due to the corruption of the other nearby peaks, even though they are comparatively small. The fit places the offset incorrectly if given the opportunity (green line in attemptedSinglePeakFitWithoutOffset.tiff and attemptedSinglePeakFitWithoutOffsetZoomed.tiff). Removing this as a parameter causes the fit to do a much better job (red line in these two graphs). The fit still places the peak 0.01 to the right of the actual peak, which worse than could simply be obtained by looking at the maximum point value. Additionally, this slight shift means that attempting to subtract out the peak so that the other peaks are accessible doesn't work -- the peaks are so steep that the error of 0.01 is enough to cause significant problems (red in attemptedPeakSubtraction.tiff is the attempted subtraction). Part of the problem is that the peaks are far from perfect lorentzians, as seen by cropping to any particular peak (OMCSweepSinglePeak.tiff ). This might be corrected in part by correcting for the conversion from PZT voltage to position, which isn't perfectly linear; though I doubt it would remove all the irregularities. At the moment, the best approach seems to be simply using a center of mass calculation cropped to the particular peak, though I have yet to try this.

Changing Josh's code to work for the digital cameras and the PMC or MC shouldn't be difficult. Changing to the MC or PMC should simply involve changing the EPICs tags for the OMC photodiodes and PZTs to those of the PMC or MC. Making the code work for the digital cameras should be as simple as redirecting the call to the framegrabber software to the Snap software.

Attachment 1: attemptedSinglePeakFitWithoutOffset.tiff

Attachment 2: attemptedSinglePeakFitWithoutOffsetZoomed.tiff

Attachment 3: attemptedPeakSubtraction.tiff

Attachment 4: OMCSweepSinglePeak.tiff

621

Wed Jul 2 06:46:05 2008

This morning I turned on the NPRO on the AP table so that it can warm up for a few hours before I start using it today.
The flipping mirror is down so no beam is injected in to the IFO.

Alberto

620

Wed Jul 2 00:59:13 2008

Masha

balanced detection, noise plots, progress

Auxiliary locking

Progress report submitted today(!). It is on the 40m wiki page. Below is a figure of some estimated noise sources.

Made voltage divider that acts as an attenuator for one of the paths in the Mach Zehnder, which should help to balance the detection and reduce noise.

First tested using a 636 Hz Matlab generated audio signal (thanks to John inspiration on portable headphones). Figure is attached, with plots of noise spectra of original and optimized signal with and without added acoustic noise (visible as peaks as 636 and 1272 Hz, linewidth approx 4 Hz). My first try at optimization reduces the noise by nearly an order of magnitude for most frequencies.

Will work on finding different noise source to better see what happens at low frequency, and try to get finer control of tunable gain.

Attachment 1: noise_sources.pdf

Attachment 2: balancing_detectors.png

619

Tue Jul 1 21:54:05 2008

Koji

Re: Abs. Length Meas. setup

General

I tried to look for the beating in the signal from the PD but I couldn't find. I had the temperature of the laser initially set to 40deg and then slowly increased by one degree. The manual of the laser says the frequency should change by several GHz. The problem is then that our PD is limited to no more than 30Mhz.

Although the two beams seem to overlap quite well, we might still need a better matching of the injected beam.

Alberto

Quote:

o The position of the iris was adjusted so as not to disturub the beam for OMCR CCD.

o The RF spectrum analyzer was returned to the place of the network analyzer.

Quote:

In the process of making this report, I noticed that one of the iris apertures is about disturbing the beam for OMCR CCD. I will check this before I go to Hanford. Also an RF spectrum analyzer is at the AP table. I try to return this near the PSL on Monday morning.

618

Tue Jul 1 21:45:48 2008

John

Mach Zehnder script and screen

I've edited C1: PSL_MACH_ZEHNDER.adl and /cvs/cds/caltech/scripts/PSL/MZ/lockMZ
to reflect the changes described in entry #616.

617

Tue Jul 1 21:27:27 2008

rob

HowTo

Computer Scripts / Programs

slider twiddling after reboot

Sometimes after we reboot the front-end machines, some of the hardware gets stuck in an unknown state. We generally fix this by twiddling EPICS settings, which refresh the hardware somehow and put it into a known state. I've started a script (slider_twiddle) which we can just run after reboots to do this for us. Right now it just has the QPD whitening gain settings. As we find more stuff, we can add to it. It's in $SCRIPTS/Admin/.

616

Tue Jul 1 16:48:42 2008

rob, john

MZ servo switch problem resolved forever

Quote:

C1:PSL-MZ_BLANK switch (to turn on/off the servo) is not working again. The switch is always off regardless of the epics state.
I pushed the cables into the xycom card, but it did not fix the problem.

We have fixed this problem forever, by totally disabling this switch. Looking at the schematic for the MZ servo and the datasheet of the AD602, we found that a HI TTL on pin 4 disables the output of the AD602. Since the MZ servo was stuck in the off position, this seemed to indicate that it may be the XYCOM220 itself which is broken, constantly putting out a +5V signal regardless of the EPICS controls. We thought we might be able to get around this by disconnecting this signal at the cross-connect, but ultimately we couldn't find it because there is no wiring diagram for the Mach-Zehnder (!). So, we pulled the board and wired pin 9A of P1 to ground, permanently NORMALizing the MZ_BLANK switch. John has marked up the schematic, and someone should modify the MEDM screen and check the new screen into svn.

We can still the turn the MZ servo on and off by using the test input 1 switch.

Someone also will need to modify the MZ autolocker to use the test input 1 (MZ_SW1) instead of the old MZ_BLANK.

615

Tue Jul 1 14:24:58 2008

rob

HowTo

Computer Scripts / Programs

conlog time machine

I've written a perl script (now in the $SCRIPTS/general directory) which implements a "conlog restore" command, restoring channels matching a regexp to a given time using the conlog records and the EpicsTools.pm perl module. The script is called time_machine_conlog:

Quote:

op440m:~>time_machine_conlog

time_machine_conlog restores EPICS control settings using a conlog time
usage: time_machine_conlog [<--dryrun>] <date=yyyy/mm/dd,hh:mm:ss> <timezone> <regexp>

Can also accept a gps time, in which case timezone=gps.
Use the option <--dryrun> to see conlog output without restoring any settings.

EXAMPLE: time_machine_conlog 2008/05/30,12:00:00 PDT "C1:SUS-MC.*_(PIT|YAW)_COMM"

It sometimes returns an error message even when the command is successful--this is because conlog stores EPICS settings to an absurd level of precision, but ezcawrite will not write EPICS values to this level (or at least won't indicate if it did). I consider this a bug in ezcawrite so I'm not touching it.

The script is untested with regards to switch settings (such as ENABLE/DISABLE). It's mainly intended for numerical values.

614

Tue Jul 1 13:34:29 2008

Quote:

For some reason, the computers requiring startup.cmd (like c1lsc) halt after running this command. Actually the computer is running ok, but the command freezes. Basically, what it does is simply to load a kernel module. I don't know what is wrong.
Anyway, I just closed the terminal after running startup.cmd and it seems fine for now.

This is normal. On the linux RTFEs (Real-Time Front Ends), the real-time code totally hijacks the kernel, disallowing any interrupts. The system thus becomes totally unresponsive while the code is running, and communicates only through the RFM and the VME backplane.

613

Tue Jul 1 12:51:34 2008

Rana, Rob, Yoichi, John

The recent computer problems and MZ work had disturbed the alignment of the interferometer.

We adjusted the MC alignment back to nominal positions using old OSEM values. We then walked
the input beam to match the MC. Coupling into the interferometer has increased noticeably.
The rest of the IFO was then aligned to the new input beam.

Proceeding to full IFO locking we were able to engage the AO path and hand off CARM to SPOBDC.
Arm powers got up to 4.

If the new alignment proves successful we will centre all QPDs etc so we can easily return to
this state.

Attachment 1: align080701.png

612

Tue Jul 1 12:08:38 2008

Joe and I switched cables so that the PMCR screen actually shows reflection not transmission.

The trans camera had a BNC connected to "video out" labelled PMC input PD. The video signal
going to the monitors does not come from "video out", it comes out the "DC in/sync" cable.
As far as we can see this diode doesn't exist. Where should the PMC input PD BNC cable be
connected?

611

Tue Jul 1 11:57:24 2008

Yoichi

MZ servo switch problem again

610

Tue Jul 1 11:53:38 2008

I took a tour of the FE machines and power cycled all of them.
After executing the software restart procedures of those computers, the RFM network got back to the normal state.
For some reason, the computers requiring startup.cmd (like c1lsc) halt after running this command. Actually the computer is running ok, but the command freezes. Basically, what it does is simply to load a kernel module. I don't know what is wrong.
Anyway, I just closed the terminal after running startup.cmd and it seems fine for now.

609

Tue Jul 1 10:15:22 2008

The laser recovered from a short temp rise. The MZ was aligned and realigned. The suspentions were kicked up accidentally.
Now the computers are down.

Attachment 1: 2d.jpg

608

Tue Jul 1 09:26:33 2008

Mon Jun 30 18:36:01 2008

John, Yoichi

We re-adjusted the MZ alignment. The reason behind this is to make sure that the MZ dark port is not falling at a strange fringe, where it is only dark at the dark port PD. It can happen when the two beams poorly overlap.
We tried both the minimization of the MZ dark PD and the maximization of the MZ transmission at the same time.
We also placed another PD in the MZ dark port at a different distance from the original dark PD and tried to minimize this too.
If the MZ dark port is at a strange fringe, one of the dark PD can be dark where the other one is still bright.
If both of the dark PD get dark, the overlap between the beams should be ok.
We tweaked only the two mirrors of the MZ after the EOMs (mainly the one with a PZT).

Right now, the MZ dark power is 0.432.
BTW, we should change the name of the MZ dark port on the medm screen (it is now MZ reflection, where it is not a reflection).
I will try to change it later.

We wanted to put the beam position on the IOO-QPD_POS_* back to the original (before John tweaked the MZ alignment earlier).
However, the trends of IOO-QPD_POS_* show a lot of fluctuation and jumps, of which we don't know the cause. So we could not find reasonable original values.
We suspect a circuit problem in IOO-QPD_POS, especially because the jumps are very strange.
We will do this investigation later too.

606

Mon Jun 30 16:00:02 2008

josephb, sam

Computers

Sam and I setup Cat6 cable from Megatron to the 1Y6 Switch (131.215.113.252) and also connected the 1Y6 Hub to the control room switch.

While I was at it, I checked the configurations of the two switchs now connected (one in 1X4 and one in 1Y6) to the martian network. For some reason, the 1X4 had switched to DHCP enabled and was using 131.215.113.105 as an IP address. I had thought I had setup it correctly initially, so am not sure what caused the change.

The easiest way I know of to check the setup is use smartwizard discovery program from the Netgear install CD (in the equipment manual file cabinet of the control room) on a windows machine. The passwords have been set to the controls password.

Megatron should now see and be accessible through the martian network.

605

Mon Jun 30 15:56:22 2008

Fixing the LO demod signal

To make the alarm handler happy, at Rana and John's suggestion I replaced R14 of the MC's Demod board, changing it from 4.99 Ohms to 4.99 kOhms. This increased the gain of the LO portion of the demod board by a factor of 10. Sharon and I have remeasured the table of LO input to the demod board, and the output on the C1:IOO-MC_DEMOD_LO channel:

Input Amplitude to LO input on demod board [dBm]: | Value of channel C1:IOO-MC_DEMOD_LO
------------------------------------------------- | -----------------------------------
-10 | -0.00449867
-8 | 0.000384331
-6 | 0.0101503
-4 | 0.0296823
-2 | 0.0882783
0 | 0.2543
2 | 0.542397
4 | 0.962335
6 | 1.65572
8 | 2.34911
10 | 2.96925

604

Mon Jun 30 15:08:52 2008

I adjusted the alignmnet of the Mach-Zehnder's two North mirrors (downstream of the EOMs).

MZ REFL is reduced from 0.54 to 0.43. The largest improvement was due to pitch on the PZT mirror.

Attachment 1: mzalign.png

603

Mon Jun 30 14:07:26 2008

Rob

Don't put the bin in front of the air conditioning unit

Quote:

We spotted that the laser power was dropping.

the offending configuration:

Attachment 1: DSC_0140.png

602

Mon Jun 30 13:48:47 2008

John, Rob

Don't put the bin in front of the air conditioning unit

We spotted that the laser power was dropping.

The air conditioning unit was blocked by the blue bin/trash can/cestino causing the laser head temp to increase by 2 degrees.

Let's be careful about this in the future.

Attachment 1: binremoval.png

601

Mon Jun 30 09:46:15 2008

MC WFS are on. They seem to do some good during the day.

600

Mon Jun 30 08:59:23 2008

steve

IOO

IOO-MC_DEMOD_LO is low

The alarm handler is beeping relentlessly: asking for help in high partical count and low demod signal

Attachment 1: demlo.jpg_____

599

Mon Jun 30 05:33:38 2008

Koji

Abs. Len. Meas. ~ Optical setup (II)

General

o The position of the iris was adjusted so as not to disturub the beam for OMCR CCD.

o The RF spectrum analyzer was returned to the place of the network analyzer.

Quote:

598

Mon Jun 30 01:49:06 2008

I'm in the process of aligning the mode cleaner/ input beam.

I turned off the WFS and cleared their histories, adjusted the input periscope and re-aligned the mode-cleaner accordingly.
I then unlocked the cavity and centred the beams on the WFS.

MC transmission is ~3.3 and the REFL beam looks a little better.

However, turning the WFS on now lowers the transmission. More thought tomorrow.

I'm leaving the MC locked with WFS off.

597

Sun Jun 29 20:29:48 2008

Correlation of PSL SLOW control v. Room temperature

Attachment 1: slowtemp.png

596

Sun Jun 29 20:09:40 2008

John

mcup and mcdown indicators

IOO

I edited the mcup and mcdown scripts so that C1IFO_STATE shows when these scripts are running.

I also added indicators to the LockMC screen.

Attachment 1: mcscreen.png

Attachment 2: ifostate.png

595

Sun Jun 29 19:53:26 2008

Quote:

I reduced the gain of the ISS (C1: PSL-ISS_VGAGAIN) from 5dB to 2dB. Any higher and it constantly saturates.

Seemed to go back to normal after the frame builder came back.

594

Sun Jun 29 19:19:47 2008

Trends of the PSL/IOO Quads over 1000 days

IOO

Only IOO POS has been working for the past 2 years. I guess we should recommission the IOO ANG and REFL QPDs

Attachment 1: a.png

593

Sun Jun 29 18:58:43 2008

1e20 is too big for AWG and/or IOVME

Computers

While testing out my matlab/awgstream based McWFS diagnostic script I accidentally put a
huge excitation into

C1:IOO-WFS1_PIT_EXC

. This went to 1e20 and then caused
some SUS to trip and c1susvme2 to go red. I tried booting it via the normal procedures
but it wouldn't come back, even after 2 crate power cycles. I also tried booting AWG
via the vmeBusReset, but that didn't do it. Then I booted c1iovme from the telnet prompt
and then I could restart c1susvme2 successfully.

The reason the excitation was so large is that the following filter command is unstable:
[b,a] = butter(4,[0.02 30]/1024);

The low pass part is OK, but it looks like making such a low frequency digital filter
is not. Que lastima. On the bright side, the code now has some excitation amplitude
checking.

592

Sun Jun 29 14:53:02 2008

Quote:

All of the computers are now showing green lights.

Remaining problems:

Alignment scripts are failing with "ERROR: LDS - NDS server error #13"
I think this is a server transmission error.

Dataviwer shows all channels as zero.

Fixed. Just started the testpoint manager on fb40m.

su
/usr/controls/tpman &

591

Sun Jun 29 11:31:52 2008

I reduced the gain of the ISS (C1: PSL-ISS_VGAGAIN) from 5dB to 2dB. Any higher and it constantly saturates.

590

Sun Jun 29 02:33:28 2008

Koji

Abs. Len. Meas. ~ Optical setup (I)

General

Attachment 1: optical_configuration.png

Attachment 2: optical_layout_ap_table2.png

Attachment 3: optical_layout_ap_table2.pdf

589

Sat Jun 28 23:23:50 2008

Sat Jun 28 14:56:44 2008

In short, I was editing the ini files yesterday evening, I didn't e-log it and after some investigation this afternoon it apears
that I am to blame for all the computer problems which followed.

I wanted to edit C0EDCU.ini and C1IOOF.ini to change C1: PSL-FSS_FAST to a fast channel as C1: PSL-FSS_FAST_F
was dead.

I opened these files and made backups. It appears this is where it all went awry. My backup for C1IOOF
is called C1IOO.ini.090627 i.e. missing the F.

Later c1susvme2 and c1iovme crashed. After failing to bring c1iovme back I wondered if my edits had
caused the problems so I restored the back up files. It appears that here I wrote over C1IOO with my backup of
C1IOOF (presumably because I had made a typo in the name).

To remedy the situation we could restore C1IOO from e.g. chans/archive/C1IOO_080618_160028.ini

No excuses for not e-logging this activity.

587

Sat Jun 28 03:10:25 2008

Quote:

C1susvme2 and C1iovme crashed which sent the optics swinging and tripped the watchdogs.

Koji and I were able to restore c1susvme2 without any trouble.

We have been unable to revive c1iovme. We have tried telneting in and running startup.cmd,
the process runs for a while then hangs with "DAQ init failed -- exiting".

Resetting the board doesn't help. I didn't try keying the whole crate.

All optics are back to normal with damping restored.

I tried keying the crate, then keying the DAQ controller & AWG, then powering down & restarting the framebuilder.
On coming up, the framebuild doesn't start a daqd process, and I can't get one to start by hand (it just prints "652", and then stops).
No error messages and daqd doesn't appear in the prstat.

I then tried keying the DAQ controller again (after the fb0 reboot), which blew the watchdogs on all the suspensions. So then I went around and keyed all the crates.

Now, the suspension controllers are back online. Still no c1iovme, and now the framebuilder/DAQ/AWG are also hosed. We can try keying all the crates again, in the order that Yoichi did last week.

After some more poking around, I found the daqd log file. It's now complaining about

Jun 28 03:00:39 fb daqd[546]: [ID 355684 user.info] Fatal error: channel `C1: PSL-FSS_MIXERM_F' is duplicated 126

This is the second error message like this. It first complained about C1: PSL-FSS_FAST_F, so I commented that out of C1IOOF.ini and rebooted the framebuilder (note this is an actual reboot of the full solaris machine). Eventually I discovered that C1IOOF.ini and C1IOO.ini are essentially identical. They presumably will keep getting these duplicate channel errors until one of them is completely removed.

C1IOO.ini has a modification time of seven PM on Friday night. Who did this and didn't elog it? I've now modified C1IOOF.ini, and I don't remember when it was last modified.

586

Fri Jun 27 19:59:44 2008

Fri Jun 27 18:21:01 2008

Response of the LO input on the MC demod board

The alarm handler has been flipping out saying that the LO input of the MC's demod board is too low, so at Rana's suggestion, Eric and I measured the response of the LO input. We used an SR345 function generator at 29.485MHz and several different amplitudes to make a table. The demod board should see an input from the LO between 0-2dBm. When I measured what was going into the LO input from the 29.5MHz delay line phase shifter, the LO input was seeing 4dBm. I'm going to put a 3dB attenuator between the phase shifter and the demod board.

Also, now that we have this table of response values, I'm going to change the settings of the alarm handler to something more reasonable.

Amplitude of 29.485MHz input sine wave [dBm]    |        Value of channel C1:IOO-MC_DEMOD_LO
--------------------------------------------    |        -----------------------------------
-10                                             |        -0.000449867
-8                                              |        -0.000449867
-6                                              |        -0.000449867
-4                                              |        0.000384331
-2                                              |        0.00526733
0                                               |        0.0199163
2                                               |        0.0492143
4                                               |        0.0931613
6                                               |        0.161523
8                                               |        0.229885
10                                              |        0.293364

584

Fri Jun 27 18:03:46 2008

Another bad cable in the MC servo

Eric was helping me to measure the response of the LO input on the MC's Demod board, and when we disconnected the end of the cable between the demod board and the delay line phase shifter for the 29.5MHz oscillator, we noticed that the phase shifter's end of the cable was loose, like the connector wasn't fully connected. When we checked it by wiggling the connector, the SMA end fell off. I made a new SMA end for the cable, and reinstalled the cable. The MC locked as soon as I plugged the cable in, so everything seems good again. I tried to not change the cable length when I remade the connector, but the cable is shorter than it was by a small amount, due to the way the end fell off.

583

Fri Jun 27 15:20:52 2008

I removed C1:LSC-XARM_CTRL from the frames and added C1:LSC-CARM_ERR

582

Fri Jun 27 14:36:39 2008

John

dust particle count is up & alarm handler is on

Locking

Rob, Yoichi, John

Some progress last night:

Switched back to SPOB_DC for CARM.

Shaped the MC LSC loop to reduce excess noise in the 20-30Hz band. Likely the most significant change.
Could this be due to fan noise from the laptop on the SPOB table?

Brought in the AO path earlier (at low gain).

Reduced offset to 6 and increased MC gain before handing off to SPOB. Ramped up AO and MC gain then switched off the
moving zero.

Looks like PD11 is the most promising candidate for RF CARM although the demod phase needs attention.

Attachment 1: gettingcloser.png

581

Fri Jun 27 09:20:15 2008

steve

Frogs

PEM

This 3 years plot show the trend of seasons.
When outside air quality goes bad ( 0.5 micron > 1 million ) the lab follows.
I will demonstrate this effect with a 4th of July fire works calibration.
Let's do not forget the construction activity next door either.

The alarm handler is busy:
It's sound level were reset to a modest level yesterday.
It would be nice to change the alarm sound so it can play Wagner:Der Ring des Nibelungen:
Das Rheingold, Die Walkure & Siegfried and Gotterdammerung
or something more appropriate than the present frog call

1, half micron count is climbing ( it's close to 16k now )
2, MZ refl signal is too high
3, MC lenght servo LO is too

Attachment 1: dust3y.jpg

580

Thu Jun 26 22:08:33 2008

3.7MHz bandstop filter in MC Servo

The 3.7MHz elliptical bandstop filter that I made during my SURF summer is now installed in the MC servo loop to reduce the noise at 3.7MHz.

I have taken transfer functions with and without the filter between TP1A and TP2A, with EXCA at -20dBm, using the HP4195A Network Analyzer. I have also taken power spectra of TP1A with and without the filter, and time domain data with the filter of OUT2 on the MC Servo Board and Qmon on the Demod board just before the MC servo board. The filter is between Qmon and OUT2 in the loop.

The UGF and phase margin don't change noticeably with and without the filter, and the MC still locks nicely (after the minor fiasco this afternoon), so I think it's okay. The UGF is around 57kHz, with about 38 degrees phase margin.

1 July 2008: I redid the plots. Same info, but the traces with and without the filters are now on the same graph for easier readability.

Attachment 1: MCLoopGainBoth.png

Attachment 2: TP1ASpectrumBoth.png

Attachment 3: QmonWithFilt.png

Attachment 4: MCOut2WithFilt.png

579

Thu Jun 26 21:07:11 2008

I realized today, that yesterday while we were trying to debug the adaptive noise canceler, I turned
off the analog dewhitening on MC1. I did this by changing settings on the Xycom screen but I
forgot to elog this -- this may have caused problems with locking via increased frequency noise.
I have now returned it to its nominal, dewhitening on, configuration.

I also used mDV to look at the last year of dust trend. I have plotted here the cumulative
histogram in percentile units of the 0.5 micron dust level. The x-axis is in units of particles per cu. ft.
and the y-axis is percentage. For example, the plot tells us that over the last year, the counts were
below 6000, 90% of the time. I have set the yellow and red alarm levels to alarm at the 95-th and 99-th
percentile levels, respectively.

Attachment 1: Screenshot-2.png

578

Thu Jun 26 20:59:22 2008

Computer Scripts / Programs

Alarm Handler

Please do not turn off the Alarm Handler on op540m.

577

Thu Jun 26 18:29:44 2008