40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 173 of 339  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  5906   Wed Nov 16 10:08:17 2011 SureshUpdateIOOEffect of turning on the MC2_TRANS_PIT and YAW loops in ASC

I turned on the two remaining loops in the ASC system to see if we can lock.   I put in some ones into the WFS_OUTPUT matrix

WFS_OUTMATRIX.png

and locked the MC2_TRANS_PIT and MC2_TRANS_YAW loops.

The effect of doing so is visible in the error signals.  The black loops are with all ASC loops off, Blue traces are with the WFS1 and 2 loops locked and Red traces are with all loops locked.  I took the red traces to a lower frequency to see if the suppression of the error signals at low frequencies is disturbed by the switching on of the MC2_TRANS loops.  They seem to be working fine without adding any perturbation above the UGF.

WFS_servo_err_20111115.png

I measured the  Transfer Function coefs (at 10Hz using the WFS Lockins)  with MC2_TRANS loops locked in this rudimentary fashion

  WFS1P WFS2P MC2TP WFS1Y WFS2Y MC2TY
MC1P -23.8541 15.2501 -24.3470 -3.3166 -2.0473 -0.1202
MC2P 29.7402 54.7689 29.5102  -0.2922 -17.4226 0.0310
MC3P 34.3612 10.7279 33.9650 6.6582 -4.0892 0.2333
MC1Y 0.9510 -6.3929 0.8722 -98.2414 -82.9129 -4.2802
MC2Y 12.0673 6.1708 11.9502 237.1172 20.7970 14.6480
MC3Y -0.8498 2.8712 -1.4195 -20.6031 111.2531 -1.5234

 

The green and blue bits are the only relevant parts since we ignore the off diagonal parts.  And most of these off diagonal coefs are indeed quite small (<5% of the max).  I have marked the not-so-small ones in yellow.

I then calculated the output matrix elements in two different ways.

a) Using a null vector in the place of MC_DoF --> MC2_TRANS transfer coefs.  The output matrix we get is

 

  WFS1P WFS2P Null Vector
MC1P -1.0000 0.8271  -0.8880
MC2P 0.0962 1.0000  0.4431
MC3P 0.9306 -0.2913  -1.0000

 

  WFS1Y WFS2Y Null Vector
MC1Y -0.2340 -0.5840 1.0000
MC2Y 1.000o -0.1551  0.4714
MC3Y -0.3613 1.0000 0.6571

 

b) Without using the null vector.  i.e. using the MC_DoF --> MC2_TRANS transfer coefs and inverting the full matrix.  The output matrix we get is

 

   WFS1P WFS2P  MC2TP
 MC1P  0.1471  -0.8880  0.8655
 MC2P  1.0000  0.4431  -0.4369
 MC3P  -0.7634  -1.0000  1.0000

 

  WFS1Y WFS2Y MC2TP
MC1Y 0.1401 1.0000 -1.0000
MC2Y 0.1449 0.4714 -0.3627
MC3Y 1.0000 0.6571 -0.6775

 

I plan to try out these two output matrices and measure the OL TFs of the MC2_TRANS and see if we can include these into ASC in a useful fashion.

Attachment 1: WFS_OUTMATRIX.png
WFS_OUTMATRIX.png
  5910   Wed Nov 16 10:53:35 2011 SureshUpdateIOOMC2 Shifted in Pitch, corrected by adjusting the pitch bias

Quote:

[Steve, Suresh]

    Steve went over to the MC2 walkway and stepped over the barrier to pick up some stuff there.  MC2 stack shifted and MC2 pitch as off.  MC unlocked and could not relock till the MC2 pitch bias was readjusted

previous MC2PIT reading: 3.6235           current MC2PIT reading:  3.9565

Without the WFS the MC to PSL alignment is poor, but it is largely due to a shift in the MC and not a shift in the PSL beam.  We know this 'coz the shift in the DC spot positions on WFS (when the MC is unlocked) is not significant nor is the shift on the C1:IOO-QPD.  When WFS loops are engaged the MC optics are turned to optimise the PSL to MC alignment, but the shift is large at the moment.

(Sorry Mirko your measurement could not be completed.  The MC unlocked in the middle)

Please Note:  If you need to access the blocked off area near MC2 stack, do not step over the barrier.  The disturbance is too great and the MC2 stack will shift.  Instead please move the barrier aside and walk as gently as possible near it, taking care not to touch the MC2 Chamber.

 

Apparently the MC2 stack had not finished shifting.   The MC unlocked while Steve was working on the PSL table installing the mirror for IOO_QPD and then it could not relock.  So I moved the MC2 once again in Pitch.  The current status of the sliders is here

