40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 133 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  5774   Tue Nov 1 13:41:38 2011 MirkoUpdateLSCAM modulation due to non-optimal SB frequency

Quote:

[Kiwamu, Mirko]

Non-optimal 11MHz SB frequency causes PM to be transformed into AM.
m_AM / m_PM = 4039 * 1kHz / df , with df beeing the amount the SB freq. is off.

Someone might want to double check ths.

 Actually there was an error.

For 11MHz it is:
m_AM / m_PM = 2228 * 1kHz / df

For 55MHz:
m_AM / m_PM = 99.80 * 1kHz / df

see PDF

Attachment 1: IMC.pdf
IMC.pdf
  5811   Fri Nov 4 15:24:13 2011 MirkoUpdateAdaptive FilteringAdaptive FF on the MC doesn't make sense

[Den, Jenne, Mirko]

DSC_3585.JPG

Here is the story:

1. High gain
The control loop has a high gain at the interesting frequencies. The error point (EP) before the servo is approx. zero and the information how much the mirror would move is in the feedback point (FB) behind the servo. The mirror doesn’t actually move because of the high gain. This is the case of the grav. wave detectors and medium frequencies (> approx. 50Hz, <<1kHz). Adding feed-forward (FF) to this doesn’t actually keep the mirror quieter. In fact if you look into the FB and subtract the seismic you make the mirror move more. Yes this is the case we have for the mode cleaner, doesn’t make sense.
In a real GW detector FF however isn’t totally useless. The FB tells you how much the mirror moves, due to GWs, seismic etc. When you record the FB and subtract (offline) the seismic you get closer to the real GW signal.

2. Low gain
When you, for technical reasons, can’t have a high gain in your control loop the EP contains information of how the mirror actually moves. You can then feed this into the adaptive filter and add its output to the FB. This will minimize the EP reducing the actual mirror motion. This is the case we will have for most or all other degrees of freedom in the 40m.

The reason we have so much gain in the mode cleaner length control is that we don’t actually move mirrors around. We change the frequency of the incoming laser light. You can do that crazy fast with a big amplitude. This gives us a high UGF and lots of gain in the 1Hz range we are interested in.

We now change the adaptive filter to look at the EP for all DOFs except for the MC. We calculate the effect of the FF on the MC length signal without ever applying the FF to the MC length control.

  5841   Tue Nov 8 17:48:21 2011 MirkoUpdateCDSDolphin weirdness

Had since yesterday evening some trouble with getting a channel from rfm on c1sus to oaf on c1lsc via dolphin. Several restarts of c1lsc and c1sus didn't help. At some point this morning a restart of c1lsc helped. Everything ok again.
At the bad time the dolphin TF looked like this:

Dolphn_TF.png

Should be flat at gain 1 and no phase change obviously.

  5842   Tue Nov 8 18:06:43 2011 MirkoUpdateAdaptive FilteringNoise injections to MC1-3 PIT & YAW

With fancy analysis tools approaching usability I looked some more into noise projections from PIT,YAW motion of the MC mirrors to MC length.

Injection channels are: C1:IOO-MC1-PIT_EXC. Actual injection signal is recorded in C1:IOO-MC1-PIT_OUT and similar.
Source channels for the projection are C1:IOO-WFS1_I_PIT_OUT_DQ and similar.
Response channel is C1:OAF-MCL_IN_IN1 or C1:IOO-MC_F_DQ.
MC auto-alignment was off.

1. Fixed sine injection @ 0.5Hz

Every injection lasted 4mins.

Start time DOF Amplitude [counts_pk] rough SNR in ASD BW 0.04Hz
16:09 MC1PIT 25 -
16:14 MC1YAW 40 12
16:21 MC2PIT 35 5
16:26 MC2YAW 35 5
16:34 MC3PIT 45 5
16:39 MC3YAW 45 -

2. Filtered white noise injection

Generated white noise from 0.5Hz-20Hz, then filtered that in the C1:IOO-MC1-PIT and similar filters by the following TF, (Notch 1Hz, Q=3, 40dB &  2 zeros @ 1.1Hz)

INJ_filter.png

All injections lasted 4mins. I left the filters in the first filter bank but disabled them. 

Start time DOF Amp. @ 0.5Hz [counts_pk (?)]
17:01 MC1PIT 250
17:10 MC1YAW 400
17:16 MC2PIT 400
17:21 MC2YAW 400
17:26 MC3PIT 500
17:31 MC3YAW 500

 

Attachment 2: MC1PIT_Noise_inj.png
MC1PIT_Noise_inj.png
Attachment 3: Noise_Inj_MC2PIT.png
Noise_Inj_MC2PIT.png
Attachment 4: Noise_Inj_MC2YAW.png
Noise_Inj_MC2YAW.png
Attachment 5: Noise_Inj_MC3PIT.png
Noise_Inj_MC3PIT.png
Attachment 6: Inj_Noise_MC3YAW.png
Inj_Noise_MC3YAW.png
Attachment 7: Inj_Noise_MC1YAW.png
Inj_Noise_MC1YAW.png
  5843   Tue Nov 8 19:08:21 2011 MirkoHowToComputersNew DV

Quote:
To use the new ligoDV (previously GEO DV) to look at 40m data, open up a matlab, set up for mDV as usual,
and then from the /cvs/cds/caltech/apps/ligoDV/ directory, type 'ligoDV'.

Then select which NDS server you want to look at and then start clicking to get some plots.

To start ligodv go in matlab to /cvs/cds/caltech/apps/ligoDV/ and call ligodv. Ligodv will start up when you are in another directory, but will give strange errors. Only seems to work with NDS2 server mafalda port 31200. This doesn't have all channels. When pointing it to fb port 8088 it freezes when you try to adjust the start/stop time. Make sure to ask for the correct UTC time, not the local time.
  5847   Wed Nov 9 13:44:04 2011 MirkoUpdateComputersNDS1 missing channels in matlab

