40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 127 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  8471   Mon Apr 22 17:06:42 2013 ranaSummaryIOOMC locked/aligned. MC WFS offloading by ezcaservo

 

 Why use the PSL beam as a reference? Don't we want to keep the MC pointing in a good direction through the Faraday instead???

  1229   Thu Jan 15 09:19:32 2009 steveUpdateIOOMC locking
MC2 sus damping was found tripped at the morning the second time this week.

Damping was restored, ISS gain lowered to avoid saturation, MZ manually locked
and MC locking was back.
  8424   Mon Apr 8 22:43:44 2013 ranaUpdatePSLMC locking troubles: MC/FSS servo unstable

The MC seemed to be losing lock recently quite a bit. I noticed that the PC Drive RMS signal was red.

This means that the high frequency drive to the Pockels cell was too high by a factor of 2-3 and sometimes saturating and breaking the lock.

I fiddled with the gains on the FSS screen until this value went down. It looks like there is some kind of high Q oscillation; it takes a couple minutes for the PC Drive RMS to settle to its new position after changing the gains.

The attached trend plot show the last 2 hours. The mean is now back to ~1 V and seems OK. We should really examine the FSS or MC error point spectra with the RF analyzer while exploring this gain space.

Attachment 1: Untitled.png
Untitled.png
  1821   Mon Aug 3 14:47:53 2009 JenneUpdateIOOMC locks again

The mode cleaner seems to be locking again.  I've manually unlocked it a few times in the past 20min, and most of the time it catches lock again (maybe about 80% of the time).  Other times, it starts to lock in a bad mode, and can't fix itself, so I unlock it, and let it restart and it usually does fine the second time around. 

 

I'd like it to be a little more robust, but I'm having a bit of trouble zeroing in on the optimal alignment for quickest, most durable lock aquisition of the MC.  Right now I'm going to leave it for a little while to make sure it doesn't fall apart.

  125   Tue Nov 27 15:47:17 2007 robConfigurationIOOMC loop
After the FSS running pretty quick, I checked the MC loop. I used TPA 1&2.

MC loop
UGF: 70kHz
Input Gain: 29dB
Boost Level: 2
phase: 40 deg
Attachment 1: MCsmall.jpg
MCsmall.jpg
  126   Tue Nov 27 16:18:58 2007 robConfigurationIOOMC loop
Reduced the common gain to 22dB in the mcup script, so that the WFS would not blow the lock. The above measure of the OLG was done without the mcWFS running, so may be a low estimate as compared to when the alignment is perfect.
  10851   Sun Jan 4 22:08:46 2015 ranaUpdateIOOMC loop characterizations: PZT/EOM crossover

 * PMC + MC were unlocked when I came in.

* I fiddled around some more with the mcup/down scripts to make locking snappier. The locking was breaking the PMC lock often, so I re-enabled the MC servo board output limiter during acquisition. It is disabled in the MC UP script.

* Re-measured the MC OLG. Still OK.

* Measured the PZT / EOM crossover (aka the FAST / PC crossover) using the connectors on Koji's summing box. With the FAST gain at 18 dB, the crossover is ~10 kHz. Looks way to shallow. Plots to follow.

* I finally discovered today that the PMC PZT stroke is what's causing the main mis-alignment of the beam going to the IMC. By relocking at a few positions, I could see that the IOO QPDs have steps when the PMC relocks. So the IO beam wander is NOT due to temperature effects on the optics mounts of the PSL table. I wonder if we have a large amount of length to angle coupling or if this is the same as the OMC PZTs ?

P.S. I found that someone is using a temporary bench power supply to power the summing box between the TTFSS and the Thorlabs HV driver...whoever did this has ~48 hours to hook up the power in the right way or else Koji is going to find out and lose it and then you have to wear the Mickey Mouse hat.

http://www.arroyoinstruments.com/files/Arroyo-UsingBenchPowerSupplies_11Apr.pdf


The first attachment shows the OLG measurements with 2 different values of the fast gain (our nominal FG is 18 dB). You can see that the higher gains produce some crossover instability; when tuning the gain we notice this as an increase in the PCDRIVE rms channel.

The second attachment shows the measurement of the 'crossover'. Its really just the direct measurement of the IN1 / IN2 from the FAST summing box, so its the crossover measurement where the OLG is high.

Attachment 1: MC_OLGs.pdf
MC_OLGs.pdf
Attachment 2: MC_xover.pdf
MC_xover.pdf
  8906   Tue Jul 23 13:55:08 2013 KojiUpdateIOOMC manually aligned

The MC was manually aligned. The spot positions were measured and it is consistent with the measurements done yesterday.

Attachment 1: MCalignment.png
MCalignment.png
Attachment 2: MCspot.png
MCspot.png
  9030   Mon Aug 19 11:30:20 2013 JenneUpdateIOOMC mirrors' ASC has non-zero inputs

[Masayuki, Jenne]

When I came in this morning, I noticed that the Mode Cleaner had not been locked for at least the past 8 hours.  We moved the MC SUS sliders until the MC SUSPIT and SUSYAW values for each mirror were back to approximately the place they were the last time the MC was nicely locked (~12 hours ago).  This got the MC flashing TEM00, so we thought we were doing well. 

However, if the servo was enabled, any time the cavity flashed a small-order mode (especially 00), the mirrors would get super kicked.  Not good

We went to investigate, and discovered that the RFPD aux laser was left on again.  We turned that off, however that didn't fix the situation. 

Manasa suggested checking that the WFS were really, really off.  When we looked at the WFS master screen, we noticed that although the WFS servos were off, the MC mirrors' ASC filter banks had non-zero inputs.  We checked, and this is not from the MCASS, nor is it from the MC WFS lockins.  At this point, I have no idea where these signals are coming from.  I have turned off the ASC outputs for all the MC mirrors (which means that we cannot turn on the WFS), and the MC locks fine