C1IOO_MC_ALIGN.png

 

Yesterday I fixed the yellow buttons on the MC_ALIGN and MCLOCK screens.  They use the new updatesnap script  .  Could we also add a couple of lines to this script so that eveytime we save a snap shot the various values are written(appended) to a text file?  That way we do not need to depend solely on the conlog, which is quite slow.

 

  5913   Wed Nov 16 17:03:19 2011 KojiUpdateIOOMC2 Shifted in Pitch, corrected by adjusting the pitch bias

MC was not locked for more than 5 hours because of the misalignment.

Noticed that MC2 WFS feedback filters had big outputs (particularly in Pitch).
They were reset to zero.

MC2 was aligned and recovered the lock. Once the WFS is engaged, the transmission returned to the uisual value.

  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.

  5916   Wed Nov 16 18:14:09 2011 KojiUpdateIOOMC unlocked and misaligned.

Actually, do we need to reset the filter history at every lock loss of the MC?

Those DC offsets were necessary to keep the alignment good just until the MC is unlocked.
So if we keep the history, we can maintain the good alignment.

  5917   Wed Nov 16 20:30:27 2011 not KojiUpdateIOOMC unlocked and misaligned.

Quote:

Actually, do we need to reset the filter history at every lock loss of the MC?

Those DC offsets were necessary to keep the alignment good just until the MC is unlocked.
So if we keep the history, we can maintain the good alignment.

 I suspect the integrators get fed a huge wrong signal on lockloss. Clearing the history on the trans DOFs when the MC was badly aligned gets it nicely aligned again. I switched off the alignment transmission DOFs for now.

  5925   Thu Nov 17 13:58:12 2011 SureshUpdateIOOMC unlocked and misaligned.

Quote:

Quote:

Actually, do we need to reset the filter history at every lock loss of the MC?

Those DC offsets were necessary to keep the alignment good just until the MC is unlocked.
So if we keep the history, we can maintain the good alignment.

 I suspect the integrators get fed a huge wrong signal on lockloss. Clearing the history on the trans DOFs when the MC was badly aligned gets it nicely aligned again. I switched off the alignment transmission DOFs for now.

I have modified the 'mcwfson' and 'mcwfsoff' scripts to include the Clear History step for the MC2_TRANS_PIT and _YAW filters.  

These scripts can be run, by hand, from LOCKMC screen or from the WFS_MASTER screen.  Use the 'Turn WFS ON/OFF' button. 

The mcautolockmain script will now clear history on all ASC filter banks when the MC unlocks.

I have turned on ASC loops on the MC2_TRANS (= alignment transmission DOFs of the above elog) paths.

 

 

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

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

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

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

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

Whiteish noise injection:

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

 MCLengthToAngleCouplingNoiseProjection.png

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

Coherence_WFS1pit.png

Coherence_WFS2pit.png

 

Coherence_WFS1yaw.png

 Coherence_WFS2yaw.png

Injection details:

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

Fixed sine injections:

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

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

Attachment 2: WFS1pit.png
WFS1pit.png
Attachment 3: WFS1yaw.png
WFS1yaw.png
Attachment 4: WFS2pit.png
WFS2pit.png
Attachment 5: WFS2yaw.png
WFS2yaw.png
Attachment 7: Coherence_WFS2pit.png
Coherence_WFS2pit.png
Attachment 11: NpWfs.pdf
NpWfs.pdf NpWfs.pdf NpWfs.pdf NpWfs.pdf NpWfs.pdf
  5933   Thu Nov 17 23:38:40 2011 DenUpdateIOOMC unlocked

MC is unlocked to measure the free swing of the MC mirrors with the local sensors.

Autolocker is disabled.

  5934   Thu Nov 17 23:44:48 2011 DenUpdateIOOMC1_SENSOR

We've found that one of the  MC1_SENSORS does not work properly.

See the figure.

Attachment 1: MCSENSORS.pdf
MCSENSORS.pdf
  5935   Thu Nov 17 23:47:43 2011 DenUpdateIOOMC1_SENSOR

The most interesting plot did not uploaded in the previous elog.

Upload now local MC1_SENSOR signals.

Attachment 1: MC1SENSOR-crop.pdf
MC1SENSOR-crop.pdf
  5939   Fri Nov 18 01:27:04 2011 DenUpdateIOOMC locked

[Mirko, Den]

While the MC was unlocked (and the local damping off) we've measured the coherence between GUR1_X and OSEM sensors. It was rather high, close to 1 at frequencies 0.1 - 1 Hz. That means that stack does not kill all coherence between seismic noise and mirror motion.

