I did a quick measurement of the beam size on the MC REFL PD today morning. I disabled the MC autolocker while this measurement was in progress. The measurement set up was as follows:
This way I was able to get right up to the heat sink - so this is approximately 2cm away from the active area of the PD. I could also measure the beam size in both the horizontal and vertical directions.
The measured and fitted data are:
The beam size is ~0.4mm in diameter, while the active area of the photodiode is 2mm in diameter according to the datasheet. So the beam is ~5x smaller than the active area of the PD. I couldn't find anything in the datasheet about what the damage threshold is in terms of incident optical power, but there is ~100mW on th MC REFL PD when the MC is unlocked, which corresponds to a peak intensity of ~1.7 W / mm^2...
Even though no optics were intentionally touched for this measurement, I quickly verified that the spot is centered on the MC REFL PD by looking at the DC output of the PD, and then re-enabled the autolocker.
Riju did the measurement of the MCREFL PD.
I found data files in her directory on the control machine.
I was not sure how much was the transimpedance of the DC out.
I assumed the default number from the circuit diagram which was 66.7Ohm.
This may cause the error in absolute caribration of the transimpedance but the shape does not change.
The RF preamp is gain-peeking at 250MHz.
Here is further characterization of the PD response.
As you can see in the second attachment, the 3dB cut off of the resonance is about 2.3MHz.
The game plan file in dropbox was also modified.
I've added MCL and WFS stop triggers into C1MCS/SUS model. Threshold value of MC_TRANS can be changed in the text entry located in MC2_POSITION medm screen. I tried 2 cases: trigger either blocks signal before MCL filter bank input or after output. Due to filter history in the 1 case MC2 was still slightly disturbed (C1:SUS-MC2_ULPD_VAR ~= 15) right after unlock. In the second case there was no disturbance as we zero output signal, but then I had to add "clear history" command to the mcup script.
WFS triggers block the signal before ASCPIT/YAW filter bank.
I've redone the WFS triggers. I left the MCL trigger alone (for now....I'll come back to it).
The trigger was setup such that (a) it was totally unclear what was going on, by looking at the WFS screen. Koji and I spent some time confused before I remembered that Den did this work recently. Also, for some reason, the triggers were just plain thresholding, not a schmidt trigger, so any time the cavity flashed, the WFS came on. Since the cavity can flash before the mcdown script has a chance to turn off the WFS servos, the outputs of the WFS filters are trying to output thousands of counts, and the signal goes through any time the cavity flashes. Not so good.
I have removed the triggering for the angular DoFs from the mcs model (leaving the MCL triggering for now). I have put new triggering into the ioo model, at the error point of the WFS loops. The idea is that if the cavity unlocks, we don't want to lose the current pointing of the mirrors. If the WFS servos were doing a lot of DC work, the bias sliders won't have the full information about where we want the mirrors to point. Since we have the integrators in FM1, removing the input signal should freeze the output signal. I need to modify the WFS on / off script so that this doesn't get turned off every lockloss.
Also, I have implemented (for the first time in a useful model, although I've done some testing in the tst model) the "wait" delay between a cavity locking and the trigger going through. The idea is that we don't necessarily want the WFS to come on simultaneously with the cavity lock. Since the wait delay resets any time it is un-triggered, this also prevents any signals from going through during cavity flashes. The wait block has 3 inputs: (1) a trigger, the output of some kind of trigger block, (2) a number of seconds to wait and (3) the model rate in Hz. The model rate should be set with a constant in the model, the trigger passed from the trigger block, and the wait time in seconds should be available as an epics input.
So far it looks like it's working as I expect, although I'm honestly too tired to do enough testing that I'm satisfied with, so I'm leaving the WFS off for the night.
I've redone the WFS triggers. I left the MCL trigger alone (for now....I'll come back to it).
Your schmitt trigger has 2 threshold values - min and max. Set thresholding value in my trigger to the max of your schmitt trigger and you get the same behavior for MC, triggers are not supposed to turn anything on in this realization as they do for locking with flashing.
The problem is that the WFS were being engaged with your triggers every time the MC flashed. That wasn't a schmidt trigger thing, but I like the schmidt trigger better anyway.
Anyhow, it's turned on, and it works really well. It's kind of awesome. I'm really excited to start using the wait block to start pushing even more of the locking out of scripts and into the real time system.
I did a raw calibration of MCL and GUR. Accuracy is a factor of 2.
GUR path : 800 V/m/s => readout box (G~100) => ADC (0.7 mV/count)
MCL path : laser 1 MHz / V, cavity length ~ 25 m
I measured feedback signal before the laser with SR and avoided whitening filters for MC_F.
I turned on some filters and gain in the SUS-MC2_MCL filter bank tonight so as suppress the seismic noise influence on MC_F. This may help the MC stay in lock in the daytime.
Koji updated the mcdown and mcup scripts to turn the MCL path on and off and to engage the Boost filters at the right time.
The attached PNG shows the MCL screen with the filters all ON. In this state the crossover frequency is ~45 Hz. MC_F at low frequencies is reduced by more than 10x.
I also think that this may help the X-Arm lock. The number of fringes per second should be 2-3x less.
MC down script is too slow to block MC_L when the cavity goes out of lock. As a result the loop strongly kicks MC2. We decided to make a threshold inside MCS model on MC TRANS that will block MC_L during lock loss. This is a lower threshold. Upper threshold can be slow and is implemented inside MC up script.
Fast threshold can be set inside MC2 POS. I did not correct MC2 top level medm screen as it is the same for all core optics.
Note: Fast trigger will also block ALS signal if MC loose lock.
As MCL is disturbing arm locking by injecting a lot of noise, I have modified 'mcup' to disable MCL
As MC WFS keeps failing to start up when it is locked, the lines in 'mcwfsoff' to clear WFS filter history were restored.
(updateAfter Eric gave me feedback on my previous elog post, I went back and fixed some of the silly stuff I stated.
First of all, I have come to realized that it makes zero sense to plot the ASD's of the mode cleaner against the seismometer noise. These measurements are not only quite different, but elementary, they posess different units. I have focused my attention to the MCL being Wiener filtered with the three siesmometer signals.
One of the major improvements that I make in the following analysis is,
1) Prefiltering; a band pass filter from 1 to 5 Hz, in order to emphasize subtraction of the bump shown in the figure below.
2) I have used vectfit exclusively in the 1 to ~5 Hz range, in order to model the FIR filter properly, as in, the kind of subtraction that we care about. Limiting myself to the 1 - 5 Hz range has allowed me to play freeley with the number of poles, hence being able to fit the FIIR filter properly with an IIR rational transfer function properly,
The resulting ASD's are shown below, in blue we show the raw MCL output, in blac the Wiener filter (FIR) result, and finally in black, the resultant data being filtered with the calculated IIR Wiener filter.
Now, in the following plots I show the IIR Wiener filters for each of the three seismometers,
For the Y seismometer,
and for the Z seismometer,
The matlab code for this work is attached: code.zip
We took data for the mode cleaner a while ago, June 30th I believe. This data contained signals from the six accelerometers and the three seismometers. In here I have only focused on the seimometer signals as witnesses in order to construct Wiener filters for each of the three seismometer signals (x,y,z) and for the combined seismometers signal. The following plot showing the ASD's shows the results,
Wiener filtering works beautifully for the seismometers. Note that subtraction is best when we use all three seismometers as the witnesses in the Wiener filter calculation, as can be clearly seen in the first plot above.
Now, I used vectfit to conver the Wiener FIR filters for each seismometer to their IIR versions. The following are the bode plots for the IIR filters,
For the x-direction seismometer,
For the y-direction seismometer
And for the z-direction seismometer,
The IIR filters were computed using 5 zeros and 5 poles using vectfit. That was the maximum number of poles that I could use wihtout running into trouble with matrices being almost singular in Matlab. I still need to figure out how to deal with this issue in more detail as fitting the y-seismometer was a bit problematic. I think having a greater number of poles will make the fitting a bit easier.
After fighting relentlessly with the mode cleaner, I believe I have achieved final results.
I have mostly been focusing on Wiener filtering MCL with a SISO Wiener filter for a reason, simplicity. This simplicity allowed me to understand the dificulties of getting a filter to work on the online system properly and to develope a systematic way of making this online Wiener filters. The next logical step after achieving my final SISO Wiener filter using the T240-X seismometer as witness for MCL (see elog:11535) and learning how to produce good conditioned Wiener filters was to give MISO Wiener filtering of MCL a try.
I tried performing some MISO filtering on MCL using the T240-X and T240-Y as witnesses but the procedure that I used to develope the Wiener filters did not work as well here. I made the decision to ditch it and use some of the training data I saved when the SISO (T240-X) filter was runing overnight to develope another SISO Wiener filter for MCL but this time using T240-Y as witness. I will compare how much more we gain when doing MISO Wiener filtering compared to just a bunch of SISO filtering in series, maybe a lot, or little.
I left both filters running overnight in order to get trainining data for arm and WFS yaw and pitch subtractions.
The SISO filters for MCL are shown below:
The theoretical FIR and IIR subtractions using the above filters:
Running the filters on the online system gave the following subtractions for MCL and YARM:
Comparing the subtractions using only the T240-X filter versus the T240-X and T240-Y:
Somehow it seems like the ELOG makes all of the thumbnails way too big by default. Did we get some sneaky upgrade recently?
I would only plot your results below 50 Hz. We don't care about the RMS at high frequencies and it can make the RMS misleading.
We definitely need to include one vertical Wilconox at each MC chamber so that it can subtract all of that junk at 10-20 Hz.
Big thumbnails? Could it have been this? elog:11498.
Anyways, I fixed the plots and plotted an RMS that can actaully be read in my original eLOG. I'll see what can be done with the MC1 and MC2 Wilcoxon (z-channel) for online subtractions.
Ignacio is correct; I forgot to shrink the value back down after testing the PDF thumbnails. Default thumbnail size is now back to 600px.
I'm not totally sure, but by eyeball, this seems like the best online MCL reduction we've ever had. Nice work.
The 3 Hz performance is the same as usual, but we've never had such good 1 Hz reduction in the online subtraction.
I would like to see a plot of the X & Y arm control signals with only the MCL filter ON/OFF. This would tell us how much of the arm signals were truly frequency noise.
Today I finished fitting the transfer function to a vectfit model for seismometers T240_X and T240_Y, and then used these to filter noise online from the mode cleaner.
The Bode plot for T240_X is in figure 1, and T240_Y is in figure 2. I made sure to weight the edges of the fit so that no DC coupling or excessive injection of high frequency noise occurs at the edges of the fit.
I used C1:IOO-MC_L_DQ as the first channel I filtered, with C1:IOO-MC_L_DQ(RMS) for RMS data. I took reference data first, without my filter on. I then turned the filter on and took data from the same channel again. The filtered data, plotted in red, subtracted from the reference and did not inject noise anywhere in the mode cleaner.
I also looked at C1:LSC-YARM_OUT_DQ and C1:LSC-YARM_OUT_DQ(RMS) for its RMS to see if noise was being injected into the Y-Arm when my filter was implemented. I took reference data here also, shown in blue, and compared it to data taken with the filter on. My filter, in pink, subtracted from the Y-Arm and injected no noise in the region up to 10 Hz, and only minimal noise at frequencies ~80 Hz. Frequencies this high are noisy and difficult to filter anyways, so the noise injection was minimal in the Y-Arm.
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"
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.
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).
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.
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.
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!
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).
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
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.
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.
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
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 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)?
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.
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.
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.
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.
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.