So, we need to know where the ASC signals are coming from.  There isn't anything that I can see, from any screen that I can find, that indicates some signals being sent over there.  Has anyone done anything lately?  I know Koji was working on IPC stuff the other day, but the MC was locking fine over the weekend until yesterday afternoon, so I suspect that's not the culprit. 

I have turned off the outputs of the WFS lockins, as part of my turning things off, so if whatever script needs them doesn't enable them, they should be turned back on by hand.

  9032   Mon Aug 19 15:23:07 2013 KojiUpdateIOOMC mirrors' ASC has non-zero inputs

[Jenne, Koji]

This disturbance in the MC ASC channels were fixed.

This craziness happened ~10pm last night. Was there any action at the time? >> Sunday-night workers? (RXA: No, Nakano-kun and I left before 9:30 PM)

We found that the signals came from c1ioo. However, restarting, recompiling c1ioo and c1mcs didn't help
to clean up this issue. Just in case we cleaned up the corresponding entries in the ipc file /opt/rtcds/caltech/c1/chans/ipc/C1.ipc
and recomplied c1ioo and c1mcs because these are the channels we touched last week to mitigate the timing out issue of c1rfm.

Incidentally, we fell into a strange mode of the RCG: IOPs could not restart. We ended up running "sudo shutdown -r now"
on each machine (except for c1lsc which was not affected by this issue). This solved the issue.

Even now c1oaf could not be running properly. This is not affecting the IFO operation right now, but we need to look into this issue again
in order to utilize OAF.

  5236   Mon Aug 15 10:58:52 2011 kiwamuUpdateIOOMC misaligned a lot

This morning Steve and I opened the doors on the IOO and OMC chamber to let the IR beam go to MC.

And found the MC flashing is way far from TEM00, there were very higher order modes.

The MC suspensions were realigned based on an assumption that the incident beam didn't change recently.

Anyways we should check the leveling of the IOO table and the spot positions on the MC mirrors again to make sure.

  15173   Wed Jan 29 03:05:47 2020 rana, gautamUpdateSUSMC misalignments / sat box games

In the last couple days, as the IMC ringdowns have been going on, we have noticed that the MC is behaving bad. Misaligning, drifting, etc.

Gautam told me a horror story about him, Koji, and melted wires inside the sat boxes.

I said, "Its getting too hot in there. So let's take the lids off!"

So then we:

  1. Removed the lid (only 4 screws were still there)
  2. cut off some of the shield - ground wires and insulated them with electrical tape
  3. squished the IDC connectors on tightly
  4. left it this way to see if MC would get better - certainly the painfully hot heatinks inside the box were now just 110 F or so

After some minutes, we saw no drifting. So maybe my theory of "hot heatsink partially shorting a coil current to GND through partially melted ribbon cable" makes sense? IF this seems better after a month, lets de-lid all the optics.

Let's look at some longer trends and be very careful next to MC2 for the next 3 days! I have put a dangerous mousetrap there to catch anyone who walks near the vacuum chamber.

gautam: the grounding situation per my assessment is that the shield of all the IDC cables are connected to a common metal strip at 1X5 - but in my survey, I didn't see any grounding of this strip to a common ground.

Attachment 1: IMG_8366.JPG
IMG_8366.JPG
  4340   Tue Feb 22 23:40:31 2011 KojiUpdateIOOMC mode mach improvement

As per Kiwamu's request I made a light touch to the input steering and the mode matching lens.

Here V_ref and V_trans are C1:IOO-MC_RFPD_DCMON and C1:IOO-MC_TRANS_SUM, respectively.

Result: Visibility = 1 - V_ref(resonant) / V_ref(anti_reso) = 1 - 0.74 / 5.05 = 85%

What has been done:

  • Alignment of the steering mirrors before and after the last mode matching lens
       V_ref: 2.7 ==> 2.2, V_trans: 34000 ==> 39000
  • Moving of the last mode matching lens away from the MC (+ alignment of the steering mirrors)
       V_ref: 2.2 ==> 0.74, V_trans: 39000 ==> 55000
Attachment 1: IOO_MMT_110222.png
IOO_MMT_110222.png
  9632   Thu Feb 13 13:18:33 2014 manasaUpdateIOOMC needed some help

The MC has been funny since yesterday. I checked the suspensions INMON channels and they seemed ok. So I went ahead and tweaked the alignment with WFS disabled (yesterday). Although the WFS PDs were cenetered at this point, the WFS servo was throwing the MC in a not-so-happy state. We worked with the WFS servo OFF all of yesterday.

This morning,

* I fine tuned the MC alignment from yesterday (TRANS_SUM > 17800 counts)

* measured the spot positions

* recentered the spots on the WFS PDs (was already quite centered)

*reset the WFS filterbank offsets.

The MC has been locked happily since then with autolocker and WFS servo enabled.

  5928   Thu Nov 17 17:03:28 2011 MIrkoUpdateIOOMC noise projection

Another go at the noise projection from MC1-3 pit/yaw to MC length. This time injecting into the MC autoalignment FB (e.g. C1:IOO-WFS1_PIT_EXC ).

LTPDA is working now, but still the NDS server is not so cooperative.

Summary: Alignment fluctuations of the MC mirrors don't significantly contribute to MC length changes up to at least 3.5Hz. Especially they can't explain the lack of coherence between seismometers and MC length below 1Hz that we worry about for the OAF.

At high frequencies >= 10Hz you can see angle to length coupling as is evident in Sureshes spot position measurements.

Whiteish noise injection:

Injection from 0.1-20Hz.Filtered by the servo filters and zp:[1],[1] , Gain = 1 @ 2Hz

 MCLengthToAngleCouplingNoiseProjection.png

Look at the coherence plots for the quality of the measurement:

Coherence_WFS1pit.png

Coherence_WFS2pit.png

 

