Summary: I calibrated MC2 pitch and yaw offsets to spot position in mm. Here's what I did:
Results: In the pitch/yaw vs pitch_offset/yaw_offset graph attached,
Around 6PM on the 27th, I found that the C1:IOO-MC_RFPD_DCMON had risen to about 2.5V. I checked the trend of MC2 sensors and found that between 2PM and 6PM, MC2 had drifted in a strange way. And also that the alignment had grown worse over several days. I also noticed that the spot on the MC2F camera had shifted to the left.
I attempted to correct the alignment (decrease the C1:IOO-MC_RFPD_DCMON to ~0.5V ) by just moving the MC2 and succeeded!! So it is quite likely that most of the slow MC drift is arising due to MC2 table drift.
I decided to try and close the MC2_TRANS QPD to MC2 loops separately to see if MC alignment becomes stable But several screens needed to be fixed before we could try anything. So I fixed C1IOO_WFS_MASTER, C1IOO_WFS_INMATRIX and ...OUTMATRIX screens. Deleted the older ones to avoid confusion.
In this process I noticed that the directory of $screens$/c1mcs/master contains copies of older C1SUS_MC1 , 2. and 3 screens which look very similar to the new autogenerated screens. Some of the links in the WFS screens were pointing to the old screens. I have redirected the links and I will delete these in a couple of days, if no one objects.
Olympus SP570 UZ - without IR blocker, set up as Atm.3 Camera distance to MC face ~85 cm, IOO-MC_TRANS_SUM 16,300 counts, Lexan cover on not coated viewport.
Image mode: RAW + JPG, M-costum, manual focus, Lens: Olympus 4.6 - 92 mm, f2.8 - 4.5, Apeture: F2.8 - 8, Image pick up device: 1/2.33" CCD (primary color filter)
Atm.1, 212k.jpg of raw 15 MB, exp 0.025s, apeture 2.97, f 4.6, iso 64,
Atm.2, Copied through my Cannon S100 ( 3.3 MB.jpg of raw from UFraw photo shop )I will look up the original raw file for details.
I found the IMC was largely misaligned and was not locking. The WFS feedback signals were saturated and MC2 was still largely misaligned in yaw after resetting the saturation.
It seemed that the MC WFS started to put the large offset at 6:30AM~7:00AM (local).
MC2 was aligned and the lock was recovered then the MC WFS seems working for ~10min now.
This afternoon I felt like saying hello to the input mode cleaner. So I decided to center the spot on MC2.
MC has 6 alignment dofs. 4 of them are controlled by the WFSs. Remaining 2 appears at the spot position on MC2.
If the spot on the MC2 is fixed, the beam hits the same places of three mirrors. If the mirrors are completely fixed
in terms of the incident beam, I suppose the reflected beam is also fixed. This makes the WFS spots more stable.
Then I feel better.
Today's goal is to confirm the behaviour of MC such as dithering amplitude, response of the couplings to the alignment,
behavior of the WFS, and the transmitted power.
1) Turned off MC auto locker. Turned off MC WFS as the WFS servos disturbs my work.
2) Dithered MC2 in Pitch and Yaw using DTT. There looks elliptic filter (fc=28Hz) in the ASC path, I used 20Hz-ish excitations.
- C1:SUS-MC2_ASCPIT_EXC 100cnt_pk@19Hz
- C1:SUS-MC2_ASCYAW_EXC 100cnt_pk@22Hz
3) Looked at C1:SUS-MC2_MCL_OUT to find the peaks at 19Hz and 22Hz. These are caused by alignment-length coupling.
If they are minimized I assume the spot is somehow centered on MC2.
Note: This may not be the true center. The suspension response should be investigated. But this is a certain reporoducible spot position.
Note: I should use ezcademod in order to obtain the phase information of the dither result.
4) Move MC2 Pitch for certain amount (0.01cnt) by the alignment slider. Align MC1/MC3 to have max transmittion.
5) If the Pitch peak got lower, the direction of 4) was right. Go further.
5') If the Pitch peak got higher, the direction of 4) was wrong. Go the other direction.
6) Repeat 4)&5) for Yaw.
After the adjustment, the couplings got lower about 10 times. (Sorry! The explanation is not so scientific.)
Next time I (or someone) should make a script to do it and evaluate the coupling by the estimated distance of the spot from the center of the mirror (the center of the rotation).
I have not seen visible change in the spectrum of C1:SUS-MC2_MLC_OUT.
By the spot centering, I could expected to see some improvement of the transmittion. But in reality, there was no change.
In fact, the transmittion power was getting down for those weeks.
I checked WFS and MCT paths. Eventually I found that a couple of possible problems:
1) MCT Total output varies more than 10% depending on the spot position on MCT QPD.
2) Just before the QPD, there is a ND1 filter.
This may suggest that:
a) Four elemtns of the MCT QPD have different responses.
b) The ND filter is causing a fringe.
So far I aligned the ND filter to face the beam. The reflection from the filter was blocked at a farther place.
Still the output varies on the spot position. Probably I have to look at the QPD someday.
So far the spot on the QPD was defined so that I get the maximum output from the QPD. This is about 8.8.
As I touched the steering mirrors, the X and Y outputs of the QPD are no longer any reference.
For now, I closed the PSL table. The full IFO was aligned.
I made good on my threat from yesterday to convert the MC2 suspension controller to the library part. Whatever changes were in MC2 were thrown out, although they are archived in the SVN. Again, this kind of undocumented breaking is forbidden.
Change was committed to SVN, and c1mcs was recompiled/installed/restarted.
While Kevin is working on the MC2 electronics chain - we disconnected the output to the optic (DB15 connector on coil driver board). I decided to look at the 'free' freeswinging MC2 OSEM shadow sensor data. Attachment #1 suggests that the suspension eigenmodes are showing up in the shadow sensors, but the 0.8Hz peak seems rather small, especially compared to the result presented in this elog.
Maybe I'll kick all 3 MC optics tonight and let them ringdown overnight, may not be a bad idea to checkup on the health of the MC suspensions/satellite boxes... [MC suspensions were kicked @1207113574]. PSL shutter will remain closed overnight...
Why is MC2 LR so different from the others???
For whatever reason, the autolocker didn't turn the tickle off for several hours. Seems to work okay now. The linked plot suggests that the coil balancing on MC2 is pretty lousy.
While we were trying to relock the MC after Jenne put back the RF box, we found there was some mysterious motion in MC2. After spending time trying to figure out where this was coming from, the source was found to be at LOCKIN2 of MC2 suspension "The MC TICKLER" that was left enabled. This was turned OFF and MC locked just fine after that.
EDIT JCD: The Tickler should be disabled, if the autolocker is disabled.
Sounds like this was just incidental, since the MC locked fine also with the tickler enabled for weeks.
The tickle is disabled by the down script, but there's no way to correctly handle all possible button pushes. If you want to disable the autolocker for some reason you should run mcdown before trying to lock. This will set up things with the correct settings.
Isn't that backwards? Shouldn't the tickler be enabled by the down script, and disabled by the up script? Either way, the problem was that, after I acquired lock, the tickler was causing the transmitted power to fluctuate by ~20%, and often the MC would lose lock after a minute or so. Also, the WFS definitely couldn't be enabled by hand.
Anyhow, I'll try to keep in mind that this exists, so I'm not stymied by it again.
You're right - down turns it on. Still, the fact that the same tickle recently causes a problem and didn't make 20% power fluctuations until now tells me that its not that the tickle amplitude is too large. Whatever changed recently is the problem.
Last night while noise hunting, Rana found that the MC2 trans beam has been left for an unknown length of time just hitting the side of the black enclosure box. Today I put a brand-spankin'-new razor dump on the MC2 table, to dump the beam.
We noticed last week that the MC2 trans camera has pitch and yaw swapped; I rotated what I thought is the correct camera by 90 degrees clockwise (as viewed from above, like in the attachment), but I now have doubts. It's the camera on the right in the attachment.
The left one is analog and 90deg rotated.
See also: This issue tracker
Just felt a big "kerplunk" type ground-shaking, presumably from all the antics next door. MC2's watchdog tripped as a result. The watchdog has been reenabled.
People complained about the MC instability: If we aligned the MC, it locked nicely for a while.
Then suddenly you find that it got totally misaligned with the order of 0.2 with the alignment slider.
This misalignment usually happens for MC2, but it happend on MC3 once.
Surprisingly to me, this instability happened even without MCL and WFS, not only once but at least three times.
This suggests that the suspensions are the cause of the trouble.
I played with the MC2 suspension for a while in the afternoon. It seems that it has a hysteresis (or say, bistablity).
And the nominal alignment of MC2 seems close to the point where the transition happens. (Dunno why)
I further played with MC2 and found that a step of POS actuation by +/-10000 induces this transition go and back.
When the POS kick is in the negative direction (-10000), the MC2 seems to return to the preferrable
position. Therefore, I applied DC position force of -5000 to pull the mirror a bit from the nominal position.
I let the MC locked for ~4hours without MCL and WFS, it kept good alignment and the lock was stable
except for unlocks because of the activties by Den and Ayaka.
All of them has been done without previous monitor data as the tools were available.
The MC2 situation is not conclusive but we should check how we can prevent the bistable transition
by restricting MCL/WFS.
During a lull in Koji vs. The Arm, I switched on the MC2_TRANSQPD feedback path to check out its UGF. In the past months, when its been on, it has had a gain of ~0.03 - 0.1.
Today, I found that with the gain turned up to 11, it has a ~1 minute step response time (as you see in the above Strip chart). So its had a UGF of ~2 hours or so during the times when we thought it might be doing bad or good or magic.
I leave it on now to see if it behaves well over the next days. Let's see if Steve thinks its good or not based on his trend monitoring.
** also touched up the PMC pointing (using the PMC REFL image / please never align the beam into the PMC without this camera image)
We turned on the MC2_TRANS paths for both PIT/YAW tonight.
I turned off the BLP200 and turned on the RLP7 (RLP always are better than BLP). G_PIT = -0.111, G_YAW = 0.111. On Monday, let's let Steve look at the trends and determine if this centering servo is bad or good.
I should've included this in my Thursday night ELOG... That evening, I aligned the mode cleaner with reasonable MC1/3 spot positions, and the MC2 spots very close to centered, and recentered the WFS and MC2 Trans QPDs. The mode cleaner held up very well over the course of that evening, even when actuating CARM on MC2 with WFS engaged (which previously wasn't very stable when the WFS weren't well aligned).
The MC was showing slow but periodic alignment drifts and eventually unlocked around noon. I looked up the alignment trend (Attach: 2 day trend)
MC_TRANS_PIT_ERR and MC_TRANS_Y_ERR show that the MC_TRANS servo slowly drifted the IMC alignment causing it to lose lock from time to time (mostly in yaw).
To confirm that the drift was NOT due to off-centering in the MC2_TRANS QPD, I turned off the WFS servo, moved MC2 to recenter the trans beam on the QPD, and re-enabled WFS servo.
MC_TRANS path in WFS is still left enabled.
This is a 4-day trend. I don't see any difference here which is significant. My guess is that the MC_TRANS servo gain is so low that its not really doing anything.
I'll turn it on periodically this week and then on Monday people can look at the trend again to see if they can identify when the servo is ON and when its OFF.
I've also turned on the MC2 TRANS path to gather some data over the weekend on how well or bad it works. Please turn it off on Monday.
MC2_TRANS path in WFS servo turned OFF.
The MC had not been stable lately with WFS drifting constantly. I checked the servo and found that the MC_TRANS path was still running. It turned out that the autolocker script enables the TRANS path in the locking process. I have turned the MC_TRANS path servo inputs OFF and now it is no more a part of the WFS servo.
P.S. Jenne fixed the PMC alignment mostly in pitch to bring it up to 0.81 from 0.77. But the temperature fluctuations have still not got us to the sweet spot for optimum PMC trans.
AA IN -> COIL DRIVER IN transfer function for MC3
I've provided excitation to the AA input, the same for all OSEM channels. In the digital domain coherence between C1:SUS-MC3_ULSEN_INMON / C1:SUS-MC3_ULCOIL_INMON and other channels OSEM -> COIL is 1 starting from 0.1Hz.
The only thing left to understand is why the coherence AA IN / COIL DRIVER IN measured in the analog domain is not 1 in the frequency range 0.1 - 1 Hz. It does not look like just SRS noise. I've connected Ch 1 and 2 to the source, coherence is close to 1.
Yesterday we found that MC3 OSEM LL PD did not have a sensible signal - the readback was close to zero and it was making MC move around. I disabled the PD LL so that the damping is done with just three face plus side PDs. There still no signal from MC3 LL PD today. It needs debugging.
I noticed that the MC3 LL sensor was apparently dead according to its suspension screen. Since it was only the fast ADC channel and not the SLOW PDmon, I could tell that it was just in the ADC cabling. I pushed in a few of the MC3 sensor cables on the front and back of the PD whitening board and it came back OK. According to this trend of the past 40 days and 40 nights, it started slipping on this past Wednesday morning.
Was anyone walking near MC2 or the suspension electronics racks before noon on Wednesday (Oct. 2nd)?
Seems like as a result of my recent poking around at 1X6, MC3 is more glitchy than usual (I've noticed that the IMC lock duty cycle seems degraded since Tuesday). I'll try the usual cable squishing voodo.
gautam 8.15pm: Glitches persisted despite my usual cable squishing. I've left PSL shutter closed and MC watchdog shutdown to see if the glitches persist. I'll restore the MC a little later in the eve.
I've terminated input to AA filters and measured signal to coils C1:SUS-MC3_??COIL_OUT.
I compared this noise to the signal when OSEM are connected to ADC.
I made BNC -> LEMO board such that all LEMOs have the same signal equal to BNC signal. I provided excitation of 50 mV as white noise to the input of the AA filter and measured coherence between excitation and MC3 coil driver. The path is
AA -> ICS 110 -> Pentium -> Pentek -> AI -> Univ Dewhitening -> Coil Driver
As all inputs have the same signal, matrices that recombine the signals should not affect coherence. But what I got for coherence between AA IN / Dewhitening OUT is
Rana asked us to write out here the new MC3 input matrix we have calculated along with the old one. The new matrix is not working out for us as it can't keep the suspension loops stable.
Note that the new matrix has been made so that the norm of each row is the same as the norm of the corresponding row in the old (current) input matrix.
Peak finding results:
Note: The highest peak on SIDE OSEM sensor free swinging data as well as the DOF basis data created using existing input matrix, comes at 0.978 Hz. Ideally, this should be 1 Hz and in MC1 and MC2, we see the resonance on SIDE DOF to show near 0.99 Hz. If you look closely, there is a small peak present near 1 Hz actually, but it is too small to be the SIDE DOF eigenfrequency. And if it is indeed that, then which of the other 4 peaks is not the DOF we are interested in?
On possiblity is that the POS eigenfrequency which is supposed to be around 0.97 Hz is split off in two peaks due to some sideways vibration and hence these peaks get strongly coupled to SIDE OSEM as well.
P.S. I think something is wrong and out limited experience is not enough to pinpoint it. I can show up more data or plots if required to understand this issue. Let us know what you all think.
I suppose you've tried doing the submatrix approach, where SIDE is excluded for the face DoFs? Does that give a better matrix? To me, it's unreasonable that the side OSEM senses POS motion more than any single face OSEM, as your matrix suggests (indeed the old one does too). If/when we vent, we can try positioning the OSEMs better.
Since we will measure (and hopefully adjust) the spot positions on the MC suspensions prior to the vent, MCASS is necessary for it.
Here is the MCASS status so far:
+ Valera worked on MCASS on the last February, and basically no progress after he left.
+ The MCASS model had been completed in C1IOO.mdl.
+ He made some useful scripts, including mcassup, mcassOn/Off, senseMCdecenter, senseMCmirrro and senseMCdofs.
Summary of those scripts can be found in his entry #4355.
+ We haven't closed the MCASS loops.
+ The control filters are still blank.
+ We haven't put any elements on the input and output matrices.
+ Some parameters for the dithering oscillators and demodulation systems were properly set.
So we can get the demodulated signals by simply running mcassUp and mcassOn. (This essentially corresponds to the A2L measurement.)
+ The PIT motions are driven at 10, 11 and 12 Hz for MC1, 2 and 3 respectively. For YAW, the frequencies were chosen to be 11.5, 12.5 and 13.5 Hz.
+ Some medm windows were prepared but not as refined as that of ASS.
+ Valera performed a measurement of the spot positions by using MCASS. The results are summarized in #4660.
+ We made an estimation about the beam clearance on the Faraday based on the measured spot positions (#4674)
So, it seems we should be able to at least measure the spot positions soon by using his scripts.
Oot on the streets and in the chat rooms, people often ask, "What is up with the MC_F calibration?".
Not being sure of the wiring in the c1ioo model, I have formed this screencap of today's model and put it here. The MC_LENGTH and MC_FREQ are the filter banks which would calibrate these channels. In the filter banks there were various version of a 'dewhite' filter. They were all approximately z=150, p=15, g =1 @ DC, but with ~1% differences. I don't trust their provenance and so I've enforced symmetry and fixed their names to reflect what they are (150:15). I have also turned on one filter in MC_FREQ so that now the whitening of the Pentek Interface board is compensated.
Why is this TF 1/f? It should be -20 dB/decade if MC_F is in units of Hz* and MCL is a pendulum response. Perhaps its because the combination of the Koji summing box, the Thorlabs HV driver, and the Pomona box forms an additional 1/f ? IF so, this would explain the TF we see. Once we get confirmation from Koji, we can load the TF into the MC_FREQ filter bank and then MC_F will be in units of Hz (as will the summary pages).
(along the way I've also turned off the craaaazzzy servo input enable tickling that gets put in the MC AutoLocker every April Fool's leap year - resist the temptation)
Since we have a frequency counter system here and some oscillators, I wonder if we can just calibrate the MC_L and MC_F directly using a mixer lashed up to one of the counters. If so, and we can get the stabilized laser frequency noise down below 10 mHz/rHz, maybe this is a viable alternative method to the photon calibrators. Counting zero crossings is more honest than counting photons.
In the filter banks there were various version of a 'dewhite' filter. They were all approximately z=150, p=15, g =1 @ DC, but with ~1% differences. I don't trust their provenance and so I've enforced symmetry and fixed their names to reflect what they are (150:15).
The filters were made in response to a measurement of the pentek whitening boards in 2015 (ELOG 11550), but this level of accuracy probably isn't important.
jiSome notes on the FSS configuration: ELOG 10321
I repeated this measurement as follows:
Here is a calibrated MC_F spectrum:
RXA: I've added this plot of the free-running noise of the Lightwave NPRO which is probably similar to our Innolight Mephisto. Seems like the laser is quieter than MC_F everywhere below 100 Hz.
What readouts do we have for the PMC length? If we could have a calibrated & whitened error and control signal for the PMC up to 16 kHz, perhaps we could see at what frequencies we can use it as a faux-RefCav.
In http://nodus.ligo.caltech.edu:8080/40m/11793 I posted the calibrated PMC free-running displcament with/without IMC locked. Unfortunately, this measurement was done with a part of the IMC electronics not perfect (https://nodus.ligo.caltech.edu:8081/40m/11794). I did the same measurement after the fix, but there is no low freq data http://nodus.ligo.caltech.edu:8080/40m/11795.
Assuming we have the similar error signal leve in the low freq band as The entry 11793, the IMC is considered to be noisier than the PMC between 0.8 and 4Hz. But we should do the same measurement with the current electronics.
The PMC calibration can be found in this entry http://nodus.ligo.caltech.edu:8080/40m/11780
I took some training data during Sunday night/Monday morning while the MCL MISO FF was turned on. We wanted to see how much residual noise was left in the WFS1/WFS2 YAW and PITCH signals.
The offline subtractions that can be achieved are:
I need to download data for these signals while the MCL FF is off in order to measure how much subtraction was achived indirectly with the MCL FF. In a previous elog:11472, I showed some offline subtractions for the WFS1 YAW and PITCH before any online FF was implemented either by me or Jessica. From the plots of that eLOG, one can clearly see that the YAW1 signal is clearly unchanged in the sense of how much seismic noise was mitigated indirectly torugh MCL.
Koji has implemented the FF paths (thank you based Koji) necessary for these subtractions to be implemented. The thing to figure out now is where we want to actually actuate and to measure the corresponding transfer functions. I will try to have either Koji or Eric help me measure some of these transfer functions.
Finally, I looked at the ARMS and see what residual seismic noise can be subtracted
I'm not too concerned about noise in the arms as if the WFS subtractions turn out to be promising then I expect for some of the arms seismic noise to go down a bit further. We also don't need to measure an actuator transfer function for arm subtractions, give that its essentially flat at low frequencies, (less than 50 Hz).
In my last post I calculated the different subtractions (offline) that could be done to YARM alone just to get a sense of what seismometers were better witnesses for the Wiener filter calculation.
In this eLOG I show what subtractions can be done when the MCL has FF on (as well as Eric's PRC FF), with the SISO filter described on elog:11496.
The plot below shows what can be done offline,
What is great about this results is that the T240-X and T240-Y channels are plenty enough to mitigate any remaining YARM seismic noise but also to get rid of that nasty peak at 55 Hz induced by the MCL FF filter.
The caviat, I haven't measured the TF for the ETMY actuator to YARM control signal. I need to do this and recompute the FIR filters with the prefiltered witnesses in order to move on to the IIR converions and online FF!
The old MCL filters are not completely useless - I find a factor of ~2 reduction in the MCL RMS when I turn the FF on. It'd be interesting to see how effective the FF is during the periods of enhanced seismic activity we see. I also wonder if this means the old PRC angular FF filters are also working, it'd help locking, tbc with PRMI carrrier...
Update: The PRC angular FF loops also do some good it seems - though the PIT loop probably needs some retuning.
As a starting point, I was looking at some of the old elogs and tried turning on the MCL feedback path with the existing control filters today. I tried various combinations of MCL Feedback and FF on and off, and looked at the MCL error signal (which I believe comes from the analog MC servo board?) spectrum for each case. We had used this earlier this year when EricQ and I were debugging the EX laser frequency noise to stabilize the low frequency excursions of the PSL frequency. The low frequency suppression can be seen in Attachment #1, there looks to be some excess MCL noise around 16Hz when the servo is turned on. But the MC transmission (and hence the arm transmission) decays and gets noisier when the MCL feedback path is turned on (see Attached StripTool screenshots).
I wanted to get a clearer idea of the FSS servo and the various boxes in the signal chain and so Lydia and I poked around the IOO rack and the PSL table - I will post a diagram here tomorrow.
We then wanted to characterize the existing loop. It occurred to me later in the evening to measure the plant itself to verify the model shape used to construct the invP filter in the feedback path. I made the measurement with a unity gain control path, and I think there may be an extra zero @10Hz in the model.
Earlier in the evening, we measured the OLG of the MCL loop using the usual IN1/IN2 prescription, in which above 10Hz, the measurement and FOTON disagree, which is not surprising given Attachment #1.
I didn't play around with the loop shape too much tonight, but we did perform some trials using the existing loop, taking into account some things I realized since my previous attempts. The summary of the performanceof the existing loop is:
All of the above is summarized in the below plots - this behaviour is (not surprisingly) in line with what Den observed back when he put these in.
The eventual goal here is to figure out if we can get an adaptive feedback loop working in this path, which can take into account prevailing environmental conditions and optimally shape the servo to make the arms follow the laser frequency more closely at low frequencies (i.e. minimize the effect of the noise injected by IMC length fluctuations at low frequency). But first we need to make a robust 'static' feedback path that doesn't inject control noise at higher frequencies, I need to think a little more about this and work out the loop algebra to figure out how to best do this...
In the Generic Pentek interface board, which is used to take in the analog 2-pin LEMO cable from the MC Servo board, there is some analog whitening before the signal is sent into the ADC.
There are jumpers in there to set whether it is 0, 1, or 2 stages of 150:15 (z:p) whitening.
Quick summary elog, details to follow. I did the following:
The measurements I have look reasonable. But I had a hard time trying to look at the schematic and determine what is the appropriate number and locations of poles/zeros with which to fit the measured transfer function. Koji and I spent some time trying to go through the MC Servo board schematic, but looks like the version uploaded on the 40m DCC tree doesn't have changes made to it reflected (we compared to pictures on the 40m google photos page and saw a number of component values were different). Since the deviation between fit and measurement only occurs above 1MHz (while using poles/zeros inferred from the schematic), we decided against pulling out the servo board and investigating further - but this should be done at the next opportunity. I've marked the changes we caught on a schematic and will upload it to the 40m DCC page, and we can update this when we get the chance.
So it remains to fit the other two measured TFs, and add them to the Simulink model. Then the only unknown will be the PDH discriminant, which we anyway want to characterize given that we will soon have much more modulation.
Data + plots + fits + updated schematics to follow...
Here are the details as promised.
Attachment #1: Updated simulink model. Since I haven't actually run this model, all the TF blocks are annotated "???", but I will post an updated version once I have run the model (and fix some of the questionable aesthetic choices)
Attachment #2: Measured and fitted transfer functions from the "IN1" input (where the demodulated MC REFL goes) to the "SERVO" output of the MC servo board (to FSS box). As mentioned in my previous elog, I had to put in a pole (fitted to be at ~2MHz, called pole 9 in the plot) in order to get good agreement between fit an measurement up to 10MHz. I didn't bother fitting all the high frequency features. Both gain sliders on the MEDM screen ("IN1 Gain" and "VCO gain") were set to 0dB for this measurement, while the super boosts were all OFF.
Attachment #3: Measured and fitted transfer function from "TEST 1 IN" to "FAST OUT" of the FSS box. Both gains on the FSS MEDM screen ("Common gain adjust" and "fast gain adjust") were set to 0dB for this measurement. I didn't need any ad-hoc poles and zeros for this fit (i.e. I can map all the fitted poles and zeros to the schematic), but the fit starts to deviate from the measurement just below 1 MHz.. perhaps I need to add a zero above 1MHz, but I can't see why from the schematic...
Attachment #4: Measured TF from "TEST 1 IN" to "PC OUT" on the FSS box. MEDM gains were once again 0dB. I can't get a good fit to this, mainly because I can't decipher the poles and zeros for this path from the schematic (there are actually deviations from the schematic posted on the 40m DCC page in terms of component values, I will try and correct whatever I notice) . I'll work on this...
Attachment #5: Data files + .fil files used to fit the data with LISO
Most of the model has come together, I am not too far from matching the modelled OLG to the measured OLG. So I will now start thinking about designing the controller for the MCL part (there are a couple of TFs that have to be measured for this path).
Rana motivated me to take a step back and reframe the objectives and approach for this project, so I am collecting some thoughts here on my understanding of it. As I write this, some things still remain unclear to me, so I am leaving these as questions here for me to think about...
and come up with the best loop that meets all our rquirements? What constitutes the "best" loop? How do we weight the relative importance of our various requirements?
For the specific problem of making the MCL feedback loop better, the approach I have in mind right now is the following:
My immediate goal is to have the Simulink model updated.
Thoughts/comments on the above will be appreciated...
In working on automatic DARM loop design, we have this code:
the things in there like mkCost*, etc. have examples of the cost functions that are used. It may be useful to look at those and then make a similar cost function calculation for the MCL/MCF loop.
I've edited Rana's Simulink model to reflect the current IMC servo topology (to the best of my understanding). I've tried to use Transfer Function blocks wherever possible so that we can just put in the appropriate zpk model in the script that will linearize the whole loop. I've also omitted the FSS SLOW loop for now.
I've been looking through some old elogs and it looks like there have been several modifications to both the MC servo board (D040180) and the TT FSS Box (D040105). I think it is easiest just to measure these TFs since the IMC is still down, so I will set about doing that today. There is also a Pomona Box between the broadband EOM and the output of the TT FSS box, which is meant to sum in the modulation for PMC locking, about which I have not yet found anything on the elog.
So the next steps are:
If anyone sees something wrong with this topology, please let me know so that I can make the required changes.
It is more accurate to model the physical frequency noises at various places.
cf. See also 40m ALS paper or Shigeo Nagano PDH thesis on https://wiki-40m.ligo.caltech.edu/40m_Library
- The output 4 should be "Laser frequency"
- Seismic path should be excluded from the summing node
- The output after the PMC: "Laser frequency after the PMC"
- "Laser frequency after the PMC" is compared (diffed) with the output 1 "mirror motion in Hz"
- The comparator output goes to the cav pole, the PD, and the PDH gain: This is the output named "PDH Error"
- Tap a new path from "Laser frequency after the PMC" and multiply with the cav pole (C_IMC)
- Tap a new path from "Mirror motion" and multiply with the cavity high pass (s C_IMC/omega)
- Add these two: This is the output named "Frequency noise transmitted by IMC"