We have completed the above points; the ITMY table is still level.
Despite what the wiki says, the SRM LR OSEM open voltage is ~1.97V instead of ~1.64, so we shot for half of that.
The in-air steering of the SRM oplev return beam needs adjustment. I'll estimate the beam path length when I'm taking pictures and closing up.
Left to do:
Related In-Air work:
Everything is aligned, AS and POY make it out of vacuum unclipped, OSEM readings look good.
I set up the SRM oplev, centered all oplevs.
Tomorrow, we just have to take pictures of the ITMY chamber before we put the heavy doors on.
I closed the PSL shutter as we didn't want to burn the mirror surface when we are not working.
Photos have been taken of the ITMY chamber, and uploaded to picasa. Here's a slideshow:
I've installed a new 2pin lemo cable going from the CM servo out to in2 of the MC servo board, and removed the temporary BNC. I used some electrical tape to give the cable some thickness where the lemo head screws on to try to strain relieve the solder joints; hopefully this cable is more robust than the last.
I put an excitation into the CM board, and saw it come out of MC_F, so I think we're set.
The IFO is ready for 3F DRMI comissioning
I haven't been able to lock the DRMI tonight, neither with 1F and no arms nor 3F and arms held off with ALS... I tried previous recipes, and new combinations informed by simulations I've run, to no avail.
I touched the alignment of the green beat PD on the PSL table, since the X beatnote was rather low, but wasn't able to improve it by much. I never took a spectrum, since it wasn't my main focus tonight, but the low frequency motion of both arms on ALS, as observed by RIN, was good as I've ever seen it.
In our WFS work earlier today, Koji and I reset the WFS offsets, and it actually seems to have helped a good deal, in terms of the "fuzz" of MC REFL on the wall striptool. I had previously presumed this to be due to excess angular motion, but perhaps it is more accurately described as an alignment offset that let the nominal angular motion couple into the RIN more.
Yesterday, Koji and I measured the transfer function of pitch and yaw excitations of each MC mirror, directly to each quadrant of each WFS QPD.
When I last touched the WFS settings, I only used MC2 excitations to set the individual quadrant demodulation phases, but Koji pointed out that this could be incomplete, since motion of the curved MC2 mirror is qualitatively different than motion of the flat 1&3.
We set up a DTT file with twenty TFs (the excitation to I & Q of each WFS quadrant, and the MC2 trans quadrants), and then used some perl find and replace magic to create an xml file for each excitation. These are the files called by the measurement script Koji wrote.
I then wrote a MATLAB script that uses the magical new dttData function Koji and Nic have created, to extract the TF data at the excitation frequency, and build up the sensing elements. I broke the measurements down by detector and excitation coordinate (pitch or yaw).
The amplitudes of the sensing elements in the following plots are normalized to the single largest response of any of the QPD's quadrants to an excitation in the given coordinate, the angles are unchanged. From this, we should be able to read off the proper digital demodulation angles for each segment, confirm the signs of their combinations for pitch and yaw, and construct the sensing matrix elements of the properly rotated signals.
The axes of each quadrant look consistent across mirrors, which is good, as it nails down the proper demod angle.
The xml files and matlab script used to generate these plots is attached. (It requires the dttData functions however, which are in the svn (and the dttData functions require a MATLAB newer than 2012b))
I brought back the PMC, MC and Arms.
The autolocker is now working, but I didn't change anything to make it so. I was just putting in some echo statements, to see where it was getting hung up, and it started working... This isn't the first time I've had this experience.
It turns out IOO had a bad BURT restore. I restored from 5AM this morning, the WFS are ok now.
We're back! It was entirely my fault.
Some months ago I wrote a script that chiara calls every night, that rsyncs its hard drive to an external drive. With the power outage yesterday, the external drive didn't automatically mount, and thus chiara tried to rsync its disk to the mount point, which was at the time just a local folder, which made it go splat.
I'm fixing the backup script to only run if the destination of the rsync job is not a local volume.
I've changed the LSC rack wiring a little bit, to give us some flexibility when it comes to REFL11.
Previous, the REFL11 demod I output was fed straight to the CM servo board, and the slow CM board output was hooked up to the REFL11I ADC channel. Thus, it wasn't really practical to ever even look at sensing angles in REFL11, since the I and Q inputs were subject to different signal paths/gains. (Also, doing LSC offsets would do wonky things to refl11 depending on the state of the switches on the CM board screen.)
Thus, I've hooked up the CM board slow output into the the previously existing, aptly named, CM_SLOW channel. The REFL11 demod board I output is split to IN1 of the CM board, and the REFL11 I ADC channel.
So, there is no longer hidden behavior in behind the REFL11 input filters, channels are what they claim to be, and the CM board output is just as easily accessible to the LSC filters as before.
We attempted some of the same old CARM offset reduction tonight, but from the other direction. (We have no direct knowledge of which is the spring and which is the anti-spring side)
We we able to get to, and sit at, arm powers on the order of 5. Really, we kind of wanted just to push things to try and inform our current ideas of what our limiting factor is, so as to appropriately expend our efforts.
We took many digital CARM OLTFs at different offsets; it never really looked like a burgeoning pole was about to make things unstable. The low frequency OLTF data had bad SNR, so it wasn't clear if we were losing gain there. We weren't at arm powers where we would expect the DC transmission curve to flatten out yet, from simulations (which is above a few tens).
My impression from at least our last lock loss was a DARM excursion. However, using the DRMI won't get rid of the second two points.
In my previous simulation results, I've always plotted W/m, which isn't exactly straightforward. We often think about the displacement that a given mirror actuator output will induce, but when we're locking the full IFO, radiation pressure effects modify the mechanical response depending on the current detuning, making the meaning of W/m transfer functions a little fuzzy.
So, I've redone my MIST simulations to report Watts of signal response due to actual actuator newtons, which is what we actually control with the digital system. Note, however, that these Watts are those that would be sensed by a detector directly at the given port, and doesn't take into account the power reduction from in-air beamsplitters, etc.
As an example, here are the SqrtInv and REFLDC CARM TFs for the anti-spring case:
The units of the SqrtInv plot are maybe a little weird, these TFs are the exact shape of the TRX W/N TFs with the DC value adjusted by the ratio of the DC sweep derivatives of TRX and SqrtInv.
All of the results live in /svn/trunk/modeling/PRFPMI_radpressure/
I touched up the PMC alignment.
While bringing back the MC, I realized IOO got a really old BURT restore again... Restored from midnight last night. WFS still working.
Now aligning IFO for tonight's work
I made some measurements to try and see if any difference could be seen with different CARM offset signs.
Specifically, at various offsets, I used a spare DAC channel to drive IN1 of the CM board, as an "AO Exciter." I used CM_SLOW to monitor the signal that was actually on the board. I used the CARM_IN1 error signal to see how the optical plant responded to the AO excitation. Rather than a swept sine, I used a noise injection kind of TF measurement.
Here are plots of CARM_IN1 / CM_SLOW at different CARM FM offsets; I chose to plot this in an attempt to divide out some of the common things like AA and delays and make the detuned CARM pole more evident). The offsets chosen correspond roughly to powers of 2, 2.5, and 3. I tried to go higher than that, but didn't remain locked for long enough to measure the TF.
By eye, I don't see much of a difference. We can zpk fit the data, and see what happens.
I went back into the DQ channels to look at the TF from AO injection to REFLDC (which is easy to do with this kind of noise injection TF).
I fear that REFL does not seem to have as much phase under the resonance as we have modeled, lacking about 10-20 degrees. This could result from the zero in the REFL DC response that we've modeled at ~200ish Hz is actually higher. I'll look into what affects the frequency of that feature.
It is, of course, possible, that this measurement doesn't properly cancel out the various digital effects, but the REFLDC phase curves do seem to settle to (+/-) 90 after the pole as expected.
DTT XML file is attached.
This CPU load may have been me deleting some old frame files, to see if that would allow daqd to come back to life.
Daqd was segfaulting, and behaving in a manner similar to what is described here: (stack exchange link). However, I couldn't kill or revive daqd, so I rebooted the FB.
Things seem ok for now...
When I came in, Rossa was booted to Ubuntu 10. I tried rebooting to select 12, but couldn't ever successfully boot again. Since Diego was setting up Allegra from scratch, I've wiped and done the same with Rossa.
I've done some preliminary modeling to see if there is a good candidate for an IR DARM control signal that is available before the AS55 sign flip. From a DC sweep point of view, ASDC/(TRX+TRY) may be a candidate for further exploration.
As a reminder, both Finesse and MIST predict a sign flip in the AS55 Q control signal for DARM in the PRFPMI configuration, at a CARM offset of around 118pm.
The CARM offset where this sign flip occurs isn't too far off of where we're currently losing lock, so we have not had the opportunity to switch DARM control off of ALS and over to the quieter IR RF signal of AS55.
Here are simulated DC DARM sweep plots of our current PRFPMI configuration, with a whole bunch of potential signals that struck me.
Although the units of most traces are arbitrary in each plot (to fit on the same scale), each plot uses the same arbitrary units (if that makes any sense) so slopes and ratios of values can be read off.
In the 300 and 120pm plot, you can see that the zero crossing of AS55 is at some considerable DARM offset, and normalizing by TRX doesn't change much about that. "Hold on a second," I hear you say. "Your first plots said that the sign flip happens at around 120pm, so why does the AS55 profile still look bad at 50pm?!" My guess is that, probably due to a combination of Schnupp and arm length asymmetry, CARM offsets move where the peak power is in the DARM coordinate. This picture makes what I mean more clear, perhaps:
Thus, once we're on the other side of the sign flip, I'm confident that we can use AS55 Q without much problem.
Now, back to thoughts about an interim signal:
ASDC by itself does not really have the kind of behavior we want; but the power out of AS as a fraction of the ARM power (i.e. ASDC/TRX in the plot) seems to have a rational shape, that is not too unlike what the REFLDC CARM profile looks like.
Why not use POPDC or REFLDC? Well, at the CARM offsets we're currently at, POPDC is dominated by the PRC resonating sidebands, and REFLDC has barely begun to decline, and at lower CARM offsets, they each flatten out before the peak of the little ASDC hill, and so don't do much to improve the shape. Meanwhile, ASDC/TRX has a smooth response to points within some fraction of the DARM line width in all of the plots.
Thus, as was discussed at today's meeting, I feel it may be possible to lock DARM on ASDC/(TRX+TRY) with some offset, until AS55 becomes feasible.
(In practice, I figure we would divide by the sum of the powers, to reduce the influence of the DARM component of just TRX; we don't want to have DARM/DARM in the error signal for DARM)
Two caveats are:
[Code and plots live in /svn/trunk/modeling/PRFPMI_radpressure]
I've been trying to figure out why daqd keeps crashing, but nothing is fixed yet.
I commented out the line in /etc/inittab that runs daqd automatically, so I could run it manually. Each time I run it ( with ./daqd -c ./daqdrc while in c1/target/fb), it churns along fine for a little while, but eventually spits out something like:
[Thu Oct 16 11:43:54 2014] main profiler warning: 1 empty blocks in the buffer
[Thu Oct 16 11:43:55 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:43:56 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:43:57 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:43:58 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:43:59 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:44:00 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:44:01 2014] main profiler warning: 0 empty blocks in the buffer
[Thu Oct 16 11:44:02 2014] main profiler warning: 0 empty blocks in the buffer
GPS time jumped from 1097520250 to 1097520257
FATAL: exception not rethrown
I looked for time disagreements between the FB and the frontends, but they all seem fine. Running ntpdate only corrected things by 5ms. However, looking through /var/log/messages on FB, I found that ntp claims to have corrected the FB's time by ~111600 seconds (~31 hours) when I rebooted it on Monday.
Maybe this has something to do with the timing that the FB is getting? The FE IOPs seem happy with their sync status, but I'm not personally currently aware of how the FB timing is set up.
On Monday, Jamie suggested checking out the situation with FB's RAID. Searching the elog for "empty blocks in the buffer" also brought up posts that mentioned problems with the RAID.
I went to the JetStor RAID web interface at http://192.168.113.119, and it reports everything as healthy; no major errors in the log. Looking at the SMART status of a few of the drives shows nothing out of the ordinary. The RAID is not mounted in read-only mode either, as was the problem mentioned in previous elogs.
I've added (TRX-TRY)/(TRX+TRY) to the DC DARM sweep plots, and it looks like an even better candidate. The slope is closer to linear, and it has a zero crossing within ~10pm of the true DARM zero across the different CARM offsets, so we might not even need to use an intentional DARM offset.
I've been able to repeatedly get off of ALS and onto (TRY-TRX)/(TRY+TRX). Nevertheless, lock is lost between arm powers of 10 and 20.
I do the transition at the same place as the CARM->SqrtInv transition, i.e. arm powers about 1.0 Jenne started a script for the transition, and I've modified it with settings that I found to work, and integrated it into the carm_cm_up script. I've also modified carm_cm_down to zero the DARM normalization elements.
I was thwarted repeatedly by the frequent crashing of daqd, so I was not able to take OLTFs of CARM or DARM, which would've been nice. As it was, I tuned the DARM gain by looking for gain peaking in the error signal spectrum. I also couldn't really get a good look at the lock loss events. Once the FB is behaving properly, we can learn more.
Turning over to difference in transmission as an error signal naturally squashes the difference in arm transmissions:
I was able to grab spectra of the error and control signals, though I did not take the time to calibrate them... We can see the high frequency sensing noise for the transmission derived signals fall as the arm power increases. The low frequency mirror motion stays about the same.
So, it seems that DARM was not the main culprit in breaking lock, but it is still gratifying to get off of ALS completely, given its out-of-loop-noise's strong dependence on PSL-alignment.
BUT, what we really need (instead of just the DC sweeps) is the DC sweep with the uncertainty/noise displayed as a shaded area on the plot, as Nic did for us in the pre-CESAR modelling.
I've taken a first stab at this. Through various means, I've made an estimation of the total noise RMS of each error signal, and plotted a shaded region that shows the range of values the error signal is likely to take, when the IFO is statically sitting at one CARM offset.
I have not included any effects that would change the RMS of these signals in a CARM-offset dependent way. Since this is just a rough first pass, I didn't want to get carried away just yet.
For the transmission PDs, I measured the RMS on single arm lock. I also measured the incident power on the QPDs and thorlabs PDs for an estimate of shot noise, but this was ridiculously smaller than the in-loop RIN. I had originally though of just plotting sensing noise for the traces (i.e. dark+shot), because the amount of seismic and frequency noise in the in-loop signal obviously depends on the loop, but this gives a very misleading, tiny value. In reality we have RIN from the PRC due to seismic noise, angular motion of the optics, etc., which I have not quantified at this time.
So: for this first, rough, pass, I am simply multiplying the single transmission noise RMSs by a factor of 10 for the coupled RMS. If nothing else, this makes the SqrtInv signal look plausible when we actually practically find it to be plausible.
For the REFL PDs, I misaligned the ITMs for a prompt PRM reflection for a worst-case shot noise situation, and took the RMS of the spectra. (Also wrote down the dark RMSs, which are about a factor of 2 lower). I then also multiplied these by ten, to be consistent with the transmission PDs. In reality, the shot noise component will go down as we approach zero CARM offset, but if other effects dominate, that won't matter.
Enough blathering, here's the plot:
Now, in addition to the region of linearity/validity of the different signals, we can hopefully see the amount of error relative to the desired CARM offset. (Or, at least, how that error qualitatively changes over the range of offsets)
This suggests that we MAY be able to hop over to a normalized RF signal; but this is a pretty big maybe. This signal has the response of the quotient of two nontrivial optical plants, which I have not yet given much thought to; it is probably the right time to do so...
After the second of the two recent power outages, the outlet powering Chiara's external drive for local backups didn't come back. The modification to the backup script I made correctly identified that the drive wasn't mounted, and happily logged its absence and didn't try to stuff the internal drive with a copy of itself. However, I hadn't checked the logs to see if the backups were proceeding until today... maybe I should set up an email alert for these, too.
I plugged the external drive into a live outlet, and mounted the 40mBackup drive with: sudo udisks --mount /dev/sdc1, which is a helpful command that puts the drive at /media/40mBackup as it should be, based on the drive label.
sudo udisks --mount /dev/sdc1
The /cvs/cds backup is now proceeding, to make up for lost time.
I spent some time trying to debug our inability to get MICH onto REFL165Q while the arms are held off with ALS, to no real success.
I set up our usual repeatable situation of PRMI on 33 I&Q, arms held off with ALS. I figured that it may help to first sideband lock on REFL55, since 165 is looking for the f2 sidebands and maybe there is some odd offset between the locking points for f1 and f2 or other weirdness.
REFL 55 settings:
Demod angle 98->126 (was previously set for PRY locking)
PRCL = 0.5 * REFL55 I (UGF of ~200 Hz) (FM gain unchanged from REFL33 situation of -0.02)
MICH = 0.125 * REFL55 Q (UGF of ~60Hz) (same FM gain as 33)
Some REFL55 offset adjusting had to be done in order to not disturb the 33-initiated lock when handing off.
I also adjusted POP110 phase to zero the Q when locked, and switched the triggering over to 110I
The PRMI can acquire lock like this with arms held off with ALS, no problem.
Here, I tried to hop over to 165. PRCL was no problem, needing a +1 on 165I. However, I had no success in handing off MICH. I twiddled many knobs, but none that provably helped.
I saw indications that the sensing angle in 165 is small (~20deg), which is not consistent with current knowledge of the cavity lengths. We last interferometrically measured the PRC length by letting the PRMI swing and looking at sideband splitting in POP110. At LLO, they did a length measurement by looking at demod angle differences in PRMI carrier vs. sideband locking. (alog8562) This might be worth checking out...
I took some spectra of the error signals and MC2 Trans RIN with the loops off (blue) and on (red) during the current conditions of daytime seismic noise.
Short report: Further frustrated by 165 tonight. The weird thing is, the procedure I'm trying with the arms held off on ALS (i.e. excitation line in MICH and PRCL, adjust relative gains to make the signs and magnitudes mach, ezcastep over) works flawlessly with the ETMs misaligned. One can even acquire SB PRMI lock on 165 I&Q, with 80-90 degrees of demod angle between MICH and PRCL. The only real difference in REFL55 settings for misaligned vs. ALS-offset arms is an extra factor of two in the FM gains to maintain the same UGF, so I hoped that the matrix elements for 165 with misaligned arms would hold for ALS-offset arms.
Alas, no such fortune. I still have no clear explanation for why we can't get MICH on 165Q with the arms held off on ALS.
I also gave a quick try to measuring the PRCL->REFL55 demod phase difference between carrier and sideband lock (with arms misaligned), and got something on the order of 55 degrees, which really just makes me think I wasn't well set up / aligned, rather than actually conveying information about the PRC length...
I just installed cdsutils r351 at /ligo/apps/linux-x86_64/cdsutils. It should be available on all workstations.
It includes a bunch of bug fixes and feature improvements, including the step stuff that Rana was complaining about.
Cdsutils r361 installed, for the "avg" updates. aLOG
Earlier today, I did some simulations that suggested that PRC lengths on the order of a cm from our current estimated one could result in degenerate PRCL and MICH signals in REFL165 at 3nm CARM offset. I attempted more demod-angle derived cavity PRC length measurements with REFL11 and REFL55, but they weren't consistent with each other...
In any case, adding dual recycling, even with a SRC length off by 1cm in either direction, doesn't seem to exhibit the same possibility, so I spent some time tonight seeing if I could make any progress towards DRMI locking.
I was able to lock SRY using AS55 in a very similar manner to PRY, after adjusting the AS55 demod angle to get the error signal entirely in I. I used this configuration to align the SRM to the previously aligned BS and ITMY. Oddly, I was not able to do anything with SRX as I had hoped; the error signal looks very strange, looking more like abs(error signal).
I then was able to lock the SRMI on AS55 I & Q, the settings have been saved in the IFO configure screen. I've used AS55Q for PRMI locking with a gain of -0.2, so I started with that; the final gain ended up being -0.6. PRMI/PRY gain for prcl is something like 0.01, so since I used a gain of 2 for locking SRX, I started the SRCL gain around 0.02, the final gain ended up being -0.03. I basically just guessed a sign for AS110 triggering. Once I lucked upon a rough lock, I excited the PRM to tune the AS55 angle a few degrees; it was luckily quite close already from the SRY adjustment. AS110 needed a bigger adjustment to get the power into I. (AS55: -40.25->-82.25, AS110: 145->58, but I put AS55 back for PRMI)
I briefly tried locking the DRMI, but I was really just shooting in the dark. I went back and measured various sensing amplitudes/angles in SRMI and PRMI configurations; I'm hoping that I may be able to simulate the right gains/angles for eventual DRMI locking.
Something to note, as we have the IMC angular controls under consideration:
Jenne has the DRMI locked right now. I took a look at the coherence between the POP QPD and MC2 transmission QPDs. (Since she's using ASC, I also included those control signals. The coherences are about the same, unsurprisingly)
Based on the observed coherences, from about 1 to 6Hz, IMC motion is responsible for a fair amount of the DRMI angular motion. Also, PIT and YAW couple differently.
I've fallen down the rabbit hole of trying to reconcile our desire for newer versions of the Numpy and Scipy python packages with the use of our handy cdsutils tools.
I've set up an installation of Anaconda python in /ligo/apps/anaconda. Installing pyepics, nds2, and cdsutils was straightforward, but there were a myriad of odd python packages that cdsutils depends on, that are typically installed at the OS level (python-gst, gobject, glib) which I just manually copied over to the anaconda directories. Also, the version of readline that anaconda ships with is somewhat borked (dark voodoo fix was found here: github link. The issue mentioned there wasn't why I needed the fix. Somehow libreadline was causing pyepics initialization to fail).
I was initially hoping this kind of exercise would be useful, as having a separate python environment that we control buffers us from the system installation and allows us to use whatever version of packages we want, but the amount of hackery I did to get to get cdsutils to work probably didn't result in the most robust solution. (Maybe there was a better way!)
In any case, I have not changed any of our machines' default paths or environment variables. Instead, I have simply created an alias that points to Anaconda python: "apython"
import scipy as sp
from ezca import Ezca
print 'Python Version: '+ sys.version
print 'ez.read test:' + str(ez.read('LSC-TRY_OUT16'))
print 'Scipy Version: '+sp.__version__
Python Version: 2.7.3 (default, Feb 27 2014, 19:58:35)
Scipy Version: 0.9.0
Python Version: 2.7.8 |Continuum Analytics, Inc.| (default, Aug 21 2014, 18:22:21)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]
Scipy Version: 0.14.0
Thus, Diego should now be able to complete his script that needs the newer Scipy, as well as CDSutils.
Final note: I've tested z (read|write|avg) with $PATH modified to have /ligo/apps/anaconda/bin at the start, and they seem to work. If things seem to hold up, maybe we can replace the default command-line python, but its not strictly necessary.
Given the checkout of the aLIGO BBPDs happening (aLOG link), wherein the PDs were acting funny, and Koji has made some measurements determining that intermodulation/nonlinearity of circuitry can corrupt 3F signals, I've made a similar measurement of the RF spectra of REFL165 when we're locked on DRMI using 1F signals. Maybe this could give us insight to our bad luck using REFL165...
In essence, I plugged the RF output of the PD into an AG4395, through a 10dB attenuator and downloaded the spectrum. I also did REFL33 as a possible comparison and because why not. The attached plots have the 10dB accounted for; the text files do not.
REFL165 (Exposed PCB BBPD):
(What is all that crap between 8 and 9 fmod?)
REFL33 (Gold Box resonant RFPD):
Green beatnotes recovered.
It was just a matter of aligning the arm greens and PSL greens on the PSL table. I suppose something knocked the PSL alignment out of whack... I was also able to simultaneously see the green beatnote and IR beatnote respond to Yend laser temperature.
Locked arms on POX/POY, checked RMS of ALS-BEAT[X/Y]_FINE_PHASE_OUT_HZ channels.
These seem fine. Locked CARM and DARM on ALS, found IR resonances.
ALS is back in business
Now that I have followed the chain, the PD signal is indeed being amplified at the LSC rack. It goes into a ZFL-1000LN+ amplifier (~23dB gain at 165MHz and 15V supply), followed by a SHP-100 high pass filter, and then enters the RF IN of the demod board.
I repeated the measurement in two spots.
First, I took a spectrum of the RF MON of the REFL165 demod board during DRMI lock; this was input-referred by adding 20dBm.
Second, I inserted a ZFDC-10-5 coupler between the high pass and the RF input of the demod board. This was input-referred by adding 10dBm.
My calibration isn't perfect; the peaks above the high pass corner seem to be different by a consistent amount, but within a few dBm.
Thus, it looks like the demod board is getting a little under -40dBm of 165MHz signal at its input.
Where is the PD out spectrum measured with the coupler???
The "coupled" port of the coupler went to the AG4395 input, the output of the Highpass is connected to the "IN", and the "OUT" goes to the demod board.
After some enlightening conversation with Koji, we figured that the RF amplifier in the REFL165 chain is probably being saturated (the amp's 1dB compression is at +3dBm, has 23dB gain, and there are multiple lines above -20dBm coming out of the PD). I took a few more spectrum measurements to quantify the consequences, as well as a test with the highpass connected directly to the PD output, that should reduce the power into the amplifier. However, I am leaving everything hooked back up in its original state (and have removed all couplers and analyzers...)
I also took some DRMI sensing measurements. In the simple Michelson configuration, I took TFs of each ITMs motion to AS55Q to make sure the drives were well balanced. They were. Then, in the DRMI, I took swept sine TFs of PRCL, SRCL and differential ITM MICH motion to the Is and Qs of AS55 and all of the REFLs. I constrained the sweeps to 300Hz->2kHz; the loops have some amount of coupling so I wanted to stay out of their bandwidth. I also took a TF of the pure BS motion and BS-PRM MICH to the PDs. From these and future measurements, I hope to pursue better estimates of the sensing matrix elements of the DRMI DoFs, and perhaps the coefficients for compensating both SRCL and PRCL out of BS motion.
I'm leaving analysis and interpretation for the daytime, and handing the IFO back to Diego...
After some enlightening conversation with Koji, we figured that the RF amplifier in the REFL165 chain is probably being saturated.
The measurements I took yesterday bear this out. However, even putting the high-pass directly on the PD output doesn't reduce the signal enough to avoid saturating the amplifier.
We need to think of the right way to get the 165MHz signal at large enough, but undistorted, amplitude to the demod board.
The current signal chain looks like:
AS Table LSC RACK
[ PD ]----------------------------------->[ AMP ]------>[ 100MHzHPF ]----->[ DEMOD ]
(1) (2) (3)
I previously made measurements at (3). Let's ignore that.
Last night, I took measurements with a directional coupler at points (1) and (2), to see the signal levels before and after the amplifier. I divided the spectrum at (2) by the nominal gain of the amplifier, 23.5dB; thus if everything was linear, the spectra would be very similar. This is not the case, and it is evident why. There are multiple signals stronger than -20dBm, and the amplifier has a 1dB compression point of +3dBm, so any one of these lines at 4x, 6x and 10x fMod is enough to saturate.
I also made a measurement at point 4 in the following arrangement, in an attempt to reduce the signal amplitude incident on the amplifier.
[ PD ]->[ 100MHzHPF ]----------------------------------->[ AMP ]--------->[ DEMOD ]
Though the signals below 100MHz are attenuated as expected, the signal at 110MHz is still too large for the amplifier.
Minicircuits' SHP-150 only has 13dB suppression at 110MHz, which would not be enough either. SHP-175 has 31dB suppression at 110MHz and 0.82dB at 160MHz, maybe this is what we want.
Here are some preliminary results from the sensing sweeps I did the other night.
xml files, and DttData matlab script used to generate these plots is attached.
Jenne and I measured the situation using a SHP-150 directly attached to the REFL165 RF output, and at first glance, the magnitude of the 165MHz signal seems to not be distorted by the amplifier.
We will soon investigate whether 165 signal quality has indeed improved.
ARG, I accidentally permuted the digital demod angles. This significantly weakens the argument for believing AS55I is broken... In fact, Jenne and I did some investigations this afternoon that showed that the channel is indeed working. SRX error signal strangeness remains unexplained, however.
Also, I have yet to compensate for the gain of the violin filters; the actuator calibration numbers I used were for the SUS-LSC FMs, not the LSC FMs where I was injecting. New measurements will be taken soon, as well, since REFL165 is hopefully improved.
Corrected plots are below.
Q >> Please measure the RF spectrum again with the notch.
The notch filter has been installed directly attached to the output of the SHP-150 at the PD output. Structurally, there is a right angle SMA elbow between the two filters; I set up a post holder under the notch pomona box to prevent torque on the PD. Via directional coupler and AG4395, we measured the output of the REFL165 RF amplifier with the PRMI locked on REFL33.
Note, the plot below is not referred to the amplifier output, as in my previous plots; it is directly representative of the amplifier output spectrum.
There are no RF signals being output above -28dBm, thus I am confident that we are not subject to compression distortion.
Given the last measurements we made (ELOG 10692), I estimate that the notch has reduced the power at 110MHz by ~33dB, which is 9dB higher than the notch performance Koji measured when he made it. Maybe this could be due to the non-50Ohm impedance of the HPF distorting the tuning, or I physically detuned it when mounting it on the PD. Still, 33dB is pretty good, and may even give us room to amplify further. (ZRL-700+ instead of the ZFL-1000LN+?)
I did some simulations to see if we are susceptible to HOM resonances as we reduce the CARM offset. I restricted my search to HG modes of the Carrier+[-55,-11,0,+11,+55]MHz fields with n+m<6, and used all the real physical parameters I could get ahold of.
In short, as I change the CARM offset, I don't see any stray resonances within 2nm of zero, either in PRFPMI or DRFPMI.
Now, the mode matching in my simulation is not the real mode matching our real interferometer has. Thus, it can't tell us how much power we may see in a given mode, but it can tell us about our susceptibility to different modes. I.e. if we were to have some power in a certain mode coming out of the IMC, or present in the vertex, we can see what it would do in the arms.
Since my simulation has some random amounts of power in each HOM coming into the interferometer, I simply swept the CARM offset and looked for peaks in the power of each mode. Many of the fields exhibited gentle slopes over the range, and we know we ok from 3nm->~100pm, so I made the selection rule that a "peak" must be at least 10 times as big as the minimum value over the whole range, in order to see fields that really do have CARM dependence.
In the following plots, normalized IFO power is plotted and the locations of HOM peaks are indicated with circles; their actual heights are arbitrary, since I don't know our real mode content. However, I'm not really too concerned, since all I see is some -11MHz modes between 2-3nm of full resonance, where we have no problem controlling things... Also, all of the carrier HOMs effectively co-resonate with the 00 mode, which isn't too surprising, and I didn't include these modes in the plots.
Finally, I visually inspected the traces for all of the modes, and didn't really find anything else peeking out.
Code, plots attached.
So, with my last entry, I was guilty of just throwing stuff into the simulation and not thinking about physics... so I retreated to Siegman for some algebraic calculations of the additional Guoy phase accumulated by the HOMs in the arms -> their resonant frequencies -> the arm length offset where they should resonate. Really, this isn't completely precise, as I treated the arms independently, with slightly differing ETM radii of curvature, but I would expect the "CARM Arm" to behave as a sort of average of the two arm cavities in this regard. (EDIT: Also, I didn't really consider the effect of the coupled vertex cavities... so there's more to be done)
The basic idea I used was:
In practice, I threw together a python script to do this all and print out a table. I've highlighted the values within 10nm, but the closet one is 3.8nm
########## X Arm HOM Resonance Locations in nm ##########
Mode Order: 0 , 1 , 2 , 3 , 4 , 5
Carrier : +0, +156.21, -219.58, -63.376, +92.832, +249.04
LSB 11 : +59.563, +215.77, -160.02, -3.8126, +152.4, -223.4
USB 11 : -59.563, +96.645, +252.85, -122.94, +33.269, +189.48
LSB 55 : -234.18, -77.975, +78.233, +234.44, -141.35, +14.857
USB 55 : +234.18, -141.61, +14.6, +170.81, -204.98, -48.776
########## Y Arm HOM Resonance Locations in nm ##########
Carrier : +0, +154.82, -222.35, -67.531, +87.292, +242.11
LSB 11 : +59.313, +214.14, -163.04, -8.218, +146.6, -230.57
USB 11 : -59.313, +95.51, +250.33, -126.84, +27.978, +182.8
LSB 55 : -235.43, -80.611, +74.212, +229.04, -148.14,
USB 55 : +235.43, -141.74, +13.08, +167.9, -209.27, -54.452
I've extended my analysis to the PRFPMI case, with the current working knowledge of radii of curvature and cavity lengths. However, losses were not included.
I do not see any HOM activity within about 20nm of the carrier TM00 resonance.
Basically, what I did was use the standard formulae for the reflection and transmission coefficients of FB cavities viewed as compound mirrors. However, I modified the normal spatial propagation terms to include the additional Guoy phase accumulated by the HOMs. I created these coefficients for each arm individually, and then used (rX + rY)/2 as a mirror in the PRC, and used that to create the transmission coefficient for the PRFPMI as a whole, as a function of frequency offset from the carrier, spatial mode order and CARM offset. As a check, this produced the correct finesse for the carrier lock to the single arm and PRFPMI.
Here is a PRFPMI CARM FSR of all of the fields' power transmission coefficients, up to order n+m=5.
One can observe some split peaks. There are two causes, the biggest effect is the mismatch between ETM radii of curvatures (ETMX:59.48, ETMY:60.26):, followed by asymmetric arm length(X:37.79, Y:37.81). (I judged this by the visual change of the plot when changing different factors).
In the following plot, I broke down the peaks by mode order:
Code, plots attached!
I took a quick look at single arm RIN. Actuating on MC2 vs. the ETM, or using AS55 instead of POY11 made no noticeable difference in the arm cavity RIN. Not too surprising, but there it is.
Similar to what Jenne did the other night, I kept the PRFPMI arm DoFs locked on ALS, in hopes to check out the RF error signals.
I was able to stably sit at nominally zero offset in both CARM and DARM, tens of minutes at a time, and the PRMI could reacquire without a fuss. Arm powers would rest between 10 and 20, intermittently exhibiting the "buzzing" behavior that Jenne mentioned when passing through resonance. 100pm CARM offset means arm powers of around 10, so since our ALS RMS is on this order, this seems ok. I saw TRX get as high as 212 counts, which is just about the same that I've simulated as the maximum power in our IFO.
To get this stable, I turned off all boosts on MICH and PRCL except PRCL FM6, and added matrix elements of 0.25 for TRX and TRY in the trigger line for the PRMI DoFs. The logic for this is that if the arm powers are higher than 1, power recycling is happening, so we want to keep things above the trigger down value of 0.5, even if POP22 momentarily drops.
I also played around a bit with DARM offsets. We know from experience that the ALS IR resonance finding is not super precise, and thus zero in the CARM FM is not zero CARM offset when on ALS. The same obviously holds for DARM, so I moved the DARM offset around, and could see the relative strengths of flashes change between the arms as expected.
I've written down some GPS times that I'm going to go back and look at, to try to back out some information about our error signals.
Lastly, there may be something undesirable happening with the TRX QPD; during some buzzing, the signal would fluctuate into negative values and did not resemble the TRY signal as it nominally would. Perhaps the whitening filters are acting up...
Steve had me measure the RIN of a JDSU HeNe laser. I used a PDA520, and measured the RIN after the laser had been running for about an hour, which let the laser "settle" (I saw the low frequency RIN fall after this period).
Here's the plot and zipped data.
Steve: brand new laser with JDSU 1201 PS
At Rana's request, I've made an in-situ measurement of the RIN of all of our OpLevs. PSL shutter closed, 10mHz BW. The OpLevs are not neccesarily centered, but the counts on darkest quadrant on each QPD is not more than a factor of a few lower than the brightest quadrant; i.e. I'm confident that the beam is not falling off.
I have not attached that raw data, as it is ~90MB. Instead, the DTT template can be found in /users/Templates/OL/ALL-SUM_141125.xml
Here are the mean and std of the channels as reported by z avg 30 -s, (in parenthesis, I've added the std/mean to estimate the RMS RIN)
z avg 30 -s,
SUS-BS_OLSUM_IN1 1957.02440999 1.09957708641 (5.62e-4)
SUS-ETMX_OLSUM_IN1 16226.5940104 2.25084766713 (1.39e-4)
SUS-ETMY_OLSUM_IN1 6755.87203776 8.07100449176 (1.19e-3)
SUS-ITMX_OLSUM_IN1 6920.07502441 1.4903816992 (2.15e-4)
SUS-ITMY_OLSUM_IN1 13680.9810547 4.71903560692 (3.45e-4)
SUS-PRM_OLSUM_IN1 2333.40523682 1.28749988092 (5.52e-4)
SUS-SRM_OLSUM_IN1 26436.5919596 4.26549117459 (1.61e-4)
Dividing each spectrum from DTT by these mean values gives me this plot:
ETMY is the worst offender here...
I've uploaded a note at T1400735 about a new implementation of CESAR ESCOBAR ideas I've been working on. Please send me any and all feedback, comments, criticisms!
Using the things I talk about in there, I was able to have a time domain simulation of a 40m arm cavity transition through three error signals, without hardcoding the gains, offsets, or thresholds for using the signals. Some results look like this:
I'm going to be trying this out on the real IFO soon...