ID |
Date |
Author |
Type |
Category |
Subject |
11728
|
Wed Nov 4 08:04:53 2015 |
Steve | Update | safety | safety training |
Yutaro Enamoto, visiting graduate student of Seiji received 40m specific basic safety training.
|
12311
|
Tue Jul 19 15:16:43 2016 |
Steve | Update | safety | safety training |
Our new graduate student Lydia received 40m specific safety training. |
12479
|
Fri Sep 9 11:24:15 2016 |
Steve | Update | safety | safety training |
Visiting graduate student Teng Zhang from Glasglow received 40m specific safety training yesterday. |
12565
|
Mon Oct 17 14:48:12 2016 |
Steve | Update | safety | safety training |
Ashley Fowler "high shool" student received basic 40m safety training and Lydia is her guarding angle.
|
12970
|
Thu May 4 08:00:54 2017 |
Steve | Update | safety | safety training |
Freshmen Rebecca Zhang as " work study undergrad " received 40m specific basic safety training yesterday. |
12994
|
Tue May 16 16:16:16 2017 |
Steve | Update | safety | safety training |
Early surfs of India Jigyasa and Kaustubh received basic 40m specific safety traning. |
13144
|
Tue Jul 25 14:27:19 2017 |
Steve | Update | safety | safety training |
Kira Dubrovina and Naomi Wharton received 40m specific basic safety training. |
13406
|
Mon Oct 30 08:08:06 2017 |
Steve | Update | safety | safety training |
Udit Kahndelwal received 40m specific basic safety traning on Friday, Oct. 27 |
14263
|
Thu Oct 25 16:17:14 2018 |
Steve | Update | safety | safety training |
Chub Osthelder received 40m specific basic safety traning today. |
488
|
Tue May 20 09:28:42 2008 |
steve | Bureaucracy | SAFETY | safety traning for 40m |
Tara Chalernsongsak, new gradstudent for K. Libbrecht was introduced to the basics of the 40m operations. |
1273
|
Thu Feb 5 09:12:29 2009 |
steve | Bureaucracy | SAFETY | safety updates & fire alarm test |
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
|
1676
|
Tue Jun 16 03:43:04 2009 |
rob | Update | Locking | same troubles |
Lock is still being lost, right at the end of the process when trying to reduce the CARM offset to zero. |
6188
|
Thu Jan 12 07:44:21 2012 |
steve | Update | SUS | sapphire wire standoff quote |
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
|
13747
|
Wed Apr 11 10:47:26 2018 |
Steve | Update | SUS | satellite amps labeled |
Satellite amplifiers labeled with date. Old labels left on. |
8719
|
Wed Jun 19 00:46:06 2013 |
Jenne | Update | SUS | save/restore alignment scripts now also work for TTs, fixed a bug |
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. |
6819
|
Fri Jun 15 00:50:54 2012 |
yuta | Update | Green Locking | scanned Y arm for 5FSR |
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.
|
6820
|
Fri Jun 15 01:53:05 2012 |
Koji | Update | Green Locking | scanned Y arm for 5FSR |
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?
|
6823
|
Sat Jun 16 12:03:41 2012 |
Zach | Update | Green Locking | scanned Y arm for 5FSR |
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)...
Quote: |
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?
|
|
6824
|
Sat Jun 16 13:01:17 2012 |
yuta | Update | Green Locking | scanned Y arm for 5FSR |
Quote: |
Is that time stamp really correct?
|
Yes. I used pyNDS to get data, but here's a screenshot of dataviewer playing back 300 seconds from GPS time 1023780144.

|
450
|
Fri Apr 25 15:44:21 2008 |
steve | Update | PSL | scattering measurments |
In pursuit of a low back scattering, high power beam dump we looked at materials such:
polished copper, polished aluminum, diamond cut aluminum, variety of polished & heat treated stainless steel and shades of black glasses.
Black glass is ideal at low power. Superpolished SS 304 #8 is the only material that measures close to bg
We are still looking for a conductive low back scattering material that would be ideal for a good high power beam trap.
Black glass-shade 12, ss304 superpolished #8 and white paper-B98-24lbs back scattering were compared at 1064 nm
Atm 1: data plot numbers from front panel of SR830 display,
sensitivity: 1x1 mV for bg and ss
1x1 V for wp
Atm 2: drawing of measurement set up
Atm 3: SR830 lock.amp settings
Atm 4: view from steering mirror
Atm 5: view from black glass trap
Atm 6: white paper |
5046
|
Wed Jul 27 15:18:50 2011 |
kiwamu | Summary | General | schedule |
The vent will start from 1 st of August ! !
|
132
|
Wed Nov 28 16:46:28 2007 |
rana | Configuration | Computers | scientific linux 5.0 |
I tried installing Scientific Linux on Tiramisu. The installation process was so bad (really)
that I quit after 15 minutes. Its back to booting Ubuntu as if nothing had ever happened. Let
us never speak of Scientific Linux again. |
9984
|
Wed May 21 13:51:19 2014 |
Steve | Update | safety | scope battery recall |
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 ! |
71
|
Tue Nov 6 16:48:54 2007 |
tobin | Configuration | Computers | scopes on the net |
I configured our two 100 MHz Tektronix 3014B scopes with IP addresses: 131.215.113.24 (scope0) and 113.215.113.25 (scope1). Let the scripting commence!
There appears to be a Matlab Instrument Control Toolbox driver for this scope. |
5159
|
Tue Aug 9 16:54:47 2011 |
steve | Update | VAC | scratch on vac door |
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!
|
4373
|
Thu Mar 3 07:25:24 2011 |
kiwamu | Update | Green Locking | screwed up the end PDH box |
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. |
4594
|
Mon May 2 11:14:27 2011 |
kiwamu | Update | SUS | script : opticshutdown |
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.
Quote from #4592 |
I leave all the suspensions free from the watchdogs for 5 hours from now.
|
|
110
|
Fri Nov 16 11:27:18 2007 |
tobin | Update | Computers | script fix |
I added a tidbit of code to "LIGOio.pm" that fixes a problem with ezcastep on Linux. Scripts such as "trianglewave" will now work on Linux.
# 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;
} |
6727
|
Thu May 31 04:03:17 2012 |
yuta | Update | IOO | script for MC beam spot measurement |
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')"
|
6871
|
Mon Jun 25 17:48:27 2012 |
yuta | Update | Computer Scripts / Programs | script for finding IR resonance using ALS |
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.
 |
