The c1lsc has been unstable since last night. Its status on the DAQ screen was oscillating from green to red every minute.
Yesterday, I power recycled it. That brought it back but the MC got unclocked and the autolocker could not get engaged. I think it's because the power recycling also turned c1iscaux2 off which occupies the same rack crate.
Killing the autolocker on op340 e restarting didn't work. So I rebooted also c1dcuepis and burt-restored almost all snapshot files. To do that, as usual, I had to edit the snapshot files of c1dcuepics to move the quotes from the last line.
After that I restarted the autolocker that time it worked.
This morning c1lsc was again in the same unstable status as yesterday. This time I just reset it (no power recycling) and then I restarted it. It worked and now everything seems to be fine.
Today I checked out the SR560 around the lab. I confirmed that the one with the label "channel A noisy" is effectively mulfuctioning.
It was coonected to the lock-in amplifier set up for the drum mode peak readout.
I repleaced that with a working one.
Could not get past arm power of ~11 or so. I was suspicious of the transmon high-gain/low-gain PD handover, so I ran the matchTransMon scripts, but that did not help. I also removed the line in the cm_step script that increased the CM gain by 18dB at an arm power of 4. The gain of the CM servo will increase naturally as the power in the IFO builds up, so it may not be good to crank it right away. I tried several other CM gains, and watched the DARM loop, but still could not get past an arm power of ~10-11. I'm not sure what's wrong, but it may be that mysterious CM-servo/McWFS conspiracy, so we can try turning down the McWFS gain next time.
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:
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.
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.
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.