40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 132 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  14804   Wed Jul 24 04:20:35 2019 KruthiUpdateCalibration-RepairMC2 pitch and yaw calibration

Summary:  I calibrated MC2 pitch and yaw offsets to spot position in mm. Here's what I did:

  1. Changed the MC2 pitch and yaw offset values using  ezca.Ezca().write('IOO-MC2_TRANS_PIT_OFFSET', <pitch offset value> ) and ezca.Ezca().write('IOO-MC2_TRANS_YAW_OFFSET', <yaw offset value> )
  2. Waited for ~ 700-800 sec for system to adjust to the assigned values
  3. Took snapshots with the 2 GigEs I had installed - zoomed in and zoomed out. (I'll be using these to make a scatter loss map, verify the calibration results, etc)
  4. Ran the mcassDecenter script, which can be found in /scripts/ASS/MC. This enters the spot position in mm in the specified text file.

Results:  In the pitch/yaw vs pitch_offset/yaw_offset graph attached,

  • intercept_pitch = 6.63 (in mm) ,  slope_pitch = -0.6055 (mm/counts) 
  • intercept_yaw = -4.12 (in mm) ,  slope_yaw = 4.958 (mm/counts) 
Attachment 1: Pitchyaw_calibration.png
Pitchyaw_calibration.png
  5751   Fri Oct 28 03:12:37 2011 SureshUpdateIOOMC2 realigned to align MC to PSL

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.

MC2_Drift_20111027.png

 

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.

 

 

 

  12973   Fri May 5 08:41:42 2017 SteveUpdateCamerasMC2 resonant pictures

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.

 

Attachment 1: P5040028MC2c.jpg
P5040028MC2c.jpg
Attachment 2: IMG_3682.JPG
IMG_3682.JPG
Attachment 3: IMG_3688.JPG
IMG_3688.JPG
  16969   Fri Jul 1 12:49:52 2022 KojiUpdateIOOMC2 seemed misaligned / fixed

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.

Attachment 1: C1-MULTI_FBDB3F_TIMESERIES-1340668818-86400.png
C1-MULTI_FBDB3F_TIMESERIES-1340668818-86400.png
Attachment 2: C1-LOCKED_MC_5E4267_TIMESERIES-1340668818-86400.png
C1-LOCKED_MC_5E4267_TIMESERIES-1340668818-86400.png
  2431   Fri Dec 18 15:40:33 2009 KojiUpdateIOOMC2 spot centered / MCT QPD issue

This afternoon I felt like saying hello to the input mode cleaner. So I decided to center the spot on MC2.

Motivation

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.


Method

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.


Result

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.


MCT QPD issue

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.

  8169   Tue Feb 26 10:20:31 2013 JamieUpdateSUSMC2 suspension controller reverted to library part

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.

  13737   Fri Apr 6 21:39:09 2018 gautamUpdateIOOMC2 suspension health checkup

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...

Quote:

Why is MC2 LR so different from the others???

 

Attachment 1: MC2_Freeswinging.pdf
MC2_Freeswinging.pdf
  15777   Tue Jan 26 10:58:30 2021 gautamUpdateSUSMC2 tickler stuck on

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.

  9102   Wed Sep 4 16:08:22 2013 manasaUpdateSUSMC2 tickler turned OFF

 [Jenne, Manasa]

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 TICKLERthat 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.

  9104   Wed Sep 4 20:39:23 2013 ranaUpdateSUSMC2 tickler turned OFF

Quote:

 [Jenne, Manasa]

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 TICKLERthat 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.

  9107   Wed Sep 4 22:14:35 2013 JenneUpdateSUSMC2 tickler turned OFF

Quote:

 

 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.

  9108   Thu Sep 5 00:40:33 2013 ranaUpdateSUSMC2 tickler turned OFF

 

 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.

  2077   Fri Oct 9 17:37:21 2009 JenneUpdateIOOMC2 trans beam is dumped

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.

  14883   Mon Sep 16 17:53:16 2019 aaronUpdateCamerasMC2 trans camera (?) rotated

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.

Attachment 1: 47D6ED9C-BF21-4D6E-9947-284FE4A336F4.jpeg
47D6ED9C-BF21-4D6E-9947-284FE4A336F4.jpeg
  14884   Mon Sep 16 19:29:24 2019 KojiUpdateCamerasMC2 trans camera (?) rotated

The left one is analog and 90deg rotated.

See also: This issue tracker

  2331   Wed Nov 25 12:28:22 2009 JenneUpdateSUSMC2 tripped

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.

  7717   Fri Nov 16 00:08:36 2012 KojiUpdateSUSMC2 woes

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.

  9886   Wed Apr 30 21:57:07 2014 ranaSummaryIOOMC2_TRANS QPD Servo now on for real

dolphin.pngMC2_QPD_trend.png

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)

  9857   Fri Apr 25 23:08:57 2014 ranaSummaryIOOMC2_TRANS QPD Servo re-re-engaged again

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.

  9858   Sat Apr 26 13:19:59 2014 ericqSummaryIOOMC2_TRANS QPD Servo re-re-engaged again

