Albert, our new undergrad work force received 40m specific- basic safety training last week. Please read and sign 40m procedures booklet.

Our early bird surf student Gautem has received 40m specific basic safety training today.

2014 surf students Nichin and Akhil received 40m specific basic safety training last week.

TaraV - geology major undergrad -  of Jenne's summer help received 40m specific basic safety training.

 Katherine Dooley has received 40m specific basic safety training in the 40m lab

Alessandra Marrocchesi received 40m specific basic safety training yesteday.

Gautom has received 40m specific basic safety training today.

Yutaro Enamoto, visiting graduate student of Seiji received 40m specific basic safety training.

Our new graduate student Lydia received 40m specific safety training.

Visiting graduate student Teng Zhang from Glasglow received 40m specific safety training yesterday.

Ashley Fowler  "high shool" student received basic 40m safety training and Lydia is her guarding angle.

Freshmen Rebecca Zhang as " work study undergrad "  received 40m specific basic safety training yesterday.

 Early surfs of India Jigyasa and Kaustubh received basic 40m specific safety traning.

Kira Dubrovina and Naomi Wharton received 40m specific basic safety training.

Udit Kahndelwal received 40m specific basic safety traning on Friday, Oct. 27

Chub Osthelder received 40m specific basic safety traning today.

The fire alarm test was completed at 13:30 yesterday.

I updated the 40M Emergency Calling List by replacing Rob by Yoichy. The calling order: Vass,  Aso and Taylor.

Rana and Yoichy were added to the "Registered PSL Operator List"  and posted it in the lab. (not in the document, that should be up dated)

We are getting ready for the annual safety audit. It will be held next week  at 14:00 Friday, Feb 13, 2009

Please participate in the preparation by correcting it or just  tell me.

Rod Luna is organizing the pick up of the following old equipment:

HP laser jet  5000n, 3 of 19" 10 base-T network ports and  4 small hubs,

2 Sun monitors, 1 Viewsonic monitor, 7 keypads and

Hitachi scopes 2 of V-355, 2 of V-422, 1 of V-202 and 1 of V-6165

Lock is still being lost, right at the end of the process when trying to reduce the CARM offset to zero.

On Tue, Dec 20, 2011 at 11:37 PM, Rana Adhikari wrote:
Steve,

We are thinking of replacing a few metal parts in the suspension with sapphire/ruby. We want to replace the standoff (which is Al) with sapphire and also the top plate where the wire is clamped.

For the top, we should make a cutout for a little plate in the existing crossbar. In the cutout would go a little mounting plate. Then the clamping plate (which is now steel) we would also replace with a Sapphire one.

I don't think it matters whether its sapphire or ruby, just has to be very hard.

Can you please get some quotes on the parts?

rana

Satellite amplifiers labeled with date. Old labels left on.

I have done a quick update of the IFO_ALIGN screen's save and restore scripts, so that we can now also save, restore, and view the saved values for the input tip tilts. 