Coherence_WFS1yaw.png

 Coherence_WFS2yaw.png

Injection details:

DOF      Amplitude[counts]        UTC Time (duration always 4mins)
WFS1p  70                               22:28
WFS1y  55                               22:03
WFS2p  70                               22:13
WFS2y  70                               22:18
None      -                                 22:23

Fixed sine injections:

To get some better SNR at low frequencies I did a fixed sine noise injection at 0.3Hz. See attached files.

DOF      Amplitude[counts]        UTC Time (duration always 4mins)    Lower limit of SNR MC length via mirror misalignment
WFS1p  4                                  00:05                                                29.3
WFS1y  4                                  00:14                                                22.0
WFS2p  4                                  00:19                                                18.5
WFS2y  4                                  00:25                                                18.0

Attachment 2: WFS1pit.png
WFS1pit.png
Attachment 3: WFS1yaw.png
WFS1yaw.png
Attachment 4: WFS2pit.png
WFS2pit.png
Attachment 5: WFS2yaw.png
WFS2yaw.png
Attachment 7: Coherence_WFS2pit.png
Coherence_WFS2pit.png
Attachment 11: NpWfs.pdf
NpWfs.pdf NpWfs.pdf NpWfs.pdf NpWfs.pdf NpWfs.pdf
  9322   Thu Oct 31 15:34:28 2013 manasaUpdateIOOMC not happy since yesterday

Quote:

 

8 day minute trend of some of the IMC alignment signals.

That step ~2 days ago in the WFS2 yaw control signal shows that I didn't do such a good job on yaw.

Nic is going to come over some time and give us a new Gouy telescope that let's us have bigger beams on the WFS. At LLO, Hartmut demonstrated recently how bigger beams can reduce offsets somehow...mechanism TBD.

Also, we must angle the WFS and figure out how to dump the reflections at the same time that we rework the table for the telescope.

Steve, can you please put 2 mounted  razor dumps near the WFS for this purpose??    

            Tuesday: Razor dumps are waiting for you.

 

The MC has not been able to hold lock for over a couple of hours since yesterday. I aligned the MC yesterday (elog 9320) and it lost lock in a couple of hours. I realigned the MC again around noon today only to see it drifting and lose lock again.

I have attached the MC trend for the 2 hours when the MC drifted slowly from its happy to sad state.

 

 

Attachment 1: MC_drift.png
MC_drift.png
  1803   Wed Jul 29 11:58:57 2009 AlbertoUpdatePSLMC not locking

This morning I found the Mode Cleaner unlocked.

I check the sliders for the mirrors bias and they have not changed. Also the OSEMs readbacks show no change in the optics positions.

I don't understand what's wrong because in the previous days, in this state of alignmanet, it could lock.

I tried to tweak a little bit the periscope to check whether it was a problem of beam matching but that didn't help the cavity to lock.

I don't want to change the periscpe alignment to much becasue I believe it is still good and I suspect that there is something else going on.

  872   Fri Aug 22 17:03:41 2008 YoichiUpdateIOOMC open loop TF
I measured the open loop TF of the overall MC loop using the sum-amp A of the MC board.
I used the Agilent 4395A network analyzer and saved the data into a floppy disk. However, the data was corrupted when
I read it with my computer. I had the same problem before. The floppy is not reliable. Anyway, I have to re-measure the TF.
From what I remember, the UGF was around 25kHz and the phase margin was less than 15deg.
Above this frequency, the open loop gain was almost flat and had a small bump around 100kHz.
This bump has a gain margin of less than 4dB (the phase is more than 180deg delayed here).
So the MC is marginally stable and either decreasing or increasing the gain will make it unstable easily.
Probably, the broken FSS is responsible for this. We have to fix it.

During the measurement, I also found that the input connectors (IN1 and IN2) of the MC board are freaky.
These are TNC connectors directory mounted on the board. Gently touching the cables hooked up to those connectors
caused a large offset change in the output.
When Rana pulled the board out and pushed it in firmly, the strange behavior went away. Probably, the board was
not correctly inserted into the backplane.
This could have been the reason for the MC unlocks.
  928   Thu Sep 4 17:17:03 2008 YoichiUpdateIOOMC open loop TF
I measured open loop transfer functions of the MC servo.
The UGF was about 30kHz. Since there was some gain margin at higher frequencies, I increased
the input gain of the MC servo board from 19dB to 22dB. Now the UGF is 40kHz and we have more
phase margin (~30deg).
Attachment 1: MC-OPLTF.png
MC-OPLTF.png
  2698   Tue Mar 23 00:31:51 2010 KojiUpdateIOOMC realigned

This is the first touch to the MC mirrors after the earthquake on 16th.

  • I made an aluminum access connector so that we can work on the MC even the door is open. We still can be able to open the aluminum tube. The photos are attached. Steve, could you please look it at a glance whether the seal is enough or not.
  • MC resonances were flashing. Align MC2 and MC3 so that we have many TEM00s.
  • Found c1vmesus2 gone mad. Restarted remotely according to the wiki entry. 
  • Reset the MC coil output matrix to 1. (Previously, balance was adjusted so that A2L was minimized.)
  • Excite MC2 Pitch/Yaw at 8 and 9 Hz, looking at the peaks in the MC-MCL output. Move MC2 Pitch/Yaw so that the peak
    is reduced. (*)
  • MC1/MC3 were aligned so that we get the maximum transmission (or minimum reflection). (**)
  • Repeat (*) and (**)

So far, I have aligned in Yaw such that the yaw peak is minimized.

Attachment 1: IMG_2346.jpg
IMG_2346.jpg
Attachment 2: IMG_2347.jpg
IMG_2347.jpg
  5990   Wed Nov 23 16:55:57 2011 SureshUpdateIOOMC realigned