Quote:

We turned on the MC2_TRANS paths for both PIT/YAW tonight.

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).

  9869   Mon Apr 28 15:47:57 2014 manasaSummaryIOOMC2_TRANS QPD Servo trend

Quote:

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.

Attachment 1: MC_TRANSservoApr28.png
MC_TRANSservoApr28.png
  9871   Mon Apr 28 20:31:38 2014 ranaSummaryIOOMC2_TRANS QPD Servo trend

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.

Attachment 1: Untitled.png
Untitled.png
  9794   Thu Apr 10 10:52:15 2014 manasaSummaryIOOMC2_TRANS path in WFS servo

Quote:

Quote:

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.

[From yesterday]

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.

  6681   Fri May 25 13:24:48 2012 DenUpdateSUSMC3

AA IN -> COIL DRIVER IN transfer function for MC3

freq_resp.png

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.

test_dig.png

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.

  4685   Wed May 11 10:49:16 2011 valeraConfigurationElectronicsMC3 LL PD has no signal

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.

  9208   Sun Oct 6 22:27:35 2013 ranaFrogsElectronicsMC3 LL sensor cable was loose

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)?

Attachment 1: MC3_LL.png
MC3_LL.png
  13901   Thu May 31 10:19:42 2018 gautamUpdateSUSMC3 glitchy

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.

Attachment 1: MC3_glitchy.png
MC3_glitchy.png
  6680   Fri May 25 02:56:44 2012 DenUpdateSUSMC3 local damping

I've terminated input to AA filters and measured signal to coils C1:SUS-MC3_??COIL_OUT.

DSC_4305.JPG

 

I compared this noise to the signal when OSEM are connected to ADC.

    osem_noise.png

 

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

osem_coil.png

  15957   Wed Mar 24 09:23:49 2021 PacoUpdateSUSMC3 new Input Matrix

[Paco]

  • Found IMC locked upon arrival
  • Loaded newest MC3 Input Matrix coefficients using /scripts/SUS/InMatCalc/writeMatrix.py after unlocking the MC, and disabling the watchdog. 
  • Again, the sens signals started increasing after the WD is reenabled with the new Input matrix, so I manually tripped it and restored the old matrix; recovered MC lock.
  • Something is still off with this input matrix that makes the MC3 loop unstable.
  15971   Sun Mar 28 14:16:25 2021 AnchalSummarySUSMC3 new Input Matrix not providing stable loop

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.


Matrices:

Old (Current) MC3 Input Matrix (C1:SUS-MC3_INMATRIX_ii_jj)
  UL UR LR LL SD
POS 0.288 0.284 0.212 0.216 -0.406
PIT 2.658 0.041 -3.291 -0.674 -0.721
YAW 0.605 -2.714 0.014 3.332 0.666
SIDE 0.166 0.197 0.105 0.074 1

 

New MC3 Input Matrix (C1:SUS-MC3_INMATRIX_ii_jj)
  UL UR LR LL SIDE
POS 0.144 0.182 0.124 0.086 0.586
PIT 2.328 0.059 -3.399 -1.13 -0.786
YAW 0.552 -2.591 0.263 3.406 0.768
SIDE -0.287 -0.304 -0.282 -0.265 0.871

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:

  Guess Values Fittted Values
PIT Resonant Freq. (Hz) 0.771 0.771
YAW Resonant Freq. (Hz) 0.841 0.846
POS Resonant Freq. (Hz) 0.969 0.969
SIDE Resonant Freq. (Hz) 0.978 0.978
PIT Resonance Q 600 345
YAW Resonance Q 230 120
POS Resonance Q 200 436
SIDE Resonance Q 460 282
PIT Resonance Amplitude 500 750
YAW Resonance Amplitude 1500 3872
POS Resonance Amplitude 3800 363
SIDE Resonance Amplitude 170 282

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.

Attachment 1: MC3_Input_Matrix_Diagonalization.pdf
MC3_Input_Matrix_Diagonalization.pdf
  15973   Mon Mar 29 17:07:17 2021 gautamSummarySUSMC3 new Input Matrix not providing stable loop

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.

  5068   Sat Jul 30 07:07:28 2011 kiwamuUpdateASCMCASS status

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.

  12723   Mon Jan 16 21:03:47 2017 ranaSummaryIOOMCL / MCF / Calibration

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.

