Quick update on my wiener filtering status:

Joe has been helping me get on the GRID, so I now have  a grid certificate, and accounts on most/all of the clusters.

Joe also helped me get menkar to get S5 data so that I can do wiener filtering to the back-data. 

I've been running the wiener filtering algorithm, and right now, it doesn't do anything to improve the DARM_CTRL data.  I am confident that this is because something is funky in the wiener filtering algorithm somewhere.  The indicator of this is that the wiener filtering calculation takes the same amount of time (~95 seconds) to calculate a filter for 64 seconds of data as for 1 hour of data (both for N = 2000 taps). 

For reference, attached are my plots for the wiener filtering result for (1) 64 seconds of S5 data, and for (2) 3600 seconds of S5 data.

These plots were made using H1:DARM_CTRL as the signal to minimize, with 4 seismometers as the witness channels (EX_SEISX, EY_SEISY, LVEA_SEISX, LVEA_SEISY)

I'm working on figuring out what's going on with the filtering algorithm, and why it does work for C1:MC_L minimization, but does not work for H1:DARM_CTRL minimization.

I've setup the GC650 camera (ID 32223) to look at the mode cleaner transmission.  I've also added an alias to the camera server and client for this camera.

To use, type: "pserv1 &"on the machine you want to run the server on and "pcam1 &" on the machine you want to actually view the video.  At the moment, this only works for the 64-bit Centos 5 machines, Rosalba, Allegra and Ottavia.

Note, you will generally want to start the client first (pcam1 or pcam2) to see if a server is already running somewhere.  The server will complain that it can't connect to a camera if it already is in use.

I've setup the GC750 camera (ID 44026) to look at the the right most analog quad TV.  This can be run by using "pserv2 &" and "pcam2 &". 

If the image stops playing you can try starting and stoping the server to see if will start back up. 

You can also try increasing or decreasing the exposure, to see if that helps.  The increase and decrease buttons change the exposure by a factor of 2 for each press.

  Lastly, the button "Read Epic Channel" reads in the current value from the channel: "C1:PEM-stacis_EEEX_geo" and uses it as the exposure value, in microseconds (in principle 10 to 1000000 should work).

For example, to exposre for 10000 microseconds, use "ezcawrite C1:PEM-stacis_EEEX_geo 10000" and press the "Read Epic Channel" button.

Osamu and Kiwamu received 40m safety training on Thursday, Feb 19, 2009

Comparing  PSL-FSS-RMTEMP and PEM-MC1-TEMPS

So, to compare temp channels, I made a plot of PSL-FSS_RMTEMP and PEM-MC1_TEMPS(the test temp sensor channel after converting from cts to degC). This plot begins about 2 months ago t_initial=911805130. The temperature channels look kinda similar but MC1-TEMPS (the temp sensor clamped to MC1,3 chamber) is consistently higher in temperature than FSS_RMTEMP. See compare_temperature_channels.png.

MC1-TEMPS isn't exactly consistent with FSS-RMTEMP. I attached a few plots where I've zoomed in on a few hours or a few days. See compare_temperature_channels_zoom1.pdf & compare_temperature_channels_zoom2.pdf

Change the room temperature, see what happens to the chamber temperature

A while ago, somebody was fiddling around with the room temperature.  See compare_temperature_channels_zoom4.pdf.  This is a plot of PEM-MC1_TEMPS and PSL-FSS_RMTEMP at t0=911805130. You can see the chamber heating up and cooling down in happy-capacitory-fashion. Although, the PSL-FSS_RMTEMP and the PEM-MC1_TEMPS don't really line up so well. Maybe, the air in the location of the MC1,3 chamber is just warmer than the air in the PSL or maybe there's an offset in my calibration equation.

Calibration equation for PEM-MC1-TEMPS

For the calibration (cts to degC) I used the following equation based on the data-sheet for the LM34 and some measurements of the circuit:

TEMPERATURE[degC]=5/9*(((-CTS/16384/451.9/1.04094)-(.0499*10^-3))/(20*10^-6)-35);

