Edit Thu Apr 15 08:32:58 2021 :
Comments are from Rana.
Corrected the plot in the attachment. It shows the correct behavior at high frequencies now.
- Do the following list for all of the testmass chambers.
- Start slow pumping
I made a quick sketch of how to include two more RF PDs on the REFL beam, given the space we have on the table. We want to install REFL33 and REFL165, 3f signals for the the two modulation frequencies we are using. The point is to make the distance from first beam splitter the same to all PDs so that we can use only one lens before this BS to make the beam the right size. Currently there are 2 PDs on the refl beam, REFL11 and REFL55, predictably. So the drawing shows 4 PDs. Drawing is to scale but is a bit coarse. Hopefully we'll take pictures once we're done.
Reference from current BS splitting beam to the existing PDs.
Just to give some heads up on how the setup on the PSL table does / will look. We start out with one of the two reflections of a window. Power about 2mW.
For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.
Suresh tells us that he already has this channel physically plugged in. Probably as a result of Valera's MCASS work. Neat. We just have to make the channel. Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.
We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things. So. Tomorrow. In the morning:
We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F". We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC. Then we will compile all the things. Or at least all the things that we touched. This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway. Neat.
Things to compile tomorrow: c1ioo and c1rfm, because of channel routing. c1oaf because of all the new stuff. That should be all.
Is it okay to have two names for the same signal? We would have both MCS_MCL and MC_F referring to MC length signal. This signal is picked up from the MC-Servo (analog) and brought into the CDS through the adc_0_0 channel in C1IOO. Then this signal is sent from C1IOO to C1MCS model without going through the c1rfm model. This seems to break the current protocol that signals passed between machines have to go through the c1rfm model. It should be sufficient to send this signal to c1rfm once and from there redirect to MCS and OAF from there, with an appropriate name.
Suresh makes a fine point. I think the channel between c1ioo and c1mcs should always have had to go through the c1rfm model. I don't know why it wasn't. Anyhow, I have changed things so that there is one signal passing from c1ioo to c1rfm, and that signal is split in two, and goes to both c1oaf and c1mcs. The naming convention I used last night is the one I kept: C1:IOO-RFM_MCL goes from c1ioo to c1rfm, and then C1:RFM-OAF_MCL goes from c1rfm to c1oaf, and C1:RFM-MCS_MCL goes from c1rfm to c1mcs.
We can't compile until Mirko and I figure out what to do with the OAF model though. Mirko, Den and I were looking at the c1oaf model, to make sure it is ready to compile, and I'm not sure that it is. And we need everything with common channel names to be compiled at the same time, so I can't compile any of the models today, until we get this figured out.
The problem is thus: The old TOP_XFCODE that mevans wrote back in 2008 takes in a certain number of inputs, calculates the new filter coefficients, and spits out the filtered signals. Back in those days, we only ever gave the adaptive system one control (target) signal at a time. Now, we want to be able to do multiple, if we so desire. I don't know exactly how to do this yet. Either we need to modify the code to make it a super-code, or we can have one copy of the code for each control signal (MC_F, XARM, YARM, DARM, MICH, etc...). Do we want to have one code adapt everything at once, and have a giant MIMO system, or do we want to have many SISO-like systems in parallel (SISO-like, because each one would take in one control signal, and many seismometer signals, and output many filtered seis signals, but it wouldn't be combining control signals together)?
Either one of these options could be waaay to computationally tough for the computer. The old computer was basically railed when we had one adaptive block, with one control signal and 7 seismometers. 7 was the max number of auxiliary channels we could use. So, how much faster are the new computers?? Do we need to have one OAF per DoF that we want to filter?
We still need elaborated test procedure posted
gautam: Koji and I were just staring at the vacuum screen, and realized that the drypumps, which are the backing pumps for TP2 and TP3, are not reflected on the MEDM screen. This should be rectified.
Steve also mentioned that the new small turbo controller does not directly interface with the drypump. So we need some system to delay the starting of the turbo itself, once the drypump has been engaged. Does this system exist?
GOAL1: Stable lock of DRMI
GOAL2: Measurement of the LSC input matrix in the DRMI configuration
/- - Daytime works - - /
+ Measurement of the arm lengths (Jenne / Kiwamu / volunteers)
+ Optimization of the oplev control loops (Paul)
+ Inversion and installation of the SUS input matrices (Jenne)
+ Tuning of the SUS damping gains (Steve)
+ Measurement of the modulation depths (Mirko)
+ Preparation of the green broadband PD (Katrin)
+ Fixing the Y arm green lock servo (Katrin / Kiwamu)
+ Installation of RFPDs (Anamaria)
+ Minimization of the AM sidebands (Anamaria / Keiko)
+ Preparation of a script for measuring the LSC input matrix (Keiko)
+ MC WFS (Suresh)
+ Online adaptive filtering (Mirko / Jenne)
+ Modification of C1ASS (Kiwamu)
+ Fixing IPPOS (volunteers)
+ Auto alignment of PRCL and SRCL (volunteers)
+ Loss measurement of the arm cavities (volunteers)
+ Fixing the ETMX SIDE slow monitor (volunteers)
/- - Nighttime works - - /
+ Locking of DRMI
+ Characterization of DRMI and complete the wiki page
It turns out that this is complicated, since there are so many people working with the IFO this week. What I would like to do is put in the new input matricies, and then do a free swinging test, to see if the suspensions are really diagonalized in the way that we want them to be. I can't do this during the day, since it will interfere with Paul's OpLev work. And at "night", I can't, since we'll be doing locking. So, this may be a late-night task. I'll write a script this afternoon that will put in all of the new input matricies, and then run the freeswing and the restore watchdogs scripts. Whomever is the last one to leave for the night can run the combo script.
EDIT: As of this time (~11:45am), ITMY has its new input matrix.
DRMI team needs to use at least three lockins on LSC
We are planning to add our reference PD to the southern third of the AS Table as pictured in the attachment. The power supply will go under the table.
Attachment #1 - Proposed mods for 40m RF freqs.
Attachment #2 - Modelled TFs for the case where all the notches are stuffed, and where only the 2f notch is stuffed.
Attachment #3 - Modelled TFs for the case where all the notches are stuffed, and where only the 2f notch is stuffed.
Any other red flags anyone sees before I finish stuffing the board?
WFS head and housing. Need to finalize the RF transimpedance gain (i.e. the LC resonant part), and also decide which notches we want to stuff.
I am confused by the discussion during the call today. I revisited Hartmut's paper - the circuit in Fig 6 is essentially what I am calling "only 2f_2 notch stuffed" in my previous elog. Qualitatively, the plot I presented in Attachment #2 of the preceeding elog in this thread shows the expected behavior as in Fig 8 of the paper - the impedance seen by the photodiode is indeed lower. In Attachment #1, I show the comparison - the "V(anode)/I(I1)" curve is analogous to the "PD anode" curve in Hartmut's paper, and the "V(vout)/I(I1)" curve is analogous to the "1f-out" curve. I also plot the sensitivity analysis (Attachment #2), by varying the photodiode junction capacitance between 100pF and 200 pF (both values inclusive) in 20 pF steps. There is some variation at 55 MHz, but it is unlikely that the capacitance will change so much during normal operation?
I understand the motivation behind stuffing the other notches, to reduce intermodulation effects. But the impression I got from the call was that somehow, the model I presented was wrong. Can someone help me identify the mistake?
I didn't bother to export the LTspice data and make a matplotlib plot for this quick analysis, so pardon the poor presentation. The colors run from green=100pF to grey=200pF.
I don't think your simulation looked inaccurate (at least not to me). In my opinion, we just want to minimize any excess noise from intermodulation. Of course, its possible that stuffing too many notches will make it difficult to have the same low noise as a simple circuit, so that's worth considering.
Also, the intermodulation is mainly a problem when the other peaks are not suppressed by some feedback: e.g. POP55_I can have excess noise if POP55_Q or POP11_I are not controlled by some MICH/PRCL/SRCL loops.
For the WFS, perhaps this is not a significant issue, but I'm not sure. My suggestion is to stuff 11 & 55 for sure, and then the others depending on the amplitude of the peaks and the consequent intermodulation. IF it works with all stuffed, that seems good. If its tricky to get it to work with all stuffed, I'd back off on a couple of them...but it probably takes more careful thought to figure out which ones are least important.
Alex and Eric
For the photodetector frequency response automation project, we plan to add modules to rack 1y1 as shown in the attached picture (Note: boxes are approximately to scale).
The RF switch will choose which photodetector's output is sent to the Agilent 4395A Network Analyzer.
The Diode Laser Module is powered by Laser Power Supply, will be modulated by the Network Analyzer and will be output to a 1x16 optical splitter which is already mounted in another rack (not pictured).
The Transformer Module has not been built yet.
We would like to install the power supply and the laser module tomorrow and will not begin routing fibers and cables until we post a drawing in the elog.
Also, our reference photoreceiver arrived today.
We mounted our Laser Module and Laser Power Source in rack 1y1. We plan to add our RF Switch and Transformer Module to the rack, as pictured. (Note: drawn-in boxes in picture are approximately to scale.) Note that the panel of knobs which the gray boxes overlap is obsolete and will soon be removed.
I've started writing up a rough testing sequence for getting the three new front-ends operational (c1bhd, c1sus2, c1ioo). Since I anticipate this plan undergoing many updates, I've set it up as a Google doc which everyone can edit (log in with LIGO.ORG credentials).
Link to planning document
Please have a look and add any more tests, details, or concerns. I will continue adding to it as I read up on CDS documentation.
I am trying to find what limits the reduction rate with wiener filtering.
I did some calculations below:
Reduction rate estimation by microphone noise
When the instrumental noise (noise in microphone) and noise injected to signal after the acoustic signal is injected exist, the noise cancellation rate is limited. (I will write a short document about it later.) I assumed that there is only instrumental noise and that the other noise in PMC is below enough, and calculated the cancellation rate. The instrumental noise is modeled according to the measurement before (ELOG).
The green line is the original PMC signal, the red one is PMC residual error, and the blue one is PMC residual error estimated by the cancelling rate.
Around 30 - 80 Hz, the wiener filtering seems to be already good enough. However, I do not know what limits the cancellation rate (such as 100 - 200 Hz).
I hypothesized that the wiener filter is not good because of some peaks or other noise. So I filtered the PMC signal and mic signal to see the difference.
The red line is wiener filter with no filters, the blue one is with filters (low pass, high pass, and notch).
The wiener filter seems to get smoother but the PMC residual error did not change at all.
I will attach a document which describes how the noise affect the wiener filter and the noise cancellation ratio.
And I re-estimate the SN ratio in the microphone (but still rough):
The yellow line is modeled signal level, and cyan line is modeled noise level.
Then, the estimated filtered residual noise is:
The noise is already subtracted enough below 80 Hz even though there is still coherence.
Above 300 Hz, the residual error is limited by other noise than acoustic noise since there is no coherence.
I am not sure about the region between 100-300 Hz, but I guess that we cannot subtract the acoustic noise because primary noise (see the document), such as a peak at 180 Hz, is so high.
We did lots of poking around with the DRMI tonight. I should elog more in the morning, but the most important points are:
Locking settings same as elog 9068, except PRCL gain changed to 0.035, and the FMs that are triggered. PRCL tonight had FM2,3,6 triggered. MICH had FM1,2,3,7 triggered. SRCL had FM1,2 triggered. Engaging the MICH boosts helped make things more quiet, so that some of the SRC boosts could be enabled. Still not as good of lock stretches as Koji got last Friday (elog 9060).
REFL55 and REFL11 were still saturating (only during acquisition), after the optical path changes I did last week (elog 9043). We reduced the REFL55 whitening slider from 15 dB to 6 dB (but forgot to compensate with digital gain), to keep the counts (as seen on DTT time series, binning off) to less than ~20,000 counts. REFL11 is still saturating, and we're not sure why, since it's slider gain is 0 dB. To be investigated.
I was prepping the ASS to be more conveniently put into a wrapper script, which could be called from the IFO Configure screen. This involved adding PRCL to the burt .req and .snap files, as well as modifying the scripts a little bit to include PRCL as an option. I ended up changing the script names from DITHER_Arm_ON.py and DITHER_Arm_OFF.py to DITHER_ASS_ON.py adn DITHER_ASS_OFF.py, since they are no longer restricted to being arms-only. You must still provide an argument to the script, to tell it which degree of freedom you want to activate. I also changed the save offsets scripts. The way they were, the X and Y arms just had separate hard-coded scripts, with no convenient way to incorporate PRCL. I merged them (including PRCL) into WRITE_ASS_OFFSETS.py, which you must now provide the DoF as an argument. I tested these new scripts on all 3 of the DoFs, and made changes to the ASS screen, so it now calls only the new scripts. It should now be easy to incorporate future ASS modifications.
Rana was in the middle of modifying the ASS model to include SRCL, and we also need to include MICH. The ASS model is not compile-ready, so don't compile it!! If you need to compile the ASS, please save what's there as a different name, and do an "svn up" to get the latest working version.
We suspected that there might be angular drive issues with the SRM (it was wiggling a lot). We checked the damping via step responses - all Qs were less than 10. Then we found that the INPUT button on the SRM PIT OL was OFF (why ???). After turning this back on it behaved better. We measured the loop shape and found that the UGF was 7 Hz; good. Need to work on some loop shaping for this guy. Its just 1/f out to 300 Hz right now. UGF should be made a little lower so that we can stably turn on the Bounce/Roll notches and a ~50 Hz low pass filter.
Most importantly, the F2A filters need to be measured and implemented. They are a few years old.
I played around with the PRMI + 2 arms situation again this evening. (I'm not ready to call it "PRFPMI" until we're at least partially using IR signals for CARM and DARM control).
I'm still a little bothered by the fact that we lose almost all light in the PRC when we're reducing the CARM offset. I'm not sure where the light is going, but it's not circulating in the PRC, since I see the POP camera get very dark. I can bring back light by changing either the PRCL offset, the MICH offset, or to a lesser extent (or maybe I'm not going far enough in offset) the DARM offset.
Tonight, I was using ALS to push on the ETMs in DARM/CARM mode (I didn't push on MC2 today, since it was being finicky and I had a hard time locking CARM with the MC as the actuator today).
For the PRMI, I was using REFL 33 I&Q. PRCL gain was -0.04, MICH gain was +0.8. REFL 33I varied between +2 and +1.2 (smaller gain necessary as CARM offset was reduced, but it's easier to acquire at large CARM offset with larger gain), and REFL 33Q was +1.0. PRCL has the usual FM 2,3,6,9 triggered, but MICH only had FM 2 triggered. The others (particularly FM6) make MICH lose lock. PRCL ASC was engaged, with the PRM oplev off.
Most of what I was trying tonight was to reduce the CARM offset, and then adjust some other offset (MICH, PRCL or DARM) to maximize POP DC. It's possible that the POP 110 and 22 diodes are changing their optimal demod phases as the optical plant changes, but POPDC is just DC.
I wasn't able to get the CARM offset below about 40 counts. At some point I had both CARM and DARM offsets at 50 counts, and had IR resonance in the Xarm, but no resonance in the Yarm. I guess this is just part of having a simultaneous CARM and DARM offset.
EDIT: If I leave the CARM offset at 0, and use a large DARM offset (100 counts), I can acquire PRMI lock, but I run into the same problems as I reduce the DARM offset - the POP power decreases, and I lose lock around 45 counts.
Side note: Earlier today I redid the POP 110 and 22 phases. POP110 was -61 deg, and is not -101 deg. POP22 was +164 deg, and is now -105 deg. I'm not sure why they needed such radical changes. When sideband locked on REFL33, POP110 had an average DC level of 580 cts, while POP22 had a value of 290 cts.
I vaguely remember that the ALS count (Phase Tracker output) is converted to Hz@532nm by a factor ~20kHz/cnt.
This means the calibration for the IR frequency is 10kHz/cnt.
If this is true 100cnt is 2MHz. Isn't it too big?
Assuming 38.5m for the arm length, FSR is 3.89MHz. (~389cnt)
Our sideband is at integer multiples of 11.03MHz. So...
1xf1 is 0.62MHz (62cnt) away from the carrier
2xf1 is 1.24MHz (124cnt)
3xf1 is 1.86MHz (186cnt)
5xf1=1xf2 is 0.79MHz (79cnt)
10xf1 = 2xf2 is 1.58MHz (158cnt)
15xf1 = 3xf2 is 1.52MHz (152cnt)
So we have to be well with in 62cnt to avoid resonating modulation sidebands.
There maybe some mistake in the factors.
e.g. Phase Tracker calibration is not correct, or CARM ALS OFFSET has factor 2 different calibration from the arm ALS offset.
I know it's really hard to remember, but our future selves will thank us dearly if we remember to commit all of our code changes to the svn with nice log messages. At the moment there's a LOT of modified stuff in the userapps working directory that needs to be committed:
controls@pianosa:/opt/rtcds/userapps/release 0$ svn status | grep '^M'
This doesn't even include things that haven't even been added yet. It doesn't take much time. Just copy and paste what you elog about the changes.
Hey, folks. Please remember to commit all changes to the SVN in a timely manor. If you don't, multiple commits will get lumped together and we won't have a good log of the changes we're making. You might also end up just loosing all of your work. SVN COMMIT when you're done! But please don't commit broken or untested code.
pianosa:release 0> svn status | grep -v '^?'
Nice. Please put this information on the DCC pages of the coil driver units. You'll find links to all the units in this document tree LIGO-E2100447. For each page, click on "Change Metadata" from the left panel and add the change made to the resistor (including the resistor name on PCB, previous and new value), and add a link to your previous elog post which has more details like photos, to "Notes and Changes", and upload an updated version of the circuit schematic by creating an annotation in the previous circuit schematic pdf. Every unit that has a serial number in the lab has a DCC page (if not, we should create one) where we should track all such hard changes.
In the attachment please find a comparison of error signals of simulation and reality after including air turbulence as input noise.
I connected the c1iscex computer to the dedicated DAQ network switch (located in 1X7).
This does not seem to have helped c1iscex stop spewing out "OMX: Failed to find peer index of board 00:00:00:00:00:00 (Peer Not Found in the Table)" at the rate of ~1 Gigabyte per minute.
c1iscex is currently off until a solution can be found.
I don't know why, but they're looking around on the roof, and inside our ceiling above the bathrooms.
Bob tells me that the carpenter is going to move the nitrogen bottles to the other side of the outside door, so that the plumbers can install a safety shower / eyewash right outside our door.
Also, the carpenter just mounted a new glass door cabinet from Bob's lab in the IFO room, so we have some new storage space.
The N2 pressure reading (C1:VAC-N2PRES) is now up-to-date after rebooting c1vac1.
The vaccum system is "Vacuum normal". We now have a space pressure transducer.
Our vacuum valves are manipulated with 60~75 PSI of nitrogen. All the valves are configured to be closed in the case of low N2 supply pressure.
In order to avoid this safety shutdown accidentally triggered, we have two N2 cylinders to sustain the vacuum valves. When one cylinder goes to low
the mechanical valve switches over to the other cylinder.
We have the monitor channel for this (combined) cylinder pressure. One shoulbe be able to see periodical pressure variation when the auto cylinder
switch is operating. However, the nirogen pressure reading got stuck at 66 PSI on Dec.16, 2014 (See attached 60-day plot of N2 supply pressure).
What we did
This morning we tracked down the cause of the trouble. We first closed the valves on EPICS and started to vary the N2 pressure.
Our first guess was the pressure transducer (Omega #236PC100GW) that was already 15 yrs old. We even has a sensor spare for replacement.
But it turned out that the direct voltage reading (to be 1mV/PSI) is changing correctly. The second guess was Omega Controller-Monitor
#DPiS32-C24 that is reading the voltage from the tranceducer. The display on this small black unit was changing corresponding to the
So our thought was
1) RS232C of the monitor unit is not working correctly
2) c1vac1 is not communicating with the monitor unit.
We wondered what could cause c1vac1 not communicating with the monitor unit, but we were afraid that some function got stuck
during either the nodus upgrade or chiara rebooting (or something else). So we decided to reboot c1vac1
In order to avoid any glitch in the main vacuum pressure, Steve disconnected some of the controller connectors for the closed valves.
We did this treatment before and it was successful.
Then c1vac1 was rebooted just by telnet and type reboot in the terminal.
Once the target is back in action, we noticed that the monitor value started to move.
Steve reverted the cables to the valves and operated the valves to recover "Vacuum Normal" state. Everything is now nicely settled.
Full list tomorrow: IP-Ang & Pos, ETMY-T, ETMY-Oplev, ETMX-T, IOO-Ang & Pos
RA: No one in the control room this evening can understand what this ELOG means. Please use more words.
Yesterday the last steering mirror mount on the PSL was changed, Manasa recovered the MC alignment and Jenne locked the arms.
I centered the following qpds: ASC-IBQPD, LSC-TRY, SUS-ETMY_OPLEV, LSC-TRX, SUS_ETMX_OPLEV
Touching the PSL pointing IOO-QPD_ANG & POS was a mistake. We lost the reference of the well refined MC input.
One and 20 days TRENDS plot showing the PSL output drift in pitch can be power drop
However initial pointing is amazingly good. ( I wonder about the lens in front of the qpd ?)
We wanted to measure the PER of the polarization maintaining fibers, so we could say to what extent they are truly polarization maintaining.
The experimental setup of this measurement includes: The NPRO, quarter and half wave plates for tuning ellipticity and orientation of the resultant polarization, attenuating optics, two steering mirrors for coupling, a polarizing beam splitter before and after the laser coupled fibers, the coupling assembly and fiber, and a powermeter.
I measured the beam power at all the pertinent locations, shown in the figure below. Note that dots represent S polarization, and orthogonal line segments represent P polarization.
I first assembled this, coupling the output to a fiber coupled powermeter, in order to adjust the coupling.
Then I needed to couple the fibers to the NPRO, which I did to 39.8%. This gave me enough output power to have a coherent, visible beam. (Visible to non-fiber coupled power meter, and on the viewer card). It was important to be sure that the fast axis of the fiber was aligned in some known orientation. Mine was aligned to the horizontal, using the key on the fiber as an indicator. This is to be certain that the output polarization is consistent with the input.
Once everything was coupled and collimated, I began tuning the polarization of the beam at different points.
Immediately after the NPRO, I used the quarter and half wave plates to first eliminate as much ellipticity as possible, and then turn the polarization to align it with the beam splitter and the fiber axis. I then tuned the first PBS to reflect as little as possible. At the output, I installed the second PBS. Since there was no fine adjustment for the angle of this one, I tuned it using the yaw controls of the 6-axis mount the collimator was held in.
Once all this tuning was done, I took power measurements (displayed above) using the unfiltered, Orion/PD power meter.
From a theoretically completely P-polarized input, the Polarization Extinction Ratio, calculated at 10*log(P/S), was -24.26 +/- 0.43 dB.
These results can be effected by environmental conditions, such as high tightly wound the cable it, its length, etc.
The next measurement to make would be to characterize the frequency noise introduced by the fiber.
In addition to this measurement, the setup of the beat note system for FOL can be done as soon as we have more collimator adapters.
These measurements may be important in FOL, and in future experiments that may use these types of apparatuses.
On the call last week, I claimed that there isn't much hope of directly measuring Ponderomotive Squeezing in aLIGO without some significant configurational changes. Here, I attempt to quantify this statement a bit, and explicitly state what I mean by "significant configurational changes".
The I/O relations will generally look something like:
The. magnitudes of the matrix elements C_12 and C_21 (i.e. phase to amplitude and amplitude to phase coupling coefficients) will encode the strength of the Ponderomotive squeezing.
For the inital study, let's assume DC readout (since there isn't a homodyne readout yet even in Advanced LIGO). This amounts to setting in the I/O relations, where the former angle is the "homodyne phase" and the latter is the "SRC detuning". For DC readout, the LO quadrature is fixed relative to the signal - for example, in the usual RSE operation, . So the quadrature we will read out will be purely (or nearly so, for small detunings around RSE operation). The displacement noises will couple in via the matrix element. Attachment #1 and Attachment #2 show the off-diagonal elements of the "C" matrix for detunings of the SRC near RSE and SR operation respectively. You can see that the optomechanical coupling decays pretty rapidly above ~40 Hz.
In this particular case, there is no benefit to detuning the SRC, because we are assuming the homodyne angle is fixed, which is not an unreasonable assumption as the quadrature of the LO light is fixed relative to the signal in DC readout (not sure what the residual fluctuation in this quantity is). But presumably it is at the mrad level, so the pollution due to the orthogonal anti-squeezed quadrture can be ignored for a first pass I think. I also assume ~10 degrees of detuning is possible with the Finesse ~15 SRC, as the linewidth is ~12 degrees.
To see how this would look in an actual measurement, I took the data from Lee's ponderomotive squeezing paper, as an estimate for the classical noises, and plotted the quantum noise models for a few representative SRC detunings near RSE operation - see Attachment #3. The curves labelled for various phis are the quantum noise models for those SRC detunings, assuming DC readout. I fudged the power into the IFO to make my modelled quantum noise curve at RSE line up with the high frequency part of the "Measured DARM" curve. To measure Ponderomotive Squeezing unambiguously, we need the quantum noise curve to "dip" as is seen around 40 Hz for an SRC tuning of 80 degrees, and that to be the dominant noise source. Evidently, this is not the case.
The case for balanced homodyne readout:
I haven't analyzed it in detail yet - but it may be possible that if we can access other quadratures, we might benefit from rotating away from the DARM quadrature - the strength of the optomechanical coupling would decrease, as demonstrated in Attachments #1 and #2, but the coupling of classical noise would be reduced as well, so we may be able to win overall. I'll briefly investigate whether a robust measurement can be made at the site once the BHD is implemented.
There is poor separation of the PRCL and MICH length error signals as sensed in the 3f photodiodes. I don't know why this is so - one possibility is that the MICH-->PRM matrix element in the LSC output matrix needs to be tuned to minimize the MICH -->PRCL coupling.
Over the last few days, I've been trying to make the 3f locking of the PRMI more reliable. Turns out that while I was able to lock the PRMI on 3f error signals, it was just a fluke. So I set about trying to be more systematic. Here are the steps I followed:
Attachment #1 is the result. I don't know what is the reason for such poor separation of the MICH and PRCL error signals in REFL165. The situation seems very different from when I had the DRMI locked in Nov last year.
After this exercise, I tried for some hours to get the 3f PRMI locking going with the arm cavities held off resonance under ALS control, but had no success. The angular motion of the PRC isn't helping, but I feel this shouldn't be a show stopper.
Updated Circuit Diagram and photos: https://dcc.ligo.org/D1500308-v2
- (1) and (6) of the diagram: TFs with various gain slider values for REFL1/REFL2/AO GAIN [ELOG 14948] (gain values and time delay modeling)
- Switching checks, latest photo of the board, Limiter check [ELOG 14953]
- (2): Boost transfer functions [ELOG 14955]
- (3): Slow (aka Length) CM output path [ELOG 14965]
- (4): Pole-Zero filter TF [ELOG 14965]
- (5): TF from TESTA2 to TESTB2 [ELOG 14966]
- (6): AC coupling TF of the AO GAIN stage [ELOG 14967]
- (7): AC coupling TF of the IN2 stage on IMC servo board [ELOG 15044]
Slow path = (1)*(2 if necessary)*(3)*(4 if necessary)
Fast path = (1)*(2 if necessary)*(4 if necessary)*(5)*(6)
gautam 20191122: Adding the measured AC coupling of the IN2 input of the IMC servo board for completeness.
It's taken a lot of trial and error, but I've found a path through MATLAB loops that seems like it may be stable at all points.
CAVEAT: This doesn't give any indication as to why we weren't able to turn up the AO gain more last night, as far as I can tell, so it's not all good news.
However, it's still ok to at least have a plan that works in simulation...
Based on the location of the optical resonance peak in the CARM plant, we estimate our CARM offset to be 200pm. I haven't simulated TFs there exactly, but do have 100pm and 300pm TFs. This procedure works in MATLAB starting at either, though 100pm is a little nicer than 300. MATLAB data and code is attached in a zip.
The steps below correspond to the attached figures: Bode plots and step response of the Loop at each step.
0. [Not Plotted] DCTrans sensing, MCL actuation on CARM. FMs1,2,3,5,8; UGF = 120. (DARM not considered at all)
#4 Seems like the most sticky part. While both sides of this look stable as far as I can tell. I feel that flipping from the red phase curve to the teal might not actually be ok, since they are on either side of the bad phase of 0 degrees. It isn't immediately evident to me how to easily model the transitions between steps, rather than just the stability of of each step in the steady state.
Probably there is the same mistake for the PMC gain slider. Possibly on the FSS slider, too???
2) The EPICS setting for the MZ gain slider was totaly wrong.
Today I learned from the circuit, the full scale of the gain slider C1:PSL-MZ_GAIN gave us +/-10V at the DAC.
This yield +/-1V to V_ctrl of the AD602 after the internal 1/10 attenuation stage.
This +/-1V didn't correspond to -10dB~+30dB, but does -22dB~+42dB and is beyond the spec of the chip.
I was working on the electronics bench and what sounded like a huge truck rolled by outside. I didn't notice anything until now, but It looks like something became misaligned when the truck passed by (~6:45-6:50 pm). I can hear a lot of noise coming out of the control room speakers and pretty much all of the IOO plots on the wall have sharp discontinuities.
I haven't been moving around much for the past 2 hours so I don't think it was me, but I thought it was worth noting.
After talking with Jenne, I realized the ADC card in the c1ass machine was currently going unused. As we are short an ADC card, a possible solution is to press that card into service. Unfortunately, its currently on a PMC to PCI adapter, rather than PMC to PCIe adapter. The two options I have are to try to find a different adapter board (I was handed 3 for RFM cards, so its possible there's another spare over in downs - unfortunately I missed Jay when I went over at 2:30 to check). The other option is put it directly into a computer, the only option being megatron, as the other machines don't have full length PCI slot.
I'm still waiting to hear back from Alex (who is in Germany for the next 10 days) whether I can connect both in the computer as well as with the IO chassis.
So to that end, I briefly turned off the c1ass machine, and pulled the card. I then turned it back on, restarted all the code as per the wiki instructions, and had Jenne go over how it looked with me, to make sure everything was ok.
There is something odd with some of the channels reading 1e20 from the RFM network. I believe this is related to those particular channels not being refreshed by their source (which is other suspension front end machines), so its just sitting at a default until the channel value actually changes.
I think I've narrowed down the source of this ground loop. It originates from the fact that the DAC from which the signals for this board are derived sits in an expansion chassis in 1Y3, whereas the LSC electronics are all in 1Y2.
Looking at Jamie's old elog from the time when this infrastructure was installed, there is a remark that the signal didn't look too noisy - so either this is a new problem, or the characterization back then wasn't done in detail. The main reason why I think this is non-ideal is because the tip-tilt steering mirrors sending the beam into the IFO is controlled by analogous infrastructure - I confirmed using the LEMO monitor points on the D000316 that routes signals to TT1 and TT2 that they look similarly noisy (see e.g. Attachment #1). So we are injecting some amount (about 10% of the DC level) of beam jitter into the IFO because of this noisy signal - seems non-ideal. If I understand correctly, there is no damping loops on these suspensions which would suppress this injection.
How should we go about eliminating this ground loop?
So either something is busted on this board (power regulating capacitor perhaps?), or we have some kind of ground loop between electronics in the same chassis (despite the D990694 being differential input receiving). Seems like further investigation is needed. Note that the D000316 just two boards over in the same Eurocrate chassis is responsible for driving our input steering mirror Tip-Tilt suspensions. I wonder if that board too is suffering from a similarly noisy ground?
We discussed possible solutions to this ground loop problem. Here's what we came up with:
Why do we care about this so much anyways? Koji pointed out that the tip tilt suspensions do have passive eddy current damping, but that presumably isn't very effective at frequencies in the 10Hz-1kHz range, which is where I observed the noise injection.
Note that all our SOS suspensions are also possibly being plagued by this problem - the AI board that receives signals is D000186, but not revision D I think. But perhaps for the SOS optics this isn't really a problem, as the expansion chassis and the coil driver electronics may share a common power source?
gautam 1530 7 Feb: Judging by the footprint of the front panel connectors, I would say that the AI boards that receive signals from the DACs for our SOS suspended optics are of the Rev B variety, and so receive the DAC voltages single ended. Of course, the real test would be to look inside these boards. But they certainly look distinct from the black front panelled RevD variant linked above, which has differential inputs. Rev D uses OP27s, although rana mentioned that the LT1125 isn't the right choice and from what I remember, LT1125 is just Quad OP27...
It looks as though we may have two IO chassis with bad timing cards.
Symptoms are as follows:
We can get our front end models writing data and timestamps out on the RFM network.
However, they get rejected on the receiving end because the timestamps don't match up with the receiving front end's timestamp. Once started, the system is consistently off by the same amount. Stopping the front end module on c1ioo and restarting it, generated a new consistent offset. Say off by 29,000 cycles in the first case and on restart we might be 11,000 cycles off. Essentially, on start up, the IOP isn't using the 1PPS signal to determine when to start counting.
We tried swapping the spare IO chassis (intended for the LSC) in ....
# Joe will finish this in 3 days.
# Basically, in conclusion, in a word, we found that c1ioo IO chassis is wrong.
[Jenne, Manasa, Jamie]
Now that we're up to air we relocked the mode cleaner, tweaked up the alignment, and looked at the spot positions:
The measurements from yesterday were made before the input power was lowered. It appears that things have not moved by that much, which is pretty good.
We turned on the PZT1 voltages and set them back to their nominal values as recorded before shut-down yesterday. Jenne had centered IPPOS before shutdown (IPANG was unfortunately not coming out of the vacuum). Now we're at the following value: (-0.63, 0.66). We need to calibrate this to get a sense of how much motion this actually is, but this is not insignificant.
- IPANG aligned on the QPD. The beam seems to be partially clipped in the chamber.
- Oplev of the IFO mirrors are aligned.
- After the oplev alignment, ITMX Yaw oplev servo started to oscillate. Reduced the gain from -50 to -20.
Notes to the fiber team:
I am aligning beam onto the RFPDs (I have finished all 4 REFL diodes, and AS55), in preparation for locking.
In doing so, I have noticed that the fiber lasers for the RFPD testing are always illuminating the photodiodes! This seems bad! Ack!
For now, I blocked the laser light coming from the fiber, did my alignment, then removed my blocks. The exception is REFL55, which I have left an aluminum beam dump, so that we can use REFL55 for PRM-ITMY locking, so I can align the POP diodes.
EDIT: I have also aligned POP QPD, and POP110/22. The fiber launcher for POP110 was not tight in its mount, so when I went to put a beam block in front of it and touched the mount, the whole thing spun a little bit. Now the fiber to POP110 is totally misaligned, and should be realigned.
What was done for the alignment:
1. Aligned the arms (ran ASS).
2. Aligned the beam to all the REFL and AS PDs.
3. Misaligned the ETMs and ITMX.
4. Locked PRM+ITMY using REFL11.
The following were modified to enable locking
(1) PRCL gain changed from +2.0 to -12.
(2) Power normalization matrix for PRCL changed from +10.0 to 0.
(3) FM3 in PRCL servo filter module was turned OFF.
5. POP PDs were aligned.
[Larry (on site), Koji & Gautam (remote)]
Network recovery (Larry/KA)
Asked Larry to get into the lab.
14:30 Larry went to the lab office area. He restarted (power cycled) the edge-switch (on the rack next to the printer). This recovered the ssh-access to nodus.
Also Larry turned on the CAD WS. Koji confirmed the remote access to the CAD WS.
Nodus recovery (KA)
Apr 12, 22:43 nodus was restarted.
Apache (dokuwiki, svn, etc) recovered along with the systemctl command on wiki
ELOG recovered by running the script
Control Machines / RT FE / Acromag server Status
Judging by uptime, basically only the machines that are on UPS (all control room workstations + chiara) survived the power outage. All RT FEs are down. Apart from c1susaux, the acromag servers are back up (but the modbus processes have NOT been restarted yet). Vacuum machine is not visible on the network (could just be a networking issue and the local subnet to valves/pumps is connected, but no way to tell remotely).
KA imagines that FB took some finite time to come up. However, the RT machines required FB to download the OS. That made the RTs down. If so, what we need is to power cycle them.
Acromag: unknown state
The power was lost at Apr 12 22:39:42, according to the vacuum pressure log. The power loss was for a few min.
The 40m experienced a building-wide power failure for ~30 seconds at ~7:38 pm today.
Thought that might be important...