I was notified by Rob and Rana that there were many measurements of the MC abs length (i.e. modulation
frequencies for the IFO.) between 2002 and now.
So, I dig the new and old e-logs and collected the measured values of the MC length, as shown below.
I checked the presence of the vent for two big steps in the MC length. Each actually has a vent.
The elog said that the tilt of the table was changed at the OMC installation in 2006 Oct.
It is told that the MC mirrors were moved a lot during the vent in 2007 Nov.
o The current modulation freq setting is the highest ever.
o Rob commented that the Marconi may drift in a long time.
o Apparently we need another measurement as we had the big earthquake.
My curiosity is now satified so far.
Local Time 3xFSR[MHz] 5xFSR[MHz] MC round trip[m] Measured by
2002/09/12 33.195400 165.977000 27.09343 Osamu
2002/10/16 33.194871 165.974355 27.09387 Osamu
2003/10/10 33.194929 165.974645 27.09382 Osamu
2004/12/14 33.194609 165.973045 27.09408 Osamu
2005/02/11 33.195123 165.975615 27.09366 Osamu
2005/02/14 33.195152 165.975760 27.09364 Osamu
2006/08/08 33.194700 165.973500 27.09401 Sam
2006/09/07 33.194490 165.972450 27.09418 Sam/Rana
2006/09/08 33.194550 165.972750 27.09413 Sam/Rana
----2006/10 VENT OMC installation
2006/10/26 33.192985 165.964925 27.09541 Kirk/Sam
2006/10/27 33.192955 165.964775 27.09543 Kirk/Sam
2007/01/17 33.192833 165.964165 27.09553 Tobin/Kirk
2007/08/29 33.192120 165.960600 27.09611 Keita/Andrey/Rana
----2007/11 VENT Cleaning of the MC mirrors
2007/11/06 33.195439 165.977195 27.09340 Rob/Tobin
2008/07/29 33.196629 165.983145 27.09243 Rob/Yoichi
I tracked the tendency for ezcaPut to fail and sometimes seg-fault in the camera code to a conflict between the camera API and ezca, either on the
network level or the thread level. Since neither are sophisticated enough to provide controls over how they handle these two things, I instead
separated the call to ezcaPut out into a small, separate script (a stripped down ezcawrite), which the camera code calls at the system level. This is a
bit hacky of a solution, but its the only thing that seems to work.
I've developed a transformation based on Euler angles that should be able to take the 4 OSEMs in a picture of the end mirror and use their relative
positions to determine the angle of the camera to the optic. This would allow the position data determined by the fitting software to be converted
from pixels to meaningful lengths, and should aid any servo-ing done on the beams position. I've yet to actually test if the equations work, though.
The servo code needs to have slew rate limiters and maximums/minimums to protect the mirrors written in to it before it can be tested again, but I
have no idea what reasonable values for these limits are.
Joe and I recently scanned the PMC by driving C1:PSL-PMC_RAMP with the trianglewave script over a range of -3.5 to -1.25 (around 50 to 150 volts
to the PZT) and read out C1:PSL-ISS_INMONPD to measure the transmission intensity. This included slightly under 2 FSRs. For slow scans (covering
the range in 150 to 300 s), the peaks were very messy (even with the laser power at 1/6 its normal value), and it was difficult to place where the
actual peak center occurred. For faster sans (covering the range in 30 seconds or so), the peaks were very clean and nearly symmetric, but were
not placed logically (the same peak showed up at two very different values for the PZT voltage in two separate runs). I don't have time to put
together graphs of the scans at the moment; I'll have that up sometime this afternoon.
G_L = G_0 * ------------ = 149 +/- 3 V/(m/s)
R_x + R_c
G_0 = 340 V/(m/s) (generator constant)
R_x = 4300 Ohms (external damping resistor in Pomona box)
R_c = 5500 Ohms (internal coil resistance)
m * x = (x_G - x) * k + d(x_G - x) * b
x w0^2 + i*w*w0/Q
---- = -----------------------
x_G w0^2 + i*w*w0/Q - w^2
d (x - x_G) ( w0^2 + i*w*w0/Q ) . w^2 .
dt = ( ----------------------- - 1 ) * x_G = ----------------------- * x_G
( w0^2 + i*w*w0/Q - w^2 ) w0^2 + i*w*w0/Q - w^2
- setsval.m uses mDV to get the minute trend from some specified start time
and duration in the past. It then writes that 'good' value to the
.SVAL field of the SUSPOS, SUSPIT, and SUSYAW records for all the
- setHILO.m reads the .SVAL field and then sets the alarm levels and severity
for the same records given a "sigma" as an argument. i.e. 1 sigma = HIGH,
2 sigma = HIHI.
function varargout = setsvals(varargin)
% sets the SVAL records for the SUS
debug = 0;
if nargin < 2
error('Needs 2 arguments.')
elseif nargin > 2
% Ex. setHILO(1000);
% this sets the SUS alarm levels to be 1000 counts
% from the nominal
% 1 for debugging
debug_flag = 0;
if nargin == 1
01:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet Controller (rev 01)
Subsystem: Intel Corporation Unknown device 304a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 209
Region 0: Memory at ff8ff000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at bc00 [size=64]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
OD = 0.0036" = 0.091 mm
Length = 46" = 1168.4 mm
Resistance = 33.3 Ohms
resistivity = R * pi * (OD/2)^2
----------------- = 1.85e-7 Ohm-meters
resistivity (Ohm-meter x 10^-7)
304 Stainless 7.2
316 Stainless 7.4
Cast Steel 1.6
G = 1e-9
p = 0, 0
z = 0.7 0.7
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.