We expect that the MC sus are susceptible to the temperature change and the alignment drifts away with time.
Here is the proper alignment procedure.
0) Assume there is no TEM00 flash or locking, but the IMC is still flashing with higher-order modes.
1) Use the CCD camera and WFS DC spots to bring the beam to the nominal position.
2) Use only MC2 and MC3 to align the cavity to have low-order modes (TEM00,01,02 etc)
3) You should be able to lock the cavity on one of these modes. Minimize the reflection (maximize the transmission) for that mode.
4) This should allow you to jump to a better lower-order mode. Continue alignment optimization only with MC2/3 until you get TEM00.
5) Optimize the TEM00 alignment only with MC2/3
6) Look at the MC end QPD. use one of the scripts in scripts/MC/moveMC2 . Note that the spot moves opposite to the name of the scripts. i.e. MC2_spot_down moves the spot up, MC2_spot_right moved the spot left, etc...
These scripts move MC1/2/3 and try to keep the good MC transmission.
7) moveMC2 scripts are not perfect. As you use them, it makes the MC alignment gradually degraded. Use MC2 and MC3 to recover good transmission.
8) If MC2 spot is satisfactory, you are done.
Step 6-8 can be done with the WFS on. This way, you can skip step 7 as the WFS servo takes care of it. But if the spot move is too fast, the servo can't keep up with the change. If so, you have to wait for the settling of the servo. Once the spot position is satisfactory, MC servo relief should be run so that the servo offset (in actuation) can be offloaded to the bias slider.
I've added two curves to the NB. Both are measured (with FET preamp) at the output of the demod board, with the LO driven at the nominal level by the Wenzel RF source pickoff (as it would be when the IMC is locked) and the RF input connected to the IMC REFL PD. For one curve, I simply closed the PSL shutter, while for the other, I left the PSL shutter open, but macroscopically misaligned MC2 so that there was no IMC cavity. So barring RFAM, there should be no PDH signal on the REFL PD, but I wanted to have light on there. I'm not sure if I understand the difference between these two curves though, need to think on it. Perhaps the IMC REFL PD's optical/electrical response needs to be characterized?
Next curve to go on here is the demod board noise with the PSL shutter closed but the IMC REFL PD connected to the RF input (or maybe even better, have light on the PD, but macroscopically misalign MC2 so there is no 29.5MHz PDH signal), just to make sure there isn't anything funky going on there...
Since ~ 2 hours ago, the IMC autolocker has not been able to keep the IMC locked. I don't see any obvious trends in the wall StripTool that may point to what's going on. For the brief periods in which a TEM00 mode is locked, the PC Drive RMS level is ~5x what the nominal level is, and while the autolocker is trying to lock the IMC, the PC drive RMS level is hovering around 4V DC, which is high. The PMC Error and Control signal spectra show huge 60 Hz (and harmonics) peaks, and indeed this is visible in the time domain signals as well (on ndscope or on the oscilloscope on the PSL table), but this is not a new feature in the last two hours. Usually, this kind of problem signals that either/both the c1psl or c1iool0 slow machines need to be power-cycled, but I confirmed that both machines are online and telnet-able. Possibilities: (i) some card in the c1psl / c1ioo crates have failed or (ii) something in the MC/FSS electronics chain has failed or (iii) there is a huge amount of excess high-frequency noise from the NPRO.
I am leaving the PSL shutter closed.
WFS loops were running for past 2 hours when I made the overall gain slider zero at:
PDT: 2022-10-18 20:42:53.505256 PDT
UTC: 2022-10-19 03:42:53.505256 UTC
The output values are fixed to a good alignment. IMC transmission is about 14100 counts right now. I'll turn on the loop tomorrow morning. Data from tonight can be used for monitoing open loop noise.
Turning WFS loops back on at:
PDT: 2022-10-19 09:48:16.956979 PDT
UTC: 2022-10-19 16:48:16.956979 UTC
Overtime the coil output filters on IMC optics have drifted into a bad configuration. Today at the meeting, Rana told us the correct configuration for these filters. I'll summarize this here and we have changes the filters on all IMC optics, MC1, MC2, and MC3 to match this configurations:
Both MC1 and MC3 have a 28 Hz 5th order elliptical low pass filter as teh dewhitening filter in LIGO-D000316
At the coil output filters named as C1:SUS-MC1_ULCOIL, the filter module FM9 is connectd in RTCDS to the analog dewhitening filter such that only one of the two can remain ON. So For MC1 and MC3, we put a ellip("LowPass", 5, 1, 50, 28) filter on FM9 for all 5 coil output filters.
Note: We do not add a inverse dewhitening filter at FM10 like most other optics as inverting this filter will create resonant peaks at the dips of the elliptical filter which we want to avoid and we anyways do not use MC1 and MC3 optics for any kind of actuation above 20 Hz.
For MC2, the dewhitening filter is a 10 Hz pole, 30Hz zero like most other suspended optic.
At the coil output filters named as C1:SUS-MC2_ULCOIL, the filter module FM9 is connectd in RTCDS to the analog dewhitening filter such that only one of the two can remain ON. So For MC2 we put a SimDW filter which is matched to the anlog filter. We also put a InvDW filter on FM10, which is the analytical inverse of the SimDW filter. This filter does the anti-dewhitening required on the digital side and should be always ON.
To MC2 equivalent to other IMC optics in terms of overall transfer function for the local damping loops and ASC loops, we need additional 28 Hz elliptical low pass filter in these loops. But such a filter should not be in the path of LSC feedback when MC2 is used for locking CARM with a bandwidth of ~100 Hz. Thus, we put a ellip("LowPass", 5, 1, 50, 28) filter on FM6 of the following filters, which should be always ON as well:
With the above changes, we see that the 60 Hz noise is same as the previous levels when we use the analog dewhitening filter (28 Hz elliptical filter) for MC1. We can move forward with our science experiments with that configuration but there is still something fishy about MC1 in comparison to MC3 which does not have this behavior. So this still needs to be looked at in future.
Information of this kind should be stored in a wiki page in my opinion. We should have a page where we list all common filter configurations for our suspensions and other loops, that can be generally classified and is useful for understanding legacy configuration for future folks who work here. I'm starting such a wiki page here, where I'll dump more information as I collect it and get time. Everyone is encouraged to update this in there free/procrastination times.
Also reply to: 40m/16125
I migrated the code used in 40m/16125 to our scripts git repo and used it to apply offsets to IMC optics and noticing the parabolic change in the transmission values. Fitting the data with parabola and using the calculations mentioned in the previous post, we get following angular actuation calibration at DC from the PIT/YAW alignment output channels (cts) to actual motion in (urad):
*Note that in the previous post, the radius of curvature of MC2 used was wrong and has been corrected in this calculation to 17.87 m taken from Gautam's thesis Table A.1
Due to lack of time, we ran test faster on MC2, hence more uncertainty in it's results. Also, during MC1 YAW test, lock for breifly lost which required me to manually throw away some data points, but it did not affect the quality of fit much. Please see attached the data plots and fit.
For calibration at AC, another test needs to be performed which I did not do right now. 40m/16125 also describes how to do that, so someone can repeat that in future.
It would be good if someone can post here the actuation calibration in radians, so that we can have a physical calibration of the sensing matrix in counts/radian.
We came in this morning and noted the IMC was grossly misaligned, with MC3 still damped but with >= 100 rms motion in all coil monitors (a lot but not enough to trip the WD)... Turning off the WFS didn't do much so it was obviously an issue with the recent f2A output filters, so we turned all off (though only MC3 had this excess motion). After this we aligned IMC, engaged the lock and turned WFS back on.
There was no elog about f2A beyond this test scheduled to run Friday, I guess the filters were meant to stay on long term?
Two days ago I opened the PSL shutter by switching the switch on the shutter driver. That caused the shutter's switch on the medm screen to work in reversed mode: open meant closed and closed meant open.
I fixed that. Now the medm screen switch state is correct.
The IMC has been misbehaving for the last 5 hours. Why? I turned the WFS servos off. afaik, aaron was the last person to work on the IFO, so i'm not taking any further debugging steps so as to not disturb his setup.
That was likely me. I had recentered the beam on the PD I'm using for the armloss measurements, and I probably moved the wrong steering mirror. The transmission from MC2 is sent to a steering mirror that directs it to the MC2 transmission QPD; the transmission from this steering mirror I direct to the armloss MC QPD (the second is what I was trying to adjust).
Note: The MC2 trans QPD goes out to a cable that is labelled MC2 op lev. This confusion should be fixed.
I realigned the MC and recentered the beam on the QPD. Indeed the beam on MC2 QPD was up and left, and the lock was lost pretty quickly, possibly because the beam wasn't centered. Lock was unstable for a while, and I rebooted C1PSL once during this process because the slow machine was unresponsive.
When tweaking the alignment near MC2, take care not to bump the table, as this also chang es the MC2 alignment.
Once the MC was stably locked, I was able to maximize MC transmission at ~15,400 counts. I then centered the spot on the MC2 trans QPD, and transmission dropped to ~14800 counts. After tweaking the alignment again, it was recovered to ~15,000 counts. Gautam then engaged the WFS servo and the beam was centered on MC2 trans QPD, transmission level dropped to ~14,900.
Gautam was doing some DRMI locking, so I replaced the photodiode at the AS port to begin loss measurements again.
I increased the resolution on the scope by selecting Average (512) mode. I was a bit confused by this, since Yuki was correct that I had only 4 digits recorded over ethernet, which made me think this was an i/o setting. However the sample acquisition setting was the only thing I could find on the tektronix scope or in its manual about improving vertical resolution. This didn't change the saved file, but I found the more extensive programming manual for the scope, which confirms that using average mode does increase the resolution... from 9 to 14 bits! I'm not even getting that many.
There's another setting for DATa:WIDth, that is the number of bytes per data point transferred from the scope.
I tried using the *.25 scope instead, no better results. Changing the vertical resolution directly doesn't change this either. I've also tried changing most of the ethernet settings. I don't think it's something on the scripts side, because I'm using the same scripts that apparently generated the most recent of Johannes' and Yuki's files; I did look through for eg tds3014b.py, and didn't see the resolution explicitly set. Indeed, I get 7 bits of resolution as that function specifies, but most of them aren't filled by the scope. This makes me think the problem is on the scope settings.
I ran a BNC from the PD on the AS table along the cable rack to a free ADC channel on the LSC whitening board. I lay the BNC on top of the other cables in the rack, so as not to disturb anything. I also was careful not to touch the other cables on the LSC whitening board when I plugged in my BNC. The PD now reads out to... a mystery channel. The mystery channel goes then to c1lsc ADC0 channels 9-16 (since the BNC goes to input 8, it should be #16). To find the channel, I opened the c1lsc model and found that adc0 channel 15 (0-indexed in the model) goes to a terminator.
Rather than mess with the LSC model, Gautam freed up C1:ALS-BEATY_FINE_I, and I'm reading out the AS signal there.
I misaligned the x-arm then re-installed the AS PO PD, using the scope to center the beam then connecting it to the BNC to (first the mystery channel, then BEATY). I turned off all the lights.
I went to misalign the x-arms, but the some of the control channels are white boxed. The only working screen is on pianosa.
The noise on the AS signal is much larger than that on the MC trans signal, and the DC difference for misaligned vs locked states is much less than the RMS (spectrum attached); the coherence between MC trans and AS is low. However, after estimating that for ~30ppm the locked vs misaligned states should only be ~0.3-0.4% different, and double checking that we are well above ADC and dark noise (blocked the beam, took another spectrum) and not saturating the PD, these observations started to make more sense.
To make the measurement in cds, I also made the following changes to a copy opf Johannes' assess_armloss_refl.py that I placed in /opt/rtcds/caltech/c1/scripts/lossmap_scripts/armloss_cds/ :
I started taking a measurement, but quickly realized that the mode cleaner has been locked to a higher order mode for about an hour, so I spend some time moving the MC. It would repeatedly lock on the 00 mode, but the alignment must be bad because the transmission fluctuates between 300 and 1400, and the lock only lasts about 5 minutes.
Back to loss measurements.
I replaced the PD I've been using for the AS beam.
I misaligned the x arm.
I tried to lock the y arm, but PRC was locked so I could was unable. Gautam reminded me where the config scripts are.
The armloss measurement script needed two additional modifications:
I ran successfully the loss measurement script for the x and y arms. I'm getting losses of ~100ppm from the first estimates.
I made the following changes to the lossmap script:
When the optic aligns itself not at the ideal position, I'm noticing that it often locks on a 01. When the cavity is then misaligned and restored, it can no longer obtain lock. To fix this, I've moved my 'save' commands to just before the loop begins. This means the script may take longer to run, but as long as the cavity is initially locked and well aligned, this should make it more robust against wandering off and never reacquiring lock.
I left the lossmap script running for the x-arm. Next would be to run it for the y arm, but I see that after stepping to a few positions the lock is again lost. It's still trying to run, but if you want to stop it no data already taken will be lost. To stop it, go to the remaining terminal open on rossa and ctrl+c
the analysis needs:
I made additional measurements on the x and y arms, at 5 offset positions for each arm (along with 6 measurements at the "zeroed" position).
While I stopped by the lab this morning to pick up some things, I took the opportunity to continue the recovery.
At some point, we should run the suspension eigenmode routine (kick optics, let them ringdown, measure peak locations and Qs) to confirm that the remaining suspensions are okay, will also help in actuation re-allocation efforts on ETMY. But I didn't do this today.
Leaving the lab at 1150.
The autolocker was struggling to lock the IMC. I disabled the autolocker and locked the IMC manually. It seems happy right now.
With PMC trans at 0.717 counts, the IMC trans sum is ~15230.
The MC autolocker hasn't been so snappy recently, and has been especially fussy today. Previously, the mcup script was triggered immediately once the transmission was above a certain threshold. However, this could waste time if it was just an errant flash. Hence, I've added a 0.5 second delay and a second threshold check before mcup is triggered.
After breaking the lock 5ish times, it does seem to come back quicker.
Recently we wondered at the meeting what the IMC round trip loss was. I had done several ringdowns in the winter of 2017, but because the incident light on the cavity wasn't being extinguished completely (the AOM 0th order beam is used), the full Isogaio et. al. analysis could not be applied (there were FSS induced features in the reflection ringdown signal). Nevertheless, I fitted the transmission ringdowns. They looked like clean exponentials, and judging by the reflection signals (see previous elogs in this thread), the first ~20us of data is a clean exponential, so I figured we may get some rough value of the loss by just fitting the transmission data.
The fitted storage time is .However, this number isn't commensurate with the 40m IMC spec of a critically coupled cavity with 2000ppm transmissivity for the input and output couplers.
Attachment #1: Expected storage time for a lossless cavity, with round-trip length ~27m. MC2 is assumed to be perfectly reflecting. The IMC length is known to better than 100 Hz uncertainty because the marconi RF modulation signal is set accordingly. For the 40m spec, I would expect storage times of ~40 usec, but I measure almost 30% longer, at ~60 usec.
Attachment #2: Fits and residuals from the 10 datasets I had collected. This isn't a super informative plot because there are 10 datasets and fits, but to eye, the fits are good, and the diagonal elements of the covariance matrix output by scipy's curve_fit back this up. The function used to fit the t > 0 portions of these signals (because the light was extinguished at t=0 by actuating on the AOM) is , where A and tau are the fitted parameters. In the residuals, the same artefacts visible in the reflection signal are seen.
Attachment #3: Scatter plot of the data. Width of circles are proportional to fit error on individual measurements (i just scaled the marker size arbitrarily to be able to visually see the difference in uncertainty, the width doesn't exactly indicate the error), while the dahsed lines are the global mean and +/- 1 sigma levels.
Attachment #4: Cavity pole measurement. Using this, I get an estimate of the loss that is a much more believable .
I started putting together some code to implement some ideas we discussed at the Tuesday meeting here. Pipeline isn't setup yet, but i think it's commented okay so if people want to play around with it, the code lives on the 40m gitlab.
Initial results and conclusions:
There still seems to be some data quality issues with the ringdown data I have, so I don't think we really gain anything from running this analysis on the data I have already collected - but in the future, we can do the ringdown with complete extinguishing of the input light, and repeat the analysis.
As for whether we should clean the IMC mirrors - I'm going to see how much power comes out at the REFL port (with PRM aligned) this afternoon, and compare to the input power. This technique suffers from uncertainty in the Faraday insertion loss, isolation and IMC parameters, but I am hoping we can at least set a bound on what the IMC loss is.
Over the weekend, I worked a bit on getting these ringdowns going. I will post a more detailed elog tomorrow but here is a quick summary of the changes I made hardware-wise in case anyone sees something unfamiliar in the lab...
I spent a while in preparation for these trials (details tomorrow) like optimizing AOM alignment/diffracted power ratio, checking AOM and PMC switching times etc, but once the hardware is laid out, it is easy to do a bunch of ringdowns in quick succession with an ethernet scope. Tonight I did about 12 ringdowns - but stupidly, for the first 10, I was only saving 1 channel from the oscilloscope instead of the 3 we want to apply the MIT method.
Here is a representative plot of the ringdown - at the moment, I don't have an explanation for the funky oscillations in the reflected PD signal, need to think on this.. More details + analysis to follow...
Dec 5 2016, 130pm:
Actually the plot I meant to put up is this one, which has the time window acquired slightly longer. The feature I am referring to is the 100kHz oscillation in the REFL signal. Any ideas as to what could be causing this?
As promised, here is the more detailed elog.
Part 1: AOM alignment and diffraction efficiency optimization
I started out by plugging in the input to the AOM driver back to the DS345 on the PSL table, after which I re-inserted the 24V fuse that was removed. I first wanted to optimize the AOM alignment and see how well we could cut the input power by driving the AOM. In order to investigate this, I closed the PMC, unlocked the PSL shutter, and dialed the PSL power down to ~100mW using the waveplate in front of the laser. Power before touching anything just before the AOM was 1.36W as measured with the Coherent power meter.
The photodiode (PDA255) for this experiment was placed downstream of the 1%(?) transmissive optic that steers the beam into the PMC (this PD would also be used in Part 2, but has since been removed)...
Then I tuned the AOM alignment till I maximized the DC power on this newly installed PD. It would have been nicer to have the AOM installed on the mount such that the alignment screws were more easily accessible, but I opted against doing any major re-organization for the time being. Even after optimizing the AOM alignment, the diffraction efficiency was only ~15%, for 1V to the AOM driver input. So I decided to play with the AOM driver a bit.
Note that the AOM driver is powered by 24V DC, even though the spec sheet says it wants 28V. Also, the "ALC" input is left unconnected, which should be fine for our purposes. I opted to not mess with this for the time being - rather, I decided to tweak the RF adjust potentiometer on the front of the unit, which the spec sheet says can adjust the RF power between 1W and 2W. By iteratively tuning this pot and the AOM alignment, I was able to achieve a diffraction efficiency of ~87% (spec sheet tells us to expect 80%), in a switching time of ~130ns (spec sheet tells us to expect 200ns, but this is presumably a function of the beam size in the AOM). These numbers seemed reasonable to me, so I decided to push on. Note that I did not do a thorough check of the linearity of the AOM driver after touching the RF adjust potentiometer as Koji did - this would be relevant if we want to use the AOM as an ISS servo actuator, but for the ringdown, all that matters is the diffraction efficiency and switching time, which seemed satisfactory.
At this point, I turned the PSL power back up (measured 1.36W just before the AOM). Before this, I estimated the PD would have ~10mW power incident on it, and I wanted it to be more like 1mW, so I I put an ND 1.0 filter on to avoid saturation.
Part 2: PMC "ringdown"
As mentioned in my earlier elog, we want the PMC to cut the light to the IMC in less than 1us. While I was at it, I decided to see if I could do a ringdown measurement for the PMC. For this, I placed two more PDs in addition to the one mentioned in Part 1. One monitored the transmitted intensity (PDA10CF, installed in the old 3f cancellation trial beam path, ~1mW incident on it when PMC is locked and well aligned). I also split off half the light to the PMC REFL CCD (2mW, so after splitting, PMC CCD gets 1mW through some ND filters, and my newly installed PD (PDA255) receives ~1mW). Unfortunately, the PMC ringdown attempts were not successful - the PMC remains locked even if we cut the incident light by 85%. I guess this isn't entirely surprising, given that we aren't completely extinguishing the input light - this document deals with this issue.... But the PMC transmitted intensity does fall in <200ns (see plot in earlier elog), which is what is critical for the IMC ringdown anyways. So I moved on.
Part 3: IMC ringdown
The PDA10CF installed in part 2 was left where it was. The reflected and transmitted light monitors were PDA255. The former was installed in front of the WFS2 QPD on the AS table (needed an ND1.0 filter to avoid damage if the IMC unlocks not as part of the ringdown, in which case ~6mW of power would be incident on this PD), while the latter was installed on the MC2 transmission table. We may have to remove the former, but I don't see any reason to remove the latter PD. I also ran a long cable from the MC2 trans table to the vertex area, which is where I am monitoring the various signals.
The triggering arrangement is shown below.
To actually do the ringdown, here is the set of steps I followed.
It is possible to do ~15 ringdowns in an hour, provided the seismic activity is low and the IMC is in a good mood. Unfortunately, I messed up my data acquisiton yesterday, so I only have data from 2 ringdowns, which I will work on fitting and extracting a loss number from. The ringing in the REFL signal is also a mystery to me. I will try using another PDA255 and see if this persists. But anyways, I think we can exclude the later part of the REFL signal, and fit the early exponential decay, in the worst case. The ringdown signal plots have been uploaded to my previous elog. Also, the triggering arrangement can be optimized further, for example by using the binary output from one of our FEs to trigger the actual waveform instead of leaving it in this low frequency oscillation, but given our recent experience with the Binary Output cards, I thought this is unnecessary for the time being...
Data analysis to follow.
I have left all the PDs I put in for this measurement. If anyone needs to remove the one in front of WFS2, go ahead, but I think we can leave the one on the MC2 trans table there...
The MC1 suspension troubles vanished as they came - but the IMC was remaining locked stably so I decided to do another round of ringdowns, and investigate this feature in the reflected light a bit more closely. Over 9 ringdowns, as seen in the below figure, the feature doesn't quite remain the same, but qualitatively the behaviour is similar.
Steve helped me find another PDA255 and so I will try switching out this detector and do another set of ringdowns later tonight. It just occurred to me that I should check the spectrum of the PD output out to high frequencies, but I doubt I will see anything interesting as the waveform looks clean (without oscillations) just before the trigger...
Following the discussion at the meeting today, I wanted to finish up the WFS tuning and then hand over the IFO to Johannes for his loss stuff. So I did the following:
At this point, I figured I would leave the WFS in this state and observe its behaviour overnight. But abruptly, the IMC behaviour changed dramatically. I saw first that the IMC had trouble re-acquiring lock. Moreover, the PC Drive seemed saturated at 10.0V, even when there was no error signal to the MC Servo board. Looking at the MEDM screen, I noticed that the "C1-IOO_MC_SUM_MON" channel had picked up a large (~3V) DC offset, even with In1 and In2 disabled. Moreover, this phenomenon seemed completely correlated with opening/closing the PSL shutter. Johannes and I did some debugging to make sure that this wasn't a sticky button/slider issue, by disconnecting all the cables from the front panel of the servo board - but the behaviour persisted, there seemed to be some integration of the above-mentioned channel as soon as I opened the PSL shutter.
Next, I blocked first the MC REFL PD, and then each of the WFS - turns out, if the light to WFS2 was blocked and the PSL shutter opened, there was no integrating behaviour. But still, locking the MC was impossible. So I suspected that something was wrong with the LO inputs to the WFS Demod Boards. Sure enough, when I disconnected and terminated those outputs of the RF distribution box, I was able to re-lock the MC fine.
I can't explain this bizzare behaviour - why should an internal monitor channel of the MC Servo board integrate anything when the only input to it is the backplane connector (all front panel inputs physically disconnected, In1 and In2 MEDM switches off)? Also, I am not sure how my work on the WFS could have affected any hardware - I did not mess around at the 1X1 rack in the evening, and the light has been incident on the WFS heads for the past few days. The change in modulation depth shouldn't have resulted in the RF power in this chain crossing any sort of damage threshold since the measured power before the changes was at the level of -70dBm, and so should be at most -40dBm now (at the WFS demod board input). The only thing different today was that the digital inputs of the WFS servos were turned on...
So for tonight I am leaving the two outputs of the RF distribution box that serve as the LO for the WFS demod boards terminated, and have also blocked the light to both WFS with beam blocks. The IMC seems to be holding lock steady, PC drive levels look normal...
Unrelated to this work, but I have committed to the svn the updated versions of the mcup and mcdown scripts, to reflect the new gains for the autolocker...
Yesterday evening I inspected at IMC servo as a preparation of the CM servo recommissioning.
More details to come.
In order to accomplish CARM control with the PSL laser frequency, we use two actuators.
One is the longitudinal direction of one of the MC mirrors. The londitudinal motion of the MC induces
the laser frequency control via the MC servo. As we move the mirror, the range is sort of big,
but the BW is limited by the mechanical response.
The other is the additive offset path. We inject a signal to the additional input port of the MC.
The MC servo supresses this injection by giving the same amount but oppsite sign offset to
the error signal (before the addtion of the inputs). The bandwidth of this AO path is limited
by the bandwidth of the MC servo. Basically the BW of the AO path is about 1/10 of that of the MC servo.
In order to confirm the capability of the AO path as a frequency actuator, 1) OLTF of the MC servo
2) TF of the AO input to the servo error was measured.
Attachment 1 shows the openloop TF of the MC servo. The UGF seems just little bit higher than
100kHz. The OLTF is empirically modelled by LISO as seen in the figure.
Attachment 2 shows the TF from the additive input (In2) to the error monitor (MC Servo module Q error mon).
The gain setting of the MC servo box was: In1 +18dB, In2 0dB. The measured TF has arbitorary gain
due to the gain setting, the measuemrent data was multiplied by 4 to mach the DC value to the unity.
This is to compare the measurement with the prediction from the OLTF.
The AO path TF is expected to show the character of -G/(1+G) where G is the OLTF. In my case,
G = 0.75*OLTF showed the best maching. There might have been some misalignment of the MC
upon the AO path measurement as I found after the measurement.
From the plot , we can see that the response is flat up to 20kHz. Above that it rapidly raises.
This should be dealt with the CM servo filter as the bump may hit the unity gain. Since we have to use
strong roll off to avoid the bump, this will eat the phase margin at low frequency.
In the case that we don't like this bump:
This bump is caused by low phase mergin of the OLTF at 30~40kHz. If the total gain
is increased, the bump is reduced. Or, we can decrease the PZT loop gain in order to
reduce the dip at the crossover ferquency between the PZT and PC loops. In both cases,
the PC path suffers more actuation. We may need to think about the HV actuation option
for the PC (Apex PA85).
Well, let's see how the CM servo can handle this.
The key point here is that we have enough data to start the design of the CM servo.
I wasn't sure how the IMC servo was optimized recently. We used to have the FSS over all gain (C1:PSL-FSS_MGAIN) of +6dB a few years back. It is not 0dB. So I decided to do a couple of measurements.
1) Default setting:
2) Looked at the power spectrum at TEST1A output (error signal)
TEST1A is the signal right after the input gain stage (C1:IOO-MC_REFL_GAIN). Prior to the measurement, I've confirmed that the UGF is ~100Hz even at +0dB (see next section). It was not too bad even with the current default. Just wanted to check if we can increase the gain a bit more.
The input gain was fixed at +4dB and the FSS overall gain C1:PSL-FSS_MGAIN was swept from +0 to +6.
At +5dB and +6dB, the servo bump was very much visible (Attachment 1).
I decided to set the default to be +4dB (Attachment 3).
3) Took OLTF at 0dB and 4dB for the FSS overall gain.
Now the comparison of the opel loop transfer functions (OLTF) for C1:PSL-FSS_MGAIN at 0dB and 4dB. The OLTF were taken by injectiong the network analyzer signal into EXCA and measure the ratio between TEST1A and TEST1B (A/B).
C1:PSL-FSS_MGAIN +0 -> UGF 100kHz / Phase Margin ~50deg
C1:PSL-FSS_MGAIN +4 -> UGF 200kHz / Phase Margin 25~30deg
The phase margin was a bit less but it was acceptable.
4) IMC FSR
Took the opportunity to check the FSR of the IMC. Connected a cable to the RF MON of the IMC REFL demod board. Looked at the peak at 40.56MHz (29.5MHz + 11.066MHz). The peak was not so clear at 11.066195MHz (see 40m ELOG 15845). The peak was anyway minimized and the new modulation frequency was set to be 11.066081MHz (new FSR). The change is 10ppm level and it is within the range of the temp drift.
I want to work on the IFO this weekend, so I reverted the IMC suspension settings just now to what I know work (until the new settings are shown quantitatively to be superior). There isn't any instruction here on how to upload the new settings, so after my work, I will just restore from a burt-snapshot from before I changed settings.
In the process, I found something odd in the MC2 coil output filter banks. Attachment #1 shows what it it is today. This weird undetermined state of FM9 isn't great - I guess this flew under the radar because there isn't really any POS actuation on MC2. Where did the gain1 filter I installed go? Some foton filter file corruption? Eventually, we should migrate FM7,FM8-->FM9,FM10 but this isn't on my scope of things to do for today so I am just putting the gain1 filter back so as to have a clean FM9 switched on.
The old setting can be restored by running python3 /users/anchal/20210505_IMC_Tuned_SUS_with_Gains/restoreOldConfigIMC.py from allegra or donatella.
I wrote the values from the c1mcs burt snapshot from ~1400 Saturday May 15, at ~1600 Sunday May 16. I believe this undoes all my changes to the IMC suspension settings.
For future reference, the new settings can be upoaded from a script in the same directory. Run python /users/anchal/20210505_IMC_Tuned_SUS_with_Gains/uploadNewConfigIMC.py from allegra.
There isn't any instruction here on how to upload the new settings
I tried to answer two questions regarding the IMC:
1. What is the coupling of fluctuations in the SB freq. to SB transmitted power?
2. What (if any) is the influence of the IMC on the AM?
I ran into some weird things regarding the corresponding optickle simulations:
1. There seems to be some artifact at the beginning of every simulation sweep.
2. The position of features depends on the parameters of the sweep.
I mailed Matt asking if he sees some error in the simulations
This is just my intuition but the IMC servo seems not so optimized. I can increase the servo gain by 6~10dB easily. And I couldn't see that the PC drive went mad (red) as I increase the gain (=UGF).
The IMC needs careful OLTF measurements as well as the high freq spectrum observation.
It seems that I have worked on the IMC servo tuning in 2014 July/Aug. Checking these elogs would be helpful.
Herewith, I describe an adventure
gautam: For those like me who don't know what the AAA representation is: the original algorithm is here, and Lee claims his implementation of it in IIRrational is better, see his slides.
[Paco, JC, Anchal]
We balanced the IMC table back again to point that got us 50% of nominal transmission from IMC. Then we tweaked the steering mirror for injection to IMC to get up to 90% of nominal transmission. Finally, we used WFS servo loop to get to the 100% nominal transmission from IMC. However, we found that the WFS loop has been compromised now. It eventually misaligns IMC if left running for a few minutes. This needs to be investigated and fixed.
The IMC table had to be leveled again, for two reasons: 1) It was un-leveled when Jenne and Kiwamu removed an extra beam dump when they took the beam profile measurements, and 2) the stack of weights I had put there before was too tall to allow the beam to pass (I didn't realize that the BS chamber is offset a bit to the north, so the beam passes right over the NE edge of the IMC table).
First of all, I was wrong before when I said that the stack of weights was 4 blocks tall; it was 6 blocks tall. I re-leveled the table this afternoon by removing the top three blocks and placing them immediately south of the bottom three in the original stack, while also moving the circular weight north of its previous position. The table is now balanced roughly to within the tolerance of the bubble level I was using.
After the leveling, I tried to re-lock the modecleaner. Upon removing the beam block on the PSL table, I got some sort of resonance flashes on the MC TRANS monitor. With some minor adjustments to MC2&3, I was able to get a decent TEM00 mode to hit. The cavity wouldn't lock, so I went to the AP table and checked to make sure that the REFL beam was hitting the PD. It was, but the beam was very close to the edge of the focusing lens, so I moved the steering mirror slightly to make the situation a little better.
I then went to the control room to finish the by-now-mundane task of fine-tuning the MC lock, but today's was a worthier opponent. For some reason, the thing didn't want to lock for more than a few seconds at a time. I saw that the spot on MC2 was quite a bit off-center, so I ran the MC2_spot_xxx scripts to get it visually in place, then revisited the AP table to ensure that the REFL beam was still on the PD. No dice.
I don't know what was different. I had Ameristat over the opening between the tanks, with posters on top and on the sides (as usual), and I checked to ensure that the servo gains were at the appropriate levels. Joe pointed out that IOO VME was not responding, but we didn't seem to think that this was the problem (based on nothing I can put in words or stick figure cartoons), and the "alive" indicator on the Auto-Lock control in the MEDM screen was not blinking, as it usually is, but I don't know what bearing this has on anything.
I will try to lock again tomorrow.
In order to address the issue of low MC1 OSEM voltages, Yuta and I looked at the IMC table levelling. Looking with the bubble level, Yuta confirmed that the table was indeed out of level in the direction that would cause MC1 to move closer to it's cage, and therefore lower it's OSEM voltages. Looking at the trends, it looks like the table was not well levelled after TT1 installation. We should have been more careful, and we should have looked at the MC1/3 voltages after levelling.
Yuta moved weights around on the table to recover level with the bubble level. Unfortunately this did not bring us back to good MC1 voltages. We speculate that the table was maybe not perfectly level to begin with. We decided to try to recover the MC1 OSEM voltages, rather than go solely with the bubble level, since we believe that the MC suspensions should be a good reference. Yuta then moved weights around until we got the MC1/3 voltages back into an acceptable range. The voltages are still not perfect, but I believe that they're acceptable.
The result is that, according to the bubble level, the IMC table is low towards MC2. We are measuring spot positions now. If the spot positions look ok, then I think we can live with this amount of skew. Otherwise, we'll have to physically adjust the MC1 OSEMS.
- Removed MCT optics in the IMC chamber
- Rotated MC1 and MC3 in clock-wise to debias the YAW bias offsets (-5V and -8V to -1.5V and -0.5V).
- Adjusted insertion of the MC1 OSEMs so as to have the outputs of about 1.0V.
- Locked to TEM00. Trying to get the beams at the center of the mirror using Yuta's A2L.
Following configurations were kept today morning:
f2a filters with Q=10 (FM3) were turned on all IMC optics.
I repeated this test for the following configuration:
The test ran for 4000 seconds between following timestamps:
start time: 1352878206
stop time: 1352882207
This script was used to run this test and can be used again in future to repeat the same test.
Something to note, as we have the IMC angular controls under consideration:
Jenne has the DRMI locked right now. I took a look at the coherence between the POP QPD and MC2 transmission QPDs. (Since she's using ASC, I also included those control signals. The coherences are about the same, unsurprisingly)
Based on the observed coherences, from about 1 to 6Hz, IMC motion is responsible for a fair amount of the DRMI angular motion. Also, PIT and YAW couple differently.
I wonder if this is the coherence caused by the beam itself, or caused by the same ground motion.
Jenne should be able to tell us...
Both were measured using the FieldMate power meter. I was hesitant to use the Ophir power meter as there is a label on it that warns against exceeding 100 mW. I can't find anything in the elog/wiki about the measured inesrtion loss / isolation of the input faraday, but this seems like a pretty low amount of light to get back from PRM. The IMC visibility using the MC_REFL DC values is ~87%. Assuming perfect transmission of the 87% of the 97mW that's coupled into the IMC, and assuming a further 5% loss between the Faraday rejected port and the AP table, the Faraday insertion loss would be ~30%. Realistically, the IMC transmission is lower. There is also some part of the light picked off for IPPOS. Judging by the shape of the REFL spot on the camera, it doesn't look clipped to me.
Either way, seems like we are only getting ~half of the 1W we send in on the back of PRM. So maybe it's worth it to investigate the situation in the IOO chamber during this vent.
c1psl, c1susaux,c1iool0,caux crates were keyed. Also, the physical shutter on the PSL NPRO, which was closed last Monday for the Sundance crew filming, was opened and the PMC was locked. PMC remains locked, but there is no light going into the IMC.
Came this morning and saw that the IMC is unlocked.
Went into MC Lock screen and see that the watchdog is down and the PSL shutter is closed. I tried to open the shutter but nothing happened - no REFL signal or beam on the MC REFL camera .
Thinking this has something to do with the watchdog I upped the watchdog:
ezcawrite C1:SUS-MC2_LATCH_OFF 1
The watchdog on the MEDM screen became green but the shutter still seemed unresponsive. I went to the PSL table and made sure that the shutter is working. I opened the AS table and saw there no MC REFL beam anywhere.
Thinking that MC1 must be completely misaligned I opened the MC align screen to find that indeed all the alignment values has been zeroed! (attachment).
I burt restore c1iooepics from Mar 4th 00:19. Didn't help.
I try to burt restore c1susepics from Mar 1st 13:19. Still zero.
I try to burt restore c1susaux from Mar 1st 00:19 -> seems like alignment values have been restored.
I open the shutter. Beam is flying! MC Watchdogs tripped! I close the shutter. OK, I need to wait until the MCs are dampped enough. MC2 and MC3 have relaxed so I enable their watchdogs. MC1 is still swinging a bit. I turn on damping for MC1 as well.
MC locked immediately but the REFL is still high like 1.2. Is it normal?
I turn on the WFSs and the REFL went down to 0.3 nice. I run the MC WFS relief script.
Hmm, the bias values were reset at 2022-03-03-20:01UTC which is 2022-03-03-12:01 PST with no apparent disruption of the data acquisition (= no resetting of the RTS). Not sure how this could happen.
*Another issue with the IMC autolocker I've noticed in the recent past: sometimes, the mcup script doesn't get run even though the MC catches a TEM00 mode. So the IMC servo remains in acquisition state (e.g. boosts and WFS servos don't get turned on). Looking at the autolocker log doesn't shed much light - the "saw a flash" log message gets printed, but while normally the mcup script gets run at this point, in these cases, the MC just remains in this weird state.
In order to switch on the angular alignment for the IMC mirrors, we needed to center the laser onto the quad-photodiodes at the IMC and the AS Table(WFS1 and WFS2)
I and Gautam went to the IMC table and did the dc centering for the quad-photodiode by varying the beamsplitter angles. After this, we turned the WFS loops off and performed beam centering for the Quad PDs at the AS Table, the WFS1 and WFS2.
Once we had the beam approximately centered for all of the above 3 PDs, we turned on the locking for IMC, and it seems to work just fine. We are waiting for another hour for switching on the angular allignment for the mirrors to make sure the alignment holds with WFS turned off.
It happened again. MC2 UL seems to have gotten the biggest glitch. It's a rather small jump in the signal level compared to what I have seen in the recent past in connection with suspect Satellite boxes, and LL and UR sensors barely see it.
I will squish Sat box cables and check the cabling at the coil driver board end as well, given that these are two areas where there has been some work recently. WFS loops will remain off till I figure this out. At least the (newly centered) DC spot positions on the WFS and MC2 TRANS QPD should serve as some kind of reference for good MC alignment.
GV edit 9pm: I tightened up all the cables, but doesn't seem to have helped. There was another, larger glitch just now. UR and LL basically don't see it at all (see Attachment #2). It also seems to be a much slower process than the glitches seen on MC1, with the misalignment happening over a few seconds (it is also a lot slower). I have to see if this is consistent with a glitch in the bias voltage to one of the coils which gets low passed by a 4xpole@1Hz filter.
wonder if its possible that the slow glitches in MC are just glitches in MC2 trans QPD? Steve sometimes dances on top of the MC2 chamber when he adjusts the MC2 camera.
I've re-enabled the WFS at 22:25 (I think Gautam had them off as part of the MC2 glitch investigation). WFS1 spot position seems way off in pitch & yaw.
From the turn on transient, it seems that the cross-coupled loops have a time constant of ~3 minutes for the MC2 spot, so maybe that's not consistent with the ~30 second long steps seen earlier.
Happy MC after last glitch at 10:28 so the credit goes to Rana
GV edit 11:30am: I think the stuff at 10:28 is not a glitch but just the WFS servos coming on - the IMC was only hand aligned before this.
The other night, I spent some time with the mode cleaner.
First, I made some model changes to the MC_TRANS part of c1mcs.mdl. Specifically, I brought in the userapps QPD part that we are using for the transmon and oplev QPDs. My main motivation for doing so was to have FMs for the pitch and yaw values, to be able to set offsets. Up until now, we have used a QPD centering servo in conjunction with the WFS, but the center of the QPD is not perfectly aligned to represent the center of MC2. Using offsets at the servo isn't really practical, since there are integrators.
I then spent some time manually aligning the mode cleaner mirrors with WFS off, followed by centering the in-lock MC REFL beam on the WFS QPDs, and setting the WFS and MC_TRANS offsets. (I updated the WFS offset script, and made one for MC_TRANS in scripts/MC/WFS. They now use averaging instead of servoing to zero, a la LSC PD offset script).
The resultant intracavity power and RIN was an improvement over the older offsets. (RMS RIN went down by half, I think.)
Since Monday, the autolocker seems to be having some trouble. At first, I suspected the changes I made weren't so hot after all, but I've now noticed a pattern. Often when I come to manually lock the mode cleaner due to a long unlocked period, I find that the sliders are not in the state specified by the mcdown script. Furthermore, it's not the same channels every time; sometimes the servo gain is left high, sometimes the boosts are left on. I fear that some of the caput commands are failing to execute. Ugh.
Often when I come to manually lock the mode cleaner due to a long unlocked period, I find that the sliders are not in the state specified by the mcdown script. Furthermore, it's not the same channels every time; sometimes the servo gain is left high, sometimes the boosts are left on. I fear that some of the caput commands are failing to execute. Ugh.
This continues to happen. I believe the network latency boogeyman is to blame.
There was a long unlocked period because the enable switch for the MC servo fast path (FASTSW) was left off. Running the mcdown script fixed this, but included the error message:
Channel connect timed out: 'C1:IOO-MC_REFL_GAIN' not found.
CA Client Library: Ignored duplicate create channel response from CA server?
which means the IN1 gain didn't get touched. A second pass of the script produced no errors.
I'm thinking of adding some logic that if the autolocker has failed to lock for some period (5 minutes?), it should rerun mcdown.