Then we've turned on the local damping and measured the coherence again between GUR1_X and OSEM sensors. It decreased due to some noise and was on the level of ~0.5. We did reduced the motion between the mirror and the frame by local damping but it is not obvious that we lost some coherence due to this effect. Probably, actuator adds some noise.

When we locked the MC, we did not see any coherence at 0.1 - 1 Hz between GUR1_X or STS1_X and OSEM sensors of MC1 and MC3 but we did see with MC2. The MC1 sensor was fixed by Suresh.

 

Attachment 1: cohnolocalpumping-crop_4.pdf
cohnolocalpumping-crop_4.pdf
Attachment 2: cohlocalpumping4-crop.pdf
cohlocalpumping4-crop.pdf
Attachment 3: cohlock4-crop.pdf
cohlock4-crop.pdf
  5941   Fri Nov 18 01:51:37 2011 KojiUpdateIOOStochmon update

Update of the stochmon status

[Attachment 1: Circuit diagram]

- The new stochmon has a low noise amplifier (MAR-6SM) inside.
The RFAM signal from the PD has the power of -60~-50dBm, which is almost at the bottom of the sensitivity for the power detector.

- The band pass filters were doubled.

- I've suffered from some RF coupling from the power line as the power detector is quite sensitive to it.
The situation has been largely improved by the EMI filters in the power supply path, although the problem is still present.
The worst remaining problem is that we can not close the aluminum lid as it cause a huge sprious coupling.

 

[Attachment 2: Calibration result]

- The outputs were calibarted with Marconi. They showed the signals linear to dBm for the input powers between -70dBm and -10dBm.

- The calibration result was fitted with the empirical fit function. The function and the results are shown in the attachment.

[Attachment 3: Detection limit]

- The attached figure shows the power spectrum of the PD output. This measurement gives us the amount of the RF power given from the PD noise when there is no RF signal.

11MHz out passband noise: −72.7dBm ===> V11 = 2.0483
30MHz out passband noise: −64.6dBm ===> V30 = 1.9333
55MHz out passband noise: −71.2dBm ===> V55 = 2.0272

- Now 11MHz and 55MHz outputs seem indicating the power correctly, but the 29.5MHz output never provides useful information.
It is a constant value independent from the state of the incident beam. Strangely this problem disappears if the marconi is used
for the RF source. Thus this issue is not seen in the calibration measurement.

- So far, 11MHz, 29.5MHz, 55MHz, and DC outputs appear in the channels C1:IOO-RFAMPD_33MHZ, C1:IOO-RFAMPD_133MHZ, C1:IOO-RFAMPD_166MHZ, and C1:IOO-RFAMPD_199MHZ.
They will be renamed.

Attachment 1: stochmon.pdf
stochmon.pdf
Attachment 2: stochmon_calib.pdf
stochmon_calib.pdf
Attachment 3: RFAM_PD_noise.pdf
RFAM_PD_noise.pdf
  5942   Fri Nov 18 02:50:10 2011 kiwamuUpdateIOORF generation box : power switch malfunction

[Suresh / Kiwamu]

 The power switch button of the RF generation box is not properly working

For tonight we are leaving it as it is but it needs to be fixed at some point.

 

(the Story)

While I was working around the green broad-band RFPD, I noticed that the RFPD was detecting the 25 MHz modulation signal.
To confirm if it really comes from the modulation source, I switched OFF the RF generation box by pressing the blue LED power button on the rear side of it.
The 25 MHz signal in the RFPD disappeared. So it was indeed the 25 MHz modulation signal.
Then I pressed the LED button again to bring it ON, but the switch didn't stay in the clicked position.
Keeping pressing the button could make it ON but once I released my finger from it it became OFF.
So the mechanical thing in the LED button is not properly working.
I removed the box from the 1X2 rack to take a look at it.
With a help from Suresh we somehow managed to keep it ON after several trials of pressing it.

The temporary solution we decided is to leave it ON so that we can survive tonight.

The box was back in place. The MC is find and 11 MHz and 55 MHz seem okay.

 

Please be aware of it.

 

broken_power_switch.png

This is a picture showing the rear view of the RF generation box. The red arrow is pointing the blue LED switch button.

  5943   Fri Nov 18 08:29:35 2011 SureshUpdateIOOHEPA air-flow effect on WFS.

