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).

 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 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?

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.

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

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.

$wget http://nchc.dl.sourceforge.net/sourceforge/ndiswrapper/ndiswrapper-1.42.tar.gz

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

$ndiswrapper -m

$modprobe 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!

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.

I attach the transfar function of the current shunt.
There is a little gap at 10 Hz for phase, but it is a ploblem of measurement and not real one.
 

I attache the transfar function of ISS servo.

The 4th stage and variable gain amplifier has alomost same transfar function, so their lines pile up.

I measured the output noise of eache stage of ISS servo, and calcurated the noise ratio between input and 
output of each stage.
Generaly, each noise ratio corresponds to their transfar function. This means servo filter works well, not 
adding extra noise.

I attache example of them.
For 2nd stage, the noise ratio is smaller than transfar function with a few factor. This is because the 
input noise is coverd by analyser's noise and ratio between output and input looks small.
This means the input noise of 2nd stage was enough small and all stage before 2nd stage work well

I fixed the broken slider to change the current of the PA.

The problem was that the EPICS database assigned a wrong channel of the DAC to the slider.

I found that the PA current adjustment signal lines are connected to the CH3 &CH4 of VMIC4116 #1. However in the database file (/cvs/cds/caltech/target/c1psl/psl.db), the slider channel (C1:PSL-126MOPA_DCAMP) was assigned to CH2. I fixed the database file and rebooted c1psl. Then the PA current started to follow the slider value.

I moved the slider back and forth by +/-0.3V while the ISS loop was on. I observed that the amount of the low frequency fluctuation of the MOPA power changed with the slider position. At some current levels, the ISS instability problem went away.

Kakeru is now taking open-loop TFs and current shunt responses at different slider settings.

MOPAs and their settings, powers of 7 years in the 40m

Yoichi and me found that the transfar function of the current shunt changed with the current of PA.
We changed PA current and fixed the unstability of ISS.
Now, laser power is stabilized finely, with band of about 1 Hz.
Yoich will post the stabilized noise spectrum.

There looks to be some non-linear relation between PA current and  the TF of current shunt.
It had changed from the TF which we measured yesterday, so it might change again.

I try to write scripts to sweep PA current and measure the laser power and its rms automatically.
It will be apply for auto-adjustment of PA current.

Attached files are the transfar function of the current shunt with changing PA.
They have difference in lower frequency.

After the ISS work, I aligned the IFO and confirmed that DRMI locks with good SPOB and AS166 values.

So, near 2 of the trashcans in the control room and underneath a desk there are hundrends of ants. Is this normal?

During the cleanup of the lab. Steve found a box with two BNCs going to the ICS DAQ interface and an unconnected D-SUB on the floor under the AP table.  It seemed like a temperature sensor.

The BNCs were connected to C1:PEM-OSA_APTEMP and C1:PEM-OSA_SPTEMP.

Steve removed the box from the floor. These channels can be now used as spare DAQ channels. I labeled those cables.

So after having broke Allegra by updating the kernel, I was able to get it running again by copying the xorg.conf.backup file over xorg.conf in /etc/X11.  So at this point in time, Allegra is running with generic video drivers, as opposed to the ATI specific and proprietary drivers.

I added a PA current limiter.
It is only a voltage devider (composed with 3.09k and 1.02k resiste) between DAC and PA current adjustment input.
The output range of DAC is +/- 10[V] and  the conversion factor of PA current adjustment is 0.84[A/V] (measured value), so the PA current adjustment is limited +/- 2.1[A] ( 10[V]*1.02k/(1.02k+3.09k)*0.84[A/V] ).

Actually, the manual of the PA tells that the conversion factor is 0.25[A/V].
There is 3 possibility.
1) There are some mistakes in channels of digital system.
2) The PA manual is wrong.
  2-1) The conversion factor of current adjustment is wrong.
  2-2) The conversion factor of current monitor is wrong.
I measured the signal of current adjustment and current monitor directly, and confirm that they are consistent to the value monitord from MEDM.
Hence the PA manual must be wrong, but I don't know which factor is wrong (or both?).
If the suspect 2-2) is guilty, it means we adjust PA current with very small range.
This is a completly safety way, but a wast of resource.

Now, the slider to control current adjustment indicate the output of DAC.
I will improve this to indicate  current adjustment input, but it takes some time for me to learn about EPICS.

I have been getting ready for the annual safety inspection in the past 2-3 days.

c1susvme1 is behaving weirdly.  I've restarted it several times but its computation time is hanging out around 260 usec, making it useless for suspension control and locking.  I also found a PS/2 keyboard plugged in, which doesn't work, so I unplugged it.  It needs to be plugged into a PS/2 keyboard/mouse Y-splitter cable. 

We centerd the input of WFS QPD.