The Matlab NDS1 access seems to only work for some channels. With other channels it just hangs 'Busy' and does nothing.
Below you can see some channels that make matlab hang. Everyting happened on allegra. I tried compiling the NDS1 sources (from https://www.gravity.phy.syr.edu/dokuwiki/doku.php?id=ligodv:nds1_ligodv_install ) into mex files myself. Same result. I
 

a=NDS_GetChannels('fb:8088'); %/cvs/cds/caltech/apps/linux64/share/matlab/NDS_GetChannels.m
%data=NDS_GetData({'C1:IOO-MC_F_DQ'},1004826500,100,'fb:8088',a)     %Works
%data=NDS_GetData({'C1:IOO-WFS1_PIT_IN1_DQ'},1004826500,100,'fb:8088',a)     %Works
data=NDS_GetData({'C1:LSC-AS11_I_OUT'},1004826500,100,'fb:8088',a)         %Doesn't work, hangs
%%%which NDS_GetData.m: /cvs/cds/caltech/apps/linux64/share/matlab/NDS_GetData.m

  5856   Wed Nov 9 20:35:58 2011 MirkoUpdateAdaptive FilteringSeismic noise injection into the MC

Very elaborated measurement ;-)

On 11-11-08:
18:40 Stomp near STS1 for 2mins
18:47 Jump near GUR1 for 2mins
18:52 Walk from MC2 approx. half-way to vertex for 2mins


Tried to see if jumping / stomping the ground near STS1 / vertex or GUR1 / MC2 would show up in the seismometer or MC length data.
In GUR1 jumping / stomping clearly shows up in the timeseries. Also it clearly shows up as a low frequency signal if you walk to a position near MC2. E.g. walk from the vertex to MC2. Stop near the cones. Gives a big dip on GUR1X, that recovers in 10-20sec if you remain stationary. Big "hill" if you come from x-arm end and stop on the x side of MC2. So probably lots of tilt to GUR1X coupling at low frequencies.

Nothing was really visible in spectra (see below).

Resonances:

There appear to be a lot of resonances in the 10-20Hz range, see e.g. 1st attached pic.

Coherence:

Looking at the coherence of difference axis of the seismometers. Kind of dirty measurement, could have all kinds of reasons.
Quite a bit of coherence in STS1 at 5-6Hz. Possibly limiting the STS1X to MC-F coherence to up to 4Hz?

Coherence_GUR.png

Coherence_STS1.png

Attachment 1: Inj_spectra_at_GUR1_all_DOFs.fig
Attachment 2: Inj_spectra_at_GUR1_all_DOFs.png
Inj_spectra_at_GUR1_all_DOFs.png
Attachment 3: Inj_spectra_at_STS1_all_DOFs.fig
Attachment 4: Inj_spectra_at_STS1_all_DOFs.png
Inj_spectra_at_STS1_all_DOFs.png
Attachment 7: Coherence_GUR.fig
Attachment 8: Coherence_STS1.fig
  5858   Wed Nov 9 21:32:38 2011 MirkoUpdateAdaptive FilteringPut accelerometers 4-6 on top of MC2 tank

Put the accelerometers on top of MC2. Orientated as the arms,GUR1 and STS1:
09112011069.jpg

Should be fixed a bit more rigidly.

 

Looking into the signals at a quiet time:

Coherence_quiet_time.png

Hmm. Either the acc. are mislabeled or there is really bad x-y coupling. The connectors in the back of the acc. power supply / amplifier box are in ascending order.

Attachment 3: Coherence_quiet_time.fig
  5863   Thu Nov 10 16:26:46 2011 MirkoUpdateComputersFirefox kills elog

Had to restart the elog many times. For some reason firefox 8 on Win 7 kills the elog pretty consistently when trying to make a new entry. IE9 works fine ....

  5864   Thu Nov 10 16:44:54 2011 MirkoUpdateAdaptive FilteringLooking into MC_F & PSL misalignment

 [Den, Mirko]

While doing the things below we accidentally misaligned the PSL laser. Thanks to Suresh and Jenne for realigning!!