In the past, there was an "if" statement to check if the optic was a PZT, and if so, define the alignment channels accordingly (since all the SOS suspensions have the same format for the name, and the PZTs were the odd ones out).  I have removed the mention of PZTs, and replaced the if statement with an "if TTs" statement, and put in the correct channel names (C1:IOO-TT#_PIT_OFFSET, and the same for YAW). 

Also, I caught a bug in the code, which explains some confusing behavior that I had seen in the past.  When deciding if the restore script should take small steps or just do a big step, it looked at the difference between the saved value and the current value of the slider.  It was *not* looking at the absolute value of the difference.  So, if you had misaligned a slider by hand, and it was in the opposite direction of what the misalign script does, the restore script wouldn't realize that the optic needed to be restored in small steps.  I have now fixed this bug for both pit and yaw cases of the restore script.

I scanned Y arm for 5FSR (below).
I could done this after I put a whitening filter.
Currently, whitening filter between the beatbox and AA filter is made of

  Ponoma blue box(passive filter with zero at 1 Hz, pole at 10 Hz) + SR560(flat gain 100)

I couldn't do more than 5FSR because SR560 overloads. I checked it by staring at the indicator during the scan.
Reason why we kept loosing lock last night was the overload of  SR560. Mystery solved!

Anyway, 5FSR is enough.
Our next step is to reduce residual arm length fluctuation.

Also, I increased the alingnment of IR. So, the higher order modes are less than the last scan.

Interesting. It seems for me that there is a dependence of the noisiness as the beat frequency is scanned.

As you increase (or decrease?) the offset, C1:ALS-BEATY-COARSE_I_IN1 becomes bigger and more crisp.
The resulting out-of-loop stability also seems to be improved as you can see from the crispness of the PDH signal.

Do you find why this happens? Is this because the beat S/N depends on the beat frequency due to the PD noise?

Is that time stamp really correct? I wanted to look at the signal closely to see if I could get any feeling for why it would look so different when positive vs. negative, but I do not see a triangle anywhere near this time (1023780144)...

 Yes. I used pyNDS to get data, but here's a screenshot of dataviewer playing back 300 seconds from GPS time 1023780144.

The vent will start from 1 st of August ! !

Tektronix RECALL on TDS3000 or TDS300B  oscilloscope BATTERIES TDS3BATB

This Lithium-Ion battery can be a fire hazard !  Remove battery pack and recycle it through Safety Office !

Jenne found a big scratch on the north vac door of ITMY. Fortunately it does not reach the inner annulos 0 -ring seal.

This is precisely what we have to avoid to preserve our vacuum system!

 I somehow screwed up the PDH box at the X end station. 

Right now it's not working, so I am going to check and fix it today.

 In the last evening I found that one of the gain stages on the PDH box wasn't fully functional.

So I started investigating it and I though it was going to finish soon, but actually it wasn't so easy.

  The PDH box has several gain stages. So an input signal goes through a buffer, a filter, a boost and an output buffer stages sequentially.

The boost stage is supposed to have gain of 10, but I found it didn't have such gain.

In fact the gain was something like -30dB which is pretty small. Plus this boost stage was imposing an wired bump on the transfer function around 50 kHz.

I checked the voltages on some components around the boost stage and confirmed there were no strange voltage.

Then I suspected that the op-amp : LF356 had been broken for some reason. So I replaced it by LT1792 to see if it fixes the issue.

Indeed it did make it functional. However after few minutes of the replacement, it went back to the same bad condition.

I have no idea about what was going on at that time. Anyway it needs more careful investigations.

  I temporarily put a jumper cable on the board to skip this stage, but now the PDH lock is not healthy at all.

Just FYI.

There is a useful script for this particular job : shutting down all the suspensions and bringing it back to operation after 5 hrs.

It is called opticshudown, which resides in /cvs/cds/rtcds/caltech/c1/scripts/SUS/.

Also I added this script on the list in the wiki where all the scripts will be listed.

http://blue.ligo-wa.caltech.edu:8000/40m/Computers_and_Scripts/All_Scripts#opticshutdown

If you find any other useful scripts, please add them on the wiki.

# On Linux, "ezcastep" will interpret negative steps as command line arguments,
# because the GNU library interprets anything starting with a dash as a flag.
# There are two ways around this.  One is to set the environment variable
# POSIXLY_CORRECT and the other is to inject "--" as a command line argument
# before any dashed arguments you don't want interpreted as a flag.  The former
# is easiest to use here:

if (`uname` =~ m/Linux/) {
    # Add an environment variable for child processes
    $ENV{'POSIXLY_CORRECT'} = 1;
}

I wrote a wrapping script for measuring MC beam spot. We had to run several scripts for the measurement (see elog #6688), but now, you only need to run /opt/rtcds/caltech/c1/scripts/ASS/MC/mcassMCdecenter.

The measured data file will be stored in /opt/rtcds/caltech/c1/scripts/ASS/MC/dataMCdecenter/ directory, with a timestamp.
The calculated beam spot position data will be logged in /opt/rtcds/caltech/c1/scripts/ASS/MC/dataMCdecenter/logMCdecenter.txt file.
I had to edit sensemcass.m file, in order to write the result into the log file. In this way, we can keep track of the beam displacement.

Currently, the calculation script is written in the MATLAB file(sensemcass.m), which isn't very nice.
To run a MATLAB file from the command line, you have to write something like this;

matlab -nodesktop -nosplash -r "sensemcass('./dataMCdecenter/MCdecenter201205210258.dat')"

I made a python script for finding IR resonance using ALS. It currently lives in /opt/rtcds/caltech/c1/scripts/ALS/findIRresonance.py.

The basic algorism is as follows.

1. Scan the arm by putting an offset to the phase output of the phase tracker(Step C1:ALS-BEAT(X|Y)_FINE_OFFSET_OFFSET by 10 deg with 3 sec ramp time).

2. Fetch TR(X|Y) and OFFSET online data using pyNDS during the step.

3. If it finds a tall peak, sets OFFSET to the value where the tall peak was found.

4. If tall peak wasn't found, go back to 1 and step OFFSET again.

The time series data of how he did is plotted below.
I ran the script for Y arm, but it is compatible for both X and Y arm.

I modified the script armloss so that the channel names in the script are properly adopted to the new CDS.

Additionally I disabled the ETMX(Y)_tickle command in the script.

The tickle command puts some offsets on the LSC signal to let the arms pass through a fringe until it gets locked, but apparently we don't need it because the arms are loud enough.

A brief check showed that the script ran fine.

I will measure the loss on the X and Y arm cavity tomorrow.

I wrote a simple script for reliefing MC WFS servo. The script is located at /opt/rtcds/caltech/c1/scripts/MC/reliefMCWFS.
It simply uses ezcaservo to minimize the offset of the WFS feedback signal using MC alignment sliders.

    ezcaservo -r C1:SUS-MC${optic}_ASC${dof}_OUT16 -s 0 -g 0.0001 -t 10 C1:SUS-MC${optic}_${dof}_COMM

I put "MC WFS relief" button on the WFS medm screen (/opt/rtcds/caltech/c1/medm/c1ioo/master/C1IOO_WFS_MASTER.adl).

We had some issues in terms of the script paths. I have fixed it by replacing /cvs/cds/caltech/scripts to /cvs/cds/rtcds/caltech/c1/scripts

Here is the output of diff

----------------------------------------------


rossa:caltech>diff cshrc.40m cshrc.40m.20110128
44,47c44,45
< # OBSOLETE set path = ($path /cvs/cds/caltech/scripts/general)
< # OBSOLETE set path = ($path /cvs/cds/caltech/scripts/general/netgpibdata)
< set path = ($path /cvs/cds/rtcds/caltech/c1/scripts/general)
< set path = ($path /cvs/cds/rtcds/caltech/c1/scripts/general/netgpibdata)
---
> set path = ($path /cvs/cds/caltech/scripts/general)
> set path = ($path /cvs/cds/caltech/scripts/general/netgpibdata)
50,51c48
< # OBSOLETE setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/perlmodules:/cvs/cds/caltech/libs/solaris9/usr_local_lib/perl5/5.8.0/:/cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules
< setenv PERL5LIB /cvs/cds/caltech/libs/solaris9/usr_local_lib/perl5/5.8.0/:/cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules
---
> setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/perlmodules:/cvs/cds/caltech/libs/solaris9/usr_local_lib/perl5/5.8.0/:/cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules
61,64c58,59
< #OBSOLETE setenv PATH ${SOLARISPATH}/bin:$GDSPATH/bin:$ROOTSYS/bin:$TDSPATH/bin:/cvs/cds/caltech/scripts/general/netgpibdata:$PATH
< setenv PATH ${SOLARISPATH}/bin:$GDSPATH/bin:$ROOTSYS/bin:$TDSPATH/bin:/cvs/cds/rtcds/caltech/c1/scripts/general/netgpibdata:$PATH
< #OBSOLETE setenv SCRIPTS /cvs/cds/caltech/scripts
< setenv SCRIPTS /cvs/cds/rtcds/caltech/c1/scripts
---
> setenv PATH ${SOLARISPATH}/bin:$GDSPATH/bin:$ROOTSYS/bin:$TDSPATH/bin:/cvs/cds/caltech/scripts/general/netgpibdata:$PATH
> setenv SCRIPTS /cvs/cds/caltech/scripts
87,88c82
< #OBSOLETE setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules
< setenv PERL5LIB /cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules
---
> setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules
99,100c93
< #OBSOLETE setenv SCRIPTPATH /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/netgpibdata
< setenv SCRIPTPATH /cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/scripts/general/netgpibdata
---
> setenv SCRIPTPATH /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/netgpibdata
103,104c96
< #OBSOLETE setenv SCRIPTS /cvs/cds/caltech/scripts
< setenv SCRIPTS /cvs/cds/rtcds/caltech/c1/scripts
---
> setenv SCRIPTS /cvs/cds/caltech/scripts
135,137c127
< #OBSOLETE alias listenDARM '/cvs/cds/caltech/scripts/c1/listenDARM'
< alias listenDARM '/cvs/cds/rtcds/caltech/c1/scripts/c1/listenDARM'
<
---
> alias listenDARM '/cvs/cds/caltech/scripts/c1/listenDARM'
156,157c146
< #OBSOLETE setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/perlmodules
< setenv PERL5LIB /cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules
---
> setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/perlmodules
167,168c156
< #OBSOLETE setenv SCRIPTPATH /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/netgpibdata
< setenv SCRIPTPATH /cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/scripts/general/netgpibdata
---
> setenv SCRIPTPATH /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/netgpibdata
172,173c160
< #OBSOLETE setenv SCRIPTS /cvs/cds/caltech/scripts
< setenv SCRIPTS /cvs/cds/rtcds/caltech/c1/scripts
---
> setenv SCRIPTS /cvs/cds/caltech/scripts
198,199c185
< #OBSOLETE alias listenDARM '/cvs/cds/caltech/scripts/c1/listenDARM'
< alias listenDARM '/cvs/cds/rtcds/caltech/c1/scripts/c1/listenDARM'
---
> alias listenDARM '/cvs/cds/caltech/scripts/c1/listenDARM'
288,295c274,277
< #OBSOLETE alias makefiltscreen '/cvs/cds/caltech/scripts/Admin/makeFilterScreen.pl'
< #OBSOLETE alias makelockinscreen '/cvs/cds/caltech/scripts/Admin/makeLockInScreen.pl'
< #OBSOLETE alias f_and_r '/cvs/cds/caltech/scripts/Admin/find_and_replace.pl'
< #OBSOLETE alias plotrgascan '/cvs/cds/caltech/scripts/RGA/plotrgascan'
< alias makefiltscreen '/cvs/cds/rtcds/caltech/c1/scripts/Admin/makeFilterScreen.pl'
< alias makelockinscreen '/cvs/cds/rtcds/caltech/c1/scripts/Admin/makeLockInScreen.pl'
< alias f_and_r '/cvs/cds/rtcds/caltech/c1/scripts/Admin/find_and_replace.pl'
< alias plotrgascan '/cvs/cds/rtcds/caltech/c1/scripts/RGA/plotrgascan'
---
> alias makefiltscreen '/cvs/cds/caltech/scripts/Admin/makeFilterScreen.pl'
> alias makelockinscreen '/cvs/cds/caltech/scripts/Admin/makeLockInScreen.pl'
> alias f_and_r '/cvs/cds/caltech/scripts/Admin/find_and_replace.pl'
> alias plotrgascan '/cvs/cds/caltech/scripts/RGA/plotrgascan'

 I just stumbled upon this while poking around:

Since the great crash of June 2014, the scripts backup script has not been workingon op340m. For some reason, it's only grabbing the PRFPMI folder, and nothing else. 

Megatron seems to be able to run it. I've moved the job to megatron's crontab for now.

Came in, found all front-ends down.

Keyed a bunch of crates, no luck:

Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS 

Powered off/restarted c1dcuepics.  Still no luck.

Powered off megatron.  Success!  Ok, maybe it wasn't megatron.  I also did c1susvme1 and c1susvme2 at this time.

BURT restored to Nov 26, 8:00am

But everything is still red on the C0_DAQ_RFMNETWORK.adl screen, even though the front-ends are running and synced with the LSC.  I think this means the framebuilder or the DAQ controller is the one in trouble--I keyed the crates with DAQCTRL and DAQAWG a couple of times, with no luck, so it's probably fb40m.    I'm leaving it this way--we can deal with it tomorrow.

Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS 

 I found the red sea when I came in this morning.

I tried several things.

1. ssh into fb40m: connection refused
2. telnet fb40m 8087: didn't respond
3. shutdown fb40m by physically pushing the power button: it worked and the FB came back to life but still with a red light on the MEDM DAQ_DETAIL screen;
4. powercycled fb40m AND C0DAQCTRL: no improvement
5. shutdown fb40m, C0DAQCTRL, C1DCUEPICS and pushed the reset button on the RF network crate; then I restarted the computers in this order: fb40m, C1DCUEPICS, C0DAQCTRL: it worked: they came back to life and the lights eventually turned green on the MEDM montior screen

I'm now going to restart the single front -ends and burtgooey them if necessary.

Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS 

Everything is back on.

Restarted all the front ends. As usual c1susvme2 was stubborn  but eventually it came up.

I burt-restored all the front-ends to Nov 26 at 8am.

The mode cleaner is locked.

Taking  a cue from entry 2346, I immediately went for the nuclear option and powered off fb40m.  Someone will probably need to restart the backup script.

 Backup script restarted.

 As I said in the past entry (see this entry), there was unknown loss of about 20dB in the beat detection path.

So I started fully characterizing the beat detection path. 

Today I measured the frequency response of the wideband RFPD using the Jenne Laser.

Since all the data were taken by using a 1064nm laser, the absolute magnitudes [V/W] for 532nm are not calibrated yet.  

I will calibrate the absolute values with a green laser which has a known power.

The data were taken by changing the bias voltage from -150V to 0V.

The shape of the transfer function looks quite similar to that Hartmut measured before (see the entry).

It has 100MHz bandwidth when the bias voltage is -150V, which is our normal operation point.

Theoretically the transfer function must keep flat at lower frequency down to DC.

Therefore for the calibration of this data, we can use the DC signal when a green beam with a known power is illuminating the PD.

I did liso simulation of the circuit in the seis box. I think that AD620 (first amplifier in the circuit) noise might be much less with the signal from guralps from 0.01 Hz. Here is the TF of AD620 output / circuit input.

The noise spectrum is at this node is

The psd of the seismic noise below 1 Hz ~ 1u m/s => circuit input signal is ~1mv.

The TF of the whole circuit is

This result differs from the graph on the circuit sheet, but may be it was done before the resistor parameteres changed. Back of the envelop calculations also show that it is not possible to acheive DC gain 200 while 50-800 Hz gain = 5000. I'll check with the spectrum analyzer.

AD620 might be a weak point in the simulation since this is not a "classical" operational amplifier, it contains a resistor that adjusts the gain. During the liso simulation I assumed that we have an ordinary opamp (with noise, gain and gbw parameters taken from the real ad620 datasheet) with a resistor parallel to the opamp = 50k and a resistor before the inverted input that corrsponds to R2. In this case the gain of the simulated opamp is the same as of the real one given by the formula 1 + 49.9k / R2, though noise parameters may change. This should be also checked with the spectrum analyzer.

I've put the seismometer box back to the 1x1, Guralp is back under MC2. When the seismometer is not plugged in, the noise is

Now, I'm going to collect some data from GUR 1 and MC_F and see if the problem with adaptive filter (increasing errror while decreasing mu) will be gone.

I've replaced R2 resistor that adjusts the gain of the AD620 amplifier. Previous value 5491Ohm, new value 464Ohm, so the gain should increase up to ~200-250. Only at the N/S 1 circuit!

LISO simulation of the circuit transfer function and noise are

LISO predicts gain ~45-46 dB = 200 and noise at the level of 10uV at 1Hz. The transfer function and noise measured are

The noise measured is 5 times higher then predicted by LISO. Though I described AD620 as an ordinary amplifier with 49.9kOhm resistor connecting output and inverted input. I specified the noise spectrum 10 nV and 1/f corner frequency 30 Hz. In the AD620 datasheet noise spectrum is 10 - 100 nV depending on the gain. However, the gain is 200 and noise spectrum should be 10 nV. May be in reality it is not the case. It also possible that the noise model used by LISO is not valid for AD620 as it is not an ordinary operational amplifier.