The PSL alignment into the MC was too poor for the autolocker to engage.  So retaining the last coil slider settings on the MC_Align screen that Kiwamu wanted, I have realigned the PSL beam and recentered the beam on the WFS.

When the WFS_MASTER was burtrestored after the recent power shutdown, the values loaded into the output matrix were not optimal.  When we switch on the WFS loops now, the MC_TRANS loops seem to push the WFS into away from the best possible coupling to PSL.  So I have switched them off for now.   Will load a new optimised output matrix and measure the transfer functions to see what is going on.

 

 

  5283   Tue Aug 23 02:03:04 2011 SureshUpdateIOOMC realigned and spot positions recentered

After the MC1 and MC3 OSEMs were  repositioned  MC had to be realigned and the beam spots had to be recentered on the actuation nodes.  

To do that I had to change the input beam direction into the MC  and the coil offsets.   

I also measured the resultant spot positions

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
    0.1354   -0.2522   -0.1383   -1.0893    0.7122   -1.5587

mcdecenter20110822.png

 

The MC1 and MC3 yaw can be improved further after the chambers are closed and evacuated.  The PZT adjustments needed to realign the input beam pointing are quite small and should not pose a problem.

 

 

  5799   Thu Nov 3 17:19:54 2011 SureshUpdateIOOMC realigned to center the spots on actuation nodes

