||Mon Nov 24 17:14:44 2008
||rana||Update||PSL||Mach Zender trends|
|It looks like the MZ has gotten less drifty after the alignment on Friday.|
|Attachment 1: Untitled.png
||Thu Nov 27 22:56:42 2008
|Attachment 1: mc.png
||Tue Dec 2 19:18:10 2008
|In entry http://dziban.ligo.caltech.edu:40/40m/881 and a follow up from Jenne I put in the Ranger calibration.|
Since then, we've reduced the SR560 gain from 200 to 100 so the calibration factor is now:
1e-9 (m/s)/count and then 2 poles at 0 Hz, and a Q~1 zero pair at 1 Hz.
G = 1e-9
p = 0, 0
z = 0.7 0.7
||Tue Dec 2 19:51:32 2008
||rana||Update||PEM||half-micron particle count is alarming|
|The 0.5 micron dust monitor count is now pretty high (36000). I wandered around the lab to see if there was anything|
nasty going on but I didn't see or smell anything in particular. Since today Alberto was sitting around where the
dust monitor is while aligning the PSL beam, we should blame him. Its either garlic, cologne, or time to bathe.
The 400 day hour trend shows that while the counts are not so unusual, the 40m is dirtier than it was last year.
|Attachment 1: Untitled.png
|Attachment 2: dust.png
||Wed Dec 3 19:21:09 2008
|I looked at the Ranger signals. Somehow it has a relative transfer function of 'f' between it and the Guralp.|
i.e. ------ ~ f
which is strange since according to their manuals, they should both be giving us a voltage output which is proportional
to velocity. I checked that the Ranger only has a load resistor and then an SR560 low pass at 300 Hz. Jenne assures
me that the Guralp breakout box shouldn't have any poles either (to be double checked). Its a mystery.
We made sure that the SR560 now is DC coupled, G = 100, & 1-pole low pass at 300 Hz. I moved it over next to the Guralp
(went through the mass recentering procedure after forgetting to lock it before moving). It is behaving as it was
Attached is a 2 page PDF of the comparisons. The 'MC1' channels are Guralp and 'MC2' is Ranger.
The second attachment compares our seismometers (in counts) with the LHO Guralp seismometers. There's no high frequency
rolloff there like what we see here so I bet a dollar that there's a pole in the Guralp box somewhere.
|Attachment 1: c.pdf
|Attachment 2: wsnb.pdf
||Fri Dec 5 09:29:59 2008
||rana||Update||IOO||drum modes observable without excitation|
|Not sure what the y-scale is since there aren't any y axis labels in the plot, but it seems like we|
now get an SNR of a ~few with a BW of 0.1 Hz. IN principle, the frequency noise out of the PSL ought
to be limited by the VCO phase noise at these frequencies (sort of) so the broadband MC_F level
is very roughly equal to 20-100 mHz/rHz.
Since dnu = dL*(c/lambda)/L_MC, the thermal peaks have a height of ~10^-15 m_RMS. We (Caryn) should check
that these numbers are true and then see if this is the correct amount of energy for thermally excited
||Fri Dec 5 14:13:41 2008
||rana||Summary||IOO||MC trend for the last 4 days|
|The MC has stayed locked for ~3 days! I just broke it to reset the MZ.|
|Attachment 1: g.png
||Sun Dec 7 16:02:46 2008
||rana||Update||General||Mag 5.1 EQ halfway to Vegas|
|There was a Mag 5.1 EQ Friday night at 8:18 PM.|
It tripped most of our optics. They all damped down passively except for MC2. Further more, ITMY seems to have come back to a different place.
Don't know why MC2 was so upset but I think maybe its watchdog didn't work correctly and the side loop is unstable when there are
large motions. After I lowered the side gain by 10x and waited a few minutes it came back OK and the MC locked fine.
I have just now put all the WDs into the Shutdown state so that we can collect some hours of free swinging data to see if there's been
any damage. Feel free to redamp the optics whenever you need them. Someone should do the eigenfrequency check in the morning and compare
with our table of frequencies in the wiki.
I excited the optics using the standard SUS/freeswing-all.csh script. Here's the output:
Excited all optics
Sun Dec 7 16:07:32 PST 2008
|Attachment 1: g.png
|Attachment 2: Untitled.png
||Sun Dec 7 16:12:53 2008
|because it was red|
||Fri Jan 2 17:20:44 2009
||rana||Summary||Computer Scripts / Programs||40m GWINC|
|I have made a '40m' directory in the iscmodeling CVS tree which allows one to run a 40m version of GWINC.|
As does the previous one, it takes the default advLIGO config file and modifies some of the struct parameters
to make it appropriate for the 40m.
To make it run, I have added susp1.m to the GWINC directory. This calculates suspension thermal noise using
the Gonzalez-Saulson method that was later extended to
mirrors by Y. Levin. This is also the code used in the LIGO Noise Budget at the sites.
The previous code was giving a much larger value for thermal noise (probably because I didn't understand how
to use it right). It was based on a SURF report from '99.
Since we will have a mixture of MOSs and SOSs in the arms, I have just used SOSs in the model. So the suspension
thermal noise is overestimated by ~sqrt(2) (and realistically its uncertain by a much larger factor).
Since the new code now uses GWINC, the mirror and coating thermal noise are now more correct and use the
coherent therm-optic noise picture.
The 2 page PDF file shows the noise for 0 deg and 90 deg tuning of the SRC.
Although it looks like, from this plot, that we could measure coating thermal noise at the 40m, in reality we would have
to fix all of the technical noise sources first. Just the coil driver noise is probably at the level of 3 x 10^-17 m/rHz
at 100 Hz.
|Attachment 1: bench40.pdf
||Thu Jan 8 16:49:37 2009
||rana||Configuration||lore||HP 5550dtn (Grazia) set up on allegra|
|I set up printing to grazia from allegra. The CUPS interface was not as straightforward as Tobin had made it seem in the Wiki. I had to type in the IP address and port number by hand.|
The steps (AFAIR):
1) Goto http://localhost:631/
2) Click on "Add Printer"
3) Choose HP JetDirect
4) Use the correct address (socket://184.108.40.206:9100)
5) Choose HP and the 5550 postscript driver as the options
6) Try to only print useful stuff and not kill too many trees.
It ought to be root to do that.
||Thu Jan 15 22:30:32 2009
||rana||Configuration||DMF||DMF start script|
|I tried to restart the DMF using the start_all script: http://dziban.ligo.caltech.edu:40/40m/280|
it didn't work
||Mon Jan 19 18:21:41 2009
||rana||Update||Computers||loadLIGOData a GUI for mDV|
|The tool is very nice; I looked at the seismic trend for 16 days (attached). |
However, it gives some kind of error when trying to get Hanford or Livingston data.
|Attachment 1: a.png
||Wed Jan 21 22:53:08 2009
||rana||Update||LSC||AS CCD centering and ASDD demod phase|
|Just my opinion, but I think all we want out of the DD signals is something to control the DRM|
and not be sensitive to the carrier and the CARM offset. So if the handoff can be done so that
the lock point is unchanged from single demod then everything is fine.
A second order concern is how the 133 & 199 MHz signals are mixed in order to minimize the
matrix cross-coupling and the SNR of the diagonal elements.
||Thu Feb 12 14:39:07 2009
||rana||Summary||General||Silicon Beam Dump test|
|Yesterday evening, Ken Mailand and I tested the reflectivity of a piece of polished Silicon. Since Silicon has such a high thermalconductivity (compared to stainless and fused silica) and can take much more heat than black glass and should have a very good BRDF and should absorb most of the 1064 nm light if we hit it at Brewster's angle, we want to try it out in the first version high power, low scatterbeam dump. This dump will be a 'V' style dump like what Steve has tested nearly a year ago, but the incoming beam will first hit this piece of Silicon.|
The pictures of the setup and the Silicon with the beam hitting it are here.
Brewster's angle for p-pol at 1064 nm is 74.2 deg (n = 3.53 @ 1064 nm). We set up a cube polarizer on the output of the ~1064 nm CrystaLaser. 144 mW got to the Si; the reflected beam was ~1.9-2.0 mW after tuning the angle for minimum power. Via eyeball and protractor it seems that we're at ~74 deg. So the reflectivity is < 1.5-2%. This is good enough; the reflected power will be < 1 W in all cases for eLIGO and that can be absorbed by the rest of the stainless V dump. The 35 W of heat in the silicon will be mostly gotten rid of through conduction into the attached heat sink fins.
This kind of dump would go into places like the PMC-REFL, MC-REFL, & IFO-REFL, where we occasionally need to take high power, but also are sensitive to backscatter.
||Mon Feb 16 00:43:46 2009
||rana||Update||Computers||medm directory wiped on nodus|
|I accidentally did an 'rm -rf' on the medm directory in nodus, instead of on my laptop as was intended.|
I then did an svn checkout. So everything should be current as of the last update, but I am sure that
we have not done a checkin on all of the latest screen enhancements. So...we may have to revert to the
Sunday morning tar to get the latest changes back.
||Mon Feb 16 20:47:48 2009
||rana||Configuration||IOO||Mode Cleaner WFS Loop Gain change|
|I found the MCWFS gain slider down at 0.012. In this state the UGFs are probably around 10-30 mHz|
and so there is no reduction of seismic noise. It is mainly a DC alignment tool in this state.
We often have reduced the loop gain thusly, to prevent the dreaded "MCWFS eating CM loop gain" disease.
That disease is where there are CM loop instabilities at ~5-30 Hz because of loop cross-couplings
who's exact nature has never been understood (TBI).
Today, I implemented a 4th order, 7 Hz low pass (RLP7) into the loops and turned up the gain by a factor
of 30 to 0.3. In this state, the damping time constants seem to be ~0.5-2 seconds as shown in the first
PDF. I didn't have enough patience to do the interminable swept sine measurements down to 0.1 Hz.
The second PDF shows the Bode plot of the RLP7 filter compared to the pre-existing but unused ELP10.
The third PDF shows my estimate of the OLG TF. This is made by just putting a "Pendulum" filter into the
MCWFS bank and then plotting all the filters together using FOTON. The BLUE curve shows the old TF but
with the new high gain and the RED curve shows the new TF with the new gain.
With this new filter, I bet that we can get away with the higher WFS gain, but if there's any problem during the
handoff, the gain should be reverted to the low value.
In the 4th PDF file, I plot the spectra of 4 of MC2's control signals so that you can see what is bigger than what.
ASCPIT is the one that has the feedback from the WFS's in it. These are all just in units of counts and so to compare
them in some sort of displacement units you have to take into account the pitch moment of inertia, the mirror mass,
and the mis-centering of the beam from the center of rotation of MC2...
|Attachment 1: pmc-pzt-cal.pdf
|Attachment 2: a.pdf
|Attachment 3: olg.pdf
|Attachment 4: mc2.pdf
||Mon Feb 16 23:09:52 2009
||rana||Update||Electronics||MC Servo Board offset gone bad!|
The attached plot shows that someone broke the MC_SUM_MON channel around 10:30 AM this past Wednesday the 11th. This is the EPICS monitor of the MC error point.
Come forward now with your confession and I promise that I won't let Steve hurt you.
|Attachment 1: mcoff.png
||Wed Feb 18 19:13:20 2009
||rana||Configuration||Computers||SVN & MEDM & old medm files|
|Allegra had a 2 year old version of SVN installed and CentOS (yum) couldn't upgrade it, so I did an 'svn remove subversion'|
and then a 'svn install subversion' to get us up to the Dec '08 version (1.5.5) which is the latest stable.
I also removed all of the old ASS medm directories without backing them up. There's a new RCG script version which is
fixed so that it no longer dumps these old medm directories in there; there's no need since there's already an
medm archive area.
I also removed the medm/old/ directory, did an svn remove, and then copied it back. This is the only way I know of
removing something from the repository without removing it from the working directory.
||Wed Feb 18 21:03:22 2009
||rana||Update||Cameras||ETMY Camera work not elogged!|
The control room video is showing us a false ETMY image. Who worked on the ETMY camera or video today??!!
||Wed Feb 18 21:10:21 2009
||rana||Update||IOO||MC Drumhead mode lost again|
|In early December, Caryn and I noticed that the MC Drumhead mode was visible at the Qmon point of|
the MC demod board using a spectrum analyzer and no external excitation of the MC mirrors. We then
started tracking the MC Drumhead modes.
Today I found that it is gone again. It also wasn't there when I looked for it in 2007.
I looked at the MC error point spectrum and it seemed reasonable. Changing the gains in the MZ, ISS, PMC, & FSS
had no good effect on the noise spectrum.
The voltage noise above 10 kHz in the MC error point is increasing like ~f. I think that this means that
the leftover is the noise from the FSS. Below 10 kHz it is the noise of the VCO (10 mHz/rHz).
One possibility is that the high frequency noise changes with the mood of the NPRO. There should be no
frequency noise induced by the decay of the PA diode power. We can do an NPRO SLOW scan to see if there
is some kind of mode hop noise happening.
||Wed Mar 4 23:42:45 2009
||rana||Configuration||PSL||psl db change|
I made the following change to correct the sign of the 126MON channel:
allegra:c1aux>ezcawrite C1:PSL-126MOPA_126MON.EGUF -410
C1:PSL-126MOPA_126MON.EGUF = -410
allegra:c1aux>ezcawrite C1:PSL-126MOPA_126MON.EGUL 410
C1:PSL-126MOPA_126MON.EGUL = 410
||Thu Mar 5 02:24:19 2009
I added the following repos which I found on allegra to megatron and then did a 'yum install sshfs' on both machines:
-rw-r--r-- 1 root root 428 Feb 12 16:47 rpmforge.repo
-rw-r--r-- 1 root root 684 Feb 12 16:47 mirrors-rpmforge
-rw-r--r-- 1 root root 1054 Feb 12 16:47 epel-testing.repo
-rw-r--r-- 1 root root 954 Feb 12 16:47 epel.repo
-rw-r--r-- 1 root root 626 Feb 12 16:47 CentOS-Media.repo
-rw-r--r-- 1 root root 1869 Feb 12 16:47 CentOS-Base.repo
-rw-r--r-- 1 root root 179 Feb 12 16:47 adobe-linux-i386.repo
This also required me to import the rpmforge GPG key:
sudo rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt
||Sun Mar 8 23:09:26 2009
||rana||Update||Computers||Not even data retrieval working|
|Although getting the regular DAQ data works, we can't get any testpoints.|
I tried restarting tpman several times; there's no inittab on fb40m for this so we should get Alex to set one up when he comes.
I also tried various power cycles and reboots: daqawg, daqctrl, etc. I also notice that Osamu's setup of new stuff is connected to
the same rack and power strips as all of our sensitive DAQ machines. We should find out if there was any hardware installed in the
last couple days; it would be easy to accidentally unplug or damage on of our fibers.
I moved the old tpman.log over to tpman.log.090308. It starts out with a header and then just lists when each TP is requested.
When restarting tpman it puts the following into the terminal:
fb:controls>VMIC RFM 5565 (0) found, mapped at 0x2868c90
VMIC RFM 5579 (1) found, mapped at 0x2868c90
Could not open 5565 reflective memory in /dev/daqd-rfm1
16 kHz system
Spawn testpoint manager
Channel list length for node 0 is 4168
Test point manager (31001001 / 1): node 0which is OK?; its the same startup outputs that are in the old log file. It would be nice if there was not and error message about the RFM.
Requesting new testpoints via tdsdata, dtt, or the diag command line doesn't seem to work. tpman doesn't spit anything out although 'tp show 0'
does show that the TP is selected.
Once Alex fixes the 'tpman' issue, we should make sure to put an inittab or startup script in there so that tpman writes a log
file and also archives its old log files upon a restart.
||Sun Mar 8 23:14:52 2009
||rana||Update||Computer Scripts / Programs||tdsdata doesn't work|
Matt logged in and rebuilt the TDS stuff for us on Mafalda in /cvs/cds/caltech/apps/linux/tds_090304.
He says that he can't build his stuff on 64-bit because there's not a sanctioned 64-bit build of GDS yet.
This should have all the latest fixes in it. I tried using both the old and new code from allegra and they both are fine:
./tdsdata 16384 2 C1:IOO-MC_F > /users/rana/test.txt
I loaded the data I got with the above command and there were no data dropouts. Possibly the dropout problem is only
associated with testpoints and so we have to wait for the TP fix.
||Mon Mar 9 19:27:16 2009
||rana||Configuration||Computers||Move of the CLIO Digital Controls test setup|
Because of the network interference we've had from the CLIO system for the past 3-4 days, I asked the guys to remove
the test stand from the 40m lab area. It is now in the 40m control room. Since it needed an ethernet connection to get out
for some reason we've let them hook into GC. Also, instead of using a real timing signal slaved to the GPS, Jay suggested
just skipping it and having the Timing Slave talk to itself by looping back the fiber with the timing signal. Osamu will enter
more details, but this is just to give a status update.
||Mon Mar 9 19:33:10 2009
||rana||Update||DMF||seisBLRMS in temp condition|
The seisBLRMS has been running on megatron via an open terminal ssh'd into there from allegra with matlab running. This
is because I couldn't get the compiled matlab functionality to work.
Even so, this running script has been dying lately because of some bogus 'NDS' error. So for today I
have set the NDS server for mDV on megatron to be fb40m:8088 instead of nodus.ligo.caltech.edu. If this seems to fix the problem
I will make this permanent by putting in a case statement to check whether or not the mDV'ing machine is a 40m-martian or not.
|Attachment 1: Untitled.png
||Wed Mar 11 01:16:40 2009
||rana||Summary||IOO||rogue trianglewave in the MC Servo offset slider|
On Monday evening, I ran this command:
trianglewave C1:IOO-MC_REFL_OFFSET 0 4 120 600;ezcawrite C1:IOO-MC_REFL_OFFSET 1.76
which I thought (from the syntax help) would move that offset slider with a period of 120 seconds for 600 seconds. In actuality, the last argument is the
run time in number of periods. So the offset slider has been changing by 8 Vpp for most of the last day. Oops. The attached image shows what effect
this had in the MC transmitted power (not negligible). This would also make the locking pretty difficult.
In the second plot you can see the zoom in view for ~30 minutes. During the first part, the MCWFS are on and there are large fluctuations
in the transmitted power as the WFS offset changes. This implies that the large TEM00 carrier offset we induce with the slider couples into
the WFS signals because of imbalances in the quadrant gains - we need someone to balance the RF gains in the WFS quadrants by injecting
an AM laser signal and adjusting the digital gains.
Since there is still a modulation of the MC RFPD DC with the WFS on, we can use this to optimize the REFL OFFSET slider. The third plot
shows a 8 minute second trend of this. Looks like the slider offset of zero would be pretty good.
|Attachment 1: Untitled.png
|Attachment 2: Untitled.png
|Attachment 3: a.png
||Wed Mar 11 04:33:57 2009
||rana||Configuration||Computer Scripts / Programs||wild ndsproxy tclshexe|
The ndsproxy tcl task on nodus was eating up all the CPU and making the elog slow. I killed it and restarted it.
It looks like it hasn't been making a log file since January. Someone who has some skill in decoding the cryptic csh stdout redirection
syntax should look into this (its in target/ndsproxy/)
||Thu Mar 12 19:11:27 2009
||rana||Update||IOO||MC drift is terrible|
|Kakeru, Rana, Yoichi|
We used the SUS DRIFT MON screen to set the MC biases such that the mirrors were returned to the old OSEM values.
To do this, we set the nominals and tolerances using the appropriate scripts in the mDV/extra/C1/ directory.
We then used the MC_ALIGN screen to set the angle bias sliders.
Then Kakeru and I went to the PSL table to the periscope magic and maximize the MC transmission. Kakeru seems to
have the careful Japanese alignment touch and I am hungry, so I am leaving him to optimize the power. After he
finishes he is going to align the beam to the WFS and turn the MC autolocker back on. The x-arm is locked on a
TEM00 mode so the MC alignment is maybe OK.
||Mon Mar 16 01:20:40 2009
||rana||Configuration||IOO||MCWFS noise filtered on the SUS-MC |
|Recently, we noticed that the IOO-WFS system runs at 2048 Hz and sends its signals to the MC SUS|
systems which run at 16 kHz. There is no upsampling filter or anti-imaging filter.
So, I've implemented an RLP666 filter as FM1 in the SUS-MCn_ASC(PIT/YAW) filter banks. This is like a 4th order
Cheby low pass with a low Q notch at 2048 Hz to catch the first image.
The attached PNG shows the ASCPIT_OUT signals before and after the filter is implemented. As you can see, the
big aliased spikes are gone. The reason that MC2 is different from MC1/3 is that they have a hardware 28Hz low pass
and MC2 doesn't. So MC2 had a 28 Hz low pass in software already to match the actuation phase between all the MC
mirrors. The apparent power law noise floor from 40-300 Hz in MC2 is not real - just the Hanning window tail.
And yes, it has been this way for several years and none of us noticed. It remains to be seen if this was causing
any noise in the MC coil drivers via slew rate limiting.
|Attachment 1: xarm.png
||Sun Mar 22 22:39:24 2009
||rana||Summary||LSC||Calibration of the ITM and ETM Actuation|
|I used the following procedure to calibrate the ITMX actuation signal.|
Free Swinging Michelson:
- Restore Michelson
- Align Michelson: Minimize AS_DC (PD3_DC_OUT) by tweaking BS alignment.
- Enable Whitening filters for PD1_Q and PD3_DC.
- Run offsets script to get rid of DC and RF offsets.
- Use DTT Triggered Time Series to get time series and measure peak-peak
amplitude of PD1_Q using DTT horizontal cursors. (Templates/Calibration/090322/FreeSwing.xml)
- Lock Michelson
- Drive ITMX_LSC_EXC using ITMX-MI-Sweep.xml template.
- (Next time remember to turn on a low pass in the MICH loop so that its an open loop measurement below 50 Hz).
- Fit and so some math.
Arm Sweeps for the ETMs:
- Lock a single arm
- Sweep ITM & ETM.
- Then sweep MC2 and record drive signal from MC board to the VCO driver.
- Compare and contrast.
|Attachment 1: free.png
||Sun Mar 22 22:47:58 2009
||rana||Update||DMF||seisBLRMS compiled but still dying|
|Looks like seisBLRMS was restarted ~1 AM Friday morning but only lasted for 5 hours. I just restarted it on megatron;|
let's see how it does. I'm not optimistic.
||Sun Mar 22 23:16:41 2009
||rana||DAQ||Computer Scripts / Programs||tpman restart|
|Could get testpoints but couldn't start excitations. Restarted tpman on daqawg. Works now.|
Still no log file.
||Mon Mar 23 15:50:44 2009
||rana||Configuration||LSC||filters deleted, lsc rebooted|
The LSC time had gone too high. I deleted ~20 filters and rebooted. CPU time came down to 50 usec.
The filters all looked like old trash to me, but its possible they were used.
I didn't delete anything from the DARM, CARM, etc. banks but did from the PD and TM filter banks. You can always go back in time by using the
||Tue Mar 24 23:23:05 2009
||rana||Update||LSC||New PO DC|
|We also found that the SPOB RF cable was going through a splitter before going into the SPOB demod board. The other|
input of the splitter was open (not terminated). Using 50m Ohm devices without terminated inputs is illegal. It
makes there be standing waves in the cables and makes the RF phase very dependent on cable lengths. We took away
the splitter and ran the cable straight. So expect some change in the SPOB gain and phase plus some shame.
||Mon Mar 30 09:07:22 2009
||rana||Update||SUS||MC1 drift investigation continued|
|Maybe we can temporarily just disconnect the bias and just use the SUS sliders for bias if there's enough range?|
||Mon Apr 6 21:50:43 2009
||rana||Update||LSC||Arm Locking via pushing MC2|
|Inspired by our 'No Refcav' scheme here, I was inspired to re-explore the idea of locking the|
CARM DOF using only feedback to the MC/laser. Last week I got this to work on the single arm and
full IFO at Livingston.
I also estimate the MC noise there.
Today I found the settings to allow X-arm locking here without any feedback to the ETM or ITM:
- Set the LSC Output Matrix to feed the XARM signal to MC2.
- Turn OFF the input of the LSC-ETMX filter bank (this does not disable tickling).
- Turn OFF FM7 (0.1:10) in MC2-MCL.
- Turn ON MC2-LSC with a gain of 0.2 and FM3 FM4 FM5.
That's enough to lock the arm - its pretty stable. This also assumes that the LSC-MC2 bank has its nominal gain of -0.178.
To determine the gain of +0.2 in the MC2-LSC filter bank, I measured the TF from MC2->PD3_I and from ETMX->PD3_I. I adjusted
the gain to be equal at 150 Hz for acquisition and the sign to be opposite to account for the (-) in LSC-MC2. The TF is
After locking, I type a zero into the MC2-MCL filter bank and that shuts off the feedback from the MC servo to MC2. This is
now topologically similar to the standard CM servo configuration.
The second attachment has the trends of this locking. You can see that the MC_F goes off into the weeds, but the MCL signal
does not so much. I think maybe the MC length is drifting a lot - not the arm.
The third attachment shows the spectra.
|Attachment 1: mc2-xarm.pdf
|Attachment 2: Untitled.png
|Attachment 3: nohands.pdf
||Wed Apr 8 18:18:33 2009
||rana||Configuration||Computers||LSC code recompiled with a fix for denormalization problem|
|Below is the link to the anti-denormalization technique that Rolf and Alex implemented at the sites,|
that was pointed out by Chris Wipf from MIT:
||Wed Apr 8 18:46:50 2009
||rana||Configuration||General||DMF, SVN, x2mc, and matlab|
While waiting for the installation of the 32-bit Matlab 2009a to finish, I tried updating our seisBLRMS.m code.
Although DMF is in SVN, we forgot to check it out and so the directory where we have been doing our mods is not a working copy and our changes have not been captured: Shame.
We will probably have to wipe out the existing SVN trunk of DMF and re-import the directory after checking with Yoichi for SVN compliance.
Also wrote a script: LSC/x2mc, which will transition from regular ETM based X Arm locking to the MC2 based locking. It ran once OK, but I get a segfault on the 'trianglewave' which was trying to run the 'ezcastep' perl script which was calling 'ezcastep.bin'.
I also restarted the seisBLRMS.m on a terminal on Mafalda in the new Matlab 2009a to see if it loses its NDS connection like it did with 2007a. I also reduced the 'delay' parameter to 4 minutes and the 'interval' to 1 minute. This should be so that the total delay is now 5 minutes between seismic noise and seismic trend.
||Fri Apr 10 01:24:08 2009
||rana||Update||Computers||allegra update (sort of)|
I tried to play an .avi file on allegra. In a normal universe this would be easy, but because its linux I was foiled.
The default video player (Totem) doesn't play .avi or .wmv format. The patches for this work in Suse but not Fedora. Kubuntu but not CentOS, etc.I also tried installing Kplayer, Kaffeine, mplayer, xine, Aktion, Realplay, Helix, etc. They all had compatibility issues with various things but usuallylibdvdread or some gstreamer plugin.So I pressed the BIG update button. This has now started and allegra may never recover. The auto update wouldn't work in default mode becauseof the libdvdread and gstreamer-ugly plugins, so I unchecked those boxes. I think we're going to have this problem as long as we used any kind ofadvanced gstreamer stuff for the GigE cameras (which is unavoidable).
||Fri Apr 10 03:10:08 2009
||rana||Summary||Locking||Laser PM to REFL-DC transfer functions at multiple CARM offsets|
I hereby award the previous rainbow transfer functions the plot innovation of the month award for its use of optical frequency to denote CARM offset.
The attached movie here shows the sensing matrix (minus MICH) as a function of CARM offset. There are 3 CARM signals plotted:
GREEN - tonights starting CARM signal - REFL_DC
RED - my favorite CARM signal - REFL 166 I
CYAN - runner up CARM signal - POX 33 I
||Sun Apr 12 19:27:20 2009
||rana||Update||PSL||PMC LO Calibration|
3.8Vpp is about 16dBm.
The mixer for the PMC demodulator is level 23. So 16dBm is insufficient.
What is the level of the new mixer Steve ordered ? 13 ?
Since Steve and Jenne were on it, I'm sure they ordered the optimum values...
From the table, it looks like the drive level adjuster is busted. Its not supposed to just give a
1-2 dB change over the full range. We'll have to think about what exactly to do, but we should
probably install the level 13 mixer and put in the right attenuation to make the LO be ~13.5 dBm
including the filter. Also need to calibrate the LO readback on the board like what Peter did for
||Sun Apr 12 19:31:43 2009
||rana||Summary||Electronics||Amphony 2500 Headphones|
|We bought the Amphony 2500 Digital Wireless headphones recently. The other cheapo headphones we have are OK for control room use, but have a lot of noise|
and are, therefore, not useful for noise hunting.
The new digital ones are pretty much noise-free. With the transmitter next to rosalba, you can walk halfway down the east arm and all around the MC area
before the reception goes bad. For real noise hunting, we will want to put the transmitter next to the BS chamber and take an analog pickoff from the DC PDs.
In the OMC diagram, we should put an AUDIO filterbank and wire it to the DAC so that we can do arbitrary IIR filtering on the audio signal.
||Wed Apr 15 02:18:42 2009
||rana||Configuration||Computers||nodus vfstab changed for rigel|
nodus was hanging because it was trying to mount the cit40m account from rigel and rigel was not responding.
Neither I nor Yoichi can recall what the cit40m account does for us on nodus anymore and so I commented it out of the nodus /etc/vfstab.
nodus may still need a boot to make it pay attention. I was unable to do a 'umount' to get rid of the rigel parasite. But mainly I don't want anything in
the 40m to depend on the LIGO GC system if at all possible.
||Wed Apr 15 03:52:27 2009
||rana||Update||DMF||NDS client32 updated for DMF|
Since our seisBLRMS.m complains about 'can't find hostname' after a few hours, even though matlab is able to ping fb40m,
I have recompiled the NDS mex client for 32-bit linux on mafalda and stuck it into the nds_mexs/ directory. This time I
compiled using the 'gcc' compiler instead of the 'ANSI C' compiler that is recommended in the README (which, I notice,
is now missing from Ben Johnsons web page!). Let's see how long this runs.
||Mon Apr 20 18:36:37 2009
||rana||Update||Cameras||Mafalda may need an update|
|Sadly, the sensoray crap doesn't seem to build on CentOS. I too would prefer a homogenous solution, |
but I don't know how to make this happen without punishing Joe with sensoray driver development on CentOS.
||Mon Apr 20 20:00:44 2009
||rana||Configuration||IOO||McWFS gains re-allocated|
|Since it looks like the night time people have been running with a WFS gain of 0.05 and I like the slider|
to be at 1.0, I lowered all of the WFS1/2_P/Y gains by 10 and increased the overall slider from 0.05 to 1.0.
So the loop gains are now 2x higher; with it like this I guess the UGFs are in the ~0.2-0.5 Hz range.
||Mon Apr 20 20:45:25 2009
||rana||Configuration||General||SVN: project area added|
|I added the /cvs/cds/project/ directory to the SVN. I've noticed that we've been using target/ for code which is not|
being targeted for any IOCs. This is out of line with the intention of separating real time FE code from just regular
code that we use for diagnostics or otherwise.
So please move all of your non-FE code over to project from target. And if you didn't have it in SVN at all, you
should experience level 3 shame and then import it.
||Mon Apr 20 23:27:59 2009
||rana||Summary||VAC||c1vac2 rebooted: non-functional for several months|
|We found several problems with the framebuilder tonight. The first symptom was that it was totally out of|
disk space. The latest daqd log file had gone up to 500 MB and filled the space. The log file was full of
a lot of requests from my seisBLRMS.m code, but what was really making it so big was that it couldn't
connect to c1vac2 (aka scipe4) to make connections for some channels.
We looked into the daqd log files and this has been going on since at least December. There were several
'whited out' records for TP2 and TP3 in the Vacuum overview as well as the Checklist screen! Why did no
one notice this and fix it?? WE cannot function if we just ignore any non-functioning displays and say
"Oh, that never worked."
For sure, we know that it was working in 2005. Jay and Steve and Alan looked at it.
Today it was responding to ping and telnet, but not allowing any new connections. I hit the RESET button
on it. Several lights went RED and then it came back up. The readbacks on the EPICS screens are OK too.
I went into fb0 and deleted many of the GB size log files from the past several months. There is now
19GB free out of its local 33GB disk.