I have moved the optical fiber module for FOL to the PSL table. It is setup on the optical table right now for testing.
Once tests are done, the box will move to the rack inside the PSL enclosure.
While doing any beat note alignment, please watch out for the loose fibers at the north side of the PSL enclosure until they are sheilded securely (probably tomorrow morning).
33MHz sidebands can be elliminated by careful choice of the modulation depths and the relative phase between the modulation signals.
If this condition is realized, the REFL33 signals will have even more immunity to the arm cavity signals because the carrier signal will lose
its counterpart to produce the signal at 33MHz.
Formulation of double phase modulation
m1: modulation depth of the f1 modulation
m2: modulation depth of the f2 (=5xf1) modulation
The electric field of the beam after the EOM
Therefore what we want to realize is the following "extinction" condition
We are in the small modulation regime. i.e. J0(m) = 1, J1(m) = m/2, J2(m) = m2/8, J3(m) = m3/48
Therefore we can simplify the above exitinction condition as
m2 < 0 means the start phase of the m2 modulation needs to be 180deg off from the phase of the m1 modulation.
After some discussion with Koji, I've asked Steve to order some SBP-30+ bandpass filters as a quick and cheap way to help out REFL33. (Also some SBP-60+ for 55MHz, since we only have 1*fmod and 2*fmod bandpasses here in the lab).
For future reference, I've taken spectra of our various RFPDs while the PRMI was sideband locked on REFL33, using a 20dB RF coupler at the RF input of the demodulator boards. The 20dB coupling loss has been added back in on the plots. Data files are attached in a zip.
I also completely removed the cabling for REFLDC -> CM board, since it doesn't look like we plan on using it anytime in the immediate future.
No elog response from outside and no elogd process on nodus, so I restarted it using 'start-elog.csh'.
While meditating over what to do about the fact that we can't seem to hold PRMI lock while reducing the CARM offset, we have started to nucleate a different idea for locking.
We aren't sure if perhaps there is some obvious flaw (other than it may be tricky to implement) that we're not thinking about, so we invite comments. I'll make a cartoon and post it tomorrow, but the idea goes like this.....
Can we use ALS to hold both CARM and DARM by actuating on the ETMs, and sit at (nominally) zero offset for all degrees of freedom? PRMI would need to be stably held with 3f signals throughout this process.
1) Once we're close to zero offset, we should see some PDH signal in REFL11. With appropriate triggering (REFLDC goes low, and REFL11I crosses zero), catch the zero crossing of REFL11I, and feed it back to MC2. We may want to use REFL11 normalized by the sum of the arm transmissions to some power (1, 0.5, or somewhere in between may maximize the linear range even more, according to Kiwamu). The idea (very similar to the philosophy of CESAR) is that we're using ALS to start the stabilization, so that we can catch the REFL11 zero crossing.
2) Now, the problem with doing the above is that actuating on the mode cleaner length will change the laser frequency. But, we know how much we are actuating, so we can feed forward the control signal from the REFL11 carm loop to the ALS carm loop. The goal is to change the laser frequency to lock it to the arms, without affecting the ALS lock. This is the part where we assume we might be sleepy, and missing out on some obvious reason why this won't work.
3) Once we have CARM doubly locked (ALS pushing on ETMs, REFL11 pushing on MC/laser frequency), we can turn off the ALS system. Once we have the linear REFL11 error signal, we know that we have enough digital gain and bandwidth to hold CARM locked, and we should be able to eek out a slightly higher UGF since there won't be as many digital hops for the error signal to transverse.
4) The next step is to turn on the high bandwidth common mode servo. If ALS is still on at this point, it will get drowned out by the high gain CM servo, so it will be effectively off.
5) Somewhere in here we need to transition DARM to AS55Q. Probably that can happen after we've turned on the digital REFL11 path, but it can also probably wait until after the CM board is on.
The potential show-stoppers:
Are we double counting frequency cancellation or something somewhere? Is it actually possible to change the laser frequency without affecting the ALS system?
Can we hold PRMI lock on 3f even at zero CARM offset? Anecdotally from a few trials in the last hour or so, it seems like coming in from negative carm offset is more successful - we get to slightly higher arm powers before the PRMI loses lock. We should check if we think this will work in principle and we're just saturating something somewhere, or if 3f can't hold us to zero carm offset no matter what.
A note on technique: We should be able to get the transfer function between MC2 actuation and ALS frequency by either a direct measurement, or Wiener filtering. We need this in order to get the frequency subtraction to work in the correct units.
As the measurements have been done under feedback control, the lower RF peak height does not necessary mean
the lower optical gain although it may be the case this time.
These non-33MHz signals are embarassingly high!
We also need to check how these non-primary RF signals may cause spourious contributions in the error signals,
including the other PDs.
Since we're having trouble keeping the PRC locked as we reduce the CARM offset, and we saw that the POP22 power is significantly lower in the 25% MICH offset case than without a MICH offset, Rana suggested having a look at the RF spectra of the REFL33 photodiode, to see what's going on.
The Agilent is hooked up to the RF monitor on the REFL33 demod board. The REFL33 PD has a notch at 11MHz and another at 55MHz, and a peak at 33MHz.
We took a set of spectra with MICH at 25% offset, and another set with MICH at 15% offset. Each of these sets has 4 traces, each at a different CARM offset. Out at high CARM offset, the arm power vs. CARM offset is pretty much independent of MICH offset, so the CARM offsets are roughly the same between the 2 MICH offset plots.
What we see is that for MICH offset of 25%, the REFL33 signal is getting smaller with smaller CARM offset!! This means, as Rana mentioned earlier this evening, that there's no way we can hold the PRC locked if we reduce the CARM offset any more.
However, for the MICH offset 15% case, the REFL 33 signal is getting bigger, which indicates that we should be able to hold the PRC. We are still losing PRC lock, but perhaps it's back to mundane things like actuator saturation, etc.
The moral of the story is that the 3f locking seems to not be as good with large MICH offsets. We need a quick Mist simulation to reproduce the plots below, to make sure this all jives with what we expect from simulation.
For the plots, the blue trace has the true frequency, and each successive trace is offset in frequency by a factor of 1MHz from the last, just so that it's easier to see the individual peak heights.
Here is the plot with MICH at 25% offset:
And here is the plot with MICH at 15% offset:
Note that the analyzer was in "spectrum" mode, so the peak heights are the true rms values. These spectra are from the monitor point, which is 1/10th the value that is actually used. So, these peak heights (mVrms level) times 10 is what we're sending into the mixer. These are pretty reasonable levels, and it's likely that we aren't saturating things in the PD head with these levels.
The peaks at 100MHz, 130MHz and 170MHz that do not change height with CARM offset or MICH offset, we assume are some electronics noise, and not a true optical signal.
Also, a note to Q, the new netgpib scripts didn't write data in a format that was back-compatible with the old netgpib stuff, so Rana reverted a bunch of things in that directory back to the most recent version that was working with his plotting scripts. sorry.
Here is a lock loss from around 11 PM tonight. Might be due to poor PRC signals.
This is with arm powers of ~6-10. You can see that with such a large MICH offset, POP22 signal has gone done to zero. Perhaps this is why the optical gain for PRCL has also dropped by a factor of 30 .
This seems untenable . We must try this whole thing with less MICH offset so that we can have a reasonable PRCL signal.
I've remeasured the QPD ASC sensing coefficients, and figured out what I did weird with the actuation coefficients. I've rearranged the controller filters to be able to turn on the boost in a triggered way, and written Up/Down scripts that I've tested numerous times, and Jenne has used as well; they are exposed on the ASC screen.
All four loops (2 arms * pit,yaw), have their gains set for 8Hz UGF, and have 60 degrees of phase margin. The loop shape is the same as the previous ELOG post. Here is the current on/off performance. The PDH signals (not shown, but in attached xml) show no extra noise, and the low frequency RIN goes down a bit, whic is good. The oplevs error signals are a bit noisier, but I suppose that's unavoidable. The Y-arm performs a bit better than the X-arm.
The up/down scripts don't touch the filters' trigger settings at all, just handles switching the input and output and clearing history. FM1 contains the boost which is intended to have a longer trigger delay than the filters themselves.
Plan C finally worked. We have 1.454mW of AUX X light at the PSL table (2mW incident on the fiber coupler).
Attached is the layout of the telescope.
What I did:
I stuck in Lens 1 (f=200mm) and measured the beam width after the focus of the lens at several points. I fit the data and calculated the beam waist and its position after this lens.
I used the calculated waist and matched it with an appropriate lens and target (fiber coupler) distance. I calculated the maximum coupling efficiency to be 77% for Lens 2 with f=50mm and the fiber coupler placed at 20cm from the waist of Lens1. I was able to obtain 72% coupling after putting the telescope together.
I locked the arms, ran ASS and brought back GTRX to its usual optimum value of ~0.5 counts after closing. We also have the X arm beatnote on the spectrum analyzer.
There are still a couple of things to fix. The rejected beam from the beam sampler has to be dumped using a razor blade.
I found the PSL enclosure open (about a feet wide) on the north side this morning. I am assuming that whoever did the X beatnote alignment last night forgot to close the door to the enclosure before locking attempts
Unfortunately, we only had one good CARM offset reduction to powers of about 25, but then my QPD loop blew it. We spent the vast majority of the night dealing with headaches and annoyances.
Things that were a pain:
I discovered that somehow my Wiener filters that show up in Foton are not the same as what I have in Matlab-land.
I have plotted each of my 3 filters that I'm working with right now (T-240 X, Y and Z for PRCL Pitch) at several stages in the filter creation process. Each plot has:
It's not just a DC gain issue - there's a frequency dependent difference between these filters. Why??
It's not frequency warping from changing between analog and digital filters. The sample rate for the OAF model is 2048Hz, so the effect is small down at low frequencies. Also, the green trace is already discretized, so if it were freq warping, we'd see it in the green as well as red, which clearly we don't.
Has anyone seen this before? I'm emailing my seismic friends who deal in quack more than I do (BLantz and JKissel, in particular) to see if they have any thoughts.
Also, while I'm asking questions, can autoquack clear filters? Right now I'm overwriting old filters with zpk(,,1)'s, which isn't quite the same. (I need this because the Wiener code needs more than one filter module to fit all of the poles I need, and it decides for itself how many FMs it needs by comparing the length of the poles vector with 20. If one iteration needs 4 filter modules, but the next iteration only wants 3, I don't want to leave in a bogus 4th filter.
Here are the plots:
(The giant peak at ~35Hz in the Z-axis fiilter is what tipped me off that something funny was going on)
We wanted to make the PRMI lock more stable tonight, which would hopefully allow us to hold lock much longer. Some success, but nothing out-of-this-world.
We realized late last week that we haven't been using the whitening for the ASDC and POPDC signals, which are combined to make the MICH error signal. ASDC whitening is on, and seems great. POPDC whitening (even if turned on after lock is acquired) seems to make the PRMI lock more fussy. I need to look at this tomorrow, to see if we're saturating anything when the whitening is engaged for POPDC.
One of the annoying things about losing the PRMI lock (when CARM and DARM have kept ALS lock) is that the UGF servos wander off, so you can't just reacquire the lock. I have added triggering to the UGF servo input, so that if the cavity is unlocked (really, untriggered), the UGF servo input gets a zero, and so isn't integrating up to infinity. It might need a brief "wait" in there, since any flashes allow signal through, and those can add up over time if it takes a while for the PRMI to relock. UGF screens reflect this new change.
I wrote the script with the recipe we used, using the Yarm and AS55 on the IN2 of the CM board; however, the steps where the offset should be reduced are not completely deterministic, as we saw that the initial offset (and, therefore, the following ones) could change because of different states we were in. In the script I tried to "servo" the offset using C1:LSC-POY11_I_MON as the reference, but in the comments I wrote the actual values we used during our best test; the main points of the recipe are:
I tried the procedure and it seems fine, as it did during the tries Q and I made; however, since it touches many things in many places, one should be careful about which state the IFO is into, before trying it.
The script is in scripts/CM/CM_Servo_OneArm_CARM_ON.py and in the SVN.
I forgot to elog about these ones, my bad... The new/updated laptops are giada, viviana and paola; paola is already in the lab, while giada and viviana are in the control room waiting for a new home. The Pool of Names Wiki page has already been updated to reflect the changes.
Baja 4.9 m earth quake tripped suspentions, except ETMX Sus damping recovered. MC is locking.
This is good news. It means that the driver probably won't limit the response of the loop - I expect we'll get 20-30 deg of phase lag @ 100 kHz just because of the acoustic response of the AOM PZT + crystal.
I'm leaving the PRC aligned and locked. Feel free to unlock it, or do whatever with the IFO.
I wanted to check the status of the ISS. The AOM driver response was measured on Friday night.
The beam path has not been disturbed yet.
- I found the AOM crystal was removed from the beam path. It was left so.
- The AOM crystal has +24V power supply in stead of specified +28V.
I wanted to check the functionality of the AOM driver.
- I've inserted a 20dB directional coupler between the driver and the crystal.
To do so, I first turned off the power supply by removing the corresponding fuse block at the side panel of the 1X1 Rack.
Then ZFDC-20-5-S+ was inserted, the coupled output was connected to a 100MHz oscilloscope with 50Ohm termination.
Then plugged in the fuse block again to energize the driver box.
Note that the oscilloscope bandwidth caused reduction the amplitude by a factor of 0.78. In the result, this has already been compensated.
- First, I checked the applied offset from a signal generator (SG) and the actual voltage at the AOM input. The SG OUT
and the AOM control input are supposed to have an impedance of 50Ohm. However, apparently the voltage seen at the
AOM in was low. It behaved as if the input impedance of the AOM driver is 25Ohm.
In any case, we want to use low output impedance source to drive the AOM driver, but we should keep this in mind.
- The first attachment shows the output RF amplitude as a function of the DC offset. The horizontal axis is the DC voltage AT THE AOM INPUT (not at the SG out).
Above 0.5V offset some non linearity is seen. I wasn't sure if this is related to the lower supply voltage or not. I'd use the nominal DC of 0.5V@AOM.
The output with the input of 1V does not reach the specified output of 2W (33dBm). I didn't touch the RF output adjustment yet. And again the suppy is not +28V but +24V.
- I decided to measure the frequency response at the offset of 0.53V@AOM, this corresponds to the DC offset of 0.8V. 0.3Vpp oscillation was given.
i.e. The SG out seen by a high-Z scope is V_SG(t) = 1.59 + 0.3 Sin(2 pi f t) [V]. The AOM drive voltage V_AOM(t) = 0.53 + 0.099 Sin(2 pi f t).
From the max and min amplitudes observed in the osciiloscope, the response was checked. (Attachment 2)
The plot shows how much is the modulation depth (0~1) when the amplitude of 1Vpk is applied at the AOM input.
The value is ~2 [1/V] at DC. This makes sense as the control amplitude is 0.5, the applied voltage swings from 0V-1V and yields 100% modulation.
At 10MHz the first sign of reduction is seen, then the response starts dropping above 10MHz. The specification says the rise time of the driver is 12nsec.
If the system has a single pole, there is a relationship between the rise time (t_rise) and the cut-off freq (fc) as fc*t_rise = 0.35 (cf Wikipedia "Rise Time").
If we beieve this, the specification of fc is 30MHz. That sounds too high compared to the measurement (fc ~15MHz).
In any case the response is pretty flat up to 3MHz.
I pulled out the Fiber Optic Module for FOL from the rack inside the PSL table enclosure and modified it. The beat PDs were moved into the box to avoid breaking the fiber pigtail input to the PD.
The box has 3 input FC/APC connectors (PSL and AUX lasers) and 2 output FC/APC connectors (10% of the beatnote for the AUX lasers).
Attachment shows what is inside the box. The box will again go back on the rack inside the PSL enclosure.
Just now we had another EPICS freeze. The network was still up; i.e. I could ssh to chiara and fb, who both seemed to be working fine.
I could ping c1lsc successfully, but ssh just hung. fb's dmesg had some daqd segfault messages, so I telnet'ed to daqd and shut it down. Soon after, EPICS came back, but this is not neccesarily because of the daqd restart...
Yesterday morning was dusty. I wonder why?
The PRM sus damping was restored this morning.
Yesterday afternoon at 4 the dust count peaked 70,000 counts
Manasa's alergy was bad at the X-end yesterday. What is going on?
There was no wind and CES neighbors did not do anything.
We kept struggling with the PRMI, although it was a little better than yesterday:
So, still no exciting news, but PRMI lock seems to be improving a little.
We were at the X end today trying to couple AUX X light into the fiber.
The proposed plan still did not give a good beampath. The last steering mirror before the fiber coupler was sticking out of the table enclosure. I tried a few other options and the maximum coupling that I could get was ~10%
I am working on plan C now; which would be to use fixed mount mirrors and steer the beam to the space created by Koji near the IR trans path and use a set of lenses instead of a single lens. I will elog more details after some modematching calculations.
We moved one of the clamps for the doubling crystal to make space. Also, the NPRO current was reduced during this work.
I reset things to how they were before I touched the table. I ensured that the green power was still the same (~3mW) after the doubler and that it could lock to the arm in TEM00.
Tonight was a sad night... We continued to pursue our strategy, but with very poor results:
The X end fiber setup will be put together tomorrow morning. Let me know if there are any concerns.
It is certain that we have space issues at the X end that has been preventing us from sticking in a lens to couple light into the fiber.
The only way out is to install a platform on the table where we can mount the lens. I have attached the a photo of how things look like at the X end (attachment 1) and also a drawing of the platform that which can hold the lens (attachment 2). Additional support to the raised platform will be added depending on how much space we can clear up on the table by moving the clamping forks of the doubler.
Steve and I have been able to gather parts that can be put together into something similar to what is shown in the drawing.
Proposed modifications to the X end table:
1. The side panels of the table enclosure will come out while putting in the new platform.
2. The clamping forks for the doubling crystal will be moved.
Let me know of any concerns about the proposed solution.
The components of the RF amplifier box are in place. The RF amplifier box has been mounted on the IOO rack and the front panel connections have been labeled. Attached is the photo of how things look in the inside for future reference.
Sometime in the next few days the box will be pulled out to replace the panel mount SMA barrels in the front with insulated ones.
I opened up the spaghetti pot over the vertex seismometer, and taped the cable to the slab. The way the cable is coiled, it was touching the underside of the seismometer. Now the only connection is at the cable connector. There is a ~few inch bit of cable, then it's taped down.
We had persistent frustration by occasional unlock during ASSing.
Today, I added triggers to the servo gains in order to elliminate this annoyance.
Each ASS servo gain slider is multiplied with the corresponding LSC Trigger EPICS channel (i.e. C1:LSC-iARM_TRIG_MON, where i=X or Y).
This has been done by ezcaread modules in RCG.
The model and screen have been commited to svn.
Please remember that Xarm ASS needs FM6 (Bounce filters) to be ON in order to work properly.
c1lsc had 60 full-rate (16kS/s) channels to record. This yielded the LSC to FB connection to handle 4MB/s (mega-byte) data rate.
This was almost at the data rate limit of the CDS and we had frequent halt of the diagnostic systems (i.e. DTT and/or dataviewer)
Jenne and I reviewed DAQ channel list and decided to remove some channels. We also reviewed the recording rate of them
and reduced the rate of some channels. c1lsc model was rebuilt, re-installed, and restarted. FB was also restarted. These are running as they were.
The data rate is now reduyced to ~3MB nominal.
The following is the list of the channels removed from the DQ channels:
The following is the list of the channels with the new recording rate:
At the lunch meeting, we were thinking about the exess high frequency content of the MICH control signal, which leads to railing against the FM output limiter and lock loss. I propsed that POPDC sensor/ADC noise was the culprit.
In short, I was wrong. Just now, I locked the PRMI with a MICH offset as we normally do, and then froze the POPDC output. The MICH spectrum did not change in any noticible way.
However, increasing the analog ASDC whitening gain showed a direct improvement of the error signal noise floor, and thus a reduction in the control signal spectrum. I.e. we have been suffereing from ASDC ADC noise.
We had previously set the ASDC whitening gain so that half fringe of the PRMI would be well within the ADC range, but since we're actually only ever going to 25%, I feel fine upping this gain. Interestingly, when increasing the whitening gain by 12dB, the control signal spectrum has fallen by more like 20 dB in the 400Hz-1kHz region, which is great.
The only potential hurdle I can think of is that when we start reducing the MICH offset at zero CARM offset, we may approach ADC saturation in ASDC before we can hand off to RF signals, in which case we would have to dynamically lower the whitening gain, which introduces offsets, which could get hairy. But, since MICH railing has been directly seen to lead to lock-loss, I'd rather solve that problem first.
[Diego, Jenne, Eric]
Tonight we kept on following our current strategy for locking the PRFPMI:
both of the last two locks, the most stable ones (one transition to usual REFL11 and one transition to "CM_SLOW" REFL11) were acquired actuating on MC2;
EDITs by JCD: At least one of the times that we lost PRMI lock (although kept CARM and DARM lock on ALS), was due to MICH hitting the rail, even after we increased the limiter to 15,000 counts.
Here is the transfer function between CARM ALS (CARM_IN1) and REFL11 coming through the CM board (CARM_B), just before we transitioned over. Coherence was taken simultaneously as usual, I just printed it to another sheet.
Here is the lockloss plot for the very last lockloss. This is the time that we were sitting on REFL11 coming through the CM_SLOW path. A DTT transfer function measurement was in progress (you can see the sine wave in the CARM input and output data), but I think we actually lost lock due to whatever this glitch was near the right side of the plots. This isn't something that I've seen in our lockloss plots before. I'm not sure if it's coming from REFL11, or the CM board, or something else. We know that the CM board gives glitches when we are changing gain settings, but that was not happening at this time.
Q: Here's the SR785 TF of CARM locked through CM board, but still only digital control; nothing exciting. Excitation amplitude was only 1mV, which explains the noisy profile.
I pulled out the RF amplifier box from the IOO rack again and added the new RF amplifiers for FOL.
I replaced one of the decoupling capacitors of the ALS beat note RF amplifier ; the poloproylene capacitor with a ceramic capacitor (0.1uF) .
After putting back the box, I confirmed that we had a beat note. I did not get a chance to measure the ALS noise after putting back the box because the IFO was already occupied.
I will post a detailed elog of the components in the RF amplifier box once I am done with it (hopefully tomorrow)!
I have removed REFLDC and the SR560 offsetter from the CM board IN2. Now, analog AS55 I lives there, for our single arm testing. (Analog I has more of the single arm Y PDH signal in it). REFL11 has been reconnected to IN1.
With ITMX super misaligned, Diego and I locked the Y-arm with the AO path on AS55, ultimately at 4kHz bandwidth, but with plenty of gain margin. We didn't allocate the gains too intelligently, and had the CM board input gain slider maxed out, but plenty of headroom in the digital and AO sliders, making it inconvenient to up the UGF even more, to engage the super boosts. However, since this is just a test case to make sure we still can AO lock, I'm not too worried about this.
Since LSC FMs and such had changed around, old recipies didn't neccesarily work 1:1. Diego is writing a script for the current recipe, and will post an elog with the steps.
Gains and signs are able to be tracked by loop TFs, the real sticking point is a stable crossover. We used the 1.6k:80 hardware filter in the CM board to give the AO Path a 1/f shape in the crossover region, and undid it digitally in the CM_SLOW input FM. However, we do use a 300:80 in the MC2 sus FM to make the digital loop like 1/f^2 around the crossover, once a little bit of AO has come in to pull up the digital loop's phase. We used the CARM filter bank to do this, so I think we should be able to use a similar technique to do it in the PRFPMI case, as long as the coupled cavity pole is around ~100Hz.
Attached are a few OLTFs from the progression.
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.
Today (after centering the POP QPD), I measured the PRM to POP QPD transfer functions. I am suspicious that this was part of my problem last week. Since most of the angular noise is coming from the folding mirrors, but I can't actuate on them, I need to know (rather, the Wiener calculator needs to know) how actuating on the PRM will affect the spot at the POP QPD.
For the plots below, I have cut out any data points that have coherence less than 0.95. I may want to go back and fill in a little bit some of the areas (particularly around 3Hz) that I had trouble getting coherence in.
Using these to prefilter my witness data, I am failing to calculate a Wiener filter. I have tried the Levinson algorithm, as well as brute-forcing it, but I'm too close to singular for either to work. I am able to calculate a set of Wiener filters without the prefiltering, or with a dummy very simple prefilter, so it's not inherently in the calculators. Separately, I can plot my vectfit-ed actuator TFs, and I can convert them to a discrete fiilter with the bilinear transform, and then use sosfilt to filter some white noise data, which comes out with the shape I expect. So. It's not inherently the filters either. More work to do, when it's not 4am.
Here are the measured actuator transfer functions. They were measured as usual with DTT, but since the measurement kept getting interrupted (MC unlock, or I wanted to add more integrations or more cycles), these are several different DTT files stitched together. In both cases I am acuating PRM's ASC[pit, yaw] EXC point, and looking at the POP QPD.
Tonight we worked on the CM board and AO path:
The BLUE plot is at MC Gain = 0.10 and REFL1 Gain = 4dB; the GREEN plot is for MC Gain = 0.10 and REFL1 Gain = 3dB, which seemed a more stable configuration; after this last configuration, we increased the MC Gain to 0.15 and the AO Gain from 8dB to 9dB and took another measurement, the RED plot; this is as far as we got as of now. We also couldn't increase the REFL11 Gain because it made things unstable and more prone to unlock.
So, some little progress on the AO path procedure, but we are very low on our UGF and we have to find a way to increase our gains without breaking the lock and avoiding the gain peaking we have witnessed tonight.
We just changed the input to the CM board from REFL11 to AS55.
Today I was around the IOO rack.
I shutdown the power to the beat PDs on the PSL table and disconnected the D sub 3w3 connector that was powering the RF amplifier panel on the IOO rack.
I moved the RF amplifier from the panel to a box that can go on the rack. The box will also hold the RF amplifiers that will be used for FOL. I have not completed putting in all the amplifiers. But the RF amplifier for ALS is in place and the box has been installed on the IOO rack for locking tonight. The power supply to the green beat PDs has been switched ON.
I took the out of loop noise measurements for ALS X and Y and the attachment is the screenshot of it (X and Y have rms of ~300Hz and ~400Hz).
I had to touch the Y end steering mirrors for green to get maximum GTRY before making thes measurments.
After aligning the PRC, I centered the POP QPD.
Nothing earth-shattering today.
A few things of note:
See first plot below for the PRCL->CARM coupling just before lockloss. The second plot is the corresponding lockloss, where the PRCL loop is starting to see that oscillation again, and it's just barely starting to get into CARM.
SP table has been a mess because Q and I had let our SURF leave without cleaning up.
I cleaned up the SP table, put things back where they belong and did some sorting. I will put back the optomechanics where they belong sometime later.
For now, check out the SP table next time you are looking for a Y1 or lens or BS.
Tonight we continued following the plan of last night: perform the transition of CARM to REFL11_I while on MICH offset at -25%:
[Aside - How do you rotate plots in the new elog? It's showing them correctly in the attachments list below the entry, but not in the body of the log :( ]
I tried a round of PRCL ASC Wiener filtering today, but something wasn't right. I was able to either make the cavity motion worse, or completely throw the cavity out of lock. Making it less noisy didn't happen.
I took only 9 minutes of data the other day, since the PRMI didn't want to stay locked while it was daytime. So, this wasn't a whole lot to train on. But, even so, I designed some Wiener filters. The plots with the designs show the calculated Wiener filter ("Wiener") and the result from vectfit ("Fit"). Below the bode plot is the coherence between that witness (seismometer direction) and the degree of freedom (QPD channel). The fits were weighted by the choherence, so you can see that in the areas where the coherence was good, the fit was good. Elsewhere, it's not so great.
Using these filters, and assuming a Cheby1 2nd order lowpass filter at 30Hz, I predicted the following residuals:
After discovering that these filters didn't work, I went rogue and also put in a high pass filter at 0.1 Hz, but that didn't really change anything.
Here is a plot of what happened in Yaw. The Wiener filters' gains were all 0.3 here, which made the cavity motion larger, but not so large that it lost lock. The filters ought to have gains of 1 - the Wiener calculation should figure out the gains appropriately, if I've given it enough information. Here, as in the prediction plots above, red is the reference with the Wiener off, and black is with the Wiener filters on. Black is supposed to be below red, if the filters are working. Blue is the estimate of the angular motion that is being fed forward to the PRM, and you can see that at least the general shape is correct. I do need to figure out what the resonance in the blue trace is from - it's at the same frequency as a peak in the T-240's spectrum (that I didn't save). I suspect the cable might be touching the spaghetti pot on the inside, and making a mechanical short to pot vibrations.
Anyhow, more work to be done. I left the PRMI locked for a while this afternoon, starting at 5:15ish, so I'll see tomorrow how long of a lock stretch I was able to capture for training.
We cleared up some optics and optomechanics at the X end table that are not being used and moved them to the SP table. [Ed by KA: They seemed to be leftover of the other projects. I blame them]
Since there will be some work that supposedly will involve moving stuff on the table and racks; here is the updated to-do list for FOL.
Below is the set of plots comparing measurements for the green and IR beat notes frequencies. The measurements were made on the spectrum analyzer at the same time. So I have not taken measurement error into account.
From the plots, the discrepancy is not very large.
Shows the two sets of measurements scaterred along y=x.
Since plot 1 shows the points tightly scattered to y=x, I plotted the difference between the two measurements against their mean to blow out the deviations.
I will do the same comparison using the frequency counter readout once we have RF amplifiers installed.