[Koji, Suresh]

    We investigated the effect of airflow from the HEPA filters on the PSL beam fluctuation and the resultant noise injected into the WFS loops.   The hint that the WFS are injecting PSL beam jitter into MC mirror motion lies in the MC2_TRANS_PIT and YAW signal's power spectrum shown here.  First, in the blue trace, which shows the spectrum when the WFS loops are off, we see that the WFS1 and WFS2 error signals have a different shape from that of MC2_TRANS.  Since WFS are affected by the PSL beam jitter while the MC2_TRANS_QPD is not, the WFS spectrum contain excess noise, while the MC2_TRANS signals show only the mirror motion.  Next, upon switching on the WFS1 and WFS2 loops, we notice that the MC2_TRANS  spectra acquire the same shape as the WFS spectra.  This shows that the excess noise from the beam jitter has been injected into the MC2 motion, and shows up in the MC2_TRANS spectra.

   To confirm these conclusions we repeated the above measurement with the HEPA fans at 0% (Blue trace), 20% (Red), 30% (Brown) and  100% (Green).   The plots are shown below.  We can see that there is no difference between 0 and 20% levels but beam jitter is visible at 30% HEPA level.  The WFS loops were ON during this time and we can can see the PSL noise injected in to MC2 motion (Green).

WFS_err_HEPA.png

 

The HEPA filter fans are now at 20%.  How can we be sure that they are really working at 20%, since we cannot see any difference between 0 and 20%?

Now that we have this quiet situation, we also investigated the effect (or lack thereof) of switching on the MC2_TRANS loops.  The figure below shows the spectra with all the loops turned off (Blue), with the WFS1 and WFS2  loops turned on (Green)  and with everything turned on (Red).   With the current output matrix, which is the same simple one as the one in this elog, we see some low frequency suppression.  But it also seems to add some noise into the other WFS loops.  I am not sure of this result, due the long duration of this measurement, the seimic noise level may have changed over the course of this measurement.

WFS_err_mc2t_effect.png

As they are not doing any good just now.  I have turned them off by setting the gain in MC2_TRANS PIT and YAW to zero.

 

  5944   Fri Nov 18 11:16:08 2011 ranaUpdateIOOeom box

Quote:

I made a super sweet new foam box for our EOM.  It's awesome, and should be reasonably easy to duplicate.  Check out the PHOTOS!

 These are great photos and a nice box, but I fear from the photos that there's too much air getting in. How to pack it so that there's no air flow? How does the temperature sensors wires get in?

  5947   Fri Nov 18 15:35:18 2011 kiwamuUpdateIOORF generation box : power switch malfunction

Jenne gave me a spare LED power switch .

I will replace the broken one on Monday.

By the way here is a picture album of the RF generation box which I took last night.

            

Quote from #5942

 The power switch button of the RF generation box is not properly working

  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

 

 

  5953   Fri Nov 18 23:44:33 2011 ranaUpdateIOOMode cleaner noise projection

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.

  5957   Sat Nov 19 01:26:16 2011 DenUpdateIOOMode cleaner noise projection

Quote:

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.

That's right. The easier problem arises if we consider one of  MC mirrors. The coherence between OSEM sensors and GUR1_X in free moving regime is equal to 0.9 at frequencies 0.1 - 1 Hz. But with local dumping coherence is 0.6. We have

Mirror -> Sensor -> Satellite Module -> Whitening -> ADC -> Computer -> DAC -> Dewhitening -> Satellite Module -> Actuator -> Mirror

Somewhere we produce noise that kills part of coherence. We can use this method with the injection of spectrum of noise into the SUSPOS filter bank only for one mirror and see how the coherence between OSEM sensor and GUR1_X will change. If the change is small, we deal with something else. It the coherence will change from 0.6 to ~0.4, than we have big OSEM noise.

It might be also the problem that the amplitude of COIL_OUT signal is ~25. If it is in counts we may have noise from DAC. 

  5958   Sat Nov 19 06:04:43 2011 SureshUpdateIOOMC_WFS Servo: The MC2_TRANS_PIT and YAW loops switched ON

Without adding significant amounts of noise to other WFS loops I have engaged the MC2_TRANS_PIT and YAW loops. 

After several attempts to measure the system response and computing the output matrix, none of which gave any useful results, I gave up on that and decided to find three orthogonal actuation vectors which enable us to close the loops.  So using the last good output matrix (below left side)  as a template, I rounded it off to the nearest set of orthogonal vectors and arrived at the following matrix (right side):

WFS_OUTMx_Lastgood.png        WFS_OUTMATRIX_20111118.png

 

I also decided that WFS1 and 2 need not drive MC2.  This is just to decouple the loops and minimise cross-talk.   This (albeit heuristic)  matrix seems to work pretty well and the real matrix is probably quite close to it.

I show below the suppressed error signals after tweaking the gains a bit.   The blue line is with no WFS, the green one with only WFS1 and 2 loops on, while the red is with all loops turned on.  The WFS1Yaw and MC2_Trans_pit loops might benefit from a more careful study to determine a better output matrix.

