40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 131 of 335  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  5676   Mon Oct 17 10:43:14 2011 MirkoUpdateCDSCommited changes to c1rfm

I want to make changes to c1rfm. Found uncommited changes to it from Sept 27. Since we recompiled it since then it should be safe to commit them, so I did. See svn log for details.

  5677   Mon Oct 17 11:06:31 2011 MirkoUpdateCDSPiping data from c1lsc to c1oaf

Changed, recompiled, installed and restarted c1rfm and c1oaf to get the MC1-3 Pitch and Yaw data into the c1oaf model.
Also changed c1oaf to use MCL as a witness channel (as well as an actuator).
Added the changes to svn.

  5679   Mon Oct 17 14:26:22 2011 MirkoUpdateCDSSeismic BLRMS channels, new RMS calculation

Quote:

[Rana, Koji, Mirko]

We looked into the CDS RMS block c-code as described in Rolfs RCG app guide. Seems the block uses a first order LP filter with a corner freq. / time of 20k execution cycles. There are also some weird thersholds at +-2000counts in there.

I was looking into implementing a hand-made RMS block, by squaring, filtering, rooting. The new RMS (left) seems nicer than the old one (bottom right). Signal was 141counts sinus at 4Hz.

Filters used: Before squaring: 4th order butterworth BP at given freq. & (new) 6th order inverse Chebyshew 20dB at 0.9*lower BP freq. and 1.1*upper BP freq. => about 1dB at BP freq.

                       After squaring: 4th order butterworth LP @ 1Hz.

C1PEM execution time increased from about 20us to about 45us.

Made a new medm screen with the respective filters in place of the empty C1PEM_OVERVIEW. Should go onto the sitemap.

New_RMS_vs_old_RMS.png

Original RMS LP is slower than 0.1Hz, see below for single LP at 0.1Hz in the new RMS. Original RMS is faster than single LP @ 0.01Hz

Original_RMS_LP_slower_than_0.1Hz.png

Some of the channels are recorded as 256Hz DAQ channels now. Need to figure out how to record these as 16Hz EPICS channls.

 Channels are now going into EPICS channels (e.g. C1:PEM-ACC1_RMS_1_3 ). Adapted the PEM_SLOW.ini file. Channels don't yet show up in dataviewer. Probably due to other C1PEM maschine

  5695   Wed Oct 19 12:06:26 2011 MirkoUpdateCDSIncluded the MC servo channel in CDS

[Jamie, Mirko]

Included the 'Servo' output from the D040180 in c1ioo, which I hoped would be a better measure of the MC length fluctuations. It goes into ADC6, labeled CH7 on the physical board.
Servo-output => C1:IOO-MC_SERVO. (Already present is Out1-output => C1:IOO-MC_F).
At low freq. the servo signal is about 4.5dB bigger. Both are recorded at 256Hz now which is the reason for the downward slope at about 100Hz.

MC_F_versus_MC_SERVO.png

Coh_MC_F_MC_SERVO.png

  5700   Wed Oct 19 15:48:20 2011 MirkoUpdatePEMMoved the STS1 from x-arm end to vortex

[Jenne, Mirko]

We moved our one STS1 from the x-arm end to the vortex. We record the data as STS1 in c1pem @ 256Hz. x is still north-south.

JD:  This is actually an STS-2.  We just call it C1:PEM-SEIS_STS1.... to differentiate the 3 STSs that we have from one another (assuming we plug in the other two).

19102011061.jpg

  5727   Fri Oct 21 18:20:54 2011 MirkoUpdateCDSFirst OAF version running

[Jenne, Jamie, Mirko]

We got the first version of the oaf code based on Matt"s code running!! :-)
Produces already data for e.g. MICH DOF. But don"t trust that. It's only 10 taps long and delay is not adjusted.

  5730   Mon Oct 24 19:48:16 2011 MirkoUpdateAdaptive FilteringFilter execution time

Toyed around some more with the adaptive filters.

Execution time:

nTaps    Downsampling factor     Execution time average / max in ca. 3 min [us], (480 us available)
1000     16                                110 / 150
2000     16                                280 / 340
3000     16                                380 / 470
4000     16                                Over limit

Now we are running with Downsampling 32, 4000 Taps => max 410us execution time.

I tried to desynchronize the downsampled operations of the filters of the different DOFs. That however increased execution time by about 10%. So I undid that.

 

  5731   Mon Oct 24 20:00:21 2011 MirkoUpdateCDSTiny little scripts

Located in /opt/rtcds/caltech/c1/userapps/release/cds/common/scripts

Script 1: Diagreset.sh
Hits the diag reset buttons on the models on c1lsc and c1sus computers.

Script 2: Burtrest.sh
Restores the burt files from "today" 4am. Use a text editor if you want to change the times.

  5738   Tue Oct 25 20:04:40 2011 MirkoUpdateAdaptive FilteringAdaptive filter witness and EP SNR

We currently have the code running for all DOFs using all witness channels. By default nothing is applied. C-Code parameters can be changed via the respective EPICS variables. Sanity checks in the C-Code make sure the code doesn't crash when nothing / zeros are fed to the code. Let's look into applying FF to one DOF only as a starting point. We start with MCL.

Remember there are two possible signals to look into MC-F and MC-Servo. See page 5695 http://nodus.ligo.caltech.edu:8080/40m/5695

Dark noise: MC-F over MC-Servo which is unconnected in this measurement:
MC-F_SNR_to_Dark_noise.png

=> At least 20dB SNR. ADC noise should not be an issue. Of course more is always better.

Coherence of seismometers to MCL:


STS1 is located at the vertex. x-axis along the x arm.
GUR1 is located at the IMC MC2 mirror. Same orientation.
Coherence.png

=> 1. Only the x-direction has good coherence (to be expected)
     2. Only good coherence at 1.5-4Hz (huh?)

So probably other noise sources are dominating. Let's look into noise projections. Remember IMC autoalignment is off.

A quick adaptive filter run with only the GUR1 and STS1 witnesses applied only to MCL didn't really do anything. Some more thought needs to be invested into the AA and shaping filters.

  5758   Fri Oct 28 15:45:52 2011 MirkoUpdateComputersNifty screen generator

Quote:

Suresh showed me a cool script that Mirko made, but didn't elog about.

You tell the script what filter banks you want, and it creates a screen for each with a bunch of different filter module display formats.  Then you can copy the format you like into the actual screen you're modifying. 

Currently PEM, LSC and IOO (and maybe others?) have "fmX" folders inside their medm/c1.../master folders.  For each subsystem, we need to copy this folder, and modify the generic .adl file so that it puts in the correct subsystem letters.  Once this is done, you can just run the generateFMscreens.py after putting in your filter bank names.

 Wasn"t me.

  5763   Sat Oct 29 22:57:03 2011 MirkoUpdateLSCAM modulation due to non-optimal SB frequency

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

  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

  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

 

  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

  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.

  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

  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

  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.

  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

 

  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.

  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

  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.

 

 

  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.

  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.

  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

 

  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!

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

  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. 

ELOG V3.1.3-