I re-centered the beam on the ISS second loop QPD and array. Power levels look ok. I did not fine tune the beam position to maximize the power.
Photodiode values (in mA), for future reference
gabriele.vajente@zotws2:~$ cdsutils avg 10 H1:PSL-ISS_SECONDLOOP_PD1_OUT16 H1:PSL-ISS_SECONDLOOP_PD2_OUT16 H1:PSL-ISS_SECONDLOOP_PD3_OUT16 H1:PSL-ISS_SECONDLOOP_PD4_OUT16 H1:PSL-ISS_SECONDLOOP_PD5_OUT16 H1:PSL-ISS_SECONDLOOP_PD6_OUT16 H1:PSL-ISS_SECONDLOOP_PD7_OUT16 H1:PSL-ISS_SECONDLOOP_PD8_OUT16 H1:PSL-ISS_SECONDLOOP_PDSUMINNER_OUT16 H1:PSL-ISS_SECONDLOOP_PDSUMOUTER_OUT16
Rick reminded me that the current pre-modecleaner was meant to be operated with a UGF of 1 kHz, as per
T1700543. There are also loop shape changes that are not
implemented with this servo card. However in order to reduce the UGF to 1 kHz, both the optical and electronic
gains had to be reduced. The unlocked light level was previously ~1.35 V, is now 0.28 V. This has been
reflected in changes to the locking thresholds on the MEDM screen.
SCRN0006.jpg shows the pre-modecleaner open loop transfer function after the above changes were made.
SCRN0007.jpg shows the power noise measured with an out of loop photodiode. Gone are the sharp ~22 kHz
and harmonics peaks.
Back here (alog 30682) and here (alog 30701) we saw some noise increase at higher UGFs. So we should keep the capability of reducing the UGF to ~few hundred Hz for future noise hunting.
Right now, the reflected light on the RFPD is turned down using the transmitted beam through a rotatable (thin film?) polarizer and it is at about the minimum level. Thus, the light on the RFPD is mostly the unwanted polarization. I suspect this is not what we want. If we replace the folding mirror directly upstream with a less polarization-selective beamsplitter (or two) we should be able to improve the ratio of wanted to unwanted polarization and get more attenuation for reducing the servo UGF, when desired.
One way to answer the question in the title is to look at the correlation between power fluctuations (for example H1:LSC-POPAIR_B_RF18_I_NORM_MON) and the residual excursion of all ASC error signals from the average value (zero if the loops are closed, non-zero otherwise). This figure of merit can be represented either with a scatter plot, or with a two-dimensional histogram. The plots below show an example for a DRMI lock from yesterday (GPS from 1217614260 to 1217614500). Only input beam and PRC loops were closed. Clearly, the alignment position was not optimal, since all histograms are skewed. If the alignment was tuned at the correct working point, one would expect all histogram to be symmetric, showing round shapes, or at most parabolic, second order, dependencies of the power on the ASC signals (this meaning that the power fluctuations are due to too loose angular controls).
Both plots show the dependency of POP_RF18 on all ASC error signals.
Danny, TJ, Georgia, TVo
Big ups to Sheila for running our measurement after ISC was finished with their work for the night.
Yesterday Georgia and Danny put in an iris on ITMX to crop out a prompt reflected beam from an in-chamber lens so that we can try to compare the spherical power on both ITMX and ITMY HWS when injecting 6 Watts of power into the ring heaters (3 top, 3 bottom):


Note that there is still a bit of clipping on ITMX on the top right corner. Using the results of a COMSOL model here, where it quotes

| Model Prediction | ![]() |
| HWS ITMX Measured | ![]() |
| HWS ITMY Measured | ![]() |
From yesterday:
Danny installed an iris on the ITMY HWS path directly before the HWS camera.
This iris blocks a problematic stray beam that appears to be reflected off a surface between the viewport and the SR3 baffle.
Attaching screenshots of the camera image (with hartmann plate removed) before (attachment 1) and after (attachment 2) iris install. We were a bit concerned about the new fringes and any noise they might introduce. Note the two screenshots were taken with different lighting conditions (table door open/closed) so the intensity difference is not a concern.
For reference, here is how the ITMX HWS return beam looked back in 2014 when everything was first installed.
2014 versus 2018
And here's a view with the 2014 and 2018 beams overlapped. Roughly 50% of the HWS probe beam is clipped.