Several activities in the past week (elog1, Mirko's rough realignment of MC and adjustment of the PSL zig-zag on Monday and elog2 ), had led to an MC state where the spots were not centered on the actuation nodes.

The change in the C1IOO model part dealing with MC_ASS led to the disappearance of all MC_ASS filter definitions in the lockins.  I have fixed all that, remade the screens and scripts for making the MC Decenter measurements.

I have just completed the re-centering of the spots on the MC and this of course will lead to some change in the input pointing. 

The MC_REFL beam also was recented on the WFS and the MC2_TRANS QPD.

Will add the mc-decenter measurement in a few mins

  5803   Thu Nov 3 22:32:48 2011 SureshUpdateIOOMC realigned to center the spots on actuation nodes

Quote:

Several activities in the past week (elog1, Mirko's rough realignment of MC and adjustment of the PSL zig-zag on Monday and elog2 ), had led to an MC state where the spots were not centered on the actuation nodes.

The change in the C1IOO model part dealing with MC_ASS led to the disappearance of all MC_ASS filter definitions in the lockins.  I have fixed all that, remade the screens and scripts for making the MC Decenter measurements.

I have just completed the re-centering of the spots on the MC and this of course will lead to some change in the input pointing. 

The MC_REFL beam also was recented on the WFS and the MC2_TRANS QPD.

Will add the mc-decenter measurement in a few mins

 The current MC spot decentering is given below:

spot positions in mm:

MC1P     MC2P     MC3P      MC1Y     MC2Y     MC3Y

0.4089    0.4800   -0.1266   -1.4095    0.3808   -1.7517

 

The yaw measurement probably has the wrong scale factor in the conversion to mm.  It could be under estimated by a factor 2.65/2.00 since the 10% step in coil gains produces a 2mm offset rather than the expected 2.65mm.  See the figures below.  I will check this during the next iteration when another mode clearner alignment comes up.

As I had to redefine all the MC_ASS lockin filters it is possible that Lockin phase might have changed by a few degrees giving rise to a change in the scale factor.

20111103_1.png    20111103_2.png

  503   Thu May 29 15:58:44 2008 JohnSummaryIOOMC realignment
I repeatedly adjusted the yaw of the upper mirror on the input periscope and re aligned the MC. With the PRM aligned I tried to optimise MC transmission and DC refl simultaneously. I subsequently centred the beams on WFS1/2. Attached is a 30 day trend of MC alignment and transmission.
  5482   Tue Sep 20 15:54:42 2011 kiwamuUpdateCamerasMC refl camera is available

[Suresh / Kiwamu]

 The MC REFL camera is now available. The camera name is "MCR" and you can call it from the videoswitch script.

 

(what we did)

 + repositioned and aligned the MCR camera.

 + checked the MCR camera.

  => found the camera view shows a negative image (i.e. the beam spot is dark and the background is bright !!)

 + replaced the camera by a spare one.

 + modified the videoswitch script because the input channel 3 was wrongly assigned to MCR.

  MCR was correctly assigned to the input channel 18.

  2444   Tue Dec 22 11:23:51 2009 kiwamu, SteveUpdateIOOMC relocked

In this morning I found MC unlocked.

Steve restored the watchdogs before I found that.

Then I relocked MC and now MC is locked and working well.

The reflected DC power is ~0.38, which is usual number.

 

  9999   Wed May 28 14:13:06 2014 manasaUpdateIOOMC relocked

Quote:

MC wouldn't relock, it looked misaligned in pitch and yaw on MC camera.

I've touched the alignment, and gotten the reflection below 0.5, but it unlocks periodically, spot positions aren't great, and turning on WFS throws it out of alignment. ughhhhh


The IMC has not been happy since the weekend and were left with WFS disabled because of the bad alignment state that the MC has been left at.

I realigned the MC mirrors and brought down MC_REFL to 0.42 and MC_TRANS_SUM came up to ~ 17400 counts.

I measured the spot positions after alignment. MC1 and MC3 are slightly off in pitch :

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
[2.0535418031770249, 0.84870716159663184, 1.9759940800847962, -1.6706240175650202, 0.089441353070240759, -1.0339963871771678]

I reset the WFS filterbank offsets and engaged the MCWFS servo. Atleast now the MC is not being thrown out of lock with WFS enabled. I have NOT touched the alignment to the WFS PDs.

  18   Fri Oct 26 16:19:29 2007 Tobin FrickeRoutineIOOMC resonances
We would like to measure the absorption of the mode cleaner optics. The plan is to repeat <a href="http://ilog.ligo-wa.caltech.edu:7285/mLIGO/Cleaning_the_Mode_Cleaner">Valera's experiment</a> in which we track the MC's thermal resonances to infer their power absorption. Last night Rana and I hooked up a lock-in amplifier to heterodyne the MC servo signal by 28 kHz and piped the output into an ADC using the MC_AO channel. We did not find any resonances.

Valera recommends we drive the POS of the three MC optics with bandlimited noise to excite the resonances.
  80   Wed Nov 7 14:05:59 2007 tobinConfigurationIOOMC ringdown
Modeling the mode cleaner as a simple cavity with all losses lumped together, we expect the cavity power to be
attenuated by a factor (1-L) after each interval (2l/c)=1/fsr. Therefore we can get the cavity loss L
(including power lost through transmission) from the ringdown time constant tau as:

L = 1 - exp[ - 1/(tau * fsr) ]

From this we have to subtract the 2000 ppm transmission for each of MC1 and MC3, and divide by three to spread
the losses across the three optics.

I get 168 39 ppm loss per optic based on a very simple exponential fit to the tails (t>0) of four of Andrey's data files.

By comparison, I get 154 37 ppm from Rana's data files from before the vent.
  74   Wed Nov 7 00:51:33 2007 andrey, rob, tobinConfigurationIOOMC ringdowns
We completed several ringdown measurements this afternoon; Andrey is currently processing the data.
  16272   Fri Aug 6 17:10:19 2021 PacoUpdateIMCMC rollercoaster

[anchal, yehonatan, paco]

For whatever reason (i.e. we don't really know) the MC unlocked into a weird state at ~ 10:40 AM today. We first tried to find a likely cause as we saw it couldn't recover itself after ~ 40 min... so we decided to try a few things. First we verified that no suspensions were acting weird by looking at the OSEMs on MC1, MC2, and MC3. After validating that the sensors were acting normally, we moved on to the WFS. The WFS loops were disabled the moment the IMC unlocked, as they should. We then proceeded to the last resort of tweaking the MC alignment a bit, first with MC2 and then MC1 and MC3 in that order to see if we could help the MC catch its lock. This didn't help much initially and we paused at about noon.

At about 5 pm, we resumed since the IMC had remained locked to some higher order mode (TEM-01 by the looks of it). While looking at C1:IOO-MC_TRANS_SUMFILT_OUT on ndscope, we kept on shifting the MC2 Yaw alignment slider (steps = +-0.01 counts) slowly to help the right mode "hop". Once the right mode caught on, the WFS loops triggered and the IMC was restored. The transmission during this last stage is shown in Attachment #1.

Attachment 1: MC2_trans_sum_2021-08-06_17-18-54.png
MC2_trans_sum_2021-08-06_17-18-54.png
  7339   Tue Sep 4 20:06:04 2012 JenneUpdateLockingMC scan input switched to the 11MHz port of EOM

Since the EOM's signal combiner (splitter backwards) is frequency-independent, Koji and Jamie (in the proper turn off, turn on order) put the 55MHz signal back to the EOM, and put the MC mode scan input to the 11MHz port.  This way we can lock the Michelson tomorrow, and we don't have to keep switching cables around when Riju wants to take some scans.

  10285   Tue Jul 29 16:41:54 2014 KojiUpdateLSCMC servo

The MC openloop gains were measured with several conditions
- MC fast/PC crossover was measured to be ~30kHz.
- No feature found in the fast path above 10kHz.

=====

I have been making a circuit to test the crossover between the PZT and PC paths.
This was supposed to allow us to inject a test signal as well as the 5V necessary to offset the voltage for the HV amp.
So far this attempt was not successful although the circuit TF looked just fine. I was wondering what was wrong.

I now suspect that the noise of the circuit was too big. It has ~65nV/rtHz noise level. This corresponds to the external
disturbance of 1~2Hz/rtHz. This is ~10 times larger noise level than the freerun frequency noise.

In the control band the circuit noise is suppressed (cancelled) by the feedback loop.
This is OK when the loop is dominated by the PZT loop. However, if the loop is dominated by the PC path,
the PC path has to work for this compensation.

So what I should do is to remove the low pass filter in the FSS and move it to the downstream of the HV amp.
This way we may be able to reduce the PC path actuation as the noise of the HV amp is also reduced by the LPF.

=====

For the meantime, I used another approach to characterize the MC crossover. I could manage to lock the MC without the PC path.
The openloop was measured with and without the PC path in this low gain setup. In fact the loop was oscillating at 6kHz
due to the low phase margin. Nevertherless, this comparison can let us find where the crossover. The loop gain was also
measured with the nominal condition.

<<Measuerement condition>>

No PC
MC IN1 Gain: +19dB
VCO Gain: +3dB
Boosts: No boost / No super boost

FSS Common Gain: +13dB
Fast Path Gain: +21.5dB
The PC path disconnected.
(Note that the loop was almost oscillating and the apparent gain may look lower than it should have been)

WIth PC
MC IN1 Gain: +19dB
VCO Gain: +3dB
Boosts: No boost / No super boost

FSS Common Gain: +13dB
Fast Path Gain: +21.5dB
The PC path connected.

Nominal
MC IN1 Gain: +19dB
VCO Gain: +15dB
Boosts: Boost On / Super boost 2

FSS Common Gain: +13dB
Fast Path Gain: +21.5dB
The PC path connected.

 

Attachment 1: MCservo.pdf
MCservo.pdf
  10293   Wed Jul 30 00:42:27 2014 KojiUpdateLSCMC servo

I used an oscillator and an oscilloscope to measure the open loop transfer function at higher frequency than 100kHz.
(I remember that I tried to use Agilent 4375A for this and failed before ... due to low input impedance???)\

Here is the update. It seems that the gain margin is not so large. We should apply low pass to prevent too large servo bump.

Attachment 1: MCservo.pdf
MCservo.pdf
  10300   Wed Jul 30 22:01:24 2014 KojiUpdateLSCMC servo

In fact there is a pomona box between the HV amp and the laser.
It is expected that the combination of the box and the laser PZT (2.36nF by Elog #3640) provides poles at 2.9Hz and 148kHz and a zero at 32Hz.
Basically, the gain of this stage is 0.1 at 10kHz. So the injected noise is reduced by factor of 10. It is just barely OK.
I need a bit more careful design of the output stage for the MC servo.

  10235   Fri Jul 18 14:59:07 2014 EvanUpdateIOOMC servo TFs

[Rana, Evan]

This morning we took several TFs of the MC servo board using the HP4395A.

The 4395 source was teed, with one output of the tee going to 4395 R and the other output going to the board's IN1. We then took TFs of (4395 A) / (4395 R), where 4395 A was one of the following four points on the servo board:

  • OUT2
  • A TEST1
  • B TEST1
  • SERVO

For each of these points, we took a TF at two gain settings: IN1 and VCO gains both at 0 dB, and then IN1 and VCO gains both at 20 dB.

Before doing these measurements, we calibrated out the cable delay. Additionally, SERVO was always loaded with 50 Ω—either from the 4395 or from a terminator.

The attached png shows the servo board settings when these TFs were taken with the 0 dB gain settings. The settings for the 20 dB measurements are identical, except for the higher IN1 and VCO gains.

Attachment 1: mcServoTFSettings.png
mcServoTFSettings.png
Attachment 2: MCtfs.pdf
MCtfs.pdf
  10251   Tue Jul 22 08:36:08 2014 EvanUpdateIOOMC servo TFs

Quote:

[Rana, Evan]

This morning we took several TFs of the MC servo board using the HP4395A.

The 4395 source was teed, with one output of the tee going to 4395 R and the other output going to the board's IN1. We then took TFs of (4395 A) / (4395 R), where 4395 A was one of the following four points on the servo board:

  • OUT2
  • A TEST1
  • B TEST1
  • SERVO

For each of these points, we took a TF at two gain settings: IN1 and VCO gains both at 0 dB, and then IN1 and VCO gains both at 20 dB.

Before doing these measurements, we calibrated out the cable delay. Additionally, SERVO was always loaded with 50 Ω—either from the 4395 or from a terminator.

The attached png shows the servo board settings when these TFs were taken with the 0 dB gain settings. The settings for the 20 dB measurements are identical, except for the higher IN1 and VCO gains.

Using the modified schematic (40m:10250), I've made a plot of the TFs I expect for GIN1 = GVCO = 0 dB, taking into account our 50 Ω loading of the board.

Evidently I'm somehow missing a factor of 2 in the gain of the overall TF, but the shapes of the expected vs. measured magnitudes agree quite well.

At 1 MHz, I expect we should have accumulated about 80 degrees of phase going through the servo board. In reality, we appear to have lost more like 105 degrees.

Attachment 1: MCtfExpectations.pdf
MCtfExpectations.pdf
  10322   Fri Aug 1 12:49:06 2014 KojiSummaryIOOMC servo analysis

Reasoning to choose the current parameters:

FSS Common: 18dB
FSS Fast: 20dB

Attachment 1:
Openloop transfer function of the IMC loop with the nominal gain setting. The UGF is 176kHz and the phase margin is 48 deg.
This is about 3 time more bandwidth than the previous setting. (Good)

It is visible that the TF has sharp roll off around 1MHz. I wonder if this comes from the demodboard LPF and/or the PMC cav pole.
In fact, according to Manasa, the PMC has the ringdown of 164.6ns which corresponds to the cavity pole of 967kHz. So this must
be there in the OLTF.

From the plot, the order of the low pass is about 5. Subtracting the slope by the cavity pole, the order is four. If I look at the TF of the minicircuits
LPFs (this entry), the phase delay of the filter at 1/10 of the cut off freq is ~30deg. And the order of the filters are maybe 6th elliptic?
So it's not yet clear if the LPF is causing a significant phase delay at 180kHz.

More significantly, the gain margin at ~1MHz is way too small. This is causing a big servo bump at that frequency as seen in Attachment 2.

In total, my recommendation is to move the LPF freq up by x2 or x3, and give a mild LPF above 500kHz.
This requires some modeling as well as try and error.

Attachment 2:

This figure is to explain how the common FSS gain was set. By increasing the gain, the UGF is increased and we can enjoy more supression (from red to purple).
The more gain, however, the more servo bump we observe above the UGF. The gain was chosen so that the total PC feedback does not exceed 3V.

Attachment 3/4:

This figure explains how the fast FSS gain (namely crossover frequency between fast and PC) was set. When the fast is low (red) the phase margin between two loops
are plenty and therefore the openloop TF is smooth. But the PC's frequency domain is large and has to work more (in rms). As the fast gain is increased, the actuation
by the PC is offloaded to the fast PZT (that's good). But eventually the phase margin is not enough and the dip start to show up (purple). This dip cause worse closed loop TF,
as seen in Attachment 4, or even an instability of the loop eventually. So the fast gain was set somewhere in between (green).

Attachment 1: MC_OLTF.pdf
MC_OLTF.pdf
Attachment 2: MC_Error_Common.pdf
MC_Error_Common.pdf
Attachment 3: MC_Crossover.pdf
MC_Crossover.pdf
Attachment 4: MC_CLTF_Fast.pdf
MC_CLTF_Fast.pdf
  10343   Thu Aug 7 11:57:59 2014 KojiSummaryIOOMC servo analysis

LISO Fit for the IMC open loop TF. The data and liso source for the fitting were attached in the ZIP file.

I noticed now that the open loop TF I measured has too less phase delay.
I used the closed loop TF to estimate the openloop TF.

Looking at this comparison, I'm afraid that the superboost was not on during the measurement.
I need a new measurement to design MC loop modification to give the AO path for broader bandwidth.

Attachment 1: MC_OLTF_Fit.pdf
MC_OLTF_Fit.pdf
Attachment 2: IMC_OLTF.zip
Attachment 3: MC_OLTF_estimated.pdf
MC_OLTF_estimated.pdf
  10351   Fri Aug 8 12:39:19 2014 ericqSummaryIOOMC servo analysis

I have measured the current boosted MC CLG below 100kHz with an SR785. Swept sine only could get me down to 10kHz, but I was able to get down to 5kHz with a noise-injection measurement. 

MCloopAug8.pdf

I am attaching the SR785 outputs, which are in dB and Degrees. Additionally I pruned the areas of bad coherence out of these, and merged them to provide data files for the CLG and OLG in Real,Imaginary format.

Attachment 1: mcLoopAug8.zip
  10354   Fri Aug 8 15:57:29 2014 ericqSummaryIOOMC servo analysis

 I did some further measurements, to try and see what corresponds to what. In the end I performed four measurements:

  1. Closed loop gain measurement on SR785: Source to MC exc, T'd to channel one. Test 2 to channel two.
  2. Open loop gain measurement on SR785: Source to MCexc, Test 2 to channel one, Test 1 to channel two.
  3. Closed loop gain measurement on AG4395: RF Source to MC exc, T'd to R input. Test 2 to A input.
  4. Open loop gain measurement on AG4395: RF Source to MC exc, Test 2 to R input. Test 1 to A input.

I then converted OLGs to CLG and vice-versa with CLG = 1/(1-OLG)

Here are two plots showing the measured and inferred loop TFs for both closed and open. 

OLTFs.pdfCLTFs.pdf

The best agreement seems to be between the directly measured OLGs. Maybe I did something weird with the CLG measurements, or input impedances are distorting things ... 

All data is attached, along with code used to generate the plots. 

Attachment 3: mcLoopAug8.zip
  10356   Fri Aug 8 18:08:12 2014 KojiSummaryIOOMC servo analysis

The closed gain I meant is the AO path: Use IN2 to excite the MC loop and measure IN1 using MON2(?).
In order to obtain the open loop gain from this meausrement, the gain mismatching needs to be compensated, though.

This measurement is to correctly predict the AO path response from the open loop transfer function.

Anyway, the openloop gain seems nicely measured. I'll try to predict AO path response from this.

  10359   Sat Aug 9 14:35:28 2014 KojiSummaryIOOMC servo analysis

Eric's OLTF turned out consistent with the AO path TF that has been measured by me on Jul 31 (entry 10322).

Attachment 1:
Updated empirical fit of the open loop TF by LISO.
In this fit, I gave some of the poles/zeros associated with the boost manually set so that I can use them for the servo design.
LISO itself can make better fitting if all of the variables are moved.

Atatchment 2:
The OLTF data and LISO source for the fitting.

Attachment 3:
Comparison of the AO path TFs. The red one was measured directly on Jul 31. The TF is normalized at the low frequency.
The blue was estimated from the OLTF model given above. They are well consistent now.

Attachment 4:
Now some servo design was tried. In the new design (blue), zeros of the super boost frequency was moved from 20kHz to 30kHz
with the hope of having flatter AO response. The improvement is very little while costing costing above 100kHz. Note that the vertical
axis is intentionally in a linear scale. In fact, the AO response is much improved compared to the one before the MC UGF was increased
(shown in magenta). We have a flatter response both in magnitude and phase.
Therefore I think there is no need to tweak the boost frequency for the AO path.
I'd rather recommend to inspect the high frequency LPFs to earn more gain margin at 1MHz as
explained in entry 10322.

Attachment 5:
This figure shows the comparison of the TFs for the current and new design trial, just in case someone is interested in to see.

 

Attachment 1: MC_OLTF_Fit.pdf
MC_OLTF_Fit.pdf
Attachment 2: liso.zip
Attachment 3: MC_CLTF_Fit.pdf
MC_CLTF_Fit.pdf
Attachment 4: MC_CLTF_new.pdf
MC_CLTF_new.pdf
Attachment 5: MC_OLTF_new.pdf
MC_OLTF_new.pdf
  10243   Sun Jul 20 09:26:27 2014 EvanUpdateElectronicsMC servo card modifications in DCC

Quote:

[Rana, Jenne]

We have decided to keep better track (using new-fangled digital "computers") of our modifications to electronics boards. 

The idea will be to create a new DCC document for every electronics board (when we pull a board and modify it, it should receive this treatment) that we have, and that document will become a history of the board's life.  Version 1 will be a copy of the original drawing.  Version 2 should be a modified version of that drawing with the current situation.  All future versions should be modified from the most recent version, to reflect any changes.  Notes for each updated version should include an elog reference to the work, so that we know why we did things, and have a place to find photos of the actual modifications.  Elogs should also include a link to the DCC version.  DCC titles should include the phrase "40m Revisions" for ease of searching.

Patient Zero for this new system will be the PMC servo card.  The DCC number is D1400221.  As of this moment, this just has the V1 original drawing with no modifications.

This has been included in the 40m's DCC document tree that Jamie started back in November 2012.

Patient One for this new system will be the MC servo card. The DCC number is D1400242. Currently, v1 is just the original drawing with no modifications. I've updated the DCC document tree at E1400326 accordingly.

It looks like we can use Jenne's information in 40m:9892 to deduce the modifications that have been made (alternatively, someone can just pull the board and examine it on the bench).

  10250   Tue Jul 22 08:24:42 2014 EvanUpdateElectronicsMC servo card: modified schematic

Quote:

Patient One for this new system will be the MC servo card. The DCC number is D1400242. Currently, v1 is just the original drawing with no modifications. I've updated the DCC document tree at E1400326 accordingly.

It looks like we can use Jenne's information in 40m:9892 to deduce the modifications that have been made (alternatively, someone can just pull the board and examine it on the bench).

The attached zip file has a modified schematic of the MC servo card (011/MC), as deduced from Jenne's photos. Someone should go through and verify that the schematic is correct. Then it can go on the DCC as D1400242-v2.

To modify the schematic, I used Inkscape (the svg files for each sheet are included in the zip file). Then to generate the pdf, I ran

for i in sheet*.svg; do inkscape -A "${i/svg/pdf}" "$i"; done

pdftk sheet*.pdf cat output D1400242

Attachment 1: D1400242.zip
  4360   Sat Feb 26 00:25:38 2011 KojiUpdateIOOMC servo improvement

[Rana / Koji]

The MC servo loop has been investigated as the MC servo was not an ideal state.

With the improved situation by us, the attached setting is used for the MC and the FSS.
The current UGF is 24kHz with phase margin is ~15deg, which is unbearably small.
We need to change the phase compensation in the FSS box some time in the next week.


- We found the PD has plenty of 29.5MHz signal in in-lock state. This was fixed by reducing the LO power and the modulation depth.

- The LO power for the MC demodulator was ~6dBm. As this was too high for the demodulator, we have reduced it down to 2dBm
by changing attenuator to 12dB (at 6 oclock of the dial) on the AM stabilization box.

- The RF power on the MC PD was still too high. The PD mush have been saturated. So the modulation slider for 29.5MHz was moved
from 0.0 to 5.0. This reduced the 29.5MHz component. (But eventually Koji restored the modulation depth after the servo shape has been modified.)

- The openloop gain of the loop has been measured using EXC A/TEST1/TEST2. The UGF was ~5kHz with the phase mergin of ~10deg. 

- This quite low phase margin is caused by the fact that the loop has f^-2 shape at around 4k-100kHz. The reference cavity has
the cavity pole of 40kHz or so while the IMC has the pole of ~4kHz. Basically we need phase lead at  around 10-100kHz.

- We decided to turn off (disable) 40:4000 boost of the MC servo to earn some phase. Then MC did not lock. This is because the LF gain was not enough.
So put Kevin's pomona box in the FAST PZT path (1.6:40). By this operation we obtain ~75deg (max) at 560Hz, ~35deg at 5kHz, ~20deg at 10kHz.

- In this setup the UGF is 24kHz. Still the phase margin is ~15kHz. This phase lag might be cause by 1)  the MC servo circut 2) PMC cavity pole

NEXT STEP

- Put/modify phase lead in the FSS box.
- Measure the PMC cavity pole
- Measure and put notch in the PZT path
- Increase the UGF / measure the openloop TF

Attachment 1: fss_servo.png
fss_servo.png
Attachment 2: mc_servo.png
mc_servo.png
  4366   Wed Mar 2 04:01:51 2011 KojiUpdateIOOMC servo improvement

[Koji / Rana]

- Since the MC servo had UGF up to ~20kHz and huge servo bump at 50kHz, we needed more phase between 20kHz to 100kHz.

- Today a phase compensation filter in a Pomona box has been inserted between the MC servo box and the FSS box.
  This is a passive filter with zero@14kHz and pole@140kHz. We obtain ~60deg at around 50kHz.

- After the insertion, the lock of the MC was achieved immediately. The overall gain as well as the PZT fast gain was tweaked
  such that the PC feedback is reduced down to 1~2.

- The OLTF has been measured.
  The insertion of the filter change increased the UGF to 130kHz even with "40:4kHz" and double super boost turned on.

  The phase margin is 54deg. Quite healthy.

- Rana modified the existed Auto Locker script.
  It is now continuously running on op340m!
  We made a couple of testsif it correctly relock the MC and it did. VERY COOL.

-----------------

NEXT STEPS
- Measure the PMC cavity pole
- Measure the circuit TF and try to shave off the phase lag.
- Measure the PZT resonance of the NPRO and put notch in the PZT path
- Increase the UGF / measure the openloop TF

Attachment 1: IMG_3904.jpg
IMG_3904.jpg
Attachment 2: MC_OLTF.pdf
MC_OLTF.pdf
  10320   Fri Aug 1 10:40:48 2014 KojiSummaryIOOMC servo summing amp

The summing amp is prepared to allow up to use bipolar full range of the FSS box output

This means that the FSS fast PZT output is now nominally 0V and can range +/-10V.

- FSS Box has the output range of +/-10V

- Thorlabs HV amp MDT694 accepts 0V ~ +10V

- This circuit add an offset of +5V while the main signal is attenuated by a factor of 2. The offset voltage is produced from the voltage reference IC AD586.

- In addition, a summing node and voltage monitors before and after the summing node are provided. They are useful to test the crossover frequency of the fast/PC loops.

- The output noise level at 10kHz was ~60 nV/rtHz. The transfer function of the circuit was measured and flat up to 100kHz. The phase delay is negligible at 10kHz and less than 3deg at 100kHz

- Although the schematic was drawn in Altium, the board is a universal 1U eurocard and all wires were hand soldered.

Attachment 1: Fast_PZT_IF.PDF
Fast_PZT_IF.PDF
  10722   Mon Nov 17 20:28:17 2014 ranaSummaryIOOMC servo summing amp

I modified the /cvs/cds/caltech/target/c1psl/psl.db file to adjust the records for the FSS-FAST signal (to make it go yellow / red at the correct voltages). This was needed to match 5V offset which Koji added to the output of the FSS board back in August.

I also manually adjusted the alarm levels with caput so that we don't have to reboot c1psl. Beware of potential tiimebomb / boot issues if I made a typo! psl.db update in the SVN (also, there were ~12 uncomitted changes in that directory....please be responsible and commit ALL changes you make in the scripts directory, even if its just a little thing and you are too cool for SVN)

ELOG V3.1.3-