RTFE. Where did the spares go?
I began setting up the host server, but immediately hit a problem: We seem to have no more memory cards or solid-state drives, despite having two more SuperMicro servers. I ordered enough RAM cards and drives to finish both machines. They will hopefully arrive tomorrow.
There was no light entering the IFO. I worked on a few things to bring the interferometer to a somewhat usable state. The goal is to get back to PRFPMI locking ASAP.
Problem: All fast models report a "0x4000" DC error. See Attachment #1.
Solution: I think this is a "known" issue that happened last new year too. The fix was to add a hard-coded 1 second offset to the daqd config files. However, incrementing/decreasing this offset by +/- 1 second did not fix the errors for me today. I'll reach out to JH for more troubleshooting tips.
Update 15 Jan 2020 830am: The problem is now fixed. See here.
Problem: c1susaux and c1auxey were unresponsive.
Solution: Keyed c1auxey. Rebooted c1susaux and as usual, manually started the eth0/eth1 subnets. The Acromag crate did not have to be power-cycled. ITMY got stuck in this process - I released it using the usual bias jiggling. Why did c1susaux fail? When did it fail? Was there some un-elogged cable jiggling in that part of the lab?
Problem: IMC autolocker and FSS slow processes aren't running on megatron after the upgrade.
Solution: Since no one bothered to do this, I setup systemd infrastructure for doing this on megatron. To run these, you do:
and to check their status, use:
The systemd setup is currently done in a naive way (using the bash executable to run a series of commands rather than using the systemd infrastructure itself to setup variables etc) but it works. I confirmed that the autolocker can re-acquire IMC lock, and that the FSS loop only runs when the IMC is locked. I also removed the obsolete messages printed to megatron's console (by editing /etc/motd) on ssh-login, advising the usage of initctl - the updated message reflects the above instructions.
In order to do the IMC locking, I changed the DC voltage to the AOM to +1V DC (it was +0.8 V DC). In this setting, the IMC refl level is ~3.6 V DC. When using the undiffracted AOM beam, we had more like +5.6 V DC (so now we have ~65% of the nominal level) from the IMC REFL PD when the IMC was unlocked. IIRC, the diffraction efficiency of the AOM should be somewhat better, at ~85%. Needs investigation, or better yet, let's just go back to the old configuration of using the undiffracted beam.
There was also an UN-ELOGGED change of the nominal value of the PMC servo gain to 12.8, and no transfer function measurement. There needs to be a proper characterization of this loop done to decide what the new nominal value should be.
I'm going to leave the PSL shutter open and let the IMC stay locked for stability investigations. Tomorrow, I'll check the single-arm locking and the ALS system.
Every new year (on Dec 31 or Jan 1), all of the realtime models will report a "0x4000" error. This happens due to an offset to the GPStime driver not being updated. Here is how this can be fixed (slightly modified version of what was done at LASTI).
Steps to fix the DC errors:
/* 2019 had 365 days and no leap seconds */
pHardware->gpsOffset += 31536000;
/* 2019 had 365 days and no leap seconds */
pHardware->gpsOffset += 31536000;
sudo make install
sudo systemctl daqd_* stop
sudo modprobe -r symmetricom
sudo modprobe symmetricom
sudo service daqd_* start
Independent of this, there is a 1 second offset between the gpstimes reported by /proc/gps and gpstime. However, this doesn't seem to drift. We had effected a static offset to correct for this in the daqd config files, and it looks like these do not need to be updated on a yearly basis. All the daqd indicators are now green, see Attachment #1.
Single arm locking using POX and POY has been restored. After running the dither alignment servos, the TRX/TRY levels are ~0.7. This is consistent with the IMC transmission being ~11000 counts with the AOM 1st order diffracted beam (c.f. 15000 counts with the undiffracted beam).
Tomorrow, I'll check the single-arm locking and the ALS system.
I don't think this is an accurate statement. XT1111 modules have sinking digital outputs, while XT1121 modules have sourcing digital outputs. Depending on the requirement, the appropriate units should be used. I believe the XT1111 is the appropriate choice for most of our circuits.
For digital outputs, one should XT1121. XT1111 should be used for digital inputs.
For the ringdowns, I suggest you replicate the setup I had - infrastructurally, this was quite robust, and the main problem I had was that I couldn't extinguish the beam completely. Now that we have the 1st order beam, it should be easy.
Per Yehonathan's request, I removed one PDA10CF from a pickoff of REFL on the AS table (it was being used for the mode spectroscopy project). I placed a razor beam dump where the PD used to be, so that when the PRM is aligned, this pickoff is dumped. This is so that team ringdowns can use a fast PD.
The measurements are consistent with the specifications, and there is no evidence of compression at any of the power levels we expect to supply to this box (<0dBm).
These "gain blocks" were acquired for the purpose of amplifying the IR ALS beat signals before transmission to the LSC rack for demodulation. The existing ZHL-3A amplifiers have a little too much gain, since our revamp to use IR light to generate the ALS beat.
Attachment #4: Setups used to measure transfer functions and noise.
For the transfer function measurement, I chose to send the output of the amplifier to a coupler, and measured the coupled port (output port of the coupler was terminated with 50 ohms). This was to avoid saturating the input of the AG4395. The "THRU" calibration feature of the AG4395 was used to remove the effect of cabling, coupler etc, so that the measurement is a true reflection of the transfer function of OUT/IN of this box. Yet, there are some periodic ripples present in the measured gain, though the size of these ripples is smaller than the spec-ed gain flatness of <0.6dB.
For the noise measurement, the plots I've presented in Attachment #3 are scaled by a factor of sqrt(2) since the noise of the ZFL-500-HLN+ and the ZHL-1010+ are nearly identical according to the specification. Note that the output noise measured was divided by the (measured) gain of the ZFL-500-HLN+ and the ZFL-1010+ to get the input referred noise. The trace labelled "Measurement noise floor" was measured with the input to the ZFL-500-HLN+ terminated with 50ohms, while for the other two traces, the inputs of the ZHL-1010+ were terminated with 50ohms.
Raw data in Attachment #5.
I will install these at the next opportunity, so that we can get rid of the many attenuators in this path (the main difficulty will be sourcing the required +12V DC for operation, we only have +15V available near the PSL table).
Note that for all the alignment work, only the two steering mirrors immediately upstream of the PMC cavity were touched.
For a few days, I've noticed that the PSL overview StripTool panel shows PMC transmission and FSS RMTEMP channels with variation that is too large to be believable. Looking at these signals on an oscilloscope, there was no such fuzziness in the waveform. I ruled out flaky connections, and while these are the only two channels currently being acquired by the temporary Acromag setup underneath the PSL enclosure, the Acromags themselves are not to blame, because once I connected a function generator to the Acromag instead of the PMC transmission photodiode, both channels are well behaved. So the problem seems to be with the PMC transmission photodiode, perhaps a grouding issue? Someone please fix this.
The PDH discriminant of the PMC servo was measured to be ~0.064 GV/m. This is ~50 times lower than what is reported here. Perhaps this is a signature of the infamous ERA decay, needs more investigation.
The light level hasn't changed by a factor of 50, leading me to suspect the modulation depth. Recall that the demodulation of the PMC is now done off the servo board using a minicircuits mixer (hence, the "C1:PSL-PMC_LODET" channel isn't a reliable readback of the LO signal strength over time). Although there is a C1:PSL-PMC_MODET channel which looks like it comes from the crystal reference card, and so should still work - this, however, shows no degradation over 1 year.
Somebody had removed the BLP-1.9 that I installed at the I/F output of the mixer to remove the sum frequency component in the demodulated signal, I reinstalled this. I find that there are oscillations in the error signal if the PMC servo gain is increased above 14.5 on the MEDM slider.
I looked into this a little more today.
Currently, the iris is set up such that the stronger beam makes it to the PMC RFPD, while the weaker one is blocked by the iris. As usual, this isn't a new issue - was noted last in 2014, but who knows whether the new window was intalled...
Today I noticed that the beam reflected from the PMC into the RFPD has a ghost (attachment) due to reflection from the back of the high transmission beam splitter that stirs the beam into the RFPD.
I estimate the PMC servo modulation depth to be approximately 50 mrad. This is only 15% lower than what was measured in Jan 2018, and cannot explain the ~x50 reduction of optical gain measured earlier in this thread. Later in the day, I also confirmed that the LO input to the ZAD-6 mixer is +7 dBm. So the crystal is not to blame.
Assuming a finesse of 700 for the PMC, we expect an optical gain of 2*Pin*J0(50e-3)*J1(50e-3)/fp ~ 1.2e-7 W/Hz (=0.089 GW/m). I can't find a measurement of the PMC RFPD transimpedance to map this onto a V/Hz value.
upgrade was done
cronjob testing wasn't one by one 😢
burt snapshots were gone
i brought them back home 🏠
Megatron is now running Ubuntu 18.04 LTS.
The mixer + LPF combo used to demodulate the PMC PDH error signal seems to work as advertised.
Measurement setup --- Attachment #1. The IF signal was monitored using the scope in High-Z mode.
Results --- Attachment #2.
So the next step is to characterize the RF transimpedance of the PMC RFPD.
The AD602 chip which implements the overall servo gain for the PMC seems to be damaged. We should switch this out at the next opportunity.
I will pull the board and effect the change later today.
I pulled the board out at 345pm after dialling down all the HV supplies in 1X1. I will reinstall it after running some tests.
The burt snapshotting is still not so reliable - for whatever reason, the number of snapshot files that actually get written looks random. For example, the 14:19 backup today got all the snaps, but 15:19 did not. There are no obvious red flags in either the cron job logs or the autoburt log files. I also don't see any clues when I run the script in a shell. It'll be good if someone can take a look at this.
The RF transimpedance of the PMC PDH RFPD was measured, and found to be 1.03 kV/A.
With the new fiber coupled PDFR system, it was very easy to measure the response of this PD in-situ 🎉 . The usual transfer function measurement scheme was used, with the AG4395 RF out modulating the pump current of the diode laser, and the measured transfer function being the ratio of the response of the test PD to the reference PD.
I assume that the amount of light incident on the reference NF1611 photodiode and the test photodiode were equal - I don't know what the DC transimpedance of the PMC REFL photodiode is (can't find a schematic), but the DC voltage at the DC monitor point was 16.4 mV (c.f. -2.04 V for the NF1611). The assumption shouldn't be too crazy because assuming the reference PD has an RF transimpedance of 700 V/A (flat in the frequency range scanned), we get a reasonable shape for the PMC REFL photodiode's transimpedance.
The fitted parameters are overlaid in Attachment #1. The 2f notch is slightly mistuned it would appear, the ratio of transimpedance at f1/2*f1 is only ~10. The source files have been uploaded to the wiki.
Knowing this, the measured PDH discriminant of 0.064 GV/m is quite reasonable:
So why is this value so different from what Koji measured in 2015? Because the monitor point is different. I am monitoring the discriminant immediately after the mixer, whereas Koji was using the front panel monitor. The latter already amplifies the signal by a factor of x101 (see U2 in schematic).
I still haven't found anything that is obviously wrong in this system (apart from the slight nonlinearity in the VGA stage gain steps), which would explain why the PMC servo gain has to be lower now than 2018 in order to realize the same loop UGF.
While I have the board out, I'll try and do a thorough investigation of TFs and noise of the various stages. There is no light into the IFO until this is done.
The PMC servo was re-installed at ~345pm. HV supplies were re-energized to their nominal values. I will update the results of the investigation shortly. The new nominal PMC servo gain is +9dB.
Jordan will write up the detailed elog but in summary,
Looks like a M=4.6 earthquate in Barstow,CA tripped all the suspensions. ITMX got stuck. I restored the local damping on all the suspensions just now, and freed ITMX. Looks like all the suspensions damp okay, so I think we didn't suffer any lasting damage. IMC was re-aligned and is now locked.
To avoid driving the PA85 without the HV rails connected, I removed R23. This was re-installed after my characterization.
Since we do the demodulation of the PMC PDH signal off this servo board, the I/F mixer output is connected to the "FP1test" front panel LEMO input.
Using some Pomona mini-grabbers, I measured the electronic TFs between various points on the circuit. There were no unexpected features, the TFs all have the expected shape as per the annotations on the DCC schematic. I did not measure down to 0.1 Hz to confirm the low frequency pole implemented by U6, and I also didn't measure the RF low pass filter at the input stage (expected corner frequency is 1 MHz).
After replacing the IC, I measured the transfer function between TP1 and TP2 for various values of the control voltage applied to pin 4A on the P1 connector, varying between +/- 5 V DC.
PZT Capacitance measurement
I confirmed that the PZT capacitance is 225 nF. The measurement was made using an LCR meter connected to the BNC cable delivering the HV to the PZT, at the 1X1 rack end.
After re-soldering R23, I put the board back into its Eurocrate, and was able to lock the PMC. For subsequent measurements, the PSL shutter was closed.
In preparation for resuming IFO locking activities, I measured the ALS noise with the arm lengths locked to IR, AUX laser frequencies locked to the arm lengths. Looks promising (y-axis units are Hz/rtHz).
I've also been noticing that the IMC Autolocker scripts are running rather sluggishly on Megatron recently. Some evidence - on Feb 11 2019, the time between the mcup script starting and finishing is ~10 seconds (I don't post the raw log output here to keep the elog short). However, post upgrade, the mean time is more like ~45-50 seconds. Rana mentioned he didn't install any of the modern LIGO software tools post upgrade, so maybe we are using some ancient EPICS binaries. I suspect the cron job for the burt snapshot is also just timing out due to the high latency in channel access. Rana is doing the software install on the new rossa, and once he verifies things are working, we will try implementing the same solution on megatron. The machine is an old Sun Microsystems one, but the system diagnostics don't signal any CPU timeouts or memory overflows, so I'm thinking the problem is software related...
It's fine to block the WFS while doing ringdowns but please return the config to normal so I don't have to spend time every night recovering the interferometer before doing the locking. As I mention in that post, it is possible to do this in a non-invasive way without having to run any extra cables / permanently block any beams. If there is some issue with the data quality, then we can consider a new setup. But I see no reason to re-invent the wheel.
The IMC was also massively misaligned. I had to re-align both MC1 and MC2 to recover the lock. I took this opportunity to reset the WFS offsets. Please do not disturb the alignment of the existing optical layout unless you verify that everything is working as it should be after your changes.
And for whatever reason, ITMX was misaligned. If you do something with the interferometer, no matter how minor it seems, please leave a note on the ELOG. It will save many painful debugging hours.
As I fix these, the seismic activity has gone up . I'll wait around for an hour, but not an encouraging restart to the locking 😢
Zeroth order IMC ringdown
Following Gautam's IMC ringdown setup, I took the the REFL PD form the PMC ringdown experiment and installed it in the IMC REFL path blocking WFS2 (Attachment 1).
To conclude my PMC noise investigations: Attachment #1 shows the PMC noise inferred from the calibrations earlier in this thread and the fitted OLTF for the PMC loop. Attachment #2 compares the frequency noise (inferred from the error point of the PMC servo) when the IMC is locked / unlocked. I don't know what to make of the fact that the PMC suggests improvement from ~20 Hz onwards already - does this mean that the NPRO noise model is wrong by 1 order of magnitude at 30 Hz?
While I initially thought the 1/f^2 rise below ~100 Hz is attributable to the IMC cavity length fluctuations, I found that this profile is present even in the measurement with the PSL shutter closed. I am not embarking on a detailed PMC noise budgeting project for now. Note however that we are not shot noise limited anywhere in this measurement band.
There were a bunch of medm processes stalled on megatron (connected with screenshot taking). To see if they were interfering with the other scripts, I killed all of the medm processes, and commented out the line in the crontab that runs the screenshots every 10 mins. Let's see if this improves stability.
With all of the shaking (man-made and divine), it was a hard to debug this problem. Summary of fixes:
At least the DC indicators are telling me that the IMC locking is back to a somewhat stable state. I have not yet checked the frequency noise / RIN.
We found that the caput commands were taking much longer to execute on megatron than on pianosa (for example). Suspecting that this had something to do with the fact that megatron was using EPICS binaries from the shared NFS drive which were compiled for a much older OS, I installed the latest stable release of EPICS on megatron. The new caput commands execute much faster. I also added the local EPICS directory to the head of the $PATH variable used by the MC autolocker and FSS Slow scripts, so that they use the new caput command. But mcup is still slow - maybe my new path definition isn't picked up and it is still using the NFS binaries? To be looked into...
To fix the apparent slowness of execution of the caput commands on megatron, I changed the "ewrite" macro in the mcup and mcdown scripts to use ezcawrite instead of caput. The old lines are simply commented out, and can be reverted to at any point if we so desire. After these changes, we saw that both scripts complete execution much faster.
The goal tonight was to go through the locking scripts to see if I could recover the state from November 2019, when I could have the arm lengths controlled by ALS, and sit at zero CARM offset with the PRMI remaining locked and the arm powers fluctuating between 0-300. The IR-->ALS transitions went smoothly tonight, and the PRMI locking was also fairly robust when the CARM offset was large, but was less good when reduced to 0. Nevertheless, it is good to know that the system can be restored to the state it was late last year. Next step is to figure out how to keep the PRMI locked and get the AO path engaged, this was what I was struggling with before the new year.
You can trend the data for the past few hours and see what the appropriate value. I think these tests should only be done when whoever is running a test is in the lab.
P.S. I was surprised that the IMC didn't lose lock when this step was applied. I manually stepped this voltage between +/- 10 V and didn't see any response in the FSS readbacks. Either the channel doesn't work, or there is a divide by 40 in the physical circuit or something...
A script I was testing errantly set C1:PSL-FSS_INOFFSET => 10 V at about 5:30 pm. I manually reverted the channel value to 0, but I don't know what the value was initially. Someone please check this value if there are problems locking the FSS.
One factor which hampers locking efforts is the apparent drift of the input beam into the IFO. Over timescales of ~1 hour, I have noticed that the spot on the AS camera drifts significantly (~1 spot size) in pitch. The IPPOS QPD bears out this observation, see Attachment #1. The IMC WFS control signals do not show a correlated drift, hence my claim that the TTs are to blame.
I am able to correct this misalignment by moving TT1 in pitch (see Attachment #2, which shows some signals from a ~1 hour PRMI lock, during which time the pointing drifted, and I corrected it by moving TT1 pitch). Assuming the problem is purely TT1 pitch drifting, this corresponds to 3mm / 6m ~500urad of shift in 1 hour - seems very large. The fact that the drift is only present in pitch and doesn't really show up in yaw makes me think the problem is likely mechanical (unless the voltage to the top two coils is drifting relative to the bottom, but no LR drift, which would be very coincidental). At the moment, this is just an annoyance, but it'd be good for this problem to be fixed.
I haven't yet figured out how to make ndscope export these plots to SVG preserving the dark color theme, hence the weird light axes...
Jon brought over a box of parts for constructing the metal PMCs. I have stored it along the Y-arm, on top of the green optics cabinet.
I didn't do an exhaustive inventory check, but the following are the rough contents of the box:
I didn't inspect the optics but since we have so many, I am hoping we can find 3 good quality ones for one cavity at least. We should check that the geometry is suitable for our RF sideband frequencies.
The CARM-->RF transition remains out of reach. No systematic diagnosis scheme comes to mind.
TBC. Mercifully at least the shaker stayed still tonight.
The goal is to try and identify the source of the excess ALS noise as the CARM offset is reduced. The idea is to look at the MC_F spectrum (or the IMC error point) in a few conditions:
#1 vs #2 is like a control experiment, we expect to see the excess noise imprinted on the MC length and hence in MC_F (provided the sensing noise is low enough). #2 vs #3 will be informative of something like backscatter to the PSL increasing the frequency noise. #2/3 vs #4 will help isolate the problem to an individual arm's AUX PDH loop or some optomechanical effect.
I was looking back at some spectra from the last couple of nights but I don't really have an apple-to-apple comparison in the various actuation schemes (some ALS loops were engaged/disengaged), so I'll do a more systematic test tonight. Already, it looks like MC_F is not a good candidate to look for the excess frequency noise, I don't really see a big difference between conditions #1 and #2. According to this, we are looking for an increase at the level of a few 100Hz/rtHz @ ~40 Hz, wheras MC_F is much noisier.
I did some more detailed tests to see if I could isolate where the excess ALS noise at low CARM offset is coming from, by measuring the spectrum of the IMC error point (in loop). The results, shown in Attachment #1 and #2, are inconclusive.
Since MC_F didn't show any signatures of elevated noise, I decided to hook up an SR785 to the A excitation bank TEST1 input of the IMC servo board to monitor the in-loop error signal. I initially took a few measurements spanning 800 Hz in frequency, and to my surprise, I found that there was elevated noise in the frequency band we see an increase in the ALS noise, even when the CARM feedback goes to the ETMs (so the IMC cavity is in principle isolated from the main interferometer). This is Attachment #1. So I re-took a couple of measurements (this time only for the case of CARM feedback to the ETMs), with a 200 Hz frequency span, and found no significant noise elevation. This is Attachment #2. I am led to conclude that the IMC error point level changes over time for reasons other than the CARM offset - it'd be nice to have a spectrogram of the IMC error point and compare excursions relative to the median level over a few 10s of minutes, but we don't have this data stream digitized by the CDS system - maybe I will hijack the MC_L channel temporarily to record this data stream. It seems a waste that we're not able to take full advantage of the measured <10pm RMS noise of the IR ALS system.
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.
Plots + interpretation tomorrow.
Getting closer... To facilitate this work, I made some convenience scripts that can be run from the CM MEDM screen.
To study the evilution of the AO path TFs a bit more, I've hooked up POY11_Q Mon to IN1 of the CM board. I will revert the usual setup later in the evening.
Update 1730: I've returned the cabling at 1Y2 to the nominal config, and also reverted all EPICS settings that I modified for this test. Y-arm POY locking works. Attachment #1 shows the summary of the results of this test - note that the AO gain was kept fixed at +5dB throughout the test. I have arbitrarily trimmed the length of the frequency vector for some of these traces so that the noisy measurement doesn't impede visual interpretation of the plots so much. At first glance, the performance is as advertised. I basically followed the settings I had here to get started, and then ramped up various gains to check if the measured OLTF evolved in the way that I expected it to. The phase lead due to the AO path is clearly visible.
Some important differences between this test and the REFL11 blending is (i) in the latter case, there will also be a parallel loop, CARM_A, which is effecting some control, and (ii) the optical gain of CARM-->REFL11_I is much higher than L_Y-->POY. So the initial gain settings will have to be different. But I hope to get some insight into what the correct settings should be from this test. I think IMC servo IN2 gain and AO gain slider on the CM board are degenerate in the effect they have, modulo subtle effects like saturation.
One possibility is that the gain allocation I used yesterday was wrong for the dynamic range of the CARM error signal. In some initial trials today, when I set the CM board IN1 gain to -32dB (as in the case of attempting the CARM RF handoff) and compensated for the reduced POY PDH fringe amplitude by increasing the digital gain for the CM_Slow path, I found that there was no phase advance visible even when I ramped up the IMC IN2 gain to +10dB. So, for the CARM handoff too, I might have to start with a higher CM board IN_1 gain, compensate by reducing the CM_Slow digital gain even more, and then try upping the IMC IN2 gain.
P.S. When the excitation input to the CM board was enabled in order to make TF measurements, I saw significant increase in the RMS of the error signal. Probably some kind of ground loop issue.
I found the PMC unlocked this morning. It was re-locked using the usual procedure. I feel like this has been happening more frequently in the last month than before. In the past, the cause seems to have been the PZT voltage drifting too close to one of the rails - however, in this case, it looks like an IMC unlock event is what triggered the PMC lockloss (admittedly the PZT voltage was somewhat close to the rail). It would be good if someone can re-connect the PMC Transmission photodiode, it was a useful diagnostic channel we had working fine before the ringdowns started.
I also tweaked the input pointing into the PMC and ran the WFS DC offset relief script.
Over the last couple of days, I've been trying to see if I can measure the phase advance due to the AO path - however, I've been unable to do so for any combination of CM board IN1 gain and MC Servo board IN2 gain I've tried. Yesterday, I tried to understand the loop shapes I was measuring a little more, and already, I think I can't explain some features.
Attachment #1 shows the TF measured (using SR785, and the EXC_A bank of the CM board) when the CM Slow path has been engaged.
Attachment #2 shows error signal spectra for the in-loop PRFPMI DoFs, for a few different conditions.
I believe that a stable crossover is hopeless under these conditions.
A few years ago, Koji and I setup a delay line phase shifter, which can be used to impart a (switchable) delay to a signal path. Since we talked about reviving the fast (= high bandwidth) ALS control scheme at the meeting, I reminded myself of the infrastructure available.
For a beat note in the regime 10-100 MHz, we should have plenty of range in this module to add a delay such that we zero one quadrature of the ALS DFD output (for a linear error signal).
I then proceeded to connect the single-ended front panel BNC corresponding to the ALS_X_I DFD channel to the IN2 input of the CM board (this would be what we use for high bandwidth ALS feedback). The conventional ALS system uses the differential output from a rear-panel D-sub, so in principle, both systems could run in parallel. I confirmed that I could see a signal when the IN2 path on the CM board was engaged (monitored using ndscope at the CM_Slow output), and that this signal stabilized when the green laser was locked to the X-arm length, which itself was slaved to the PSL frequency using the usual POX locking scheme. I have not yet routed the LO leg of the ALS_X beat through the delay line phase shifter - see next elog for details.
Update about the ALS MEDM screen slider: the trick was to change the OMSL field of the C1:LSC-BO_1_0 channel to "closed_loop" instead of "supervisory". Once this is done, the DOL value of the same channel can be set to the soft channel C1:ALS-DelayCalc, which sets the 16 bit binary string that controls the delay. Because arbitrary delays are not possible, I think it's more natural for the user to interact with this 16-bit binary string rather than the actual delay itself. So the MEDM screen has been slightly modified from what is shown in Attachment #1.
I measured the transfer function of the AO path, and think that there are some features indicative of a problem somewhere in the IMC locking loop.
Regardless of the locking scheme used, high bandwidth control of the laser frequency relies on the fact that the laser frequency is slaved to the IMC cavity length with nearly zero error below ~50 kHz (assuming the IMC loop has a UGF > 100 kHz). In my single arm experiments, I didn't know what to make of the ripples that became apparent in the measured OLTF as the AO gain was ramped up.
Tonight, I measured the TF of the "AO path", which modifies the error point of the IMC, thereby changing the laser frequency.
Attachment #1 shows the result of the measurement.
I didn't use POX / POY as a sensor to confirm that this is real frequency noise, I will do so tomorrow. But it may be that realizing a stable crossover is difficult with so many features in the AO path.
Previous thread with a somewhat detailed characterization of the IMC loop electronics.
In the process of setting up some cabling at 1Y2, I must've bumped a cable to the c1lsc expansion chassis. Anyways, the c1lsc models crashed. I ran the reboot script around 530pm PDT. Usual locking behavior was recovered after this. The work at 1Y2 was:
The IN2 to CM board was already connected to I single ended output of the ALS X demodulator. The ~100 Hz UGF digital locking using the CM_SLOW path is straightforward but I didn't have any success with the AO path tonight. I wonder how high BW this lock can be made without injecting a ton of noise into the IMC loop, given that the EX uPDH only has ~ 10 kHz UGF.
Attachment #1 shows the spectra of the ALS signal
Attachment #2 is an OLTF measurement.
Unlikely, the alignment was probably just not good. I restored the alignment and now the arms can be locked to IR frequency.
Even though we were not able to lock the the IR beat (by enabling LSC) during the day possibly because of increased seismic activity
Today, I did the following tests (and so was touching electronics/cables at/around 1X2):
Results to follow.
After this work, I reverted the EPICS channels to the usual values. The IMC can be locked.
The quantum noise curves here are not correct. c.f. amplitude quadrature noise budget.
In the style of the KA characterization of the CM board, the AO path gain EPICS slider (IN2) of the IMC servo board was stepped by 1 dB through the full available range of -32 dB to +31 dB. For each value of the requested gain, I measured the TF from the injected signal (to IN2) to TP1A on the IMC servo board. I used the BNC connector for this test, whereas we use the LEMO connector for the AO path. The source was tee-d off at the SR785 side, with one leg going to IN2 of the IMC servo board, and the other going to CH1A of the SR785. TP1A of the IMC board was connected to CH2A of the SR785.
Attachment #1 - Measured gain vs requested gain.
Attachment #2 - Frequency dependent transfer functions
The motivation here is to try and figure out why I cannot engage the AO path smoothly in the CARM handoff part of lock acquisiton. I plan to use this information to do some loop modeling and project laser frequency noise coupling in various stages of the lock acquisition process.