I think I've tracked down the source of the problem with the HWSX probe beam clipping. The issue stems from the fact that the new HWSX STEER M1 optical mount required the base to be moved. This was known and we aimed to keep the optic face in the same location. However, in placing the new optical mount, the wrong face has been kept in the same location - resulting in a displaced front surface.
We aligned the in-vacuum optics assuming the front surface had not moved(aLOG 39053). I'll need to investigate further to trace out the beams but this is almost certainly the cause of the clipping we're seeing.
The attached images show an overlay of two photos of the HWSX STEER M1 optic in 2014 (aLOG 12615) and 2018 (aLOG 39071)
FRS issue (https://services.ligo-la.caltech.edu/FRS/show_bug.cgi?id=11691)

After looking closely at the in-chamber photos, I've tried to estimate what the optical axis is doing. It should move in the -Y direction by ~7-10mm in the Hartmann Scraper Baffle.

If that's the case, then the beam size (at one beam radius) going through the aperture will look something like the following. The red beam is getting close to the edge of the aperture.

TJ took some photos of the in-vacuum optics with his phone and we can see relatively well along the optical axis of the HWS (although not with enough resolution to see the scraper baffle).

We'd like to try to do this with the chamber illuminated and a good SLR camera that is placed in the optical axis and focussed at the same distance as the scraper baffle. We should see a series of concentric circles and ellipses that are the apertures of all the optics and baffles. If, as I suspect, the HWS scraper baffle is now off center relative to the beam, it should be visible as such in this image.
WP7749 Hugh, Dave:
New models were restarted for h1isiham[2-4] and the DAQ was restarted.
Each model has six new 4kHz DQ channels added to the DAQ (total of 18 channels)
H1:ISI-HAM[2-4]_GS13INF_[H,V][1-3]_OUT_DQ
Today is maintenance day and there are people working in the enclosure at this time.
Laser Status:
SysStat is good
Front End Power is -0.002978W (should be around 30 W)
HPO Output Power is 0.3117W
Front End Watch is RED
HPO Watch is RED
PMC:
It has been locked 0 days, 0 hr 40 minutes (should be days/weeks)
Reflected power = 16.24Watts
Transmitted power = 48.17Watts
PowerSum = 64.4Watts.
FSS:
It has been locked for 0 days 0 hr and 9 min (should be days/weeks)
TPD[V] = 2.464V (min 0.9V)
ISS:
The diffracted power is around 0.24% (should be 3-5%)
Last saturation event was 0 days 0 hours and 40 minutes ago (should be days/weeks)
Possible Issues:
Front End Power is Low
ISS diffracted power is Low
LRA out of range, see SYSSTAT.adl
Sheila, Craig CARM UGF ~ 22 kHz, Phase Margin ~ 45 degrees IMC UGF ~ 100 kHz, Phase Margin ~ 25 degrees Today we worked on locking the interferometer (surprise). We increased the gains on the IMC servo board inputs by 8 dB each, increasing the UGF from 36 kHz to above 100 kHz. TR_CARM gain was increased to 2, then decreased back to 1 as this was causing gain peaking at 500 Hz in CARM when lowering the offset. START_TR_CARM has been improved so we no longer lose lock or saturate SRM. When we reach RESONANCE, things are pretty wobbly according to the AS AIR camera and our PR_GAIN calculation. We can improve this by engaging FM3 in DHARD_P and increase the gain to -30. We increased the analog CARM loop gain by a factor of ten (it used to be ~ 2kHz) to allow us to engage the Common servo board compensation boost in the CARM_TO_ANALOG state. We did this by increasing the REFL9I summing board gain to 23 dB. In O2 it was 8 dB, and last night it was 14 dB. POP sensors were phased for DRMI (POP 45 to minimize SRCL in Q). We then measured TFs between the REFLAIR 3f PDs and the POP 1f PDs, found a POP 1f sensing matrix relative to the REFLAIR 3f one, then switched DRMI to POP control. The POP 1f sensing matrix has been touted as "pretty similar to O2" by Sheila. Pics below. The new values are in the guardian, loop measurements are attached for PRCL and SRCL. We were manually stepping through the rest of the DRMI_ON_POP guardian state when we lost lock probably for unrelated reasons. Buildups were slightly worse today (TR_X_NORM ~ 930, implying a PR gain of about 28). We were locked on CARM_TO_ANALOG for over an hour (August 7, 2018 6:30:00 to 7:39:00 UTC) while we did this, very stable even without ASC (except for DHARD_WFS and occasional BS touches).
I started the script that Thomas sent me to turn the ring heaters on at about 7:50 UTC on August 8th (12:50 am)
They will end in an hour. I shuttered the ALS beams at around 8:00 UTC since I wasn't sure if this test needs them off.
[Hang, Gabriele, Jenne]
Since the Xarm green ITM camera was showing us that the spot on ITMX was more than a spot size different in pitch than we had been using the last few weeks, we wanted to see if we could find the geometric centers of the test masses, and use that as a new alignment reference. (Spoiler alert: for locking today, we're using the alignments from yesterday, but those are pretty close to the alignment with the spots at the centers of the Xarm test masses).
I had tried this in the past, but hadn't tried increasing the PD whitening gain, which turned out to be the key to being able to see the dither lines.
The guardian set us up for locking the Xarm in IR on POP45 (once upon a time we used to use ASAIR45, but we switched to using POP45 when we pulled out the ASAIR PD, and haven't changed things back to use AS_A_SUM_45 once the model changes were in place to use it - probably we should make that change, since AS will get much more light than POP). Anyhow, before Sheila pointed that out to me, we stuck with POP and increased it's whitening from one stage to 2, and increased the analog gain from 30dB to 42dB (I also changed the I and Q digital gains from 1 to 0.1 to compensate for the gain change).
We used the ADS system, oscillators 8 and 9, with 300,000 counts amplitude at 19.1 and 23.1 Hz on ETMX and ITMX pitch. We utilized the DARM filter banks with gains of 1 and all filter modules off (DARM triggering forced to prevent any signal from going to any suspensions) to send actually the Xarm error signal to the input matrix of the ADS demodulators. Gabriele made new band passes for the demods, and set the phases of the demods. I set the P2L gains of both ITMX and ETMX to zero. The ALIGN_IFO guardian was in INPUT_ALIGN, so the INP1 and INP2 loops were making IM4 and PR2 move such that the beam was following the Xarm cavity axis. I also slowly increased the PSL power using the guardian 1W at a time to 10W input power. Hang moved ITMX and ETMX to minimize the dither lines' appearance in the Xarm error signal. We then repeated this procedure for yaw.
Hang has screenshots of our final slider positions in this state. They weren't all that far from the slider positions from Sunday's locks, which is good. It means that the full IFO locking over the weekend was using something closer to the centers of the optics, and the alignment we'd been using the last few weeks just wasn't so great.
Since Team Alignment ran out of time on our morning shift, we just put everything back to how it was on Sunday, so that Team Length locking could work on the IFO. But we may think about this alignment in the future.
Moral of the story is, we can measure test mass spot positions with single arm locks. But, maybe we'll just measure the spots with the full IFO, now that we're getting close to lock, and we know that the full lock alignment is pretty close.
Jenne, Hang
The slide bar and osem outputs after we zeroed the dithering signals are attached. Since we did the measurement in the input align state, only IM4, PR2, ITMX, and ETMX values are meaningful here. This alignment is actually not very different from the ones we've been using these days for the lock acquisition.
In addition, we also updated the green camera's locking points for the XARM. The new values are PIT = 454.5 and YAW = 414.0. These were the values during yesterday's initial alignment at Aug 06 21:52:00 UTC (leaving the camera loop, DOF3, open at that point).
We had wasted a bit of time this evening battling with ALS DIFF to FIND_IR.
Note: when the ISC_LOCK does not find IR with DIFF, check that the diff VCO servo is off before spending too much time tuning the offset by hand. It turns out we were battling the servo and getting confused, possibly this happened because DIFF was in the IR_FOUND state, even though the IR was not found.
Attached is the pump down curve for IP12 pumping against its closed O-ring gate valve. I'll isolate IP4 tomorrow for a comparitive reference.
Regarding previous logs mentioning "remote leaks" or possible "permeation" etc... I have since decided that I must have overlooked the 1 1/2" pump port valve during previous leaks checking efforts. I likely had excluded it as we had recieved the rebuilt ion pump under good vacuum etc... and the pump-side flange of this valve has not been undone. However, if this flange is "gappy" (I'll check tomorrow), the later act of me bolting on the small turbo pump to this valve could have induced a leak. Spraying helium around the suspect HV feedthroughs and 16.5" flange joints (which are underneath the 1 1/2 valve) might have been cross-talking to the newly induced leak on the pump port valve.
Heck! Tomorrow is maintenance day and I will have access to this! I'll just leak check the 1 1/2" pump port valve tomorrow and be done with it!
Ran scripts to generate T240 and STS mass centering report. The 10 T240 and one STS masses which are not centered are highlighted in red. Closing FAMIS task #7324.
Averaging Mass Centering channels for 10 [sec] ...
2018-08-06 15:17:35.363674
There are 10 T240 proof masses out of range ( > 0.3 [V] )!
ETMX T240 1 DOF Z/W = -0.61 [V]
ETMX T240 2 DOF X/U = -1.071 [V]
ETMX T240 2 DOF Y/V = -0.988 [V]
ETMX T240 2 DOF Z/W = -0.48 [V]
ETMX T240 3 DOF X/U = -0.325 [V]
ETMX T240 3 DOF Y/V = 0.385 [V]
ITMX T240 1 DOF X/U = -1.159 [V]
ITMX T240 3 DOF X/U = -1.29 [V]
ITMY T240 3 DOF X/U = -1.076 [V]
ITMY T240 3 DOF Z/W = -1.842 [V]
All other proof masses are within range ( < 0.3 [V] ):
ETMX T240 1 DOF X/U = 0.146 [V]
ETMX T240 1 DOF Y/V = -0.268 [V]
ETMX T240 3 DOF Z/W = -0.075 [V]
ETMY T240 1 DOF X/U = -0.163 [V]
ETMY T240 1 DOF Y/V = -0.033 [V]
ETMY T240 1 DOF Z/W = -0.178 [V]
ETMY T240 2 DOF X/U = -0.046 [V]
ETMY T240 2 DOF Y/V = -0.167 [V]
ETMY T240 2 DOF Z/W = -0.074 [V]
ETMY T240 3 DOF X/U = -0.206 [V]
ETMY T240 3 DOF Y/V = -0.178 [V]
ETMY T240 3 DOF Z/W = 0.063 [V]
ITMX T240 1 DOF Y/V = 0.231 [V]
ITMX T240 1 DOF Z/W = 0.113 [V]
ITMX T240 2 DOF X/U = 0.05 [V]
ITMX T240 2 DOF Y/V = 0.172 [V]
ITMX T240 2 DOF Z/W = 0.213 [V]
ITMX T240 3 DOF Y/V = 0.123 [V]
ITMX T240 3 DOF Z/W = 0.059 [V]
ITMY T240 1 DOF X/U = -0.157 [V]
ITMY T240 1 DOF Y/V = -0.12 [V]
ITMY T240 1 DOF Z/W = -0.224 [V]
ITMY T240 2 DOF X/U = 0.033 [V]
ITMY T240 2 DOF Y/V = 0.025 [V]
ITMY T240 2 DOF Z/W = -0.091 [V]
ITMY T240 3 DOF Y/V = -0.025 [V]
BS T240 1 DOF X/U = -0.077 [V]
BS T240 1 DOF Y/V = -0.167 [V]
BS T240 1 DOF Z/W = 0.188 [V]
BS T240 2 DOF X/U = -0.051 [V]
BS T240 2 DOF Y/V = 0.184 [V]
BS T240 2 DOF Z/W = -0.154 [V]
BS T240 3 DOF X/U = -0.004 [V]
BS T240 3 DOF Y/V = -0.223 [V]
BS T240 3 DOF Z/W = -0.274 [V]
Assessment complete.
Averaging Mass Centering channels for 10 [sec] ...
2018-08-06 15:19:49.359288
There are 1 STS proof masses out of range ( > 2.0 [V] )!
STS A DOF X/U = -8.121 [V]
All other proof masses are within range ( < 2.0 [V] ):
STS A DOF Y/V = -0.77 [V]
STS A DOF Z/W = -0.457 [V]
STS B DOF X/U = 0.404 [V]
STS B DOF Y/V = 0.343 [V]
STS B DOF Z/W = -0.356 [V]
STS C DOF X/U = 0.436 [V]
STS C DOF Y/V = -0.169 [V]
STS C DOF Z/W = 0.949 [V]
STS EX DOF X/U = -0.083 [V]
STS EX DOF Y/V = 0.488 [V]
STS EX DOF Z/W = 0.072 [V]
STS EY DOF X/U = 0.104 [V]
STS EY DOF Y/V = -0.045 [V]
STS EY DOF Z/W = 0.531 [V]
Assessment complete.
Visual inspection of the PSL chiller and filters found no problems or issues. The crystal chiller filter is a bit yellow but has not changed in color since the bypass valve was installed in early July. The diode chiller is clean and clear. Added 50ml water to crystal chiller. No water added to diode chiller. Closing FAMIS task #8311.
Last Friday, Niko and I performed TX module maintenance measurements on both EX and EY PCal systems. Primarily we were interested in the health of the aging lasers in the TX modules, which have been running continuously for both O1 and O2 as well as much of the time when we were not in observing runs. The stated expected lifetime of these lasers from the CrystaLaser website is >10000 hours. The duration of just O1 and O2 combined was ~10000 hours, so I would estimate these lasers have been running for more like 20000 hours. See attached photos of the log sheets for both ends stations. Comparing the laser output powers for both lasers from what was measured in the incoming inspection document (T1300100):
| SN | Incoming power as measured | Current power as measured | |
| EX | 01 | 2.05 W | 1.72 W |
| EY | 08 | 2.03 W | 1.94 W |
The EX laser appears to be degrading faster than EY and is at a level that we believe we should attempt to tune up the laser itself. Rick has instructions from CrystaLaser on how to do so, which we will attempt during an upcoming maintenance period.
We also took OLTF measurements of the OFS servo as per T1600436. We adjusted the gains to get the UGFs to be at 100kHz. Screen dumps of the SR785 traces also attached.
I turned the lasers off after these measurements to save some lifetime, but Rick suggested that we leave them on to stabilize and start producing baseline data. Today, I turned both EX and EY PCal lasers ON.
Summary: The epics channel H1:GRD-ISC_LOCK_STATE_N recorded at least one lockloss 1/4 of a second before the guardian log records entering that state. We are trying to investigate locklosses that we keep having while transitioning to the TR_CARM signal; there are a lot of things happening quickly, and we would like to understand the relative timing.
Details:
If i use the lockloss tool to plot the middle lockloss in this list:
2018-08-05_22:04:58Z ISC_LOCK LOCKING_ALS -> LOCKLOSS
2018-08-05_22:18:04Z ISC_LOCK START_TR_CARM -> LOCKLOSS_DRMI
2018-08-05_22:18:08Z ISC_LOCK ACQUIRE_DRMI_1F -> LOCKLOSS
the time listed in the title of the plot is 2018-08-05 22:18:04.69000UTC. The channel H1:GRD-ISC_LOCK_STATE_N goes to "LOCKLOSS_DRMI" (state 3) at time 0 in the plot.
However:
We can manually pull up the guardian log around the lockloss time (because the feature of the lockloss tool that used to do this for us doesn't work anymore). We see that the guardian log records itself entering the LOCKLOSS_DRMI state a quarter of a second later (2018-08-05_22:18:04.929352Z)
2018-08-05_22:18:01.409750Z ISC_LOCK new target: CARM_TO_TR
2018-08-05_22:18:01.411666Z ISC_LOCK executing state: START_TR_CARM (201)
2018-08-05_22:18:01.412065Z ISC_LOCK [START_TR_CARM.enter]
2018-08-05_22:18:01.671585Z ISC_LOCK [START_TR_CARM.main] ezca: H1:LSC-MCL => ON: FM3
2018-08-05_22:18:01.716869Z ISC_LOCK [START_TR_CARM.main] ezca: H1:ALS-C_COMM_PLL_BOOST => 0
2018-08-05_22:18:01.717531Z ISC_LOCK [START_TR_CARM.main] timer['wait'] = 2
2018-08-05_22:18:03.717666Z ISC_LOCK [START_TR_CARM.run] timer['wait'] done
2018-08-05_22:18:03.796693Z ISC_LOCK [START_TR_CARM.run] ezca: H1:ALS-C_COMM_VCO_CONTROLS_ENABLE => 0
2018-08-05_22:18:03.797668Z ISC_LOCK [START_TR_CARM.run] ezca: H1:ALS-C_REFL_DC_BIAS_GAIN => 24
2018-08-05_22:18:03.798400Z ISC_LOCK [START_TR_CARM.run] timer['wait'] = 2
2018-08-05_22:18:04.828452Z ISC_LOCK JUMP target: LOCKLOSS_DRMI
2018-08-05_22:18:04.830722Z ISC_LOCK [START_TR_CARM.exit]
2018-08-05_22:18:04.922221Z ISC_LOCK JUMP: START_TR_CARM->LOCKLOSS_DRMI
2018-08-05_22:18:04.922822Z ISC_LOCK calculating path: LOCKLOSS_DRMI->CARM_5_PICOMETERS
2018-08-05_22:18:04.923199Z ISC_LOCK new target: ACQUIRE_DRMI_1F
2018-08-05_22:18:04.929352Z ISC_LOCK executing state: LOCKLOSS_DRMI (3)
2018-08-05_22:18:04.929352Z ISC_LOCK [LOCKLOSS_DRMI.enter]
I have verified the system time on h1guardian1 is correct
david.barker@CDSADMIN!! ssh root@h1guardian1 date +"%T.%N";date +"%T.%N"
10:14:37.515521821
10:14:37.517143842
I trended the STATE_N and the exec time, expecting the exec time to have increased around the lock loss. Oddly, it was 0 around the time that STATE_N changed values. Dead end.
Then I looked at other jump transitions. What Sheila posted above seems to be the norm. The STATE_N channel will change first before there is any info in the log about the jump.
If we look at this jump transition below, the node gets a new target on the second line and then registers it as a jump in the third. The gps time of line 2 is 1217633455.83, but when I pulled the data, the gps time of the STATE_N transition to ALIGN_RECYCLING_MIRRORS (99) is at 1217633455.75. About a tenth of a second before we start to see anything on the log about this state. This matches with Sheila's example above, it registers the jump target in the log about a tenth of a second after the STATE_N value changed. The process must just take this long to exit the current state, calculate the new path in the graph, and then begin to start running the next state.
2018-08-06_23:30:37.828905Z ISC_LOCK calculating path: ACQUIRE_PRMI->ACQUIRE_DRMI_1F
2018-08-06_23:30:37.836971Z ISC_LOCK new target: ALIGN_RECYCLING_MIRRORS
2018-08-06_23:30:37.905879Z ISC_LOCK JUMP target: ALIGN_RECYCLING_MIRRORS
2018-08-06_23:30:37.914834Z ISC_LOCK [ACQUIRE_PRMI.exit]
2018-08-06_23:30:37.941559Z ISC_LOCK JUMP: ACQUIRE_PRMI->ALIGN_RECYCLING_MIRRORS
2018-08-06_23:30:37.959656Z ISC_LOCK calculating path: ALIGN_RECYCLING_MIRRORS->ACQUIRE_DRMI_1F
2018-08-06_23:30:37.971022Z ISC_LOCK new target: ACQUIRE_DRMI_1F
2018-08-06_23:30:37.985272Z ISC_LOCK executing state: ALIGN_RECYCLING_MIRRORS (99)
2018-08-06_23:30:37.986421Z ISC_LOCK [ALIGN_RECYCLING_MIRRORS.enter]
So, this is normal (for ISC_LOCK at least, I haven't checked on other nodes yet). I don't know if we need it to be much faster, but it may be something that we have to keep in mind.
I'm trying to understand the timing of the events inside of guardian (a 1/4 second is definitely a bit of a discrepency), but I'm curious why this timing issue is of such concern.
The EPICS time stamp as seen at the time of the event I believe is set by the system clock on h1guardian1. The time stamp recorded in the data for the transition might be set by the DAQD EDCU. We should confirm with Jonathan and Dave. The logs are time stamped when they are processed by the journald on h1guardian1.
While the setting of the STATE channels and the emission of the log that you're looking at happen adjacent to each other in the code, they're definitely not guaranteed to end up with the same timestamp, since there's various other variables at play. 1/4 second does seems pretty different, though, I agree, so I will try to investigate what's causing the relative timing slop.
But I'm puzzled why this is of such concern. Is it just about wanting to know which time is more authoritative? I would just use either as a guide to look at the real-time data as recorded via DAQD. If you're worried about when exactly a slow channel actuated by guardian changed, look at the record of the slow channel directly. But please do help me understand what the ultimate concern is so that I can know how to help.
Daniel, Haocun, Sheila, Nutsinee
Good news:
1) SQZ pump laser-to-PSL locking (with TTFSS) recovered. The alignment seems to have drifted over the past couple of months (probably since I left last time). With a bit of a tweak the beat note is back to -8dB. One of the beams was clearly larger and fuzzier than the other (I think this was the pick off beam from the pump laser, not the PSL). To get much more out of it we'd have to come up with a new mode matching solution.
2) OPO IS LOCKED! We feed the signal from fast path out of the common mode board to a VCO that's connected to LO input of the TTFSS. The signal from slow path now goes to OPO PZT1. We were afraid that VCO may not have enough range (it probably would have done just fine without). The loop hasn't been characterized or optimized yet.
Not so good news:
OPO scan looked funny on green. The transmission would peak up (or dip down on the refl) and then suddenly dropped (see attachment 3). So the trans, refl, error signal scans looked very asymmetry. This asymmetry also depended on whether you are ramping the PZT up or down (0-100V or 100V back to 0, sharp drops can happen on the left or the right of the peak). When the power was low enough this asymmetry disappeared (see attachment 1). The asymmetry started to show at 3mW green input to the fiber coupler on ISCT6. An idea we have (well, Daniel's idea) for what could have caused this was that the green heats up the crystal, increase the cavity length, and because the PZT would either increase for decrease the length of the cavity, we may have a sudden drop when the PZT is working against the crystal (in terms of getting the resonance) and suddenly cut the resonance short. This idea can be easily tested once we have red and green resonances lined up by tweaking the crystal temperature (next week to-do list). If the sharp drop was due to the temperature once the red resonance is overlapped with green we should see the cut off in red as well.
Note: I have a temporary set up on SQZT6 to look at the seed trans on the temporary thorlabs diode (I think this was a PD100A) and the camera. This set up was for the dual-resonance adjustment next week. Please do not disassemble.
Attachment:
#1 OPO green scan given 1mW input to the fiber coupler on the ISCT6
#2 OPO green scan given 3mW input to the fiber coupler on the ISCT6
#3 OPO green scan given 13 mW input to the fiber coupler on the ISCT6
#4 OPO seed scan given 2mW input to the fiber coupler on the ISCT6
#5 OPO locked on (pump) 00
The hypothesis that the green absorption/crystal temperature causes the assymetry in the scan can also be tested by changing the scan rate. (The rate at which the green absorption changes the cavity length should be mostly independent of the scan rate. Haocun effectively did this test by moving the PZT offset slowly by hand to try to get the OPO to sit on resonance. I think that when she did this the transmitted power dropped off about as suddenly as during a PZT scan, but it might be worth a more careful test to compare the timing.
Haocun, Sheila, Nutsinee
We moved the crystal temperature such that red and green are co-resonance but had no nlg effect. Red resonance seemed to be cut short as well. We begin to believe this crystal heating theory now. Haocun is working on this length<->temperature model hoping to explain what we're seeing here.