WFS_err_MC2T_on_OMx5_20111118.png

  5959   Sat Nov 19 10:41:30 2011 ranaUpdateIOOMC_WFS Servo: The MC2_TRANS_PIT and YAW loops switched ON

I'm quite sure that this is not good: since MC2 can produce a signal in WFS1 and WFS2, it cannot be removed in this way from the actuation without introducing a significant cross-coupling between the MC_TRANS and WFS loops.

Really need loop TFs measured and compared with the model.

The WFS noise model will also show that we need to have a much lower UGF in the MCT loop since that sensor is just a DC QPD: it can never have as good of a sensing noise as a good WFS. In the current case with no Whitening, this is even more so.

  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
  5964   Sun Nov 20 15:11:09 2011 kiwamuUpdateIOORFAM monitoring test

DO NOT CHANGE THE IFO ALIGNMENT UNTIL TOMORROW MORNING OR FURTHER NOTICE.

Plus, MC has to be kept locked with the WFS.

 

An RFAM measurement is ongoing

 

 Since the Stochmon turned out to be tricky to calibrate the outputs, Koji and I decided to monitor the RFAMs using REFL11 and REFL55 RFPDs while the beam is single-bounced from PRM.
This is, of course, not a permanent RFAM monitor, but at least it gives us a long-term continuous RFAM information for the first time.
Before the measurement I ran the offset zeroing scripts, therefore any offsets from electronics must be tiny in the acquired REFL signals.
The measurement has begun from approximately 3:00 pm.
 
 Also I found C1LSC.ini file again became default (no channels had been acquired).
So I replaced it with an archived ini file and then restarted fb.
  5966   Mon Nov 21 12:48:00 2011 JenneUpdateIOORFAM monitoring test

I don't think I touched/adjusted/whatever anything, but I did open the PSL table ~5-10min ago to measure the size of the Kiwamu-Box, so if the RFAM stuff looks funny for a few minutes, it was probably me.  Just FYI.

  5967   Mon Nov 21 14:15:25 2011 JenneUpdateIOORFAM monitoring test

Quote:

DO NOT CHANGE THE IFO ALIGNMENT UNTIL TOMORROW MORNING OR FURTHER NOTICE.

 [Mirko,  Jenne]

We're playing with the MC OAF, so we're actuating on MC2.  Again, FYI.

  5968   Mon Nov 21 14:35:28 2011 kiwamuUpdateIOORFAM monitoring test

REFL_RFAM.png

 This is a trend for a day long showing the REFL11/55 demod signals, REFLDC (corresponding to the MC transmitted power) and the PSL booth temperatire.

There are sudden jumps in the REFL55_I and REFL11_Q signals around 5:00 AM this morning, also at the same time the temperature suddenly went up.

But the quality of the signal turned out to be not so good because the fluctuation is still within 1 bit of the ADCs,

we have to try it again with a bigger gain in the analog whitening circuit.

Quote:

An RFAM measurement is ongoing

  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.

  5972   Mon Nov 21 17:48:36 2011 KojiUpdateIOORFAM monitoring test

Do we care about the AC? I thought what we care is the DC.

  5975   Tue Nov 22 04:02:47 2011 kiwamuUpdateIOOchanged MC alignment

I have changed the MC2_YAW DC bias because the PZT1_YAW was railing.

I also realigned the steering mirrors in zig-zag path since the mode cleaner tended to resonate with higher order modes after I have changed the MC2 bias.

  C1:SUS-MC2_YAW_COMM =  -1.1548    => -1.1208

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

 

  5990   Wed Nov 23 16:55:57 2011 SureshUpdateIOOMC realigned

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

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

 

 

  5991   Wed Nov 23 18:28:09 2011 KojiUpdateIOORFAMPD channels / EOM monitor channels added to DAQ

The following channels have been registered in c1iool0 database, and are now recorded by FB

C1:IOO-RFAMPD_11MHZ
C1:IOO-RFAMPD_29_5MHZ
C1:IOO-RFAMPD_55MHZ
C1:IOO-RFAMPD_DCMON
C1:IOO-EOM_TEMPMON
C1:IOO-EOM_HEATER_DRIVEMON


PROCEDURE

1) The EPICS database file has been edited to rename/add some channels

/cvs/cds/caltech/target/c1iool0/ioo.db

