The first nameserver on all of the workstation machines inside of the file /etc/resolv.conf has been changed to be 192.168.113.104, which is Chiara's IP address (it used to be 192.168.113.20, which was linux1). This change has also been made on the framebuilder, and in the framebuilder's /diskless/root/etc/resolv.conf file, which is what all of the fast front ends look to.
On the framebuilder, and in the /diskless place for the fast front ends, presumably we must have changed something to point at the new location for the shared drive, but I don't remember how we did that [ERIC, what did we do???]
In all of the fstabs, we're using chiara's IP instead of name, so that if the nameserver part isn't working, we can still get the NFS mounts.
On control room computers, we mount the NFS through /etc/fstab having lines like:
192.168.113.104:/home/cds /cvs/cds nfs rw,bg 0 0
fb:/frames /frames nfs ro,bg 0 0
Then, things like /cvs/cds/foo are locally symlinked to /opt/foo
For the diskless machines, we edited the files in /diskless/root. On FB, /diskless/root/etc/fstab becomes
master:/diskless/root / nfs sync,hard,intr,rw,nolock,rsize=8192,wsize=8192 0 0
master:/usr /usr nfs sync,hard,intr,ro,nolock,rsize=8192,wsize=8192 0 0
master:/home /home nfs sync,hard,intr,rw,nolock,rsize=8192,wsize=8192 0 0
none /proc proc defaults 0 0
none /var/log tmpfs size=100m,rw 0 0
none /var/lib/init.d tmpfs size=100m,rw 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0
none /sys sysfs defaults 0 0
master:/opt /opt nfs async,hard,intr,rw,nolock 0 0
192.168.113.104:/home/cds/rtcds /opt/rtcds nfs nolock 0 0
192.168.113.104:/home/cds/rtapps /opt/rtapps nfs nolock 0 0
("master" is defined in /diskless/root/etc/hosts to be 192.168.113.202, which is fb's IP)
and /diskless/root/etc/resolv.conf becomes:
nameserver 192.168.113.104 #Chiara
Current computer status:
All fast machines except c1iscey are up and running. I can't ssh to c1iscey, so I'll need to go down to the end station and have a look-see. On the c1lsc machine, neither the c1oaf nor the c1cal models are running (but for the oaf model, we know that this is because we need to revert the blrms block changes to some earlier version, see Jamie's elog 9911).
Daqd process is running on framebuilder. However, when I try to open dataviewer, I get the popup error saying "Can't connect to rb", as well as an error in the terminal window that said something like "Error getting chan info".
Slow machines c1psl, c1auxex and c1auxey are not running (can't telnet to them, and white boxes on related medm screens for slow channels). All other slow machines seem to be running, however nothing has been done to them to point them at the new location of the shared hard drive, so their status isn't ready to green-light yet.
Things that we did on Friday for the fast machines:
The shared hard drive is "physically" on Chiara, at /home/cds/. Links are in place so that it looks like it's at the same place that it used to be: /opt/rtcds/......
The slow front ends that we have tried changing have not worked out.
First, we tried plugging a keyboard and monitor into c1auxey. When we key the crate to reboot the machine, we get some error message about a "disk A drive error", but then it goes on to prompt pushing F1 for something, and F2 for entering setup. No matter what we press, nothing happens. c1auxey is still not running.
We were able to telnet into c1auxex, c1psl, and c1iool0. On each of those machines, at the prompt, we used the command "bootChange". This initially gives us a series of:
$ telnet c1susaux
Connected to c1susaux.
Escape character is '^]'.
c1susaux > bootChange
'.' = clear field; '-' = go to previous field; ^D = quit
boot device : ei
processor number : 0
host name : linux1
file name : /cvs/cds/vw/mv162-262-16M/vxWorks
inet on ethernet (e) : 192.168.113.55:ffffff00
inet on backplane (b):
host inet (h) : 192.168.113.20
gateway inet (g) :
user (u) : controls
ftp password (pw) (blank = use rsh):
flags (f) : 0x0
target name (tn) : c1susaux
startup script (s) : /cvs/cds/caltech/target/c1susaux/startup.cmd
other (o) :
value = 0 = 0x0
If we go through that again (it comes up line-by-line, and you must press Enter to go to the next line) and put a period a the end of the Host Name line, and the Host Inet (h) line, they will come up blank the next time around. So, the next time you run bootChange, you can type "chiara" for the host name, and "192.168.113.104" for the "host inet (h)". If you run bootChange one more time, you'll see that the new things are in there, so that's good.
However, when we then try to reboot the computer, I think the machines weren't coming back after this point. (Unfortunately, this is one of those things that I should have elogged back on Friday, since I don't remember precisely). Certainly whatever the effect was, it wasn't what I wanted, and I left with the machines that I had tried rebooting, not running.
My SURF week-1 work...
To measure the transimpedence of the Broadband photodiode (D1002969-v8), using a New focus photodiode (1611) as reference. The amplitude modulated Jenne Laser (1.2mW) was used.
The steps involved in getting the transimpedence are as follows:
1) Frequency sweep range: 1MHz to 200 MHz.
2) Number of Points sampled in the range: 201
3) Type of sweep: Logarithmic
The Plots of transimpedence obtained are attached (results.pdf) . The results obtained for BBPD is consistent with the ones obtained before, but the same method and code gives a different transimpedence for 1611.
The transimpedence of NF 1611 was obtained to be around 4-5 V/A which is very much off-track compared to the one given in the datasheet (elog: 2906).
The transimpedence of Broadband photodiode (D1002969-v8) was around 1200 - 1300 V/A for most of the range, but the value started falling as the frequency approached 100 MHz. This result is consistent with DCC document: T1100467-v2.
2014 surf students Nichin and Akhil received 40m specific basic safety training last week.
ELOG is back up and running after last Friday's disk-crash-a-thon. SVN is still a work in progress. Jenne and I are now restarting computers and such.
Wait. It is not so clear.
Do you mean that the IFO was locked with REFL11I for the first time?
Why is it still in the "low finesse" situation? Is it because of misalignment or the non-zero CARM offset?
Sorry, the X arm is completely misaligned. This is the configuration I first tried in ELOG 9859, that is: a PRM->ITMY recycling cavity and ITMY->ETMY arm cavity. ITMX is completely misaligned, so the BS is dumping much of the recycling cavity light out, which is why I wrote "low finesse." This is the first time I've used REFL11 to control any of our cavities, though.
Do you mean that the IFO was locked with REFL11I for the first time?
Ant season has set in. I spotted and killed a few ants around the optics and the enclosure of the PSL table yesterday. TIme for our pest control crew to get busy!
I'll put more detail in the morning, but I was able to get the PRM/ITMY/ETMY coupled cavities locked with 32kHz bandwidth using the AO path. (However, this is a pretty low-finesse situation, since the BS is dumping so much power out of the PRC. Full buildup is only 3 or 4 times the single arm power)
Since our ALS is better than it was a month ago when I last played with this, I was able to hop straight from ALS to REFL11 I on resonance, with the PRY locked on 3f.
Here are some quick OLTF plots I took along the way.
I'm using this configuration to validate my loop modelling for the full double arm case. Right off the bat, this tells me that the "minus" polarity on the CM servo is the correct one. I didn't use REFLDC at all tonight, but I figure I can check it out by doing the transition backwards, so to speak.
If the PD is the suspect, just pull it from the table and bring it to the PD testing setup.
The transimpedance of the PD should be ~2000 Ohm for both of the RF and DC outputs.
The test setup gives you the systematic opportunity for examination of the signal line.
Check the signal level with the active probe.
Once the broken component is found replace it. You are supposed to have the replacement
components on the blue tower.
Grr. I am very frustrated. After lunch I redid alignment for both X and Y green systems (Yarm both at the end and on the PSL table, Xarm just on the PSL table). After that realignment work, I cannot find a beatnote for the Xarm!!!
At this point, I still hadn't touched anything on the X path (except the PZT input steering mirrors, remotely from the control room). The beatnote was about the same size as it was on Friday, around -27dBm. I went onto the PSL table and did the same alignment procedure that I had just done for the Yarm: Remove the green trans PD and the accompanying lens so that I get far-field spots on the wall, and then steer the PSL green and the X green spots until they are nicely overlapped at both the camera (near-field) and on the wall. I looked at the DC output of the beat PD, and centered the beam on the diode. I put back the thorlabs DC transmission PD and the lens, and centered the beam on that. However, after this work, I cannot find a beatnote for the X arm! I still see the nice big Ygreen beatnote, and I have the PSL and Xend temperatures where they usually are ( abs(FSS Slow) < 0.1, and X end Slow around 10,090. ) I scanned -10,000 counts, and +5,000 counts from there, and still don't find a beatnote!
I went back inside, and I don't see an RF signal coming into the beatbox from the Xarm. It's not the cable's fault though, since I then hooked the RF output of the beat PD to a 'scope, and still didn't see any beatnote. The DC path of the PD is definitely seeing things, because when I switch the 'scope over to the DC output of the Xbeat PD, and I block/unblock the beam, I see the voltage step up and down as expected.
I have not pulled out the Xgreen broadband PD, but unless someone else has a good idea of what to check, that might be one of the next things to do.
Ideas of things I could try:
* Put the X broadband PD on the Y beatnote path to see if I see the same Y beatnote (use the port where the Y green trans PD is, since it has the coaligned beams, and a lens).
* Open the PD and see if anything on the RF path is fried.
* Move the Y PD over to the X path, to see if it sees the beatnote.
I made my attempts trying to figure out what was wrong.
Checking if we are at the right X end laser temperature:
I aligned the arms and found the Y beatnote.I blocked the light falling on the X beat PD so that the RF analyser was only looking at the output from the Y beat PD. AT the RF analyser, I found the strong Y-PSL beatnote, the X-Y beat note and a weak X-PSL beatnote. This confirmed that we have the X end laser at the right temperature to be able to detect the beatnote. Unblocking the light on the X beat PD did not bring in any additional peaks.
Checking the RF cabling from the X beat PD to the beat box:
I swapped the RF cables such that the signal from the Y beat PD output was going to the X input on the beatbox. I could still see the beatnote on the RF analyser. This confirmed that there aren't any broken RF cables along the X path.
Checking X green PSL alignment:
I replaced the X beat PD with the Y beat PD to check if the alignment of X&PSL green are alright. I could find the X beat note this way without any alignment tweaking.
I suspect we probably have some RF component burnt in the X beat PD. Do we have any spares lying around? There is a Koji's box with a PD having the same serial number.
IFO status report for anyone who is looking to do some locking tonight :
The Y beat PD is back along the Y path and I have confirmed the presence of Y-PSL beat note after replacing the PD.
The X beat PD has been removed and now rests on the electronics bench for checking.
While aligning the arms today, I noticed that enabling LSC would cause misalignment of the ETMY suspension. I haven't tried to find out what has been causing this. Could be something similar to what was noticed with the ETMX suspension a couple of weeks ago elog9969.
MC wouldn't relock, it looked misaligned in pitch and yaw on MC camera.
I've touched the alignment, and gotten the reflection below 0.5, but it unlocks periodically, spot positions aren't great, and turning on WFS throws it out of alignment. ughhhhh
I realigned the MC mirrors and brought down MC_REFL to 0.42 and MC_TRANS_SUM came up to ~ 17400 counts.
I measured the spot positions after alignment. MC1 and MC3 are slightly off in pitch :
spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
[2.0535418031770249, 0.84870716159663184, 1.9759940800847962, -1.6706240175650202, 0.089441353070240759, -1.0339963871771678]
I reset the WFS filterbank offsets and engaged the MCWFS servo. Atleast now the MC is not being thrown out of lock with WFS enabled. I have NOT touched the alignment to the WFS PDs.
Also, while I was working on the PSL table, I heard noise that sounded like a bearing rolling around. I suspected the HEPAs, since the one on the north east corner of the table has a problem when it's turned up high (we've known about this for a long time), however turning off the HEPAs didn't affect the noise. The noise is strongest near the back of the PSL controller on the shelf above the table, and the PSL controller box is vibrating. So, I suspect that the fan on the PSL controller box is about to give out.
EDIT: To clarify, I mean the Innolight's controller.
The bearing is chirping in the back of the 2W Innolight laser controller. It is loud enough to hear it. I placed 4 soft rubber feet under the controller to avoid shaking other things on self.
The HEPA filter bearing becomes noisy at 50V
Keep it at 20V for low noise
The Ybeat, after aligment, was up to -5.5 dBm when the beat was at 11 MHz. Last week it was something like -20 dBm, so alignment makes a big difference. After doing IR alignment I had noticed that the green transmitted through the Yarm didn't look very bright on the camera, and the power was around 0.2, so I went to the Yend and gently touched the green input steering mirrors, and got the Ygreen trans PD back to more than 0.9 with the PSL green shutter closed. Awesome. Then I touched up the Ygreen PSL alignment, and then saw that the beatnote was nice and large. Hooray. I measured the out of loop noise, and it was even better than the best we saw last week: (greenish was best last week for Yarm, teal blue is new Ygreen):
Sorry, I had been in a hurry when I worked on this last week, and again when I wrote the elog, but I wanted to at least put in a note for any weekend workers.
The ALS beatnote setups need alignment on the PSL table. However, even at very low RF beat frequency, the X beatnote now at low frequencies matches our best measurement from last week. The "HEPA off" (teal and purple) measurements are from last week, and the red and blue are from this week. The X beatnote was 10MHz and the Y beatnote today was 31MHz.
Rga scan at pump down 77, vacuum normal valve configuration, maglev rotation 560 Hz and day 111
I came in and PMC transmission was at 0.5V, and ETMX was swinging around a lot, (LSC mode was on).
Turning off oplevs let ETMX calm down. I realigned the PMC to 0.82V.
And the out-of-loop level of the ALSX compared with the previous measurement is ...?
I just realized that I forgot to elog this, but yesterday afternoon I bypassed the amplifier in the BeatX path, and now the X beatnote is about -27dBm. Arms lock nicely with ALS.
The Y arm green transmission had come down to 0.3 and the green steering mirrors on the Y end table required some minor alignment adjustments to bring back transmission to around 0.75 counts.
Anodized aluminum dumps replaced by 6 razor beam dumps.
Two more razor beam dumps added this afternoon. The picture will updated tomorrow.
There are 9 razor beam dumps at ETMY-ISCT
I added two green glass absorbers. The oplev centering may need a touch up when it is well aligned.
Below are the transfer functions measured between the angular (pit, yaw) motion of X arm mirrors and the ALSX error signal. The measurements were again made for 1Hz-30Hz.
The transfer functions are mostly flat.
ITMX P - 200-300 Hz/urad (beat freq = 45 MHz)
ITMX Y - 700-800 Hz/urad (beat freq = 27MHz)
ETMX P - 500-600 Hz/urad (beat freq = 56 MHz)
ETMX Y - 1000-2000 Hz/urad (beat freq = 62.5MHz)
Data xml files can be found in /users/manasa/data/140521/
PMC has been unlocked for ~4hrs, not sure why. It's servo gain was down at -10dB...
Relocked with transmission of .76V, MC locks fine with WFS, transmission of 15.5k.
Tektronix RECALL on TDS3000 or TDS300B oscilloscope BATTERIES TDS3BATB
This Lithium-Ion battery can be a fire hazard ! Remove battery pack and recycle it through Safety Office !
9. Arm cavity alignment. Significant DC effect.
* When the alignment of one of the arm cavity mirrors is changed, the DC value of the beatnote signal changes.
* ITMX moved in yaw, we see a 7kHz/15urad DC shift in the BEATX_FINE_PHASE_OUT_HZ time series.
* ETMX moved in yaw, we see an 8kHz/5.5urad DC shift in the time series. We aren't sure why this is about a factor of 3 times larger effect (same shift for smaller misalignment) than the ITM.
* We want to do a Yuta-style analysis to see what the angle to length coupling looks like, so that we can measure the angular motion of our cavity mirrors and put the expected noise into our ALS noise budget. Perhaps this will help us understand the low frequency difference between our in-loop beatnote error signal and our in-loop PDH error signals (red vs. maroon on the ALS noise budget posted above Pianosa).
* I've asked Manasa to take some transfer functions in the morning, so that we can start to have an idea of what is going on with this.
Attached is the measurement of the transfer function from ITMX oplev error in yaw to the ALSX error signal.
The arm was locked to the IR using POX and the green beat frequency (between X arm trans in green and PSL green) in this case was 27MHz.
The transfer function looks mostly flat between 1Hz - 30Hz at 700-800 Hz/urad. The DC shift that Jenne measured from the time series is ~500 Hz/urad.
So far I have not been able to measure the TF below 1Hz without the arm losing its lock. Updates will follow.
Data xml file can be found in /users/manasa/data/140521/
I fixed a bug in the SUS_SINGLE screen, where the total YAW output was incorrectly displayed (TO_COIL_3_1 instead of TO_COIL_1_3). I noticed this by seeing that the yaw bias slider had no effect on the number that claimed to be the yaw sum. The first time I did this, I accidently changed the screen size a bit which smushed things together, but that's fixed now.
I committed it to the svn, along with some uncommitted changed to the oplev servo screen.
I found MC unlocked this morning. I looked at the 2 day trend of the MC suspensions and found MC2 suspensions have been misaligned.
I used Rana's ezcaservo trick to recover MC lock. This brought the MC_REFL down to 0.7 counts. I did the rest of the alignment by moving the MC2 suspension sliders only. MC_REFL is down to 0.45-0.5 counts and TRANS_SUM is at ~16300.
Also, I found the WFS servo was left turned OFF. I re-enabled them as well.
We spent some time tonight looking at locking the PRMI with REFL165 vs. REFL33, while reducing the CARM offset.
We were not able to lock the PRMI on REFL165 I&Q at small CARM offsets. When locking at larger CARM offsets (about 100 counts, which is about 100nm) and then re-adjusting the REFL165 demod phase as I reduced the CARM offset, I saw that I had to significantly rotate the phase. For PRMI only (no arms), the REFL165 demod phase was -138.5 deg. When the PRMI was locked with a -100 count CARM offset, the optimal demod phase was -123 deg. Then at -90 counts the phase was -113 deg. At -70 counts, the phase was -108 deg, at -50 counts it was -98 deg, and at -40 it was -93 deg. We want to go back and look at these more carefully, and in a more continuous way, by watching the sensing matrix calibration lines. It's unclear to me right now why we're seeing this, but it's possible that we're getting some kind of extra 55MHz resonances.
REFL DC looks like it should be good - same slope and gain as sqrtTR, extra 20 or 30 deg of phase margin, so we think that we should be able to transition over to it, and then try engaging the AO path. Tonight we had Den's new 1kHz lowpass engaged, and with this, everything looks nice and stable.
Game plan: Bring CARM in until transmissions are at about 10ish, then try keeping CARM on sqrtInvTrans for the DC part, and engage the AC AO part with REFL DC. We probably just need to try this for a while more to find just the right way to turn it on.
Need to think about demod phase rotation vs CARM offset as well as extra resonances, but this may take a while, and if we can just get the AO path engaged, that would be good.
Since Q has found that REFL165 will be better for holding the PRMI while we reduce the CARM offset, I had a look at locking PRMI sideband locking with both 3f PDs.
I checked the REFL165 demod phase, and changed it from -142.5 deg to -138.5 deg. to minimize the Q signal while driving PRM length.
I found that keeping the MICH and PRCL loop gains the same, and using matrix elements +0.1 for both I and Q for REFL165, rather than +1 for both I and Q for REFL 33.
MICH gain is +0.8, PRCL gain is -0.02. FMs 4,5 on for both, FM 2 triggered for MICH, FMs 2,3,6 triggered for PRCL.
I then locked the PRMI on sideband with REFL 33 and then REFL 165, and measured the other one as an out of loop sensor of the motion. I find that REFL33 and 165 are both comparable, and so we shouldn't have any trouble using REFL165 for locking.
Here's the angles of MICH and PRCL from the my earlier plot by themselves; this shows that the individual demod angles in REFL165 aren't changing much either.
So, I really should have done this as soon as Manasa measured the arm lengths... I've updated my MIST model with the real arm lengths, but still am using assumed identical losses of 75ppm on each mirror. (I've tried measuring the arm losses for real, but got numbers in the hundreds of ppms, so I need to reexamine things...)
Here's a simulation of the fields in a perfectly locked PRC when CARM is swept (Normalized to input power = 1).
More importantly, here's the latest simulation of MICH vs. PRCL demodulation angle separation in the 3F signals. It seems that we may be getting burned by using REFL33 for the PRC lock. REFL165, on the other hand looks much more robust. We should try this out.
(Some of my previous simulations incorrectly implemented MICH excitations; I only moved the ITMS, not the ETMS along with them, so some other stuff slipped in... )
This QPD circuit (D980325-C1 ) uses the nice OP497 Quad FET opamp as the transimpedance amplifier. It has a low enough current noise, such that we can increase the resistors (R1-4) up to 100k and still be Johnson noise limited. We should also make sure that the compensation caps (C3-6) are ~2.2 nF so as to not destabilize the opamp. f_low = 1/2/pi/R/C = 730 Hz.
I will do the swap later today unless someone else gets to it first. (note: check for oscillations w/ fast scope probe after installing)
I did these modification tonight. The slideshow of some images is attached. Instead of 100k, I used 97.6k thin film, since this seemed like an oddball size that doesn't get used otherwise. I forgot to measure the dark noise of the quadrants before doing the swap, but comparing the pit/yaw/sum before/after the swap shows that the signal is basically unchanged (since pit/yaw is normalized by SUM), but that the noise is lower by a factor of a few above 100 Hz due to being above ADC noise now. Previously, it was bottoming out at ~10 prad/rHz. Since the signal is unchanged, I guess that the calibration and therefore the loop gain should not have changed either...
And the sum went up by almost 10x as expected from the resistor change.
ETMX oplev qpd gain has to be increased.
Atm3, Oplev sum read 12,000 counts when the qpd was disconnected ?
Dark qpd was zero and normal He/Ne incident on qpd was 1,730 counts.
We have looked at a few things that do and don't affect the out of loop noise of the ALS X beat, and found that cavity alignment and beatnote RF frequency had the strongest effects.
Possible causes of noise:
1. Air currents from A/C or flowbench. No effect.
* When table lid is on, turning on and off the flow bench air did not qualitatively change the out of loop beatnote time series signal.
2. Scattered light from other beams hitting green PDH PD. No effect.
* There are a few spots of green light that are hitting the case of the PDH photodiode, but when I put an iris in place to block those spots, there was no change in the beatnote spectra. This makes sense to me since none of those spots were close to hitting the diode itself.
* Rana did notice that the beam was not well centered on the PD, so he steered the beam onto the center of the diode. Also, the PD is now tilted a little bit so that the reflection from the diode doesn't go back into the beam path. Neither of these things had an effect that we noticed in the beatnote noise.
3. Oplev laser light getting to PDH PD. Not tested.
* We don't see any red light over by the PDH PD, so we did not try turning off the oplev's laser to see if that had an effect, but we suspect that it is not the cause of our noise.
4. Clipping of main IR / green beam on Xend table. Not tested.
* We should still go have a look at this, but we no longer think that this is the main cause of the elevated noise.
5. Scattered light all over Xend table. Not tested.
* We should still work on dumping extraneous beams on the table, but we do not think that this is the main cause of the elevated noise.
* Rana took some photos so that we can see how truely bad the situation is.
6. Amplitude modulation dip in NPRO. Not tested.
* It is probably still a good idea to check this, in case the dip in the amplitude modulation has changed over the year or two since it was last measured, but we also don't think that this is the main problem.
7. Check PDH servo. Not done.
* I think this is still on Q's long-term todo list, but we should give the PDH servos a once-over.
8. Arm cavity longitudinal motion. No effect.
* While the Xarm was locked with IR, we put a line at 1.7 Hz with 325 counts into the ITMX position. To keep lock, the ETM had to move as well. When we turned on this line (and increased its amplitude up to the final value of 325 cts), we did not see any qualitative change in the beatnote time series noise.
10. Beatnote RF frequency. Significant broadband effect.
* We have found that when the Xarm beatnote is at low RF frequencies, the noise is high, and when the beatnote is at high RF frequencies, the noise is low!
* Low RF freqs are below about 40 MHz, while high RF freqs are above about 90 MHz. This has not been tested for the Yarm. Also, these are for the case of "temp slider up, beatnote up". I have not checked if the same is true for the other side of the PSL frequency, although I don't have reason to believe that it would be.
* Maybe we are saturating some amplifiers? We need to check this out. One thought that Den mentioned was the harmonics, and that perhaps they are causing trouble in the electronics.
* Den is going to think about implementing a frequency divider so that we can directly digitize the beatnote signal.
* Here are spectra for different cases:
* And here is a spectrogram showing us going back and forth between the high and low noise states:
* A: First noticing that noise is good when RF frequency is high.
* B: Not locked on TEM00 mode, so extra noisy. Disregard.
* C: Bad noise time. Xbeat was 21 MHz (dark purple on DTT spectrum above), Ybeat was 118 MHz (sea green on DTT spectrum above).
* D: Good noise time. Xbeat was 89 MHz (light purple on DTT plot), Ybeat was still 118MHz (turquoise on DTT plot).
* E: Bad noise time. Xbeat was 37.5 MHz, Ybeat was still 118 MHz.
* F: Good noise time. Xbeat was 113 MHz, Ybeat was still 118 MHz.
Yend seismometer isolation kit (elog 8461) hosts Guralp seismometer. I made a cable for inside connection, assembled the kit and relocated the instrument from its previous position at the yend inside the kit.
Seismometer is connected to the readout box and running.
Xend internal cabling and external connector is ready. We are waiting for seismometer from Gyro lab. We still need to fix the pot with clamps after we put the instrument in.
We also need a long cable from Xend to the guralp readout box.
The daytime crew had noticed that there were some ETMX angular shifts happening without any control or intention.
I reseated and strain relieved the bias cable coming into the backplane of the coil driver and now it seems OK.
In the 4-hour-long second trend plot below, the era before 2300 is before reseating. Afterwards, we make a couple adjustments, but so far there has been no un-asked for alignment shifts.
AdS has been run on both arms and offsets saved. Its locked on green/red and the beat frequencies are low and the amplitudes high.
Sun May 18 23:53:37 2014: still OK...I declare it fixed.
We noticed that PRMI RIN is high when the cavity is locked on RELF33 I&Q signals. We compared the level of power fluctuations when PRMI was locked using REFL11, REFL55 and REFL 33. Attached plot "prmi_rin" shows the spectra.
Then we excited PRM and measured length to RIN coupling when PRMI was locked on REFL33 I&Q. DC offset of PRCL is only 3%. But MICH offset seems to be ~nm. When we gave offset of -15 cnts to the servo, power fluctuations improved by a factor of few.
Then we looked at DRMI. It seems that SRC macroscopic length is off but we still could lock it stably. To account for macroscopic length detuning we had to rotate REFL55 phase from 25 degrees to 50 degrees. Power at AS port increased by factor of ~2 compared to PRMI configuration. SPOP18 is decreased only by 30%. Attached plot "drmi_power" shows POP18, POP90, POPDC and ASDC in PRMI and DRMI configurations.
Plot "src_ol" shows srcl OL transfer function. UGF is 70 Hz. We have also centered SRM OL and copied the servo filters from PRM, gains are set to keep UGF at ~0.1 Hz and 7 Hz
This is a more detailed procedure:
1. Phase: REFL11: 19 degree, REFL55: 50 degrees (25 degrees for PRMI configuration)
2. Input matrix:
3. Servo parameters:
PRCL: gain = -0.02, FM4,5 + trigger FM2,3,6,9
MICH: gain = 0.8, FM4,5 + trigger FM2
SRCL: gain = 0.25, FM4,5 + trigger FM2,3
signal is SPOP22 , levels 40:25
Last week Rana and I struggled to figure out how to un-full-screen windows on the Ubuntu workstations that appeared to be stuck in some sort of full screen mode such that the "Titlebar" was not on the screen. Nothing seemed to work. We were in despair.
Well, there is now hope: it appears that this really is a "fullscreen" mode that can be activated by hitting F11. It can therefore easily be undone by hitting F11 again.
Electronic components should be ISOLATED as they are installed on the optical tables.
This is essential to avoid ground loops, 60 Hz and harmonic peaks in the spectrum. We have just got some made.
Please only use it for this reason. Earlier black delrin base plates were used up in not needed places.
The anodized Aluminum base plates with magenets certainly will conduct.
Den and I spent some time with the interferometer last night with hopes of bringing in the AO path, but were stymied by the (re)occurrence of the anomalously high low frequency motion of the Xarm, as seen by fluctuations of TRX from .9 to .2 while "held" on resonance.
Jenne reported that they weren't seeing it earlier in the evening, and then it started again when I showed up. Holding the arms on IR, we could see a fair amount of excess low frequency noise in the BEATX_FINE_PHASE_OUT_HZ channel, as compared to BEATY, bringing its RMS to 5 times that of the Y arm. From the shape of the excess noise (broad slope from DC to tens of Hz), Rana suspected air currents and/or scattering effects being the culprit.
Den poked around a bit on the PSL table, which didn't really change much. He then went down to the X end table to inspect the table, and while he was there, I noticed the noise go down to being in line with the Yarm. I joined him at the end, and we found the beat phase noise in the frequency region of concern to be hugely sensitive to tapping on the enclosure, air current, etc. There is also a ton of green light everywhere, and multiple spots of green light around the green refl PD.
At that point however, the quiescent noise was acceptable (TRX fluctuations of <.2), so we went back to the control room to try to lock. Unfortunately, after a few attempts, the noise was back. At this point, we went home. The layout of the end table likely needs some attention to try and minimize our susceptibility to excess scatter effects.
Turn off the AC and flow bench please.
The qpd was removed from the east end table and threaded adaptor ring epoxied on it's shell.
This tube will cut down the amount of emergency exit light getting into the qpd.
Tonight I noticed that the drop in PMC transmission was ~1V, more than the usual of ~0.5V from the daily drift.
While re-aligning on the table, I noticed that the misalignment was not from either of the steering mirrors; i.e. I has to walk them both to get the alignment back. This implies that the misalignment is generated far upstream. Maybe the the laser itself is moving. We need some updates from Steve's laser misalignment tracker.
I'd like to replace the paper target with IOO -QPD_POS so we can log it.