There are a lot of strange features in MC_F (see for example http://nodus.ligo.caltech.edu:8080/40m/5738 )
To get some better understanding of the signals in the control loop we looked some more into what happens to the MC feedback signal after it exits the MC servo board (D040180 see DCC).

10112011076.jpg
The MC_F signal is actually the servo signal: http://nodus.ligo.caltech.edu:8080/40m/5695
The Thorlabs temperature controller is actually used in the PZT path!

 We measured the LP filter in the PZT path (that is kind of mislabeled as temp.)

10112011073.jpg

 

  5867   Thu Nov 10 22:00:38 2011 MirkoUpdateAdaptive FilteringLooking into MC_F & PSL misalignment

Quote:

 [Den, Mirko]

While doing the things below we accidentally misaligned the PSL laser. Thanks to Suresh and Jenne for realigning!!

There are a lot of strange features in MC_F (see for example http://nodus.ligo.caltech.edu:8080/40m/5738 )
To get some better understanding of the signals in the control loop we looked some more into what happens to the MC feedback signal after it exits the MC servo board (D040180 see DCC).

10112011076.jpg
The MC_F signal is actually the servo signal: http://nodus.ligo.caltech.edu:8080/40m/5695
The Thorlabs temperature controller is actually used in the PZT path!

 We measured the LP filter in the PZT path (that is kind of mislabeled as temp.)

10112011073.jpg

 

 

We looked into the signal from the MC servo board at different position at the PSL table.


We looked into the FB going into the temp. and PZT parts of the FB.
Temp.:
Screenshot.png

PZT:

Screenshot-1.png
We also looked at the signal in just in front of the FSS box No idea why the elog doesn't preview these pdfs.

Signal_at_MC_servo_board_and_PSL_table_2_1.pdf

Signal_at_MC_servo_board_and_PSL_table_2_2.pdf

Signal_at_MC_servo_board_and_PSL_table_2_3.pdf

Signal_at_MC_servo_board_and_PSL_table_2_4.pdf
Lots of extra noise there. We will check out where that comes from.

  5879   Sat Nov 12 02:00:36 2011 MirkoUpdateAdaptive FilteringMC-F and other signals

Regarding http://nodus.ligo.caltech.edu:8080/40m/5867 and http://nodus.ligo.caltech.edu:8080/40m/5869 :

MC_F signal:

The measurements on p. 5867 were done using the ADC attached to the PEM computer. There was a big difference between the MC_F signal recorded directly after the server board and the signal just before the FSS board as recorded by a PEM channel.
To understand how this happens we measured the signal at different places with a spec. analyzer:

1. WIth a locked MC measuring the signal just before the PEM ADCs (meaning after a 60ft BNC cable)
2. Same position, but unlocked and seemingly dark MC
3. Locked MC, signal just before the FSS box
4. MC_F signal that is usually going into the Pentek Generic board and is recorded in C1:IOO

Compare_signals_at_all_places.png

=> The 60ft BNC cable adds a considerable amount of noise, but doesn't fundamentally change the signal. It is weird that the signal is white from approx. 4Hz on.
Due to Jenne's measurement ( http://nodus.ligo.caltech.edu:8080/40m/5848 ) we know the TF from MCL through PD, mixer Pentek and into C1:IOO looks like this:
OAF-MCL-Delay-9Nov2011.pdf

This is with the double HP from 15Hz on that should be in the Pentek. So one might expect a less white signal going into the FSS board...

 PEM ADCs

The dark noise in the PEM ADCs is actually a factor 10 higher than in the IOO ADCs. Still ok wrt the the seismometers.
We also tried to measure essentially the dark noise of the whole seismometer readout (seismometer box, then ADC). That seemed ok, but is of limited value since the seismometer electronics behave a bit strange when there is no seismometer connected.

Channels_attached_to_the_PEM_ADC.png

Attachment 3: Compare_signals_at_all_places.fig
Attachment 5: Channels_attached_to_the_PEM_ADC.fig
  5900   Tue Nov 15 22:31:39 2011 MirkoUpdateAdaptive FilteringTowards wiener filtering and improved OAFing


[Jenne, Mirko]

1. We should help the OAF by compensating for the actuator TF:

The actuator TF, from adaptive filter output to MC2, through PD, mixer, Pentek and into C1:IOO looks like this:

 TFofTheMclLoop.pdf

If we assume a white-ish error signal that the adaptive code tries to compensate for its job gets extra complicated because it has to invert this TF. So we really should compensate for that. Easiest place for that is the CORR filter directly behind the adaptive code block.

Using the TF measurement from above I used the vectfit (" /cvs/cds/caltech/apps/mDV/extra/firfit_forFotonMirkoComplex.m" ) to get fit a corresponding digital filter:

MCL_round_trip.png

If we invert swap the zeros and poles in the digital filter we get the inverted TF.
(Todo: Figure out how to invert the TF. Just switching the poles and zeros doesn't work).

2. Wiener filtering

The idea was to use the adaptive filtering only for small corrections to the wiener filtering. So we really should try to get the wiener filtering going.

Howto:

1. Get data for STS1X and GUR1X and MC_F in matlab. E.g. via ligodv
2. Check the MC was in lock the entire time.
3, Filter MC_F with the actuator TF, so the wiener filter knows about that and compensates for it
4. Calculate the wiener filter " h1winolevLigoDV.m "
5. Export the data to the workspace. It is also saved to the disc as "h1filtcoeffTS.mat". Make sure there are first the witnesses, then MC_F
6. Execute " /cvs/cds/caltech/apps/mDV/extras/LHO/firfit_for_FotonMirko.m" while one directory higher. 
7. Copy the digital filter in SOS form that is printed into the matlab command line and put it into the corresponding filter in the OAF model via foton.

With data from 11-11-15 04:00 to 05:45. Sampling freq. 256Hz. 8000 Taps => length = 30.2s. Prefiltered to notch the 60Hz line in MC_F, but not compensation the actuator TF. This results in the following wiener filter and corresponding SOS filter to be copied into foton.
STS1X:

STS1X_Wiener_filter_data_from_11-11-15.png

GUR1X:

GUR1X_Wiener_filter_data_from_11-11-15.png

Attachment 3: MCL_round_trip.fig
Attachment 6: STS1X_Wiener_filter_data_from_11-11-15.fig
Attachment 7: GUR1X_Wiener_filter_data_from_11-11-15.fig
  5901   Tue Nov 15 23:44:44 2011 MirkoUpdateCDSC1:LSC & C1:SUS restarted

Earlier this evening C1:LSC died then I hit the DAQ reload after adding an OAF channel to be recorded. No change to any model. Had to restart C1:SUS too. Reloaded burts from this morning 5am, except for C1:IOO, which I loaded from 16:07.

  5915   Wed Nov 16 17:40:48 2011 MirkoUpdateIOOMC unlocked and misaligned.

MC fell out of lock and was then quite badly misaligned. Mostly in pitch. I realigned it and it locked ok.

Turns out the MC falls often out of lock when the WFS servo comes on. I think the MC2_Trans history is not cleared on lockloss. I cleared it manually and realigned. Seems fine for now.

  5949   Fri Nov 18 15:45:11 2011 MirkoUpdateIOOMode cleaner noise projection

[Rana, Den, Mirko]

Updated the MC noise projection to include the longitudinal motion of the MC mirrors.

WholeMCNoiseProjection.png

=> Lots of OSEM - local dampling noise!

Consistent with static wiener filter showing only benefits in the 1 - 4Hz region.

Attachment 2: WholeMCNoiseProjection.fig
  5952   Fri Nov 18 19:57:19 2011 MirkoUpdateIOOMode cleaner noise projection

 

Some more info on this:
 

f > 1 Hz:

At these frequencies the pendulum should be quieter than the stacks. By quite a bit actually since there is the stack resonance at a couple Hz. 'Glueing' them together via the local control is not wise. We put an elliptic LP ( 2.5Hz, 4th order 6dB) into the C1:SUS-MC?_SUSPOS pathes and MC-F got better above 1Hz

MC_ELP.png

Added an extra LP @ 10 Hz afterwards. Doesn't make a visible difference.

f < 1 Hz:

Now here is more stuff to consider.

1. The OSEMs glue the MC mirrors to the stacks
2. The pendulum TF should be 1
3. It shouldn't matter if the OSEMs do or do not act on the mirror at these frequencies, assuming they don't add extra noise.
4. Page http://nodus.ligo.caltech.edu:8080/40m/5547 seems to indicate OSEM sensor noise is so low it can be neglected.

Reduced OSEM gain below 1Hz:

If we reduce the gain in the OSEMs by adding additional HP filters ( cheby2, HP 0.3Hz, 6dB 4th order ) the happens:

1. MC length gets a bit more noisy at low frequencies - should be looked into some more
2. Coherence between the GUR1 seismometer and MC length goes up between 1E-2 and 1E-1 Hz:

( Ref is with low OSEM gain )

WithAndWithoutHPs.pdf

Possible explanation:

The stacks might be more correlatedly moving together than the pendulums. This would be not so nice for OAF test, but really fine for actually using the MC.
Todo: Measure the OSEM to seismometer coherences with high and low OSEM gains.

For reference the seismometer coherence with one another:
SeismCoh.pdf

 

 

  5960   Sat Nov 19 12:57:55 2011 MirkoUpdateIOOMode cleaner noise projection

Quote:

Could use some more detail on how this measurement was done. It looks like you used the SUSPOS signal with the mirror moving, however, this is not what we want. Of course, the SUSPOS with the mirror moving will always show the mirror motion because the OSEMs are motion sensors.

Instead, what we want is to project how the actual OSEM noise in the presence of no signal shows up as MC length. For that we should use the old traces of the OSEM noise with no magnets and then inject that spectrum of noise into the SUSPOS filter bank with all the loops running. We can then use this TF to estimate the projection of OSEM noise into the MC length.

As far as improving the damping filter, the 2.5 LP is not so hot since it doesn't help at low frequencies. Instead, one can compute the optimal filter for the SUSPOS feedback given the correct cost function. To first order this turns out to be the usual velocity damping filter but with a resonant gain at the pendulum resonance. This allows us to maintain the same gain at the pendulum mode but ~3x lower gain at other frequencies.

In the past, we had some issues with this due to finite cross-coupling with the angular loops. It would be interesting to see if we can use the optimal damping feedback now that the SUS DOFs have been diagonalized with the new procedure.

 The measurement was done with the MC in lock and the OSEMS active.

1. I injected noise into MC1-3 SUSPOS_EXC at a level that domiated the SUSPOS output.
2. Then I calculated the coupling coefficients of the SUSPOS outputs to MC_F during the time the noise is injected.
3. Without noise injection I projected the SUSPOS outputs to MC_F by multiplying the coupling coefficients with the SUSPOS outputs.

All on 11-11-18. White noise inj. from 0.1Hz to 20Hz. Duration 4mins each.

DOF      Amplitude(counts)     Time(UTC)
MC1      200                           22:08
MC2      25                             22:25
MC3      25                             22:50

Some thoughts on this, bare with me:

As you say this does not show the dark / bright noise of the OSEMs. It shows the influence of the OSEMS output onto MC_F in normal operation of the MC. I would have expected that to be very low everywhere except at the pendulum resonance. Reason for that not to be true could either be the OSEMs having considerable gain off of the resonance, or noise intrinsic to the OSEMs knocking the mirrors around. Since we know the OSEM signal to MC_F TF we only need to compare the OSEM signal to OSEM noise to see the noise contribution to MC_F. We know from http://nodus.ligo.caltech.edu:8080/40m/5547 that the OSEM sensor bright noise is considerably below the OSEM signal above 0.1Hz in actual operation. We checked that the MC OSEM signals are above the noise in the reference above 0.1Hz by a factor 3-10.

We actually measured the cost function with the noise projection (valid to 10Hz). It's just the coupling coefficient, right?

CouplingMClengthsToMCF.pdf

 

Attachment 2: NpModeCleaner.pdf
NpModeCleaner.pdf NpModeCleaner.pdf NpModeCleaner.pdf NpModeCleaner.pdf NpModeCleaner.pdf NpModeCleaner.pdf NpModeCleaner.pdf NpModeCleaner.pdf
  5961   Sat Nov 19 15:58:04 2011 MirkoUpdateIOOSome more looks into OSEM noise

[Den, Mirko]

We looked some more into the the OSEM signals and their coherence to the seismometer signals.

We were able to verify that the coherence OSEM sensor <-> seismometer signal goes down with increasing the OSEM gain. This seems to indicate that the OSEM FB add noise to the distance mirror <-> frame. We injected some noise into the OSEMs to see how the coherence behaves.

MC2 SUSPOS, 0.1Hz - 0.8Hz, 3mins each

Inj. amplitude   Time(UTC) Note

-                     21:35          Free swinging
-                     21:42          Big LF OSEM gain
-                     21:48          Small LF OSEM gain
150                     21:56          -"-
300                     22:00          -"-
900                     22:05          -"-

Free swinging:

FreeSwinging.png

High OSEM gain:


LocalDampingOn.pdf

Low OSEM gain:

LowOsemGain.pdf

LowOsemGainInj150.pdf

Low_LF_OSEM_Gain_Inj300.fig

LowOsemGainInj900.pdf

 

We left the filters that lower the OSEM gain below 0.3Hz on.

Attachment 2: High_Osem_Gain.pdf
High_Osem_Gain.pdf
Attachment 4: Low_LF_OSEM_Gain.fig
  5969   Mon Nov 21 15:47:58 2011 MirkoUpdateIOOOsem loop shape

[Jenne, Mirko]

To reiterate: We changed the OSEM loop shape for MC1-MC3. Below in black is the old loop shape, which simulated pendulum response in there. In red is the new loop shape.

OsemFilterShape.pdf

The differences are due to extra filter in C1:SUS-MC?_SUSPOS module 6,7,9

6: Elliptical LP @ 2.5Hz
7: Inverse Chebychev HP @0.3Hz
8: 1st order LP @ 10Hz

This has the potential to be unstable, but is not. At some point these filters should be tuned further.

  5971   Mon Nov 21 17:07:34 2011 MirkoUpdateCDSc1pem model dead

For some reason C1PEM doesn't seem to work anymore after a recompilation. It did recompile fine. We just changed some channel / subsystem names.

Tried reverting to the svn version. Doesn't work. Reboot C1SUS also no good.

  5973   Mon Nov 21 22:51:55 2011 MirkoUpdateCDSc1pem model dead

Quote:

For some reason C1PEM doesn't seem to work anymore after a recompilation. It did recompile fine. We just changed some channel / subsystem names.

Tried reverting to the svn version. Doesn't work. Reboot C1SUS also no good.

 It is fine again. Thanks Jamie.

  5981   Tue Nov 22 20:45:21 2011 MirkoUpdateIOOMeasurement of the actuator matrix

Tried measuring the actuator matrix for MC1.

With the watchdogs tripped I cut the loops for pos, pitch and yaw open just before the servos. Then I injected a fixed sine at 0.4Hz into the three DOFs (suspos, suspit, susyaw) one by one, while looking into the error signal just before the servos.

 

                                                         Response DOF

                                     pos                 pit             yaw

Injection DOF pos          0.008417       0.00301        0.004975
                     pit            0.01295         0.01959        0.0158
                     yaw         0.007188        0.002152     0.0144

Inverting that and dividing by the norm gives us

 0.8322   -0.1096   -0.1669
-0.2456    0.2869   -0.2293
-0.3777    0.0118    0.4211

Somehow putting this into the 'To coil' matrix has an effect even with the watchdog tripped!?!?

 

  5986   Wed Nov 23 02:34:28 2011 MirkoUpdatePEMSeismic spectrum & Striptool

The Striptool for the BLRMS seismic channels is running now. Channels are ( still ) recorded as slow EPICS channels.

A big peak in the 0.1 - 0.3Hz seismic region in both GUR1 and STS1 irritated us for a while. I added an extra LP filter @ 0.05Hz to the RMS_LP modules.

SeismicSpectrum.pdf

 

  6004   Thu Nov 24 20:22:42 2011 MirkoUpdateIOOF2A filter for MC

I calculated the F2A filters for the input mode cleaner optics as described in T010140-01-D eq (4). On Ranas recommendation I added an s/ ( w_0 * Q ) term to the numerator.

The used values are:

w_0 = 2pi / s
h= 0.0009
D= 2.46957E-2
Q=10

UpperCoils.pdf

LowerCoils.pdf

I put theses filters into C1:SUS-MC1_TO_COIL_1_1 to _4_1 . For convenience split in Z and P. Well it doesn't work. After a few seconds the optic begins to swing wildly.

  6005   Fri Nov 25 12:46:13 2011 MirkoUpdateWienerFilteringWiener filtering tryout

Tried the wiener filter with the TF from p.5900

Tried it out with the TFs from p.5900:

WienerFiltering.pdf

Adding a filter element that compensates the acutator TF makes the MC lose lock.

  6011   Fri Nov 25 22:11:12 2011 MirkoUpdateCDSBeware of fancy filter modules

[Rana, Den, Mirko]

It seems you can shoot yourself in the foot if your filter modules are too complex.

Den discovered this when looking into the C1:SUS-MC?_SUSPOS filter module named Cheby, consisting of cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501) by noticing that the coherence between input and output of the filter is low.

Cheby filter:

Cheby.png

CoherenceCheby.pdf

This is most likely due to the filter spanning more than the 16 orders of precision that the double data type spans.

The coherence is fine when one splits the filter in two, giving every cheby1 filter its own module. The coherence is also fine when you use the Cheby filter in a 2kHz system, although the freq. response looks very odd

Black: 16kHz, Red 2kHz (yes the filter was converted correctly, no text file editing there)

ChebyAt16kHzBlackand2kHzRed.png

The problem occurs on c1lsc as well as c1sus computer.

 

Looking into the foton files actually points to a precision problem, with the huge range of scale covered in there:

C1:MCS 16kHz (Cheby: Original filter with low coherence. CHbyTST & ChebyTST: Original filter split amongst two filter modules)
################################################################################
### SUS_MC3_LSC                                                              ###
################################################################################
# DESIGN   SUS_MC3_LSC 0 zpk([0],[30],0.333333,"n")
# DESIGN   SUS_MC3_LSC 1 cheby1("LowPass",6,1,12)
# DESIGN   SUS_MC3_LSC 2 cheby1("LowPass",2,0.1,3)gain(1.13501) \
#                       
# DESIGN   SUS_MC3_LSC 3 cheby1("LowPass",2,0.1,3)gain(1.13501)cheby1("LowPass",6,1,12)
# DESIGN   SUS_MC3_LSC 4 ellip("BandStop",4,1,40,16.1,16.9)ellip("BandStop",4,1,40,23.7,24.5)gain(1.25871)
###                                                                          ###
SUS_MC3_LSC 0 12 1  32768      0 30:0.0          9.942903833923793  -0.9885608209680459   0.0000000000000000  -1.0000000000000000   0.0000000000000000
SUS_MC3_LSC 1 21 3      0      0 CHbyTST     9.095012702673064e-18  -1.9978637592754149   0.9978663974923444   2.0000000000000000   1.0000000000000000
                                                                 -1.9984258494490537   0.9984376515442090   2.0000000000000000   1.0000000000000000
                                                                 -1.9994068831713223   0.9994278587363880   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 2 12 1  32768      0 ChebyTST    1.228759186937126e-06  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000
                                                                 -1.9978637592754149   0.9978663974923444   2.0000000000000000   1.0000000000000000
                                                                 -1.9984258494490537   0.9984376515442090   2.0000000000000000   1.0000000000000000
                                                                 -1.9994068831713223   0.9994278587363880   2.0000000000000000   1.0000000000000000
SUS_MC3_LSC 4 12 8  32768      0 BounceRoll     0.9991466189294013  -1.9996634951844035   0.9997010181703262  -1.9999611719719754   0.9999999999999997
                                                                 -1.9999303040590390   0.9999684339228864  -1.9999605309876360   0.9999999999999999
                                                                 -1.9999248796830529   0.9999668732412945  -1.9999594299327190   1.0000000000000002
                                                                 -1.9996385459838455   0.9996812069238987  -1.9999587601905868   1.0000000000000000
                                                                 -1.9996161812709703   0.9996978939989944  -1.9999163485656493   0.9999999999999999
                                                                 -1.9998855694973159   0.9999681878303275  -1.9999154056705493   0.9999999999999998
                                                                 -1.9998788577090287   0.9999671193335300  -1.9999137972442669   1.0000000000000000
                                                                 -1.9995951159123118   0.9996843310430819  -1.9999128255920269   1.0000000000000000

C1:OAF 2kHz
###############################################################################
### YARM_IN                                                                  ###
################################################################################
# DESIGN   YARM_IN 0 zpk([0],[30],0.333333,"n")
# DESIGN   YARM_IN 3 cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501)
# DESIGN   YARM_IN 4 ellip("BandStop",4,1,40,16.1,16.9)ellip("BandStop",4,1,40,23.7,24.5)gain(1.25871)
# DESIGN   YARM_IN 8 cheby1("LowPass",6,1,12)cheby1("LowPass",2,0.1,3)gain(1.13501)zpk([],[10],1,"n")
###                                                                          ###
YARM_IN  0 12 1   4096      0 30:0.0           9.56649943398763  -0.9119509539166185   0.0000000000000000  -1.0000000000000000   0.0000000000000000
YARM_IN  3 12 4   4096      0 Cheby       1.829878084970283e-16  -1.9828889048300398   0.9830565293861987   2.0000000000000000   1.0000000000000000
                                                                 -1.9868188576622443   0.9875701115261976   2.0000000000000000   1.0000000000000000
                                                                 -1.9940934073784453   0.9954330165532327   2.0000000000000000   1.0000000000000000
                                                                 -1.9781245722853238   0.9784022621062476   2.0000000000000000   1.0000000000000000

Attachment 1: ChebyTST3.png
ChebyTST3.png
  6012   Fri Nov 25 23:25:24 2011 MirkoUpdateIOOF2A filter for MC

Quote:

Woo. Pretty crazy. The numerators should only be ~10% larger than the denominator below 1 Hz. Let's try again.

 [Rana, Mirko]

I redid this calculation. The idea behind it is to get rid on any pitch that is introduced by applying longitudinal feedback to the mirrors. This coupling happens because the center of percussion for pitch , which is identical with the point where the wires lift off of the mirror, is above the center of mass.

With the same values as before, just less faulty math and Q = 2 instead of 10 we end up with the following filters:

For the lower coils (red), compared to corresponding preexisting BS filters (black):

F2aForMCcomparedToBS.pdf

The upper coils' TF is just mirrored at the 0dB magnitude axis, and have a corresponding frequency response.

I switched the F2a filters on for all MC mirrors. For convenience they are split into F2aZeros and F2aPoles. Everything seems fine. The F2a filters seem to be off for ( all ?) other mirrors.

  6013   Sat Nov 26 02:05:43 2011 MirkoUpdateCDSBeware of fancy filter modules

 

We replaced the complicated Cheby filter module with three separate filter modules. Probably the filter doesn't need to be so complicated, but rather not change too many things at once. The new filter modules are called:
Ch1, Ch2, Ch3 and are in filter module 3,9, and 10 of the C1:SUS-MC?_SUSPOS filters. The coherence with these filters is fine. Someone should look into the possibility of simplifying these filters.

It would be good to check for numerical problems in other filters!

  6014   Sat Nov 26 02:15:42 2011 MirkoUpdateSUSNot adaptive, still cool

[Rana, Mirko]

I tried out the virtual pendulum idea today. The idea is to compensate the physical pendulum via the control system, and then add a virtual pendulum formed in the control system. We know the actuator TF from p. 5900 and apply its inverse to the C1:SUS-MC?_SUSPOS filters. Also we add an pendulum Q=3 with a resonance frequency of 0.1Hz to the POS control loops.

The result is pretty awesome!

1. Black: Standard config. Wfs on. New Cheby filter in place ( p. 6031 )
2. Red: With virtual pendulum. Extra eliptic LP filter @ 2.5Hz

PendulumQ0.1HzWithElip2comma5HzLpWfsOnCorrectedShape.pdf

Filter shape:

VirtualPendulumFilterShape.pdf

This is stable for 5-10minutes, at which point it falls out of lock, swinging in yaw.

 

 

Attachment 3: SetupVirtualPendulumV2.png
SetupVirtualPendulumV2.png
  6057   Thu Dec 1 03:27:39 2011 MirkoUpdateSUSNot adaptive, still cool

Quote:

[Rana, Mirko]

I tried out the virtual pendulum idea today. The idea is to compensate the physical pendulum via the control system, and then add a virtual pendulum formed in the control system. We know the actuator TF from p. 5900 and apply its inverse to the C1:SUS-MC?_SUSPOS filters. Also we add an pendulum Q=3 with a resonance frequency of 0.1Hz to the POS control loops.

The result is pretty awesome!

1. Black: Standard config. Wfs on. New Cheby filter in place ( p. 6031 )
2. Red: With virtual pendulum. Extra eliptic LP filter @ 2.5Hz

PendulumQ0.1HzWithElip2comma5HzLpWfsOnCorrectedShape.pdf

Filter shape:

VirtualPendulumFilterShape.pdf

This is stable for 5-10minutes, at which point it falls out of lock, swinging in yaw.

 

 

In the above entry MC_f  signal is improved off of resonance by the implementation of the pendulum compensation. It should be checked if this is actually due to the implementation of the virtual pendulum at 0.1Hz. A way to check that might be to implement a simple double LP at 0.1Hz instead and look at the resulting MC_f signal. A projection of the OSEM FB noises with the compensation active might be interesting.
The physical resonance at 1Hz is clearly not compensated correctly, which is probably the reason for the lock losses after a few minutes. It might be a good start to measure the residual resonance with the compensation in place. The filters in bank 7 of C1:SUS-MC?_SUSPOS have both the compensation of the 1Hz resonance( really the inverse actuator TF ) and the virtual pendulum in them. The ‘pure’ compensation can be found in the InvTF module in the C1:OAF-ADAPT_MCL_CORR filter.
The fact that the beam swings in yaw at lock loss indicates that the separation of the DOFs might not be perfect. One should have a look into the yaw and pitch DOFs with the compensation active.

  2091   Wed Oct 14 15:48:26 2009 MottHowToGeneralPhase Noise measurement

I have gotten the hang of the procedure for measuring phase noise on the AOMs. 

Koji suggested I right up a short guide (wiki page?) on how to do this. 

I will finish up here, then go measure the AOMs at the other lab (may have to be tomorrow, after laser safety), and then write up the instructions.

  2117   Mon Oct 19 13:00:53 2009 MottUpdateGeneralPhase Noise Measurement

Here is the result for the measurement of the phase noise.  We used the marconi function generator and compared it with an Isomet AOM driver (model 232A-1), so this is really a measure of the relative phase between them.  We used a 5x gain and a frequency response of 13 Hz/V for the modulation.  In all the attached plots, the blue is the data and the red is the measurement limit (as determined by the noise in the SRS785).  Also note that the units on the yaxis of the Phase noise plot are incorrect, they should be dB/Sqrt(Hz), I will fix this and edit as soon as possible.

Attachment 1: PhaseNoiseWithError.jpg
PhaseNoiseWithError.jpg
Attachment 2: G.jpg
G.jpg
Attachment 3: PSD.jpg
PSD.jpg
  2362   Mon Dec 7 19:02:22 2009 MottUpdateGeneralReflectivity Measurements

I have made some measurements of the R value for some coatings we are interested in.  The plots have statistical error bars from repeated measurements, but I would suspect that these do not dominate the noise, and would guess these should be trusted to plus or minus 5% or so.  They still should give some indication of how useful these coatings will be for the green light.  I plan to measure for the ITM as soon as possible, but with the venting and finals this may not be until late this week.

 

EDIT (12/9/09): I fixed the label on the y axis of the plots, and changed them to png format.

Attachment 1: Y1-45P_R.png
Y1-45P_R.png
Attachment 2: Y1-45S_R.png
Y1-45S_R.png
Attachment 3: Y1-50CC_R.png
Y1-50CC_R.png
  2392   Thu Dec 10 18:27:48 2009 MottUpdateGeneralUpdated R & T Measurements

Attached are updated plots of the T&R Measurements for a variety of mirrors, and diagrams for the setup used to make the measurements.

T is plotted for the 1064 nm measurement, since these mirrors are highly reflective at 1064, and either R or R&T are plotted for the 532 nm measurement, depending on how larger the R signal is.

As with the previous set of plots, the error bars here are purely statistical, and there are certainly other sources of error not accounted for in these plots.  In general, the T measurement was quite stable, and the additional errors
are probably not enormous, perhaps a few percent.

The mirrors are:

Y1-1037-00.50CC

Y1-2037-45S

Y1-2037-45P

Y1S-1025-0

Y1S-1025-45

 

Attachment 1: Y1S-0.png
Y1S-0.png
Attachment 2: Y1S-45.png
Y1S-45.png
Attachment 3: Y45P.png
Y45P.png
Attachment 4: Y45S.png
Y45S.png
Attachment 5: Y150CC.png
Y150CC.png
Attachment 6: Setup.png
Setup.png
  2474   Mon Jan 4 17:26:01 2010 MottUpdateGeneralT & R plots for Y1 and Y1S mirrors

The most up-to-date T and R plots for the Y1 and Y1S mirrors, as well as a T measurement for the ETM, can be found on:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/Optics/RTmeasurement

 

  2696   Mon Mar 22 22:11:26 2010 MottUpdateABSLPLL reconstructed

 

 It looks like the PLL drifted alot over the weekend, and we couldn't get it back to 9 dBm.  We switched back to the new focus wideband PD to make it easier to find the beat signal.  I replaced all the electronics with the newly fixed UPDH box (#17) and we aligned it to the biggest beat frequency we could get, which ended up being -27 dBm with a -6.3V DC signal from the PD.  

Locking was still elusive, so we calculated the loop gain and found the UGF is about 45 kHz, which is too high.  We added a 20 dB attenuator to the RF input to suppress the gain and we think we may have locked at 0 gain.  I am going to add another attenuator (~6 dB) so that we can tune the gain using the gain knob on the UPDH box.  

Finally, attached is a picture of the cable that served as the smb - BNC adaptor for the DC output of the PD.  The signal was dependent on the angle of the cable into the scope or multimeter.  It has been destroyed so that it can never harm another innocent experiment again!

Attachment 1: IMG_0150.JPG
IMG_0150.JPG
  2697   Mon Mar 22 23:37:32 2010 MottUpdateABSLPLL reconstructed

 

We have managed to lock the PLL to reasonable stability. The RF input is attenuated by 26 dBm and the beat signal locks very close to the carrier of the marconi (the steps on the markers of the spectrum analyzer are coarse).  We can use the marconi and the local boost of the pdh box to catch the lock at 0 gain.  Once the lock is on, the gain can be increased to stabilize the lock.  The locked signals are shown in the first photo (the yellow is the output of the mixer and the blue is the output to the fast input of the laser.  If the gain is increased too high, the error signal enters an oscillatory regime, which probably indicates we are overloading the piezo.  This is shown in the second photo, the gain is being increased in time and we enter the non-constant regime around mid-way through.

Tomorrow I will use this locked system to measure the PZT response (finally!).

Attachment 1: 2010-03-22_23.14.00.jpg
2010-03-22_23.14.00.jpg
Attachment 2: 2010-03-22_23.24.50.jpg
2010-03-22_23.24.50.jpg
  2703   Tue Mar 23 18:44:46 2010 MottUpdateABSLPLL reconstructed

 

 After realigning and getting the lock today, I tried to add in the SR785 to measure the transfer function.  As soon as I turn on the piezo input on the PDH box, however, the lock breaks and I cannot reacquire it.  We are using an SR650 to add in the signal from the network analyzer and that has worked. We also swapped the 20 dB attenuator for a box which mimics the boost functionality (-20 dB above 100 Hz, 0 dB below 6Hz).  I took some spectra with the SR750, and will get some more with the network analyzer once Alberto has finished with it. 

The SR750 spectra is posted below.  The SR750 only goes up to 100 kHz, so I will have to use the network analyzer to get the full range. 

Attachment 1: NPRO_PLL_freqresp.png
NPRO_PLL_freqresp.png
  2729   Mon Mar 29 15:26:47 2010 MottHowToComputersNew script for controlling the AG4395A

I just put a script in the /cvs/cds/caltech/scripts/general/netgpibdata/ directory to control the network analyzer called AG4395A_Run.py .   A section has been added to the wiki with the other GPIB script sections (http://lhocds.ligo-wa.caltech.edu:8000/40m/netgpib_package#AG4395A_Run.py)

  2738   Wed Mar 31 03:45:49 2010 MottHowToComputersNew script for controlling the AG4395A

 

I took data for the 2 NPRO PLL using the script I wrote for the AG4395, but it is very noisy above about 1 MHz.  I assume this is something to do with the script (since I am fairly confident we don't have 600 dB response in the PZT), so I will go in tomorrow to more carefully understand what is going on, I may need to include a bit more latency in the script to allow the NA to settle a bit more.  I am attaching the spectrum just to show the incredibly high noise level, 

Attachment 1: noisy_spec.png
noisy_spec.png
  2746   Thu Apr 1 00:43:33 2010 MottUpdateGeneralPZT response for the innolight

Kiwamu and I measure the PZT response of the Innolight this evening from 24 kHz to 2MHz.  

We locked the PLL at ~50 MHz offset using the Lightwave NPRO and and swept the Innolight with the network analyzer (using the script I made; it has one peculiar property, but it does work correctly).  

We will post the plot of the Lightwave PZT response tomorrow morning.

 

**EDIT**: As Koji pointed out, the calibration factor on this plot is WRONG.  See my more recent update for the correctly calibrated plot.

Attachment 1: Innolight_Bode.png
Innolight_Bode.png
  2748   Thu Apr 1 10:21:58 2010 MottUpdateGeneralPZT response for the innolight

Quote:

The shape of the TF looks nice but the calibration must be wrong.

Suppose 1/f slope with 10^-4 rad/V at 10kHz. i.e. m_pm = 1/f rad/V
This means m_fm = 1 Hz/V. This is 10^7 times smaller than that of LWE NPRO.

Quote:

Kiwamu and I measure the PZT response of the Innolight this evening from 24 kHz to 2MHz.  

We locked the PLL at ~50 MHz offset using the Lightwave NPRO and and swept the Innolight with the network analyzer (using the script I made; it has one peculiar property, but it does work correctly).  

We will post the plot of the Lightwave PZT response tomorrow morning.

 

 Koji is absolutely right.  I just double checked my matlab code, and saw that I divided when I should have multiplied.  The correctly calibrated plots are attached here for the Innolight and the lightwave.  Kiwamu and I will measure the amplitude and the jitter today.

Attachment 1: Innolight_Response.png
Innolight_Response.png
Attachment 2: Lightwave_response.png
Lightwave_response.png
  2754   Thu Apr 1 18:05:29 2010 MottUpdateGeneralPZT response for the innolight

 

 We realized that we had measured the wrong calibration value; we were using the free-running error signal with the marconi far from the beat frequency, which was very small.  When we put the Marconi right at the beat, the signal increased by a factor of ~12 (turning our original calibration of 10 mV/rad into 120 mV/rad).  The re-calibrated plots are attached. 

Attachment 1: Innolight_Response_calFix.png
Innolight_Response_calFix.png
Attachment 2: Lightwave_response_calFix.png
Lightwave_response_calFix.png
  2756   Thu Apr 1 19:59:32 2010 MottUpdateGeneralPZT response for the innolight

 

 We measured the Amplitude Modulation response of the PZTs, to find regions with large phase modulation but small amplitude modulation.

We did this by blocking 1 arm of the PLL, feeding the source output of the Network Analyzer into the PZT input of the laser in question, and reading the output of the PD on the NA.  We calibrated by dividing by the DC voltage of the PD (scaled by the ratio of the AC gain to DC gain of the New Focus PD).

The AM response of the Innolight looks fairly smooth up to ~1MHz, and it is significantly below the PM response for most of its range.  The region between 20 and 30 kHz shows very good separation of about 10^3 rad/RIN (and up to 10^5 rad/RIN at ~21.88 kHz, where there is the negative spike in the AM response). The region between 1.5 MHz and 2MHz also looks viable if it is desirable to actuate at higher frequencies.

The Lightwave offers very good AM/PM separation up to about 500 kHz, but becomes quite noisy about 1MHz.

Attachment 1: Innolight_AM_Response.png
Innolight_AM_Response.png
Attachment 2: Innolight_AM_PM.png
Innolight_AM_PM.png
Attachment 3: InnoVsLW_PM.png
InnoVsLW_PM.png
Attachment 4: Innolight_AM_Response.png
Innolight_AM_Response.png
Attachment 5: Lightwave_AM_PM.png
Lightwave_AM_PM.png
  2799   Tue Apr 13 19:53:06 2010 MottUpdateGreen LockingPZT response for the innolight and lightwave

 

 I redid the PZT Phase Modulation measurement out to 5 MHz for both the Innolight and the Lightwave.  The previous measurement stopped at 2MHz, and we wanted to see if there were any sweet spots above 2MHz.  I also reduced the sweep bandwidth and increased the source amplitude at high frequency to reduce the noise (the Lighwave measurement, especially, was noise dominated above 1MHz).  I also plotted the ratio of PM/AM in rad/RIN, since this is the ultimate criterion on which we want to make a determination.

It looks like there is nothing extremely useful above 2MHz for either laser.  There are several candidates for the lightwave at about 140 kHz and again at about 1.4 MHz.  The most compelling peak, however, is in the innolight at 216 kHz, where the peak is about 2.3e5 rad/RIN.

Below about 30kHz, the loop suppresses the measurement, so one should focus on the region above there.

Attachment 1: Innolight_PM.png
Innolight_PM.png
Attachment 2: Innolight_AM_PM.png
Innolight_AM_PM.png
Attachment 3: Innolight_PM_AM_Ratio.png
Innolight_PM_AM_Ratio.png
Attachment 4: Lightwave_PM.png
Lightwave_PM.png
Attachment 5: Lightwave_AM_PM.png
Lightwave_AM_PM.png
Attachment 6: Lightwave_PM_AM_Ratio.png
Lightwave_PM_AM_Ratio.png
  3233   Thu Jul 15 23:51:47 2010 Mr. MaricHowToSUSLevitate me if you can

You guys must work harder.

mag_lev.jpg


  8742   Tue Jun 25 10:18:34 2013 Mystery ManUpdateLSCArm Cavity scan with X-ALS after ALS servo upgrade

Quote:

RMS is now less than 1 kHz or ~50 pm. (in your face, Kiwamu!)

 Isn't this still a factor of 2 away from the limit in the paper?

  3027   Tue Jun 1 18:39:59 2010 NancyUpdate Lead spheres for the seismographs

 

the lead spheres that were placed below the granite slab have been flattened by hammering to have lesser degree of wobbling of the slab.

the height of each piece, and the flatness of their surfaces was checked by placing another slab over them and checking by the spirit level.

P6010170.JPG

P6010166.JPG

P6010164.JPG

 

  3386   Mon Aug 9 12:46:24 2010 NancyUpdateIOOMode Cleaner WFS


 Yesterday , I put in the Output Matrix, and changed the gain sliders for the 4 WFS loops.

From how much to how much have you chnged the gain?

I changed the gains from all 4 0.01 to o.27, 0.23, 0.32 and 0.11 and the main alignment gain to be 0.8

 

 

Next we stepped to putting in the gains for the MC2 oplev servo.

I like to put the credit to Aidan for teaching Nancy how to use FOTON.

 Yes, I am sorry for not mentioning this.

Thanks Aidan

 

 

ELOG V3.1.3-