Today, I worked with Kakeru on ISS.
The problem is sort of elusive. Some time, the laser power looks fine, but after a while you may see many sharp drops in the power. Some times, the power drops happen so often that they look almost like an oscillation.
We made several measurements today and Kakeru is now putting the data together. Meanwhile, I will put my speculations on the ISS problem here.
The other day, Kakeru took the transfer function of the ISS feedback filter (he is supposed to post it soon). The filter shape itself has a large phase margin ( more than 50deg ?) at the lower UGF (~3Hz) if we assume the response of the current shunt to be flat. However, when we took the whole open loop transfer function of the ISS loop, the phase margin was only 20deg. This leads to the amplification of the intensity noise around the UGF. The attached plot is the spectrum of the ISS monitor PD. You can see a broad peak around 2.7Hz. In time series, this amplified intensity noise looks like semi-oscillation around this frequency.
Since it is very unlikely that the PD has a large phase advance at low frequencies, the additional phase advance has to be in the current shunt. We measured the response of the current shunt (see Kakeru's coming post). It had a slight high-pass shape below 100Hz (a few dB/dec). This high-pass response produces additional phase advance in the loop.
There seems to be no element to produce such a high-pass response in the current shunt circuit ( http://www.ligo.caltech.edu/docs/D/D040542-A1.pdf )
This Jamie's document shows a similar high-pass response of the current ( http://www.ligo.caltech.edu/docs/G/G030476-00.pdf page 7 )
Now the question is what causes this high-pass response. Here is my very fishy hypothesis :-)
The PA output depends not only on the pump diode current but also on the mode matching with the NPRO beam, which can be changed by the thermal lensing. If the thermal lensing is in such a condition that an increase in the temperature would reduce the mode matching, then the temperature increase associated with a pump current increase could cancel the power increase. This thermal effect would be bigger at lower frequencies. Therefore, the intensity modulation efficiency decreases at lower frequencies (high-pass behavior). If this model is true, this could explain the elusiveness of the problem, as the cancellation amount depends on the operation point of the PA.
To test this hypothesis, we can change the pump current level to see if the current shunt response changes. However, the PA current slider on the MEDM screen does not work (Rob told me it's been like this for a while). Also the front panel of the MOPA power supply does not work (Steve told me it's been like this for a while). We tried to connect to the MOPA power supply from a PC through RS-232C port, which did not work neither. We will try to fix the MEDM slider tomorrow.
Symptoms: Belladonna could not (for a while) connect to the wireless network, since there was a driver problem for the wireless card. This (I believe) started when Yoichi was doing updates on it a while back.
The system: Belladonna is a Dell Inspirion E1505 laptop, with a Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card (rev 01)
Result: Belladonna now can talk to it's wireless card, and is connected to the Martian network. (MEDM and Dataviewer both work, so it must be on the network.)
What I did:
0. Find a linux forum with the following method: http://www.thelinuxpimp.com/main/index.php?name=News&file=article&sid=749
The person who wrote this has the exact same laptop, with the same wireless card.
1. Get a new(er) version of ndiswrapper, which "translates" the Windows Driver for the wireless card to Linux-ese. Belladonna previously was using ndiswrapper-1.37.
2. Put the ndiswrapper in /home/controls/Drivers, and installed it.
$ndiswrapper -i bcmwl5.inf 3. Get and put the Windows driver in /home/controls/Drivers/WiFi$wget http://ftp.us.dell.com/network/R140747.EXE
4. Unzip the driver
$unzip -a R140747.EXE
5. Make Fedora use ndiswrapper
6. Change some files to make everything work:
/etc/sysconfig/wpa_supplicant CHANGE FROM: DRIVERS="-Dndiswrapper" CHANGE TO: DRIVERS="-Dwext"
/etc/sysconfig/network-scripts/ifcfg-wlan0 CHANGE FROM: BOOTPROTO=none CHANGE TO: BOOTPROTO=dhcp
/etc/rc.d/init.d/wpa_supplicant CHANGE FROM: daemon $prog -c $conf $INTERFACES $DRIVERS -B CHANGE TO: daemon $prog -c$conf $INTERFACES $DRIVERS -B
6. Restart things
$service wpa_supplicant restart
$service network restart
7. Restart computer (since it wasn't working after 1-6, so give a restart a try)
8. Success!!! MEDM and Dataviewer work without any wired internet connection => wireless card is all good again!
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
We found that one OP-amp used in ISS servo oscillated in 10 MHz, 100mV.
Moreover, we found another OP-amp had big noise.
We guess that these oscilation or noise cause saturation in high frequency, and they effect to lower frequency to cause
Attached files are open loop transfar function of ISS.
The blue points are open loop TF, and the green line is product of TF of ISS servo filter and TF of current shunt TF of servo filter.
This two must be same in principle, but They have difference f<2Hz and f>5kHz.
I notice that Megatron is slower than any other computer in running code that invokes optickle or looptickle (i.e. three times slower than Ottavia). Even without the graphics.
Has anyone ever experienced that?
As a reference. The elog runs on background in nodus.
To kill the process:
1) pkill -3 elogd
2) rm -f /var/run/elogd.pid
To restart it:
elogd -p 8080 -c /export/elog/elog-2.7.5/elogd.cfg -D
I think I solved the problem (as you can probably see).
The cause was that this WYSIWYG interface for HTML is provided by an independent text editor called FCKeditor which is included in the elog. Although the elog installer has a bug and does not unzip properly the relative package. One has to do it by hand. (going to /elog/scripts/ and unzipping fckeditor.zip by hand in the same directory).