REMOVED
#grecord(ao,"C1:IOO-RFAMPD_VC")
#grecord(ai,"C1:IOO-RFAMPD_TEMP")
#grecord(ai,"C1:IOO-RFAMPD_DCMON")
#grecord(bo,"C1:IOO-RFAMPD_BIAS_ENABLE")
#grecord(bi,"C1:IOO-RFAMPD_BIAS_STATUS")
#grecord(calc, "C1:IOO-RFAMPD_33MHZ_CAL")
#grecord(calc, "C1:IOO-RFAMPD_133MHZ_CAL")
#grecord(calc, "C1:IOO-RFAMPD_166MHZ_CAL")
#grecord(calc, "C1:IOO-RFAMPD_199MHZ_CAL")

ADDED/EDITED
grecord(ai,"C1:IOO-RFAMPD_11MHZ")
        field(DTYP,"VMIVME-3113")                                              
        field(INP,"#C1 S25 @")
...

grecord(ai,"C1:IOO-RFAMPD_29_5MHZ")
        field(DTYP,"VMIVME-3113")                                              
        field(INP,"#C1 S26 @")

...
grecord(ai,"C1:IOO-RFAMPD_55MHZ")
        field(DTYP,"VMIVME-3113")                                              
        field(INP,"#C1 S27 @")

...
grecord(ai,"C1:IOO-RFAMPD_DCMON")
        field(DTYP,"VMIVME-3113")                                              
        field(INP,"#C1 S28 @")

...
grecord(ai,"C1:IOO-EOM_TEMPMON")
                                                
        field(DTYP,"VMIVME-3113")                                               
        field(INP,"#C1 S29 @")

...
grecord(ai,"C1:IOO-EOM_HEATER_DRIVEMON")

        field(DTYP,"VMIVME-3113")                                              
        field(INP,"#C1 S30 @")

2) The channels have been added to the frame builder database

/cvs/cds/rtcds/caltech/c1/chans/daq/C0EDCU.ini

[C1:IOO-RFAMPD_11MHZ]
[C1:IOO-RFAMPD_29_5MHZ]
[C1:IOO-RFAMPD_55MHZ]
[C1:IOO-RFAMPD_DCMON]
[C1:IOO-EOM_TEMPMON]
[C1:IOO-EOM_HEATER_DRIVEMON]

Note that this C0EDCU.ini is the file that has been registered in

/cvs/cds/rtcds/caltech/c1/target/fb/master

3) burt restore request files were updated

RFAM related settings were removed as they don't exist anymore.

/cvs/cds/caltech/target/c1iool0/autoBurt.req
/cvs/cds/caltech/target/c1iool0/
saverestore.req

4) c1iool0 were rebooted. Framebuilder restarted. c1iool0 were burtrestored.

  5995   Thu Nov 24 05:10:00 2011 KojiUpdateIOORFAMPD channels / EOM monitor channels added to DAQ

EOM TEMPMON and HEATER DRIVEMON have been hooked up to the following channels.

C1:IOO-EOM_TEMPMON
C1:IOO-EOM_HEATER_DRIVEMON 

What a fragile circuit...

I found some of the resistors popped up from the board because of the tension by the Pomona grabbers.
I tried to fix it based on the schematic (photo) and the board photo.

  5996   Thu Nov 24 05:47:16 2011 KojiSummaryIOOStochmon running

Now stochmon for 11MHz and 55MHz is running. The calibration / noise measurement are going to be post later...

  5997   Thu Nov 24 10:27:07 2011 JenneUpdateIOORFAMPD channels / EOM monitor channels added to DAQ

Here is a drawing of where the monitors are coming from:

EOM_temp_sense_heater_drive_schematic_withMONs.png

 Since we can't put current into the ADC, the heater drivemon is measuring the input of the OP27, which is related to the amount of current sent to the heater.

Quote:

EOM TEMPMON and HEATER DRIVEMON have been hooked up to the the following channels.

C1:IOO-EOM_TEMPMON
C1:IOO-EOM_HEATER_DRIVEMON

 

  5998   Thu Nov 24 12:45:12 2011 ZachUpdateIOORFAMPD channels / EOM monitor channels added to DAQ

Jenne: The point you indicate for the heater monitor is a virtual ground--it will be driven to zero by the circuit if it's functioning properly; the readout should be done at the input pin (2, I think) to the BUF634.

Koji: This is odd, as I made a point of not attaching any clips directly to resistors for exactly this reason. I was also careful to trim resistor/capacitor leads so that they were not towering over the breadboard and prone to bending (with the exception of the gain-setting resistor of the AD620, which was changed at the last minute). At the end of the day, it is a breadboard circuit with Pomona "readout", so it's not going to be truly resilient until I put it on a protoboard. Another thing: I think the small Pomona clips are absolutely terrible, since they slip off with piconewtons of tension; I could not find any more regular clips, so I used them against my better judgment.

  5999   Thu Nov 24 13:54:31 2011 KojiUpdateIOORFAMPD channels / EOM monitor channels added to DAQ