5074
|
Sun Jul 31 00:05:52 2011 |
kiwamu | Update | LSC | script for loss measurement : modified |
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.
Quote from #5067 |
Next : Health-check for the X arm ASS, the loss measurements.
|
|
6726
|
Thu May 31 02:27:24 2012 |
yuta | Update | IOO | script for reliefing MC WFS |
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).
|
4221
|
Fri Jan 28 13:05:56 2011 |
Koji | Configuration | Computers | script path fixed |
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'
|
10816
|
Thu Dec 18 16:21:08 2014 |
ericq | Update | Computer Scripts / Programs | scripts not being backed up! |
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. |
2344
|
Sun Nov 29 16:56:56 2009 |
rob | AoG | all down cond. | sea of red |
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. |
2345
|
Mon Nov 30 10:28:47 2009 |
Alberto | AoG | all down cond. | sea of red |
Quote: |
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.
|
I found the red sea when I came in this morning.
I tried several things.
- ssh into fb40m: connection refused
- telnet fb40m 8087: didn't respond
- 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;
- powercycled fb40m AND C0DAQCTRL: no improvement
- 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. |
2346
|
Mon Nov 30 11:29:40 2009 |
Alberto | AoG | all down cond. | sea of red |
Quote: |
Quote: |
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.
|
I found the red sea when I came in this morning.
I tried several things.
- ssh into fb40m: connection refused
- telnet fb40m 8087: didn't respond
- 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;
- powercycled fb40m AND C0DAQCTRL: no improvement
- 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.
|
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. |
2355
|
Sat Dec 5 14:41:07 2009 |
rob | AoG | all down cond. | sea of red, again |
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. |
2356
|
Sat Dec 5 15:20:10 2009 |
Jenne | AoG | all down cond. | sea of red, again |
Quote: |
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. |
3970
|
Mon Nov 22 20:31:58 2010 |
kiwamu | Update | Green Locking | searching for unknown loss in green PD path |
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.
|
6328
|
Mon Feb 27 21:26:22 2012 |
Den | Update | PEM | seis box |
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. |
6349
|
Fri Mar 2 18:55:06 2012 |
Den | Update | PEM | seis box |
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.
|
6346
|
Fri Mar 2 11:05:28 2012 |
Den | Update | PEM | seis box gain |
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. |
6338
|
Wed Feb 29 01:02:06 2012 |
Den | Update | PEM | seis box measured |
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. |
6343
|
Thu Mar 1 00:05:23 2012 |
Den | Update | PEM | seis box noise |
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. |
6345
|
Thu Mar 1 21:48:34 2012 |
Den | Update | PEM | seis box noise |
Quote: |
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. |
287
|
Wed Jan 30 20:39:31 2008 |
rob | Update | DMF | seisBLRMS |
In order to reduce the probability of seisBLRMS crashing due to unavailability of data, I edited seisBLRMS.m so that it displays data from 6 minutes in the past, rather than 3. After compiling, this version ran for ~8 hours without crashing. I've killed the process now because it seems to interfere with alignment scripts that use ezcademod, causing "DATA RECEIVING ERROR 4608" messages. These don't cause ezcademod to crash, but so many of them are spit out that the scripts don't work very well. I guess running DMF constantly is just making the framebuilder work too hard with disk access. In the near term, we can maybe work around this by having DMF programs check the AutoDithering bit of the IFO state vector, and just not try to get data when we're running these sorts of scripts. |
2387
|
Thu Dec 10 15:18:55 2009 |
Jenne | Update | VAC | seisBLRMS |
last 20 days - including the pounding from next door |
1730
|
Fri Jul 10 17:32:08 2009 |
rana | Update | Environment | seisBLRMS & mafalda restarted |
Rana, Alberto
Mafalda's ethernet cable had fallen out of the connector on the hub-side. We reconnected it and rebooted mafalda and restarted seisBLRMS.
Mafalda didn't mount /cvs/cds on start up for some reason. I mounted it using 'sudo mount linux1:/home/cds /cvs/cds' and it took at least
30 seconds, so maybe there's a timeout issue. Seems OK now. |
282
|
Mon Jan 28 18:56:47 2008 |
rana | Update | DMF | seisBLRMS 1.0 |
I made all of the updates I aludded to before:
- 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.
I still have yet to compile and test the new version. Its running on linux3 right now, but feel free to kill it and compile it to run on Mafalda.
It should be making trends overnight and so we can finally see what the undergrads are really up to. |