Tonight I managed to lock CARM and DARM under ALS control only
ALS error signal tuning
To find the error signals for CARM/DARM, I turned on the oscillators (at 307.8 and 313.31 Hz respectively) with 150 counts and enabled FM10 (Notch for sensing matrix) in the CARM and DARM servo banks. I then removed the ALS offsets (C1:LSC-ALSX_OFFSET, C1:LSC-ALSY_OFFSET) and looked at the transfer functions shown in Attachment #2. I optimized the ALS blending until I maximized the CARM and DARM A to B paths and minimized CARM and DARM cross couplings. The signs were chosen to leave a phase of 0.
After measuring the OLTFs for eCARM and eDARM (loop closed with the A error point) and tuning the ALS error signals, I gradually blended the A and B paths and checked the OLTFs for CARM and DARM. During this I realized I needed to disable some of the notch violin filters because they sometimes made the DARM loop unstable after >50% blending. In the end the simultaneous CARM_A/DARM_A to CARM_B/DARM_B handoff was successful in 0.5 seconds. Attachment #3 shows the OLTFs under ALS control.
After getting nominally stable ALS control, I tried adding an offset. The LSC CARM offset range was insufficient, so I ended up directly scanning the C1:LSC-ALSX_OFFSET and C1:LSC-ALSY_OFFSET. The first couple of attempts the ramp time was set to 2.0 seconds, and a step of 0.01 was enough to break the lock. I managed to hold the control with as much as C1:LSC_CARM_A_IN1 offset by ~ 500 (rms ~ 200 counts). I roughly estimate this to be ~ 5% of the CARM pole which is 4 kHz in this case so overall 200 Hz which is not that large.
- Saved BURT backup in /users/anchal/BURTsnaps/
- Copied existing code for mode cleaner noise budget from /users/rana/mat/mc. Will work on this from home to convert it inot new pynb way.
Get baseline IMC measurements (passive):
- What is MC_F? Let's find out.
- On MC_F Cal window titled 'C1IOO-MC_FREQ', we turned off ON/OFF and back on again.
- Using diaggui, we measured ASD of MC_F channel in units of counts/rtHz.
- Using diaggui, measured ASD from a template (under /users/Templates) and overlay the 1/f noise of the NPRO (Attachment 1)
- WFS Master
- Went through the schematic and tried to understand what is happening.
- Accidentally switched on MC WF relief (python 3). Bunch of things were displayed on a terminal for a while and then we Ctrl-C it.
- The only thing we noticed that change is a slight increase in WFS1 Yaw, and a corresponding decrease in WFS1 Pitch, WFS2 Pitch, and WFS2 Yaw.
- We need to find out what this script does.
- First ran burtgooey as last time.
- Installed pyepics on base environment of donatella
- Clicked on ON in the drop down of "! More Scripts" below "! Scripts XARM" in C1ASS.adl
- Clicked on "Freeze Outputs" in the same menu after some time.
- Noticed that the sensing and output matrix of ASS on XARM and YARM look very different. The reason probably is because the YARM outputs have 4 TT1/2 P/Y dof instead of BS P/Y on the XARM. What are these TT1/2?
(Probably, unrelated but MC Unlocked and kept on trying to lock for about 10 minutes attaining the lock eventually.)
- From scripts/XARM we ran lockXarm.py from outside any conda environment using python command.
- Weirdly, we see that YARM is locked??? But XARM is not. Maybe this script is old.
- C1:LSC-TRY-OUTPUT went to around 0.75 (units unknown) while C1:LSC-TRX-OUTPUT is fluctuating around 0 only.
POY11 Spectrum measurement when YARM is locked:
- Created our own template as we couldn't find an existing one in users/Templates.
- Template file and data in Attachment 2.
- It is interesting to see most of the noise is in I quadrature with most noise in 10 to 100 Hz.
- Given the ARM is supposed to be much calmer than MC, this noise should be mostly due to the mode cleaner noise.
- We are not sure what units C1:LSC-POY11_I_ERR_DQ have, so Y scale is shown with out units.
Trying to lock Green YEND laser to YARM:
- We opened the Green Y shutter.
- We ensured that when temperature slider og green Y is moved up, the beatnote goes up.
- ARM was POY locked from previous step.
- Ran script scripts/YARM/Lock_ALS_YARM.py from outside any conda environment using python command.
- This locked green laser but unlocked the YARM POY.
Things moving around:
- Last step must have made all the suspension controls unstable.
- We see PRM and SRM QPDs moving a lot.
- Then we did burt restore to /opt/rtcds/caltech/c1/burt/autoburt/today/08:19/*.snap to go back to the state before we started changing things today.
[Paco left for vaccine appointment]
- However the unstable state didn't change from restore. I see a lot of movement in ITMX/Y. PRM and BS also now. Movement in WFS1 and MC2T as well.
- I closed PSL shutter as well to hopefully disengage any loops that are still running unstably.
- But at this point, it seems that the optics are just oscillating and need time to come back to rest. Hopefully we din't cause too much harm today :(.
My guess on what happened:
Gautam came in and noted that the optics damping watchdogs had been tripped by a >5 magnitude earthquake somewhere off the coast of Australia. So, under guided assistance, we manually damped the optics using following:
Gautum also noticed that MC autolocker got turned OFF by me (Anchal), we turned it back on and MC engaged the lock again. All good, no harm done.
- Started zoom stream; thanks to whoever installed it!
- Spent some time trying to understand how anything we did last thursday lead to the sensing matrix change, but still cannot figure it out.
- Tracking back on our actions, at ~10:30 we ran burt Restore with the 08:19/.*snap and in lack of a better suspect, we blame it on that action for now.
# ARM locking??
- Reading (not running) the scripts/XARM/lockXarm.py script and try to understand the workflow. It is pretty confusing that the result was to lock Yarm last time.
- It looks like this script was a copy of lockYarm.py, and was never updated (there's a chance we ran it for the first time last thursday)
- *Is there a script to lock the Arms?* Or should we write one? To write one, we first attempt a manual procedure;
1. No need to change RFPD InMTRX
2. All filters inputs / outputs are enabled
3. Outputs from XARM and YARM in the Output matrix are already going to ETMX and ETMY
- Maybe we can have the ARM lock engage by changing the MC directly?
4. Change C1:SUS-MC2_POS_OFFSET from -38 to -0, and enable C1:SUS-MC2_POS_OFFSET_ON
5. Manually scan MC2_POS_OFFSET to 250 (nothing happens), then -250, then back to -38 (WFS1 PIT and YAW changed a little, but then returned to their nominal values)
- Or maybe we need to provide the right gain...
6. Disabled C1:SUS-MC2_POS_OFFSET_ON (back to nominal state)
7. Look into manually changing C1:LSC-XARM_GAIN;
From the command line using python:
>> import epics
>> ch_name = 'C1:LSC-XARM_GAIN'
>> epics.caput(ch_name, 0.155) # nominal = 0.150
- Could be unrelated, but we noted a slow spike on C1:PSL-FSS_PCDRIVE (definitely from before we changed anything)
- Still nothing is happening
8. Changed the gain to 0.175, then back to 0.150, no effect... then 0.2, 0.3 ...
- Stop and check SUS_Watchdogs (should not have changed?) and everything remains nominal
- Revert all changes symmetrically.
- Could we have missed enabling FM1?
- Briefly lost MC lock, but it came back on its own (probably unrelated)
- Wrap it up for the day. In summary; no harm done to our knowledge.
- Upon arrival, MC is locked, and we can see light in MON5 (PRM) (usually dark).
# XARM locking
- Read through "XARM POX" script (path='/cvs/cds/rtcds/caltech/c1/burt/c1configure/c1configureXarm')
- Before running the script, we noticed the PRM watchdog is down, so we manually repeat the procedure from last time, but see more swinging even though the watchdog is active.
- Run a reEnablePRMWatchdogs.py script (a copy of reEnableWatchdogs.py with optics=['PRM']), which had the same effect.
- We manually disable the watchdog to recover the state we first encountered, and wait for the beam in MON5 to come to rest.
- The question is; is it fine to lock Xarm with PRM watchdog down?
- To investigate this, we look at the effect of the offset on the unwatchdog-PRM.
- Manually change 'PRM_POS_OFFSET' to 200, and -800 (which is the value used in the script) with no effect on the PRM swinging.
- Moving on, run IFO > CONFIGURE > ! (X Arm) > RESTORE XARM (XARM POX), and ... success.
# MC-POX noise spectra
- With XARM locked, open diaggui and take spectra for C1:LSC-POX11_I_ERR_DQ, C1:LSC-POX11_Q_ERR_DQ, C1:IOO-MC_F_DQ
- Lost XARM lock while we were figuring out unit conversions...
- Assuming 2.631e-13 m/counts (6941) and using 37.79 m (arm length), 1064.1 nm wavelength, we get a calibration factor of 2.631e-13 * c / (2*L*lambda) ~ 0.9809 Hz/count
- (FAQ?, how to find/compute/measure the correct calibration factors?)
- Relock XARM, retake spectra. Attachment 1 has plots for POX11_I/Q_ERR_DQ spectrum (cts/rtHz, we couldn't find relevant calibration) and MC_F_DQ in (Hz/rtHz from referring to 15576, we couldn't get the units to show on y scale.)
# MC-POY noise spectra (attempt)
- Now, run IFO > CONFIGURE > ! (Y Arm) > RESTORE YARM (YARM POY), and XARM locks (why?)
- Could PRM watchdog being down be the cause?
- Try C1ASS > (YARM) ! More Scripts > ON, and looked at YARM PIT/YAW striptool.
- C1ASS > (YARM) ! Freeze Outputs, then OFF
- Go back to IFO > CONFIGURE > ! (Y Arm) > Align YARM (ASS ON: Unfreeze), try running this then Freeze, then OFF Zero Outputs.
- Try RESTORE YARM (POY) again, still not working.
- Try RESTORE YARM ALS, then try again after opening the shutter, but also fail to lock AUX.
- Is the PRM WD behind some evil misalignment? Will move forward with XARM bc it is happy.
# ARM locking
- Attempted the IFO > CONFIGURE > ! (X Arm) > RESTORE Xarm (XARM ALS) but green failed to lock and we lost XARM lock.
- Try to recover XARM lock... success. It's nice to have a (repeatable) checkpoint.
- Attempt YARM lock. Not successful. It just seems like the lock Triggers are not raised (misalignment?)
- From C1SUS_ETMY, try changing the bias "C1:SUS-ETMY_YAW_OFFSET" manually to reduce the OPLEV_YERROR. Changed from -47 to -57.
- Retry YARM lock script... no luck
- From C1SUS_PRM, try changing the bias "C1:SUS-PRM_PIT_OFFSET" manually to reduce OPLEV errors. Changed from 34 to 22 with no effect, then realized the coil outputs are disabled because the WD is down...
- So we do the following BIAS changes "C1:SUS-PRM_PIT_OFFSET" = 34 > 770 and "C1:SUS-PRM_YAW_OFFSET" = 134 > -6
- Enable all Coil Outputs, turn WD to Normal, turn OPLEVs ON, (this time the beam does not swing like crazy).
- Fine tune BIASes "C1:SUS-PRM_PIT_OFFSET" = 770 > 805 and "C1:SUS-PRM_YAW_OFFSET" = -6 > 65
- Saw YARM locking briefly, then unlocking, but we stopped once the OPLEV_ERRs no longer overloaded (from magnitudes > 50 to ~ 40).
- Retry YARM lock... no luck
- From C1SUS_ETMY, try changing the bias "C1:SUS-ETMY_PIT_OFFSET" from -1 to 6.
Stop for the day. Leave XARM locked, MC locked.
# Initial State
- MC is locked. The PRM monitor shows some oscillations.
- POP monitor shows light flashing once in a while.
- AS monitor shows one beam along with some other flashing beam around it.
- PRM Watchdog is tripped and shutdown. Everything else is normal except for overload on SRM OpLevs.
- Donatella got a mouse promotion
# Reenabling PRM watchdog:
- The custom reEnablePRMWatchdog.py has been deleted.
- Tried enabling the coil outputs manually and switching watchdog to Normal.
- Again saw large fluctuations like yesterday.
- Probably still the same issue of how current calculated actuations to the coils is in range -600 to -900 and gives and impulse to the optics when suddenly turned on.
- Waiting for PRM to damp down a little.
- Today we plan to change the position bias on PRM C1:SUS-PRM_POS_OFFSET instead of changing biases in pitch and yaw.
- Changing C1:SUS-PRM_POS_OFFSET from 0 to +/- 100 without enabling the coils, it seems upper and lower coils are anticorrelated with just changing the position. So going back to changing pitch.
- Changing C1:SUS-PRM_PIT_OFFSET from 0 -> 780. Switched on watchdog to normal.
- PRM damped down. OpLev errors are also within range.
- Enabled both OpLevs.
# Try locking Y-Arm
- IFO>CONFIGURE>YARM>Restore YARM (POY) using Donatella. See a bunch of python error messages in the call complaining about unable to find some python 2 files. Closed it with Ctrl-C after a stuck state.
- Tried running it on Pianosa, the script ran without error but Y-Arm didn't lock.
# Try locking X-Arm
- IFO>CONFIGURE>XARM>Restore XARM (POX) on Donatella. Again a bunch of OSError messages. Donatella is not configured properly to run scripts.
- Tried running it on Piasnosa, the script ran without error but X-Arm didn't lock.
- This might mean that both arms are misaligned or the BS/PRM is misaligned.
- Moving around C1:SUS-PRM_PIT_OFFSET and C1:SUS-PRM_YAW_OFFSET in order to see if the transmitted light is misalgined. Both arms are set to acquire lock if possible. No luck.
# Hypothesis: The Arm cavity is not aligned within itself (ITM-ETM)
- Will try to lock X-Arm with green light while tuning the ETMX. Hopefully the BS and ITM are aligned so that once we align ETMX to get a green lock, the IR will also lock from the other side.
- Running IFO>CONFIGURE>XARM>Restore XARM (ALS) on Pianosa. No lock, moving forward with tunning ETMX pitch and yaw offsets. Nothing changed. Brought back to same values.
[Rana joined, Anchal moved to Rossa from Pianosa]
# Moving on to IMC suspensions characterization:
- Closed the PSL shutter, to our suprise, the MC was still locked. We thought this would take away any light from IMC but it doesn't. Maybe the IFO Overview needs to show the schematic in a way where this doesn't happen: "No light from any laser entering the MC but it still is locked with a resonating field inside."
- Shutting IMCR shutter (hoping that would unlock the IMC), still nothing happend.
- Tried shutting PSL shutter from Rossa, nothing happened to MC lock still.
- Closed shutter IOO>Lock MC> Close PSL and this unlocked the IMC. Found out that this shutter channel is C1:PSL-PSL_ShutterRqst while the one from the sitemap>Shutter>PSL changes C1:AUX-PSL_ShutterRqst. Some clarification on these medm screens would be nice.
- Disabled the MC autolocked from IOO>Lock MC screen (C1:IOO-MC_LOCK_ENABLE).
- Checked the scripts/SUS/freeswing.py to understand how kick is delivered and optic is left to swing freely.
- Next, we are looking at the C1SUS_MC1 screen to understand what channels to read during data acquisition.
- In sensor matrix, we see INMON for each sensor which is probably raw counts data from the OSEMs. Rana mentioned that OSEM data comes out in units of microns. These are C1:SUS-MC1_ULSEN_OUTPUT (and so on for UR, LL, LR, SD).
- In prep for finishing, recovered Autolocker by first opening the PSL mechanical shutter, then re-enabling the Autolocker. The IMC lock didn't immediately recover, and we saw some fuzz on the PSL-FSS_FAST trace, so we closed the shutter again, waited a minute, then re-opened it and MC caught its lock.
A tmux session named "MCFreeSwingTest" will run on Rossa. This session is running script scripts/SUS/freeSwingMC.py (also attached) which will trigger at 5:00 am to impart 30000 counts kick to MC1, MC2, and MC3 after shutting PSL shutter and disabling the MC autolocker. It will let them freely swing for 1050 sec and will repeat 15 times to allow some averaging. In the end, it will undo all the changes it does and switches on autolocker on IMC. The script is set to restore any changes in case it fails at any point or a Ctrl-C is detected.
The triggered code went on at 5:00 am today but a last minute change I made yesterday to increase number of repititions had an error and caused the script to exit putting everything back to normal. So as we came in the morning, we found the mode cleaner locked continuously after one free swing attempt at 5:00 am. I've fixed the script and ran it for 2 hours starting at 8;10 am. Our plan is to get some data atleast to play with when we are here. If the duration is not long enough, we'll try to run this again tomorrow morning. The new script is running on same tmux session 'MCFreeSwingTest' on Rossa
10:13 the script finished and IMC recovered lock.
Thu Mar 11 10:58:27 2021
The test ran succefully with the mode cleaner optics coming back to normal in the end of it. We wrote some scripts to read data and analyze it. More will come in future posts. No other changes were made today to the systems.
- Today we spent the morning shift debugging SUS input matrix diagonalization. MC stayed locked for most of the 4 hours we were here, and we didn't really touch any controls.
After jumping through few hoops, we have one successful result in diagonalizing the input matrix for MC1, MC2 and MC3.
Since the new generated matrices were created for the measurement made last time, they are of course going to work well for it. We need to test with new independent data to see if it works in general.
After Anchal left for his test, I took the time to set up the iMAC station so that Stephen (and others) can remote desktop into it to use Omnigraffle. For this, I enabled the remote login and remote management settings under "Sharing" in "System Settings". These two should allow authenticated ssh-ing and remote-desktopping respectively. The password is the same that's currently stored in the secrets.
Quickly tested using my laptop (OS:linux, RDP client = remmina + VNC protocol) and it worked. Hopefully Stephen can get it to work too.
[Jon walked in, asked him for help]
(selected through burtgooey):
burtwb -f /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2021/Mar/19/08:19/c1iooepics.snap -l /tmp/controls_1210319_113410_0.write.log -o /tmp/controls_1210319_113410_0.nowrite.snap -v <
We found that following protocol works for changing the input matrices to new matrices:
We repeated this for MC2 as well and were able to lock. However, we could not do the same for MC3. It was getting unstable as soon as cavity was locked i.e. the WFS were making the lock unstable. However, the unstability was different in different attempts but we didn't try mroe times as we had to go.
So actually, it was the C1PSL channels that had died. We did the following to get them back:
We ran the coil balancing procedure 4 times while iterating through the output matrix optimization.
Attachment 1, pages 1 to 4 show the progression of cross coupling from current output matrix (which is theoretical ideal) to the latest iteration. We plot the sensed DOF ASD which we used to determine the cross coupling when different excitations are fed using the LOCKIN1 feeding 13Hz oscillation of 200 counts amplitude along the vector defined in output matrix. That means, when we change the output matrix, in subsequent tests, we alos change the exciation direction along with it.
Unfortunately, we don't see a very good optimizations over iterations. While we see some peaks going down in sensed PIT and sensed POS (through MC_F), we rather see an increase in cross coupling in the sensed YAW.
Paco worked on alignign the beam splitter to get light on the ETMY QPD and was successful in centering it without any other changes in the settings.
MC was unlocked and struggling to recover this morning due to misguided WFS offsets. In order to recover from this kind of issue, we
The MC is now restored and the plan is to let it run for a few hours so the offsets converge; then run the WFS relief script.
We're trying to reduce the demodulated error signals after running the ASS script for the XARM.
After running the ASS script, we initially tried to play around with the with the EXC Gain and brought all of them down to 300. It didn't make a huge difference on the error signals or the transmission signal. We then tried tweaking the XARM_OUT_MTRX by flipping the signs/changing the magnitude but it mostly just made things worse. We then changed that matrix to closely resemble the YARM_OUT_MTRX (structurally). At an XARM GAIN of about 0.02, with the EXC Gains at 300 and the XARM_SEN_MTRX having 1.00 on the diagonal terms, the error signals slowly started converging to 0. However, X_ARM_ETM_PIT_L_DEMOD_I_OUT16 kept oscillating which wasn't good.
We later tried looking at the spectrum for the demodulated signals to see if there were any peaks at frequencies outside of the delmodulating frequencies. Most of them looked consistent with peaks at demodulation frequencies (and modes) and signal input frequencies (60Hz and modes). We compared the spectrum with the YARM where everything was optimized, there were no noticable differences.
Later in the day, both XARM and YARM lost lock a couple of times for reasons unknown. We restored to an earlier point in the day (12:00) suspecting there was misalignment with the input optics.
THE XARM ASS MYSTERY REMAINS.
We resumed playing around with ASS for XARM. We approached each error signal one at a time to try to determine the sign of actuation and ensure the error was reduced.
1. Resume nailing down the "fast" control by using ITM transmission error signal to feedback to ITM
2. Add in "slow" pointing control by feeding back ETM LSC error (centering) to BS.
*NOTE* We tried to do this before feeding back any ITM error signal, but this immediately caused transmission to drop because ITM had no way to adjust to new input pointing.
To create the sensing matrix, we tried the DC offset method by giving offsets in the Pitch and Yaw DOFs for ITMX, ETMX and the BS respectively. The signals we looked at were the demodulated ETMX_L, ETMX_T and ITMX_T. We wrote a quick notebook that does the following things for each DOF:
1. Calculate the mean error signal (over 10s)
2. Give an offset of 3 steps in each DOF corresponding to their step size serially with some buffer time (restoring the offset after each DOF)
3. Calculate the new mean error signal (over 10s)
4. Find the difference in error signals and divide by their respective step sizes to get each sensor's sensitivity to the offset.
5. Invert to obtain the sensing matrix.
Sensing Matrix for Pitch:
Sensing Matrix for Yaw:
*NEED TO TRY THESE OUT*
The Output Matrix for the from intuition was set to *Attachment 2* which improved the net average transmission (see Attachment 1), but wasn't really stable after the improvement.
We recalculated the sensing matrix for XARM ASS by collecting each sensor's step response to an offset in each DOF. This produced the following dense output matrix A (see Attachment 1 for rows/cols):
[[-0.02047695, 0. , -0.10262752, 0. , -0.0157128 , 0. ],
[ 0. , 0.16908344, 0. , -0.00929291, 0. ,-0.35916455],
A = [-0.28050764, 0. , 0.26982002, 0. , -0.55100297, 0. ],
[ 0. , 0.85501491, 0. , 0.0606197 , 0. , 0.27568672],
[-0.95963335, 0. , 0.95742611, 0. , 0.83435534, 0. ],
[ 0. , -0.49026554, 0. , -0.99811768, 0. , 0.89162641]]
Turning the XASS gain up slowly to ~0.15, we observed that several error signals diverged and transmission started to drop. Debugging this matrix proved difficult since there were many nonzero elements to consider. So we reverted to build the matrix from our intuition, considering the centering and input pointing loops, and using the YASS output matrix as a reference.
The YARM ASS servo gains are all +1. The YASS output matrix has the following length (centering) signal mapping:
ITM PIT/YAW L ----> ETM feedback
(ETM PIT/YAW L - ITM PIT/YAW L) ----> ITM feedback
We mirrored this in the XASS output matrix. Note that previously the ITM L error signals were not used for XASS. To simplify the process, we decided to just work out the beam centering first and ignore the input pointing coming from the beam splitter (setting BS PIT/YAW matrix elements to 0). We also set all the XARM ASS servo gains to +1. See the output matrix below:
We cleared the outputs and turned on the XARM GAIN slowly (0.1) and immediately noticed the YAW signals in ETM start to diverge (C1:ASS-XARM_ETM_YAW_T_DEMOD_I_OUT16, C1:ASS-XARM_ETM_YAW_L_DEMOD_I_OUT16). We turned down the XARM gain and flipped the sign for the signal going to ETM YAW. (suspect a difference in sign convention).
To check the stability, we sequentially gave offsets in PIT/YAW for ETM and ITM. We saw the signal (C1:ASS-XARM_ETM_PIT_L_DEMOD_I_OUT16) oscillate wildly at a frequency of ~(1/15 Hz). We suspected the ASS loop was driving these oscillations so we turned down the gain going to ETM PIT to 0.25 which worked really well and the transient oscillation of further checks was gone.
We saw similar wild oscillatory signals in ITM PIT (C1:ASS-XARM_ITM_PIT_T_DEMOD_I_OUT16, C1:ASS-XARM_ITM_PIT_L_DEMOD_I_OUT16) on applying offsets so we reduced the gain going to ITM PIT to 0.3. (0.25 and 0.3 are arbitary relatively smaller weights, can be fine tuned).
We checked the stability of this setup as a whole by giving a few offsets to ITMX and ETMX, with a servo gain of 0.15 it did a great job! (0.25 made it diverge once again). See final state for centering in Attachment 1, and error signal suppression in Attachment 2. (Ignore XAUX transmission in grey - we were toggling the shutter.) Note that the Length error signals were successfully suppressed, but the dark green/brown Transmission error signals were not fed back and thus remain nonzero.
WE SHALL INVESTIGATE THE INPUT POINTING NEXT FEEDING BACK TO THE BS and ITMX. We will give an update shortly about whether restoring XARM ASS is feasible by Monday.
Today I worked on getting the ITMY and SRM oplevs back in working order. I aligned the SRM path back onto the QPD. I put excitations on the ITMY and SRM in pitch and yaw and observed the beam at the QPDs to check for clipping. They looked clean from clipping.
Just to find out where we are currently, I plotted the ITMY and SRM oplev spectra along with the ETMY oplev spectra. ETMY seems to be very good, so comparing with this seemed useful, so we know how much we have to improve by. The SRM power spectrum appears to be around 2 orders of magnitude higher than ETMY over pretty much the whole measurement band. The ITMY power spectrum is not so bad as the SRM above about 60Hz. Next thing to do is to check the dark noise level for the ITMY and SRM QPDs.
The title of this post should of course have been " ... - comparison with ETMY" not " ... - comparison with ITMY"
I took a dark noise measurement for the ITMY QPD, for comparison with measurements of the oplev noise later on. Initially I was plotting the data from test points after multiplication by the oplev matrix (i.e. the OLPIT_IN1 / OLYAW_IN1), but found that the dark noise level seemed higher than the bright noise level (!?). Kiwamu realised that this is because at that test point the data is already divided by QPD SUM, thus making the dark noise level appear to be greater than the bright level, since QPD SUM is much smaller for the dark measurements. The way around this was to record the direct signals from each quadrant before the division. I took a power spectrum of the dark noise from each quadrant, then added them in quadrature, then divided by QPD SUM at the end to get an uncalibrated PSD. Next I will convert these into the equivalent for pitch and yaw noise spectra. To calibrate the plots in radians per root Hz requires some specific knowledge of the oplev path, so I won't do this until I have adjusted the path.
I tried again at plotting the ITMY_QPD noise spectra in for dark and bright operation. Before we had the strange situation where the dark noise seemed higher, but Kiwamu noticed this was caused by dividing by the SUM before the testpoint I was looking at. This time I tried just multiplying by the measured SUM for bright and dark to normalise the spectra against each other. The results looks more reasonable now, the dark noise is lower than the bright noise for a start! However, the dark noise spectrum now doesn't look the same as the one I showed in my previous post.
I checked the dark and bright noise of the SRM oplev QPD. The SRM QPD has a rather high dark level for SUM of 478 counts. The dark noise for the SRM QPD looked a little high in the plot against the bright noise (see first attachment), so I plotted the dark noise with the ITMY QPD dark noise (see second attachment). It seems that the SRM QPD has a much higher dark noise level than the ITMY! In case anyone is wondering, to make these traces I record the data from the pitch and yaw test points, then multiply by the SUM (to correct for the fact that the test point signal has already been divided by SUM). I will check the individual quadrants of the SRM QPD to see if one in particular is very noisy. If so, we/I should probably fix it.
I've calculated a suitable collimating telescope for the ITMY/SRM oplev laser, based on the specs for the soon-to-arrive 2mW laser (model 1122/P) available here: http://www.jdsu.com/ProductLiterature/hnlh1100_ds_cl_ae.pdf
Based on the fact that the 'beam size' value and 'divergence angle' value quoted don't match up, I am assuming that the beam radius value of 315um is _not_ the waist size value, but rather the beam size at the output coupler. From the divergence angle I calculated a 155um waist, (zR = 12cm). This gives the quoted beam size of about 316um at a distance of 8.5" away from the waist. This makes me think that the output coupler is curved and the waist is at the back of the laser, or at least 8.5" from the output coupler.
The collimating telescope gives a waist of size 1142um (zR=6.47m) at a distance of 1.427m away from the original laser waist, using the following lens combo:
L1 f=-0.15 @ 0.301m
L2 f=0.3 @ 0.409m
This should be fine to get a small enough spot size (1-2mm) on the QPDs.
I just drew a basic picture of how the ITMX oplev path could be reworked to minimise the number of optics in the path. Only possible problem with this might be the turning mirror onto the ITMX getting in the way of the collimating lenses. Should be easy to solve though. Does anyone know if there is a ITMX pick off beam I should be careful to avoid?
First of all I moved the lenses on the ITMY/SRM oplev path to get a smaller spot size on the QPDs. I couldn't get the beam analyzer to work though, so I don't know quite how successful this was. The software brought up the error "unable to connect to framegrabber" or something similar. I don't think the signal from the head was being read by the software. I will try to get the beam analyzer working soon so that we can characterize the other oplev lasers and get decent spot sizes on the QPDs. I searched the elog for posts about the analyzer, and found that it has been used recently, so maybe I'm just doing something wrong in using it.
After this I measured the transfer function for the ITMY oplev yaw. I did a swept sine excitation of the ITMY in yaw with an amplitude of 500, and recorded the OSEM yaw values and the oplev yaw values. This should show a flat response, as both the QPD and the OSEMS should have flat frequency response in the measurement band. This measurement should therefore just yield a calibration from OSEM yaw to oplev yaw. If the OSEM yaw values were already calibrated for radians, we would then immediately have a calibration from oplev yaw values to radians. However, as far as I'm aware, there is not a calibration factor available from OSEM yaw values to radians. Anyway, the TF I measured did not appear to be very flat (see attached plot). Kiwamu suggested I should check the correlation between the OSEM measurements and the oplev QPD measurements - if the correlation is less than 1 the TF is not reliable. Indeed the coherence was poor for this measurement. This was probably because at frequencies above the pendulum frequency, the excitation amplitude of 500 was not enough to cause a measurable change in the optic angle. So, the plot attached is not very useful yet, but I learned something while making it.
In order to estimate the amount of noise that the oplevs are injecting into the GW channel, we first need to calibrate oplev signals in terms of angular change in the optic. I said in my previous post that there wasn't a calibration factor for OSEM values to radians, but I found that Kakeru had estimated this in 2009 - see entry 1413. However, Kakeru found that this was quite a rough estimate, and that it didn't agree with his calibrated oplev values well. He does quote the 2V/mm calibration factor for the OSEM readings though - does anyone know the provenance of this factor? I searched for OSEM calibration and found nothing.
I replaced the lenses that were there with a -150mm lens followed by a +250mm lens. This gave a significantly reduced beam size at the QPDs. With the beam analyzer up and running it should be possible to optimize this later this afternoon. Next I will remove the SRM QPD from the path and make measurements of the beam spot position movement and corresponding OSEM values for different DC mirror offsets. I will then repeat the process for ITMY.
I've got the bench set up for the measurement of the beam spot change with DC SRM alignment offsets. The ITMY oplev is aligned and fine to use, but the SRM one isn't until further notice (probably a couple of hours).
I made the first measurements towards oplev calibration measurements: calibrating the oplevs in SRM YAW. The measurements seemed fine, I had a range of between -1.5 and 1.5 in SRM DC alignment before clipping on mirrors on the oplev bench became a problem. This seemed to be plenty to get a decent fit for the spot position against DC alignment value - see attached plot. The fitted gradient was -420um oplev yaw count. I calculated oplev yaw values as UL+LL-UR-LR. Pitch next.
Same measurements for SRM pitch (as previously done for yaw in entry 5460) are complete. The QPD is back in the path and aligned. I will be doing the same measurements for ITMY now though, so please ask before activating the SRM or ITMY oplev servos, as I may be blocking the beam.
I've now taken data for the pitch and yaw calibrations for the OSEMs of SRM and ITMY. Until such time as I know what the calibrated oplev noise spectra are like, I'm leaving the servo gains at zero.
I estimate the length of the lever arm from SRM to measurement position to be 3.06m, and the length of the lever arm from the ITMY to the measurement position to be 3.13m.
From the fits shown on the attached plots, this gives the following calibration factors for the SRM and ITMY OSEMs pitch and yaw counts (i.e. counts from channels such as SUS-ITMY_ULSEN_SW2 multiplied by a matrix of 1s and -1s) to pitch and yaw angle:
SRM PITCH: 1 OSEMs pitch count = 11.74 microradians
SRM YAW: 1 OSEMs yaw count = 12.73 microradians
ITMY PITCH: 1 OSEMs pitch count = 13.18 microradians
ITMY YAW: 1 OSEMs yaw count = 13.52 microradians
Next step is to do some DC offsets with the oplev paths back in place to get the final calibration between OSEMs counts and oplev counts, thus finally getting a conversion factor from oplev counts to radians.
I noticed while taking these measurements that the DC offsets I put on ITMY caused around 5 times larger change in angle than those on the SRM. The different path length is not enough to account for this, so I propose that the actuation is working differently for the two. I guess this should be taken into account when designing the output matrices (unless the control is passed through a different output matrix than the DC offsets?). I'll quantify the difference shortly, and write a conversion factor between output alignment count (e.g. SUS-ITMY_PIT_COMM) and angle.
The measured calibration factors for the oplevs are as follows:
Kiwamu noticed that the 1/L in the counts per radian should have just been L, which accounts for most of the discrepancy. We checked the input filters on the OSEMs, and they have 10dB of gain at DC. Accounting for this, estimates on the order of 20urad/count, which is much more reasonable!
I found that some of the Optical Lever Servos were ON today and injecting nonsense into the interferometer optics. I have set all of the gains = 0 to save us more headaches.
I had previously set the gains to zero, see the first line of my entry on Monday 5468. I should have the servo and noise characterisation done today for these oplevs today, so we can review it soon.
Here are the open loop transfer functions for ITMY and SRM. The various settings for the OLTFs were as follows:
Oplev filter used for all OLTFs: 300^2:0
Gains for oplev servos (for each OLTF only the 1 servo for the measured TF was on. They are all set back to 0 now):
SRM yaw gain = 1
SRM pitch gain = -1
ITMY yaw gain = -1
ITMY pitch gain = 1
measurement band = 0.2Hz to 200Hz
points = 33
swept sine magnitude envelope: amp = 2 for f > 60Hz, amp = 0.1 for f < 60Hz
Measurement points were from e.g. C1-SUS-ITMY-OLPIT-IN2 to C1-SUS-ITMY-OLPIT-IN1 to give a TF of -(loop gain).
Next step is to divide this through by the sensor reponse (i.e. the calibration factor measured earlier) and the filter response to get just the actuator response.
I divided the open loop transfer functions by the filter response and the sensor responses (previously measured calibration factors) to leave just the actuator responses. I've attached the actuator responses plotted in radians/count and phase over frequency.
Next step: fit the actuator response with poles and zeros.
EDIT: I divided by the wrong filter function earlier - the plots there now are divided by the correct filter function
I used an fminsearch function to fit the SRM and ITMY actuator response magnitudes. The testfunction was just that for a single second order pole, but it gave what I consider to be good fits for the following reasons:
*for 3 of the 4 fits the residuals were less than 0.5% of the summed input data points. The worst one (ITMY pitch) was about 2.7%, which I think is due to the resonance happening to be right in the middle of two data points.
*the tolerance of 1 part in 10^9 was reached quickly from not very finely tuned starting points.
The test function was: G=abs(Gp./(1+1i.*f./fp./Qp-(f./fp).^2)), where G(f) is the actuator response magnitude, Gp is the pole gain, fp is the pole frequency, and Qp is the pole Q factor.
In the end I just fitted the response magnitude. I was initially fitting the complex response function, but ran into problems which I think were cased by overall phase offsets between the data and test function. Can I canvass for opinion if fitting the magnitude is OK, or should I try again fitting the phase too?
Anyway, here are the results of the fits, and I've attached plots of each too (each one in linear and log y axis because each on its own might be misleading for fits):
EDIT - I added more points to the otherwise sparse looking fitted curves
ITMY PITCH actuator response fit
-- Fit completed after 190 iterations--
Started with: Gain = 3e-06,
Q factor = 5,
Pole frequency = 1,
Fit results: Gain = 1.32047e-06,
Q factor = 4.34542,
Pole frequency = 0.676676
Residual (normalised against the sum of input datapoints) = 0.0268321
ITMY YAW actuator response fit
-- Fit completed after 156 iterations--
Fit results: Gain = 1.14456e-06,
Q factor = 8.49875,
Pole frequency = 0.730028
Residual (normalised against the sum of input datapoints) = 0.00468077
SRM PITCH actuator response fit
-- Fit completed after 192 iterations--
Fit results: Gain = 7.94675e-06,
Q factor = 7.16458,
Pole frequency = 0.57313
Residual (normalised against the sum of input datapoints) = 0.00301265
SRM YAW actuator response fit
-- Fit completed after 156 iterations--
Fit results: Gain = 3.34179e-06,
Q factor = 9.57601,
Pole frequency = 0.855322
Residual (normalised against the sum of input datapoints) = 0.000840468
Did you take the 180 deg shift into your account ?
Since your measurement was done when the loop was closed, there must be an additional 180 deg phase shift (in other words, minus sign).
I thought I had, but apparently not, and I'd made another error or two in the complex version of my fitting routine. I've fixed them now, thanks! I'll put up the new fitting results tomorrow morning.
Here are the results of the complex fitting. The residuals are bigger this time, but still probably small enough to be ok(?), with the possible exception of ITMY PITCH (due again I think to the data points straddling the resonance).
ITMY YAW actuator response complex fit
-- Fit completed after 282 iterations--