Those clips for the readouts were the ones who popped out.
When I have restored the connections, I checked the schematic and the heater drive mon is clipped on the output side of the OP27.

Quote:

Jenne: The point you indicate for the heater monitor is a virtual ground--it will be driven to zero by the circuit if it's functioning properly; the readout should be done at the input pin (2, I think) to the BUF634.

Koji: This is odd, as I made a point of not attaching any clips directly to resistors for exactly this reason. I was also careful to trim resistor/capacitor leads so that they were not towering over the breadboard and prone to bending (with the exception of the gain-setting resistor of the AD620, which was changed at the last minute). At the end of the day, it is a breadboard circuit with Pomona "readout", so it's not going to be truly resilient until I put it on a protoboard. Another thing: I think the small Pomona clips are absolutely terrible, since they slip off with piconewtons of tension; I could not find any more regular clips, so I used them against my better judgment. 

 

  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.

  6006   Fri Nov 25 17:52:28 2011 ranaUpdateIOOF2A filter for MC

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

  6009   Fri Nov 25 20:03:05 2011 KojiUpdateIOOStochmon update

 New RFAM mon calibration

Attachment 1: stochmon_calib.pdf
stochmon_calib.pdf
  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.

  6015   Sat Nov 26 07:18:11 2011 SureshUpdateIOOMC WFS related changes to c1ioo model

What I did:

    I have changed the c1ioo model such that the signals which are demodulated in the WFS lockin (the SIG inputs) are now picked up just after the input matrix.  This permits us to put a notch filter at the excitation frequency into the WFS servo filterbanks and thus prevent the excitation of all the actuators when we wish to excite just one of them. 

 

The Problem:

    I had followed the procedure of determining the TF coefs between actuators (MC1,2,3 P and Y ) and sensors (WFS1, 2 and MC2Trans P and Y)  and found the output matrix by inverting this TF coef matrix. However these matrices, once substituted for the heuristically determined matrices were always unsuccessful in keeping the WFS servo lock.  The reason appeared to be that when the loops are closed the exitation of one actuator led to the excitation of all actuators through the cross couplings in the output matrix.    In order to prevent this we need a notch filter in the servo filter banks.   But then we will not be able to see the sensor response after the servo filters since the response at 10Hz would be blocked from reaching the lockins.  So I shifted the point at which we sample the sensor response to a point before the WFS servo filters. 

The solution:

a) shift the point where the lockin input signals are picked up in the c1ioo model.

b) retune the lockin servo phases to minimise Q phase

c) edit the WFS lockin scripts to ensure that the 10Hz notch is turned on

d) measure the TF coefs and compute the -1*inverse

e) plug it into the output matrix and tweak the gains to ensure a stable lock

f) examine cross talk by comparing the expected TF in each loop with the expected loop TF.

 

Current state:

  I have completed steps a to e above.  The loops are stable and the error signal is suppressed (see attached pdf files)

To be done:

  The open loop transfer function has to be compared with expected OLTF to be sure we have minimised cross talk.

 

Attachment 1: WFS_err_20111127.png
WFS_err_20111127.png
Attachment 2: cioo_20111127.png
cioo_20111127.png
  6028   Mon Nov 28 18:19:53 2011 kiwamuUpdateIOOStochmon seems working

Here is a 48 hours trend of the RFAM monitor (a.k.a StochMon):

RFAM_48hours.png

The upper plot is the DC output from the StochMon PD and the lower plot shows the calibrated RIN (Relative Intensity) at each modulation frequency.

I have downloaded minutes trends of StochMon for 48 hours staring from 6:00AM of Nov/24.

I followed Koji's calibration formula (#6009) to get the actual peak value (half of the peak-peak value) of the RF outputs and then divided them by the DC output to make them RIN.

