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.

I've measured the input signal to the seismic box from seismometer Guralp 1. The spectrum of the signal in the "input +" (TP 1) is

The spectrum below 1 Hz is ~250 uV/sqrt(Hz). As the input is differential, then the input voltage is 0.5 mV/sqrt(Hz). The spectrum of the "output +" signal (TP 2) is

So the gain at ~ 1Hz is ~20. I've measured the transfer function between the "input +" and "output +" (TP1 and TP2) for all 9 circuits

The channels 1-6 are of new modification and have gain ~20 at the frequencies 0.2 - 100 Hz. Below 0.2 Hz the gain is reduced. 100 Hz - cut off frequency of the low-pass filters. Meanwhile channels 7-9 (old configuration) have much more gain and 10_50 Hz filters work here.

The coherence between  "input +" and "output +" (TP1 and TP2) for 9 circuits is

We can see that channel VERT 3 is very bad. For others coherence is lost below 0.2 Hz. The spectrum analyzer noise measured is ~1000 times less then the signal at these frequencies. I'll pay more attention to this loss of coherence at low frequencies. Something is noisy.

I've moved GUR1 seismometer from MC2 to the working tables in order not to disturb the MC while working with the seismometer box. The new place for the GUR1 for a few days is near the printer, cables and blue boxes. I've cleaned all mess and wires from the floor, so that seismometer now looks like that

I've connected 2 inputs of the N/S 1 circuit of the seismometer box with a 50 Ohm resistor and measured the noise at the output. The comparison with the seismic signal is

The noise increased at 0.5 Hz and is pretty big. This might explain the loose of coherence at low frequencies.

 This is because spectrum analyzer did not plot the real noise spectrum at the first few points at low frequencies. I've remeasured the noise at 1mHz - 3Hz at "output -" (TP9) and compared it to the seismometer signal

The noise seems to be much less then the signal. I've measured the noise several times and once I got a huge amount of noise

I made another measurement in some time and got the low noise again. A circuit might have a bad contact somewhere.

The plan is to change AD620 adjustable resistor (R2) from 5.49kOhm to 500Ohm to increase the gain from 20 up to 200.

last 20 days - including the pounding from next door

• Expanded the dmf.db file on c1aux to include all accelerometers and the seismometer.
  
• Added the channels to the C0EDCU.ini file and restarted the framebuilder daqd.
  
• Modified seisBLRMS.m to use .conf files for the channels. The .conf files are now residing in the compiled matlab directory that Rob made.
  

The compiled version of seisBLRMS had been running ~2 weeks without crashing as of last night, when I killed it
so it wouldn't interfere with alignment scripts.  I added an EPICS channel C1:DMF-ENABLE, and updated the DMF
executables to check this channel while running.  So far it seems to work.  When you're running alignment acripts,
simply click the DISABLE button on the C1DMF_MASTER.adl screen, and then re-ENABLE when the scripts finish. 
It's not clear why this is necessary though.  Theories include the constant disk access is keeping the
framebuilder busy, reducing its ability to deal with ezcademod commands and DMF programs just flooding the
network with so much traffic that ezcademod-related packets run late and get ignored.

Also, for reasons of aesthetics, I changed the data delay from 6 minutes to 5 minutes.  We'll see if that's enough.