How does the chamber temperature compare with the air temperature?

It looks like the chamber may be warmer than the air around it sometimes.

I wanted to check the temperature of the air and compare it with the temperature the sensor had been measuring. So, at t=918855087 gps, I took the temp sensor off of the mc1-mc3 chamber and let it hang freely, close to the chamber but not touching anything. See compare_temperature_chamber_air.png. MC1_TEMPS increases in temperature when I am handling the temp-sensor and then cools down to below the chamber temperature, close to FSS_RMTEMP, indicating the air temperature was less than the chamber temperature.

 When, I reattached temp sensor to the chamber at t=919011131 gps, the the temperature of the chamber was again higher than the temperature of the air. See compare_temperature_air2chamber.pdf.

Also, as one might expect, when the temp-sensor is clamped to the chamber, the temperature varies less, & when it's detached from the chamber, the temperature varies more. See compare_temperature_air_1day.pdf & compare_temperature_chamber_1day.pdf.

New temp-sensor power supply vs old temp-sensor power supply

The new temp-sensor is less noisy and seems to work OK. It's not completely consistent with PSL-FSS_RMTEMP, but neither was the old temp-sensor. And even the air just outside the chamber isn't the same temperature as the chamber. So, the channels shouldn't line up perfectly anyways.

I unplugged the 'old' temp-sensor power supply for a few hours and plugged in the 'new' one, which doesn't have a box but has some capacitors and and 2 more voltage regulators. The MC1_TEMPS channel became less noisy. See noisetime.png & noisefreq.pdf. For that time, the minute trend shows that with the old temp-sensor power supply the temp sensor varies +/-30cts and with the new power supply, it is more like +/-5cts (and Volt/16,384cts * 1degF/10mV -->  apprx +/-0.03degF). So, it's less noisy. 

I kept the new temp-sensor power supply plugged in for about 8 hours, checking if new temp sensor power supply worked ok. Compared it with PSL-FSS_RMTEMP after applying an approximate calibration equation. See ver2_mc1_rmtemp_8hr_appxcal.png.

Just for kicks

Measuring time constant of temp sensor when detached from chamber. At 918858981, I heated up the temp sensor on of the mc1-mc3 chamber with my hand. Took hand off sensor at  918859253 and let it cool down to the room temperature. See temperature_sensor_tau.pdf. 

I found a strange jump of value in my data taken with tdsdata.
I couldn't find same jump in a playback of DataViewer, so I think this is a problem of tdsdata.
Be careful when you use tdsdata!

The attached file is an example of jumped data.
I try to get data with allegra and op440m, and both has same kind of jump.
(A downsampling or interpolation may be wrong.)

Rana said there is a fixed version of tdsdata in some PC, but 64bit linux may not have.
I try it tomorrow.

Yoichi, Peter

While continuing our efforts to lock, we noticed the procedure failed at a point it had gotten past last night:  turning on the bounce/roll filters in MICH, PRC, and SRC.  We checked the MICH transfer function and noticed that the unity gain point was ~10 Hz, well below the bounce modes.   We tried increasing the gain but found saturation, and Rob suggested that there could be misalignment on the AP table, which Steve worked on today.  We went out and found two of the PDs (ASDD133 and AS166) to be badly misaligned probably due to a bumped optic upstream.  We re-aligned.

I checked a broken QPD, which was placed for PSL angle monitor, and finally I cocluded one segment of the quadrant diode was broken.

The broken segment has a offset voltage of -0.7V after 1st I-V amplifier. It means the diode segment has a current offset without any injection of light.

Tomorrow I will check a new QPD for replacement.

Kiwamu IZUMI

The control room video is showing us a false ETMY image. Who worked on the ETMY camera or video today??!!

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.

We centerd the input of WFS QPD.

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. 

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

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.

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.

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, near 2 of the trashcans in the control room and underneath a desk there are hundrends of ants. Is this normal?