Our Osaka TG360MB maglev failed with CSB error message. This means that the dry emergency landing bearing has to be replaced.
I will consalt with Osaka about the choice of replacing bearing or installing new spare tomorrow.
Mean while V1 is closed and the vac envelope is not pumped.
Valve configuration: BG -background, pumping on the RGA-only
High voltage to IOO PZT steering mirrors and OMC are turned off.
PSL output shutter is closed and manual block is in place.
I will start cooling the CYO pump in the morning, so the IFO will be pumped by noon.
Outgassing plus leakrate after 10 hrs the pressure is 2.3 mTorr
This rate of rise is normal and it is safe to work with the ifo.
We successfully compiled and installed the Real time Code Generator "Hello World" example (which is a skeleton for the ETMX suspension controller) on megatron. In order to get it to compile, we had to add a flag indicating the computer is stand alone, and not using a myrinet card at the moment. This was done by adding the shmem_daq = 1 flag to the cdsParameters module. The symptom was it was unable to find gm.h (and there is no installed /opt/gm directory).
It is called "sam". It was installed to /cvs/cds/caltech/target/sam, and produced medm screens in /cvs/cds/caltech/medm/c1/sam. As nothing points to these, I figure it won't harm any of the current configuration, but lets us play around a bit. If by some strange reason, these do cause problems, feel free to remove them.
Ben and I found this vacuum valve relay box intermittently shorthing yesterday.
It effects V4, V5, VA6 and VM1........ Please do not touch this box under the beam pipe next to the vac rack!
The function of this box to send 120VAC to the vacuum valve to move.
With no DARM offset, sweeping CARM shows an asymmetry between the state where we lock to a DARM spring and the state with a DARM anti-spring. This is why we have a link between the DARM and CARM optical springs.
For each DARM detune direction (positive or negative, spring or anti-spring), there is only one CARM direction which can yield a DC-based error signal lock with a CARM offset but no DARM offset, which is what we want.
As PSL-126MOPA_DTEC went up, the power out put went down yesterday
[From Jenne: When we first opened up the MOPA box, the NPRO's cooling fins were HOT. This is a clear sign of something badbadbad. They should be COLD to the touch (cooler than room temp). After jiggling the needle valve, and hearing the water-rushing sounds, the NPRO radiator fins started getting cooler. After ~10min or so, they were once again cool to the touch. Good news. It was a little worrisome however that just after our needle-valve machinations, the DTEC was going down (good), but the HTEMP started to rise again (bad). It wasn't until after Alberto's tinkering that the HTEMP actually started to go down, and the power started to go up. This is probably a lot to do with the fact that these temperature things have a fairly long time constant.
Also, when we first went out to check on things, there was a lot more condensation on the water tubes/connections than I have seen before. On the outside of the MOPA box, at the metal connectors where the water pipes are connected to the box, there was actually a little puddle, ~1cm diameter, of water. Steve didn't seem concerned, and we dried it off. It's probably just more humid than usual today, but it might be something to check up on later.]
For several of the channels on the PEM ADCU, zeros are occuring at the same time. Does anyone know why that might happen or how to fix it?
The NPRO cooling water was clogged at the needle valve. The heat sink temp was around ~37C
The flow-regulator needle valve position is locked with a nut and it is frozen. It is not adjustable. However Jeenne's tapping and pushing down on the plastic hardware cleared the way for the water flow.
We have to remember to replace this needle valve when the new NPRO will be swapped in. I checked on the heat sink temp this morning. It is ~18C
There is condensation on the south end of the NPRO body, I wish that the DTEC value would just a little higher like 0.5V
The wavelenght of the diode is temp dependent: 0.3 nm/C. The fine tuning of this diode is done by thermo-electric cooler ( TEC )
To keep the diode precisely tuned to the absorption of the laser gain material the diode temp is held constant using electronic feedback control.
This value is zero now.
Note the effect of quadrature rotation for small offsets.
Our spare Osaka maglev purchased in Oct 2005 turned out to be having a viton o-ring seal connection on the intake.
It was shipped back to San Jose for retrofitting it with 6" conflat flange ( CF ) This CF is using copper gasket so there will be no permeation of He when you leak check the IFO
The digital controller and cable are here. The controller needs to be interfaced with the interlocks and computer system; those have been in a neglected condition lately.
see elog #1505 Historically after every REBOOT of c1vac2 the readbacks works for 3-4 days only. Fixing of this was postponed many times in the past as low priority or lack of knowledgeable
The maglev TG390MCAB wil be back on Tuesday, May 4, 2009. The mourning of our fateful 360 will only end at the first levitation of the 390.
I've plotted TRX, TRY, PD12I and PD11Q. Arm powers after locking increase for a few tens of minutes, peak out, and then decrease before lock is lost.
I should have mentioned that the AS port camera image seems to get progressively uglier over the course of these locks. Maybe we can use the JoeCam to make a movie of it.
Can't find hostname 'fb40m'
it only lasted a few hours
locks last for about an hour. this was true last night as well (see "arm power curve" entries). the second lock shown here evolves differently for unknown reasons. the jumps in the arm powers of the first lock are due to turning on DC readout. length-to-angle needs tuning.
attached plot shows MC_IN1/MC_IN2. needs work.
This is supposed to be a measurement of the relative gain of the MCL and AO paths in the CM servo. We expect there to
be a more steep slope (ideally 1/f). Somehow the magnitude is very shallow and so the crossover is not stable. Possible
causes? Saturations in the measurement, broken whitening filters, extremely bad delay in the digital system? needs work.
the align script was run after the third lock here. it would have been interesting to see the arm powers in a 4th lock
To include the plots that I've been working on in some form other than on my computer, here they are:
First is the big surface plot of all the amplitude spectra, taken in 10min intervals on one month of S5 data. The times when the IFO is unlocked are represented by vertical black stripes (white was way too distracting). For the paper, I need to recreate this plot, with traces only at selected times (once or twice a week) so that it's not so overwhelmingly large. But it's pretty cool to look at as-is.
Second is the same information, encoded in a pseudo-BLRMS. (Pseudo on the RMS part - I don't ever actually take the RMS of the spectra, although perhaps I should). I've split the data from the surface plot into bands (The same set of bands that we use for the DMF stuff, since those seem like reasonable seismic bands), and integrated under the spectra for each band, at each time. i.e. one power spectra gives me 5 data points for the BLRMS - one in each band. This lets us see how good the filter is doing at different times.
At the lower frequencies, after ~25 days, the floor starts to pick up. So perhaps that's about the end of how long we can use a given Wiener filter for. Maybe we have to recalculate them about every 3 weeks. That wouldn't be tragic.
I don't really know what the crazy big peak in the 0.1-0.3Hz plot is (it's the big yellow blob in the surface plot). It is there for ~2 days, and it seems awfully symmetric about it's local peak. I have not yet correlated my peaks to high-seismic times in the H1 elog. Clearly that's on the immediate todo list.
Also perhaps on the todo list is to indicate in some way (analagous to the black stripes in the surface plot) times when the data in the band-limited plot is just extrapolated, connecting the dots between 2 valid data points.
A few other thoughts: The time chosen for the training of the filter for these plots is 6:40pm-7:40pm PDT on Sept 9, 2007 (which was a Sunday night). I need to try training the filter on a more seismically-active time, to see if that helps reduce the diurnal oscillations at high frequency. If that doesn't do it, then perhaps having a "weekday filter" and an "offpeak" filter would be a good idea. I'll have to investigate.
I unplugged Guralp EW1b and Guralp Vert1b and plugged in temp sensors temporarily. Guralp NS1b is still plugged in.
ETMY damping restored.
Cryo interlock closed VC1 ~2 days ago. P1 is 6.3 mTorr. Cryo temp 12K stable, reset photoswitch and opened VC1
The 40m frame builder is currently being patched to be able utilize the full 14 TB of the new raid array (as opposed to being limited to 2 TB). This process is expected to take several hours, during which the frame builder will be unavailable.
After looking at some oplev noise spectra in DTT, we discovered that the ETMY quad (serial number 115) was noisy. Particularly, in the XX_OUT and XX_IN1 channels, quadrants 2 (by a bit more than an order of magnitude over the ETMX ref) and 4 (by a bit less than an order of mag). We went out and looked at the signals coming out of the oplev interface board; again, channels 2 and 4 were noise compared to 1 and 3 by about these same amounts. I popped in the ETMX quad and everything looked fine. I put the ETMX quad back at ETMX, and popped in Steve's scatterometer quad (serial number 121 or possibly 151, it's not terribly legible), and it looks fine. We zeroed via the offsets in the control room, and I went out and centered both the ETMX and ETMY quads.
Attached is a plot. The reference curves are with the faulty quad (115). The others are with the 121.
I adjusted the ETMY quad gains up by a factor of 10 so that the SUM is similar to what it was before.