Attachment 1: c1ioo_zoom_MCLF.png
c1ioo_zoom_MCLF.png
Attachment 2: MCL.pdf
MCL.pdf
  12732   Wed Jan 18 12:34:21 2017 ericqSummaryIOOMCL / MCF / Calibration
Quote:

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.

  12757   Wed Jan 25 18:18:08 2017 KojiSummaryIOOMCL / MCF / Calibration

jiSome notes on the FSS configuration: ELOG 10321

  12905   Fri Mar 24 12:21:27 2017 gautamSummaryIOOMCL / MCF / Calibration

I repeated this measurement as follows:

  1. Added a filter in the MC_F filterbank (FM9) to account for the Pomona box between the PZT control signal and the laser PZT (pole@2.9Hz). So the filter bank at the time of TF measurement looks like this:
  2. Measured TF from driving MC2 (with C1:SUS-MC2_MCL_OUT channel) to C1:IOO-MC_F, which is the output of the above filter bank. The response is the expected 1/f^2 shape of the free optic
     
  3. From this transfer function, the magnitude is 0.0316 ct/ct. Using the value of 6nm/ct for the MC2 actuator gain that I found in a previous elog entry, I calibrated the MC_F output into Hz using the calibration factor 3.95MHz/ct (FM10 in the above filterbank).

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.

Attachment 2: MCF_cal.pdf
MCF_cal.pdf
Attachment 3: MCFTF_mag.pdf
MCFTF_mag.pdf
Attachment 4: MCFTF_phase.pdf
MCFTF_phase.pdf
Attachment 5: MCFTF_coh.pdf
MCFTF_coh.pdf
Attachment 6: FreqNoiseReq.pdf
FreqNoiseReq.pdf
  12907   Mon Mar 27 12:48:36 2017 ranaSummaryIOOMCL / MCF / Calibration

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.

  12912   Mon Mar 27 22:40:44 2017 KojiSummaryIOOMCL / MCF / Calibration

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

  11552   Tue Sep 1 06:58:11 2015 IgnacioUpdateWienerFilteringMCL FF => WFS1 and WFS2 FF => ARMS 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:

For WFS1

 

For WFS2

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).

 

  11510   Sat Aug 15 02:10:35 2015 IgnacioUpdateLSCMCL FF => YARM FF

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!

 

Attachment 1: YARM_LIVES.png
YARM_LIVES.png
  15054   Wed Nov 27 17:51:52 2019 gautamUpdateWienerMCL FF status

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.

Attachment 1: MCL_FF.pdf
MCL_FF.pdf
Attachment 2: PRC_FF.pdf
PRC_FF.pdf
  12623   Thu Nov 17 15:17:16 2016 gautamUpdateIMCMCL Feedback

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).

Attachment 1: MCLerror.pdf
MCLerror.pdf
Attachment 2: MCLtest.png
MCLtest.png
Attachment 3: YarmCtrl.pdf
YarmCtrl.pdf
  12635   Wed Nov 23 01:13:02 2016 gautamUpdateIMCMCL Feedback

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:

  • Below 1Hz, MCL loop injects noise to the arm control signal. I need to think about why this is, but perhaps it is IMC sensing noise?
  • Between 1-4Hz, the MCL loop suppresses the arm control signal
  • Between 4-10Hz (and also between 60-100Hz for the Xarm), the MCL loop injects noise. Earlier in the evening, we had noticed that there was a bump in the X arm control signal between 60-100Hz (which was absent in the Y arm control signal). Koji later helped me diagnose this as too low loop gain, this has since been rectified, but the HF noise of the X arm remains somewhat higher than the Y arm.

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...

Attachment 1: MCL_plant.pdf
MCL_plant.pdf
Attachment 2: OLG.pdf
OLG.pdf
Attachment 3: MC_armSpectra_X.pdf
MC_armSpectra_X.pdf
Attachment 4: MC_armSpectra_Y.pdf
MC_armSpectra_Y.pdf
  12637   Wed Nov 23 15:08:56 2016 ranaUpdateIMCMCL Feedback

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.

  12812   Wed Feb 8 19:13:02 2017 gautamUpdateIMCMCL Feedback - TF measurements

Quick summary elog, details to follow. I did the following:

  • Updated the Simulink model based on Koji's feedback. 
  • Today morning, I measured the (electronic) open-loop TFs of
    • MC Servo Board
    • FSS Fast path (PZT)
    • FSS PC Drive path
  • The summing amplifiers in the latter two paths are assumed to be broadband for the purposes of this model.

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...

 

  12815   Thu Feb 9 23:35:34 2017 gautamUpdateIMCMCL Feedback - TF measurements

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

