We were working on getting back into the locking groove tonight.
The POP2F and REFL3F demod angles needed some tuning to lock the PRC reliably. The green alignments were mostly fine, the X end PZT ASS works reasonably well. Suspensions, especially the ITMs, seemed to be drifting a fair deal; today was fairly hot out, I guess.
We only got to the point of attempting the SqrtInv handoff once (which failed because I forgot to check the filter bank offsets). This was because the Mode Cleaner refused to stay locked longer than ~5-10 minutes at a time. We adjusted the MC and FSS servo offsets by the usual means, but this didn't make a difference.
We discussed and decided that the time is right to roll up our sleeves and dig into the MC loop, and try to figure out why these intermittent times of unreliability keep cropping up. We will check out the servo board, and see if we can find the missing phase than Evan observed, as well as characterize the FSS/PZT crossover, and investigate what kind of conditions we may create that cause the PC to saturate.
I am still unable to achieve arm powers greater than TRX/TRY ~10 while keeping the PRMI locked. A couple of times, I was able to get TRY ~50, but TRX stayed at ~10, or even dropped a little, suggestive of a DARM offset? On the positive side, the ALS system seems to work pretty reliably, and I can keep the arms controlled by ALS for several tens of minutes.
More tomorrow, but I tried the following tonight:
In preparation for attempting some DRMI locking, I did the following:
Not related to this work, but I turned the Agilent NA off since we aren't using it immediately.
In preparation for some locking work tonight, I did the following at the POP in air table with the PRMI locked on carrier:
Tonight we want to measure the LSC matrix for PRMI and compare the simulation posted last night (#5495).
First. we locked MICH and PRCL, and measured the OLT to see how good the locking is. The following rough swept sine plots are the OLTs for MICH and PRCL. The gain setting was -10 and 0.5 for MICH and PRCL, respectively. Integrators were off. Looking at the measured plots, MICH has about 300 Hz UGF, when the gain is -20, and PRCL has about 300 HZ UGF, too, when the gain is 0.8.
As these lokings seemed good, so we tried the LSC matrix code written by Anamaria. However it is not working well at this point. When the script add excitations to the exc channels, they kick the optics too much and the lockings are too much disturbed...
Also, we have been trying to lock PRC with the SB resonant, it doesn't work. Looking at the simulated REFL11I (PRCL) signal (you can see it in #5495 too), the CR and SB resonances have the opposite signs... But minus gain never works for PRCL. It only excites the mirror rather than locking.
Both loops basically have no phase margins. i.e. unstable. How can you lock PRMI with these servos?
The following rough swept sine plots are the OLTs for MICH and PRCL. The gain setting was -10 and 0.5 for MICH and PRCL, respectively. Integrators were off. Looking at the measured plots, MICH has about 300 Hz UGF, when the gain is -20, and PRCL has about 300 HZ UGF, too, when the gain is 0.8.
The scripts I wrote can be found in /users/anamaria/scripts/sensemat/
]There are two of them:
- one that sets all the switches, gains, frequencies, etc, then cycles through the various RFPDs I and Q into the LOCKIN signal, so as to see the sensing matrix.
- the second one is a matlab script that takes the crappy file tdsavg outputs and makes it into a cute mag/phase matrix.
They're quite primitive at this point, I've forgotten a lot of tcsh... may improve later. But could be useful later to someone else at least.
I don't think it's particularly the fault of the script that we can't measure the sensing matrix. We can slam on the excitation by hand, and it holds for a little while. I set a wait time for lock to adjust, and most times it just oscillates a bit for a few seconds. Also, the script turns on the excitation and it's done, the rest is just measurement, then turns it off at the end. So during the script, there's not much to deal with, except keeping the lowpass filters quiet when switching the signal to demod; but that doesn't go anywhere, so it definitely doesn't disturb the ifo. Turns out pressing the RSET clear history button needs a 2 to make it happen.
I think I might prefer to set the excitation to run, and then do the old retrieve-data-later-nds-matlab thing. I do not trust these measurements without coherence and a bit of variance study, given instabilities.
Point is... Even on carrier, the PRC lock is not stable by any means. Can barely turn on low freq boosts, every other lock. Until we fix the lock stability issue, there's not much to measure I guess.
Unfortunately, I don't know how to make that happen. Before we leave on Friday we could do a few sanity checks such as measuring the noise of the RFPDs vs ADC+whitening, which I may have said I would do; and perhaps setting up a couple OSAs, one on REFL, one on AS, to make sure we know what the sidebands are doing. Both of which Rana suggested at some point.
(There used to be a quote here from Keiko here but I got mad when it reformated my entire log to be one cluster- hence the look)
Hardware issues that need addressing:
The DQ channels of the ETM coils were active tonight, so I'll make the coil driver actuation budget over the next couple of days.
Some locking efforts tonight; many locklosses due to PRC angular motion. Furthest progress was arm powers of 15, and I've stared at the corresponding lockloss plot, with little insight into what went wrong. (BTW, lastlock.sh seems to catch the lock loss reliably in the window)
CARM and DARM loops were measured not long before this lock loss, and had nominal UGFs (~120Hz, ~20deg PM). However, there was a reasonably clear 01 mode shape at the AS camera, which I did nothing to correct. Here's a spectrum from *just* before the lockloss, recovered via nds. Nothing stands out to me, other than a possible loss of DARM optical gain. (I believe the references are the error signal spectra taken in ALS arms held away + PRMI on 3F configuration)
The shape in the DARM OLTF that we had previously observed and hypothesized as possible DARM optical spring was not ever observed tonight. I didn't induce a DARM offset to try and look for it either, though.
Looking into some of the times when I was measuring OLTFs, the AS55 signals do show coherence with the live DARM error signal at the excitation frequencies, but little to no coherence under 30Hz, which probably means we weren't close enough to swap DARM error signals yet. This arm power regime is where the AS55 sign flip has been modeled to be...
A fair amount of time was spent in pre-locking prep, including:
There seems to be stronger-than-expected coupling between CARM and the 3f sensors.
Full analysis tomorrow, but I collected sensing matrix measurements with lines driven in PRCL,MICH and CARM at a couple of CARM offsets. I also wanted to calibrate the CARM offset to physical units so I ran some scans of the CARM offset and collected the data so I can use the arm cavity FSR to calibrate CARM. Koji suggested using REFL165_I for PRCL and REFL165_Q for MICH control - this would allow us to see if the problem was with the 1f sideband only. While the lock could be established, we still couldn't push the arm powers above 10 without breaking the PRMI lock. While changing the CARM offset, we saw a significant shift in the DC offset level of the out-of-loop REFL33_I signal. Need to think about what this means...
The CARM-->RF transition remains out of reach. No systematic diagnosis scheme comes to mind.
TBC. Mercifully at least the shaker stayed still tonight.
I managed to partially stabilize the arm citculating powers - they stay in a region in which the REFL 11 signal is hopefully approximately linear and so I can now measure some loop TFs and tweak the transition appropriately.
The main change I made tonight was to look at the REFL11 signal as I swept the ALS CARM offset through 0. I found that the maximum arm powers coincided with a non-zero REFL11 signal value (i.e. a small CARM offset was required at the input to the CARM_B filter bank). Not so long ago, I had measured the PM/AM ratio for 11 MHz to be ~10^5 - so it's not entirely clear to me where this offset is coming from. Then, I was able to turn on the integrator (z:p = 20:0) in the CARM_B filter bank while maintaining high POP_DC. At this point, I ramped up the IN2 gain on the IMC servo board (= AO path), and was able to further stabilize the power.
Attachment #1 shows this sequence from earlier in the evening. Note that in this state, both ALS and IR control of CARM is in effect. The circulating power is fluctuating wildly - partly this is probably the noisy ALS control path, but there is also the issue of the (lack of) angular control - although looking at the transmon QPDs and the POP QPD signals, they seem pretty stable.
The next step will be to try and turn off the ALS control path. Eventually, I hope to transition DARM control to AS55 as well. But at this point, I can at least begin to make sense of some of the time series signals, and get some insight into how to improve the lock.
No systematic diagnosis scheme comes to mind.
No real progress tonight - I made it a bunch of times to the point where CARM was RF only, but I never got to run a measurement to determine what the DARM_B loop gain should be to make the control fully RF.
Today the locking was not as easy as that was last Friday.
So I tried something new. Today Rana talked about the ASDC locking with POPDC normalization.
This technique was tried. (This is somewhat similar to DC readout.)
Signal source: REFL33I / Normalization POP110I x 0.04 / Trigger POP110I 20up 3down, otherwise untouched from Friday locking
Servo: input matrix 1.00 -> PRCL Servo FM3/4/5/6 Always ON G=+0.06
Actuator: output matrix 1.00 -> PRM
Signal source: ASDC Offset -109.5 (nominal of the day -49.5) / Normalization POPDC x 1.00 / Trigger POP110I 20up 3down
Servo: input matrix 1.00 -> MICH Servo FM5 Always On G=+10000
ActuaroL output matrix -1.00 -> ITMX / +1.00 -> ITMY
- POP110I was ~120 during the lock (cf 170 on Friday). So there is some small leakage from the dark port.
- Lock was easier when FM4 of the MICH loop was turned off.
- During the lock horizontal motion of the intracavity mode was visible as usual.
I tried using the POX_I error signal for the DC CARM_B path today a couple of times. Got to a point where the AO path could be engaged and the arm powers stabilized somewhat, but I couldn't turn the CARM_A path off without blowing the lock. Now the IMC has entered a temperemental state, so I'm abandoning efforts for tonight, but things to try tomorrow are:
I have some data from a couple of days ago when the PRFPMI was locked as usual (CARM_B on REFL for both DC and AO paths), and the sensing lines were on, so I can measure the relative strength of the sensing lines in POX/REFL and get an estimate of what the correct digital gain should be.
The motivation here is to see if the sensing matrix looks any different with a modified locking scheme.
The usual technique is that keeping the IFO locked with the old set of the signals and the relative gain/TF between the conventional and new signals are measured in-lock so that you can calibrate the new gain/demod-phase setting.
From Attachment #1, looks like the phasing and gain for CARM on POX11 is nearly the same as CARM of REFL11, which is probably why I was able to execute a partial transition last night. The response in POY11 is ~10 times greater than POX11, as expected - though the two photodiodes have similar RF transimpedance, there is a ZFL-500-HLN at the POY11 output. The actual numerical values are 2.5e10 cts/m for CARM-->REFL11_I, 2.6e10 cts/m for CARM-->POX11_I, and 3.2e11 cts/m for CARM-->POY11_I.
So I think I'll just have to fiddle around with the transition settings a little more tonight.
One possible concern is that the POX and POY signals are digitized without preamplificatio, maybe this explains the larger uncertainty ellipse for the POX and POY photodiodes relative to the REFL11 photodiode? Maybe the high frequency noise is worse and is injecting junk in the AO path? I think it's valid to directly compare the POX and REFL spectra in Attachment #2, without correcting for any loops, because this signal is digitized from the LSC demodulator board output (not the preamplified one, which is what goes to the CM board, and hence, is suppressed by the CARM loop). Hard to be sure though, because while the heads are supposed to have similar transimpedance, and the POX photodiode has +12dB more whitening gain than REFL11, and I don't know what the relative light levels on these photodiodes are in lock.
I have some data from a couple of days ago when the PRFPMI was locked as usual (CARM_B on REFL for both DC and AO paths), and the sensing lines were on, so I can measure the relative strength of the sensing lines in POX/REFL and get an estimate of what the correct digital gain should be
I tried some locking anyway tonight, even though we don't have TRY.
The biggest conclusion is that I miss the auto-resonance-finding. I've been roughly scanning the Y-ALS offset to find the POY zero crossing when I see the resonance on the test mass face cameras.
The next-biggest conclusion, is that I can hold the PRFPMI close to resonance, using ALS for CARM and DARM. I was trying to transition DARM to AS55, but I couldn't get the last bit of the way. That is, I couldn't turn off the ALS control. So, I think that AS55 wasn't actually holding DARM, until maybe the last moment or so.
Anyhow, here are some time series. My average TRX value is around 40 counts, and POPDC is maybe 250 counts (just PRMI, POPDC is about 75 counts). Obviously this is noisy as hell, but I'm not using any IR signals for the arms. Near the end of this first time series, I am trying to switch to AS55 for DARM.
Zooming in, my real lockloss is due to PRCL oscillating at ~350 Hz:
However, I also saw ~25Hz peaks in CARM and DARM on the spectra starting to show up, and I see a ~25 Hz oscillation in DARM a few moments after the PRCL lockloss. (Plot #2 is a zoom of the ~1.1 second mark on Plot #3.)
The locking parameters:
Input: Using the new CESAR matrix, -1*ALSX, +1*ALSY. Beatnotes both move up in freq if temp sliders move up.
Servo: gain = 6, FMs 1, 2, 3, 5, 6, 7, 9 on. Offset = 0 counts.
Output = -1*MC2
Input: +1*ALSX, +1*ALSY
Servo: gain = 4. FMs 1, 2, 3, 5, 6, 7, 9 on. Offset = 0 counts.
Output = -1*ETMX, +1*ETMY
Input: +1*REFL33_I, Norm = +0.01*POPDC, sqrt engaged.
Servo: acquisition easier with -0.04 or -0.06, less gain peaking at -0.02 FMs 4, 5 on; 2, 3, 6, 9 triggered with 0.5 sec delay. Servo trigger = POPDC, up 100, down 10. FM trigger = POPDC, up 300, down 20.
Output = +1*PRM
PRCL ASC off, PRM oplev on.
Input: +1*REFL33_Q, Norm = +0.01*POPDC, sqrt engaged.
Servo: gain = 2, FMs 4, 5 on; 2, 3 triggered with 0.2 sec delay. Servo trigger = POPDC, up 100, down 10. FM trigger = POPDC, up 300, down 20.
Output = +0.5*BS, -0.2625*PRM
REFL33 analog gain set to 30 dB for both I&Q.
AS55 set to 0 dB for both I&Q. AS55 had DC normalization of 80 counts (which was the measured number for PRFPMI when TRX was about 0.1 count this evening)
This seems the ever best stability at the zero offset PRFPMI.
Can you look at REFLDC in this data stream too? How was it promising?
Here is 1 second of data, with REFLDC, POPDC and TRX:
Here is a zoom of the first 3 big peaks in TRX. The weird jumps at the beginning of each TRX peak are due to the triggered switching between the Thorlabs trans PD and the QPD trans PD. Clearly we need to work on their relative normalizations. There are also little jumps after each peak as the triggering sends the signal back to the Thorlabs PD.
Here is a zoom of the single big peak about halfway through the 1 second of data:
And here is a zoom of the tail of that peak. It looks to me like we want to start thinking about using REFL DC when our transmitted powers are around 2 counts. We could do as soon as 1 count, but 2 is a little farther into the dip.
Brief elog of my activities tonight:
I was able to transition the digitial CARM control to REFL11 through the common mode board a total of one time, lock broke after a few seconds.
My suspicion was that when we did this on Monday, we unintentionally had a reasonable DARM offset, which reduced the finesse enough to let us take linear transfer functions and hop over. So, tonight, I intentionally looked at transitioning to CM_SLOW at some DARM offset. Using DARM offset of a few times 0.1 really calms the "buzzing" down, and makes it fairly straightforward to measure linear CARM sensing TFs. However, the CARM optical plant seems to change a fair amount depending on the DARM offset, in such a way that I was not able to compensate well enough to repeatedly transition.
Before I did anything else tonight, I measured the ALS noise down to 0.1 Hz, as a benchmark of how things are behaving.
With the arms locked on POX/POY, the HZ calibrated ALS channels reported
Then, with the arms CARM/DARM locked on ALS, the PDH signals reported (using a line and the HZ channels for conversion)
Not bad! I roughly estimate this to mean ~90pm RMS CARM/DARM motion. (If X was as good as Y, it would be ~50pm...)
Some things I feel are worth noting:
Tomorrow, I'll post some transfer functions of the difference between the ALS and CARM plants that I measured.
I updated our lockin simulink pieces to use the newer, more streamlined lockin piece that is currently in CDS_PARTS (with new documentation block!). It means we are no longer passing clock signals through three levels of boxes.
In order to use the piece, you need to right click on it after copying from CDS_PARTS and go to Link Options->Disable Link. This forces the .mdl to save all the relevant information about the block rather than just a pointer to the library. I talked with Rolf and Alex today and we discussed setting up another model file, non-library format for putting generically useful user blocks into, rather than using the CDS_PARTS library .mdl.
The BS, ITMX, ITMY, PRM, SRM, ETMX, ETMY now have working lockins, with the input matrix to them having the 2nd input coming from LSC_IN, the 3rd from the oplev pitch, and the 4th from oplev yaw.
This necessitated a few name changes in the medm screens. I also changed the lockin clock on/off switch to a direct amplitude entry, which turns green when a non-zero value is entered.
Currently, the Mode cleaner optic suspension screens have white lockins on them. I started modifying a new set of screens just for them, and will modify the generate_master_screens. Unfortunately, this requires modifying two sets of suspension screens going forward - the main interferometer optics and the MC optics.
I swapped out one of the channels on Q's lockloss plotter - we don't need POP22Q, but I do want the PC drive.
So, we still need to look into why the PC drive goes crazy, and if it is related to the buildup in the arms or just something intrinsic in the current FSS setup, but it looks like that was the cause of the lockloss that Q and Diego had on Wednesday.
With some advice from Jamie, I've gotten the lock loss plotting script that is used at LHO working on our machines. The other night, I modified the ALSwatch.py script to log lockloss times. Tying it together, I've written a small wrapper script that grabs the last time from the lockloss log, and plots it.
It is: scripts/LSC/LocklossData/lastlock.sh
Jamie's going to make an adjustment to the pydv codebase that will let me implement the auto y-scaling that we like. We also will need to get a feel for the right timing window, once we see what kind of delay in the ALSwatch script is typical.
Here's an example of the output, with the window of [-10,+2] seconds from the logged GPS time:
[Jenne, Diego, EricQ]
Tonight we worked on the acquisition sequence (including re-re-re-commissioning the UGF servos, hopefully for the last time...) for the PRFPMI with large MICH offsets.
The procedure is all in the carm_up script, as far as things work.
We had some locklosses, but they were mostly due to non-carefulness on my part during the transitions between error signals, or the UGF servos getting upset because the oscillator peaks had gotten lost in the noise. The one that I show here is our very last one of the night, where we are hitting the rails for the MICH signal, which is then causing the other loops to have to do weird things to try to compensate, and they lose lock.
Here also is a StripTool shot during that lock stretch. I was in the middle of increasing the MICH offset to 75% of the fringe. The yellow trace (called MICH_B_MON) is ASDC/POPDC normalized so that it always goes 0-1. I was pleased to see that perhaps REFL11I and AS55Q are turning over, although as Q will tell us in a more detailed elog tomorrow, having a large MICH offset does weird things and moves the DARM zero-point. So, maybe we aren't actually anywhere awesome yet.
After some MICH offset, the maximum arm power is always going to be about 50, so arm powers of 8 or 10 equates to 100 pm. We didn't get there tonight while on IR signals.
The locking sequence is now something like this:
After this, we tried a few times to lower the CARM offset, but kept losing lock, I think because the UGF servos went crazy. The final lock, shown above, we lost because the MICH output was hitting the rails.
The problem with the MICH servo right now is the low SNR of the POPDC being used to normalize ASDC. The control output is enormous, even if we have the 400Hz lowpass on. We need to rethink our MICH servo, starting with a lower UGF, so that we're not injecting all this sensing noise all over the place.
Added the following channels to C0EDCU.ini:
Also modified the old P1 channel to
Unfortunately, we realized too late that we don't have these channels in the frames, so we don't have the data from this test pumpdown logged, but we will have future stuff. I say we should also log diagnostics from the pumps, such as temperature, current etc. After making the changes, I restarted the daqd processes.
Things to add to ASA wiki page once the wiki comes back online:
The N2 pressure channel name was also wrong in C0EDCU.ini, so I updated it this morning to the correct name and units:
Now it too is being recorded to frames.
The EUCLID-style Michelson readout is on the SP table now and is aligned. See image below. I took several power spectra with the plotter attached to the HP3563 (not sure if there's another way to get the data out) and I'm still waiting to calibrate (since dP/dL isn't constant as it isn't locked, this is taking a bit longer). When put into XY mode on the oscilliscope (plotting Voltage at PD2 on the x and Voltage at PD3 on the y), a Lissajous figure as in the first plot below. It's offset and elliptical due to imperfections (noise, dc offset, etc) but can ideally be used to calculate the L_ target mirror movement. By rotating the first quarter wave plate by ~80.5deg counter-clockwise (fast axis was originally at Pi/8, now at 103deg), I was able to turn the Lissajous figure from an ellipse into a more circular shape, which would ideally allow for us to use a circular approximation (much simpler) in our displacement calculations.
After Rana and Yoichi tweaked the arm locking filters, we have had some pretty awesome lock stretches. 5-day minute trend.
We laid out a 45m long BNC cable from the LSC rack to the IOO rack via overhead cable trays. There is ~5m excess length on either side, which have been coiled up and cable-tied for now. The ends are labelled "TO LSC RACK" and "TO IOO RACK" on the appropriate ends. This is to facilitate hooking up the output of the DFD for making a PM measurement of the AUX X laser. There is already a long cable that runs from the IOO rack to the X end.
In order to synchronise the FS725 Rb clock with our GPS timing signals, I laid out a longish cable running from 1X7 to the IOO rack via the overhead cable guide. There was a T-connector attached to the 1pps output of the GPS timing unit, with one of the outputs unused - I have connected one end of the cable I laid out to this output, with the other end going to the 1pps input of the FS725. I am now waiting for the FS725 to sync to the external reference, before running the calibration of the phase tracker once again using the same method detailed here, using the 10MHz output from the FS725 to serve as a reference for the Fluke RF signal generator...
Today I set up the EUCLID long range michelson design on the SP table; It's the same as the setup posted earlier, but without the pickoff (at PD1), which can be added later, and a few other minor changes (moved lenses, mirrors, PDs - nothing major). I hooked up the two PD's to the oscilliscope and got a readout that pointed to more power hitting PD2 than PD3.
Here is a longer lock, about 100 seconds RF only, from later that same night. The in-loop CARM and DARM error signals have the order of magnitude of 1nm per count.
From ~-150 to -103, we were fine tuning the ALS offsets to try and get close to the real CARM/DARM zero points then blending the RF CARM signal.
At -100, the CARM bandwidth increases to a few kHz and stabilizes the arm powers. By -81, the error signals are all RF. At -70, I turned on the transmon QPD servos, which brought the power up a bit.
If I recall correctly, lock was lost because I put waaaay too big of an excitation on DARM with the goal of running its UGF servo for a bit. The number I entered was appropriate for ALS, but most certainly too huge for AS55...
When c1oaf starts up there are 446 gain channels that should be set to 0.0 but which end up at 1.0. An example channel is C1:OAF-ADAPT_CARM_ADPT_ACC1_GAIN. The safe.snap file states that it should be set to 0. After model start up it is at 1.0.
We ran some tests, including modifying the safe.snap to make sure it was reading the snap file we were expecting. For this I set the setpoint to 0.5. After restart of the model we saw that the setpoint went to 0.5 but the epics value remained at 1.0. I then set the snap file back to its original setting. I ran the epics sequencer by hand in a gdb session and verified that the sequencer was setting the field to 0. I also built a custom sequencer that would catch writes by the sdf system to the channel. I only saw one write, the initial write that pushed a 0. I have reverted my changes to the sequencer.
The gain channel can be caput to the correct value and it is not pushed back to 1.0. So there does not appear to be a process actively pushing the value to 1.0. On Rolfs sugestion we ran the sequencer w/o the kernel object loaded, and saw the same behavior.
This will take some thought.