It looks the RINs are hovering at ~ 4 x 10-4 and fluctuate from 1x10-4 to 1x10-3. Those numbers agree with what we saw before (#5616)

So it seems the StochMon is working fine.

Quote from #6009

 New RFAM mon calibration

  6064   Sat Dec 3 16:55:52 2011 DenUpdateIOOdigital noise in MC

I looked once again to the local OSEM sensors and MC length signals. Then I replaced 1e-20 to 1e-50 in the if-statement of the iir_filter function. Here I report about the difference of the signals in question.

First we look at the MC2 OSEM local sensor. In the figure below the psd of the signal is presented in three cases - with a free MC2 mirror without feedback, with a feedback signal and with a feedback signal with corrected if-statement. We can see that without FB the wire resonances are high and dumped when OSEMs are on. However we can see that below 1 Hz the psd of the sensor signal with 1e-20 in the if-statement is higher then psd of the sensor signal from free mirror. FB with 1-50 in the if-statement fixes this problem. 

psd_sensors.jpg

If we take a look on the plot of the coherence between GUR1_X and SENSOR signals we can see that coherence is corrupted when 1e-20 is used in the is-statement and is good when 1e-50 is used.

coh_sensors.jpg

 Next we look at the psd of the MC length. We can see how strongly these curves diverge below 1 Hz. The MC_F signal was also corrupted at higher frequencies.

psd_mcl.jpg

 The coherence between MC_F and GUR1_X is also improved.

coh_mcl.jpg

  6066   Sun Dec 4 13:56:54 2011 DenUpdateIOOWFS

Yesterday I locked the MC and left at 8 pm. Analyzing the data I saw that MC was locked all time from 8 pm to 12.30 am when it lost lock. Moreover there was no light on transmition and reflected screens at all. I went to the PSL and saw that no red light comes to the MC from PSL, only green. I took infrared sensos to track the laser light. Then I came back to control room to study the medm diagram of the PSL. Then I came back and saw that the laser beam goes to the MC! I returned to control room and saw light on the MC screens. Does someone do something parallel with me through ssh?

I enabled the auto locker and saw the MC locked for a couple of seconds. After that the WFS were turned on automatically and I saw that the signal of the OSEM local sensors of the MC mirrors began to increase. So the WFS master provides not good feedback signal. I thought that it is due to my recompilation of c1mcs with a fixed if-statement line. And may be if c1mcs workes without digital noise and c1ioo with it then there might occur some mismatches and the signal is corrupted. For this assumption I've recompiled c1mcs back to 1e-20 in the if-statement and so added the digital noise back that I saw in the dtt tools.

However, the problem was still present - WFS feedback signal crashed the MC lock. I open the WFS master window and disabled the output to MC. I can see that the C1:IOO-WFS1_PIT_INMON and other input channels have reasonable values 8 - 20 but the output continues to increase up to 1000000. The output was off so the MC stayed at lock. As for now I turned off WFS so no feedback is applied to MC mirros.

  6067   Sun Dec 4 23:49:38 2011 DenUpdateIOOWFS

Quote:

Yesterday I locked the MC and left at 8 pm. Analyzing the data I saw that MC was locked all time from 8 pm to 12.30 am when it lost lock. Moreover there was no light on transmition and reflected screens at all. I went to the PSL and saw that no red light comes to the MC from PSL, only green. I took infrared sensos to track the laser light. Then I came back to control room to study the medm diagram of the PSL. Then I came back and saw that the laser beam goes to the MC! I returned to control room and saw light on the MC screens. Does someone do something parallel with me through ssh?

I enabled the auto locker and saw the MC locked for a couple of seconds. After that the WFS were turned on automatically and I saw that the signal of the OSEM local sensors of the MC mirrors began to increase. So the WFS master provides not good feedback signal. I thought that it is due to my recompilation of c1mcs with a fixed if-statement line. And may be if c1mcs workes without digital noise and c1ioo with it then there might occur some mismatches and the signal is corrupted. For this assumption I've recompiled c1mcs back to 1e-20 in the if-statement and so added the digital noise back that I saw in the dtt tools.

However, the problem was still present - WFS feedback signal crashed the MC lock. I open the WFS master window and disabled the output to MC. I can see that the C1:IOO-WFS1_PIT_INMON and other input channels have reasonable values 8 - 20 but the output continues to increase up to 1000000. The output was off so the MC stayed at lock. As for now I turned off WFS so no feedback is applied to MC mirros.

With the help of Suresh we have adjusted optics near PMC and input to the MC on the PSL and in the black box where WFS are. Surprisingly, some optics near WFS was not attached to the table. But these mirrors are not used. One screw was near the hole but not screwed in. This mirror is used. Suresh could also rotate other screws. I thought that they must be attached to the table more rigidly.

Then we found that WFS output matrix is wrong and Suresh recalculated it. After that we've locked the MC using WFS. C1:IOO-MC_RFPD_DCMON is 0.7-0.8. 

We also recompiled and reinstalled C1MCS and C1IOO with fixed if-statement and again saw how MC_F curve moves down. WFS error signals are also improved. But still some more work on output matrix is needed.

  6084   Thu Dec 8 00:04:50 2011 ranaUpdateIOORAM Mon is now being demodulated

Monitoring good, but remember that the EOM alignment must be done carefully to minimize the RAM before we can use these trends.

ELOG V3.1.3-