Quote:

 

Data + plots + fits + updated schematics to follow...

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).

Attachment 1: mc40_v1.pdf
mc40_v1.pdf
Attachment 2: CMboard_OLTF_fit.pdf
CMboard_OLTF_fit.pdf
Attachment 3: FSSFast_OLTF_fit.pdf
FSSFast_OLTF_fit.pdf
Attachment 4: PCdrive_OLTF_measured.pdf
PCdrive_OLTF_measured.pdf
Attachment 5: data.zip
  12793   Fri Feb 3 00:36:52 2017 gautamUpdateIMCMCL Feedback - framing the problem

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...

Objectives

  1. The PSL is locked to the IMC cavity - but at frequencies near 1 Hz, the laser frequency is forced to follow the IMC cavity length fluctuations, even though the free-running PSL frequency noise at those frequencies is lower. This excess is also imprinted on the arms when locked to the IR. We would like to improve the situation by feeding back a portion of the MC PDH error signal to the cavity length actuator to stabilize the MC cavity length at low frequencies. Moreover, we would like this loop to not imprint additional control noise in the arm control signals, which is a problem we have observed with the existing MCL loop. 
     
  2. The borader goal here is to use this project as a case study for designing the optimal loop and adaptive feedback. Can we come up with an algorithm, which takes
    • A model of our system (made with measured data where possible)
    • A list of our requirements (e.g. in this case, frequency noise requirements in various frequency bands, smooth crossovers between the various loops that enable locking the PSL to the IMC cavity and avoid injecting excess control noise into the plant)

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? 


Proposed approach:

For the specific problem of making the MCL feedback loop better, the approach I have in mind right now is the following:

  1. Build a model of the 40m IMC loop. Ultimately the performance of the loop we implement will depend on the transfer function from various additive noise sources and disturbances in the feedback loop (e.g. electronics noise) to the output (i.e. laser frequency). Building an accurate model will allow us to quantify the performance of the proposed control loop, and hence, optimize it with some algorithm. I did some work on a simplistic, purely analytical model of the two MC loops (MCF and MCL), but Rana pointed out that it is better to have something more realistic for this purpose. I have inherited his Simulink models, which I will now adapt to reflect the 40m topology. 
  2. Come up with a list of requirements for the MCL controller. Some things that come to mind:
    • Reduce the arm control signal spectral amplitude below 20 Hz
    • Not increase the arm control signal spectral amplitude above 20 Hz
    • Crossover smoothly with the FSS slow temperature control loop and the MCF loop. 
    • What factor of suppression are we looking for? What is achievable? Once I build the model, it should shed some light on these..
    • Is the PMC a more stable frequency reference than the NPRO crystal at low frequencies? This measurement by Koji seems to suggest that it isn't (assuming the 1e4 product for the NPRO free-running frequency noise)..
  3. Once we have a model and a satisfactory list of requirements, design a control loop that meets these using traditional techniques, i.e. desired tracking error in the control band of 0.1-20 Hz (is this possible? The model will tell us...), gain and phase margin requirements etc. But this need not necessarily be the optimal controller that meets all of our requirements
  4. Optimize the controller - how? Can we define an objective function that, for example, rewards arm control signal suppression and penalizes injection of control noise, and just fminsearch in the [z,p,k] parameter space of the controller? Is there a smarter way to do this?
  5. Can this algorithm be adaptive, and optimize the controller to adapt to prevailing seismic conditions for example? Is this the same as saying we have a model that is accurate enough for us to predict the response of the plant to environmental disturbances? 

My immediate goal is to have the Simulink model updated.

Thoughts/comments on the above will be appreciated...

 
  12795   Fri Feb 3 11:40:09 2017 ranaUpdateIMCMCL Feedback - framing the problem

In working on automatic DARM loop design, we have this code:

https://git.ligo.org/rana-adhikari/ModernControls/tree/master/OptimalFeedback/GlobalCost

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.

  12804   Mon Feb 6 17:03:41 2017 gautamUpdateIMCMCL Feedback - simulink model updated

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:

  1. Measure/estimate all the unknown TFs and gains in this schematic
  2. Linearize the model, get the OLG, see if the model matches previously measured OLGs (with the MCL part disabled)
  3. Once the model is verified to be correct, look at couplings of various noise sources in the MCL part of the loop, and come up with a suitable controller.

If anyone sees something wrong with this topology, please let me know so that I can make the required changes.

Attachment 1: mc40_v1.pdf
mc40_v1.pdf
  12805   Mon Feb 6 18:20:08 2017 KojiUpdateIMCMCL Feedback - simulink model updated

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"

ELOG V3.1.3-