40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 118 of 344  Not logged in ELOG logo
IDup Date Author Type Category Subject
  5892   Tue Nov 15 01:44:36 2011 SureshUpdateIOOMC WFS Servo: Open loop gain

Quote:

Somehow, I generically don't like the idea of lead filters for the WFS loops. We don't really need so much bandwidth. I think you should include with the servo measurements, a servo model ( on the same plot ) that matches the loop shape.

For example, this means including the 28 Hz ELP in the MC1/3 hardware and MC2 ASCPIT/YAW digital filter banks. BY comparing the model v. measurement we can determine if the cross-coupling due to imperfect output matrix is very serious or not.

In the measurements, the loop with the most low frequency gain looks the most promising.

WFS1_PIT servo replotted with foton data overlaid:

I included the following filters in foton:

1) Integrator: zpk([0.8],[0],0.8,"n")

2) zpk([0.8],[100,100],1,"n")

3) zpk([1:10],[3,30],1,"n")

4) ELP28

I have unwound the phase by adding or subtracting 180 to portions of the phase data.

And here is the plot for WFS1_PIT.  I will repeat this process for the other three WFS loops tomorrow.

WFS1PIT_OL_gain.png

 

  5893   Tue Nov 15 09:51:04 2011 ZachUpdateGreen LockingY end PDH lock : UGF at 17 kHz

Also the servo shape formed by Newfocus LB1005 looks too simple : we should have a more sophisticated servo filter (i.e. PDH box!!).

 As promised, I will get on this this week.

  5894   Tue Nov 15 12:25:38 2011 kiwamuUpdateGreen LockingY arm ALS : beat-note free run fluctuation

Locking activity last night :

  The free run beat-note in 532 nm has been measured.

However I couldn't close the ALS loop somehow.

Every time I tried closing the loop it broke the Y end PDH lock in a couple of minutes.

 

noise_budget.png

 

 (Things to be done)

   1.  Optimization of the Y end PDH servo loop

      1.1 Measurement of the arm fluctuation => to allow re-designing the servo shape
      1.2 Preparation of PDH box, and temporary SR560 servo
      1.3 Sanity checks on the modulation depth, reflectivity, PD dark noise and etc.,
      1.4 Make the servo more robust
      1.5 Some modifications on the medm screens
      1.6 Activation of the temperature feedback through the realtime digital control

   2. Refinement of the broadband RFPD setup

      2.1 Investigation of the peak source => there was a relatively big peak around 50 MHz or so.
      2.2 Noise characterization of the frequency detection system
      2.3 Nicer routing of some cables.
      2.4 Make two-more ADC channel connectors
      2.5 Power budget on the PSL beat-note setup => estimate the expected RF level of the beat-note
      2.6 Realignment of the PSL doubling and resetting of the doubling oven temperature
     
  3. Noise budgeting
 
     3.1 IR locked condition  => measure the noise in the green beat-note system.
     3.2 ALS engaged condition
          3.2.0 shot noise
          3.2.1 ADC noise
          3.2.2 PD dark noise
          3.2.3 freq. discriminator noise
          3.3.4 DAC noise through the coil-magnet actuators
          3.3.5 End laser suppression
          3.3.6 Intensity noise
          3.3.7 Thermo-elastic noise
          3.3.8 Thermo-refractive noise

 

  5895   Tue Nov 15 15:16:04 2011 kiwamuUpdateCDSdataviewer doesn't run

Dataviewer is not able to access to fb somehow.

I restarted daqd on fb but it didn't help.

Also the status screen is showing a blank white form in all the realtime model. Something bad is happening.

blank.png

JAMIEEEE !!!!

  5896   Tue Nov 15 15:56:23 2011 jamieUpdateCDSdataviewer doesn't run

Quote:

Dataviewer is not able to access to fb somehow.

I restarted daqd on fb but it didn't help.

Also the status screen is showing a blank while form in all the realtime model. Something bad is happening.

 So something very strange was happening to the framebuilder (fb).  I logged on the fb and found this being spewed to the logs once a second:

[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 15:28:51 2011] going down on signal 11
sh: /bin/gcore: No such file or directory

Apparently /bin/gcore was trying to be called by some daqd subprocess or thread, and was failing since that file doesn't exist.  This apparently started at around 5:52 AM last night:

[Tue Nov 15 05:46:52 2011] main profiler warning: 1 empty blocks in the buffer
[Tue Nov 15 05:46:53 2011] main profiler warning: 0 empty blocks in the buffer
[Tue Nov 15 05:46:54 2011] main profiler warning: 0 empty blocks in the buffer
[Tue Nov 15 05:46:55 2011] main profiler warning: 0 empty blocks in the buffer
[Tue Nov 15 05:46:56 2011] main profiler warning: 0 empty blocks in the buffer
...
[Tue Nov 15 05:52:43 2011] main profiler warning: 0 empty blocks in the buffer
[Tue Nov 15 05:52:44 2011] main profiler warning: 0 empty blocks in the buffer
[Tue Nov 15 05:52:45 2011] main profiler warning: 0 empty blocks in the buffer
GPS time jumped from 1005400026 to 1005400379
[Tue Nov 15 05:52:46 2011] going down on signal 11
sh: /bin/gcore: No such file or directory
[Tue Nov 15 05:52:46 2011] going down on signal 11
sh: /bin/gcore: No such file or directory

The gcore I believe it's looking for is a debugging tool that is able to retrieve images of running processes.  I'm guessing that something caused something int the fb to eat crap, and it was stuck trying to debug itself.  I can't tell what exactly happend, though.  I'll ping the CDS guys about it.  The daqd process was continuing to run, but it was not responding to anything, which is why it could not be restarted via the normal means, and maybe why the various FB0_*_STATUS channels were seemingly dead.

I manually killed the daqd process, and monit seemed to bring up a new process with no problem.  I'll keep an eye on it.

  5897   Tue Nov 15 16:16:34 2011 steveUpdatePSLenclosure interlocks are working on all sliding doors

Ben and Sam came over to fix one of  the east side  sliding  door sensor that had to be moved from the inside  to outside on the enclosure.

We turned off the 2w Innolight for 20minutes. The power is back on, the  PMC and MC locked itself immediately.

  5898   Tue Nov 15 16:25:38 2011 steveUpdatePSLIOO angle qpd centered

This moring I centered the IOO Angle QPD. The IOO Pos QPD was not centered. The existing layout does not allow the beam centering of the Pos qpd without misaligning the MC

input. We have to add an aditional steering mirror. I will do that tomorrow morning.

  5899   Tue Nov 15 19:59:41 2011 SureshUpdateIOOWFS output matrix measured (open loop)

Quote:

Quote:

 The scripts used to make the WFS outmatrix measurement live in /cvs/cds/rtcds/caltech/c1/scripts/MC/WFS

 I assume you mean /opt/rtcds/caltech/c1/scripts/MC/WFS.

As I've tried to reitterate many times: we do not use /cvs/cds anymore.  Please put all new scripts into the proper location under /opt/rtcds.

 Yes the files are in /opt/rtcds/caltech/c1/scripts/MC/WFS.

I just went to wherever the 'scripts' alias takes me, found the 'pwd' and did a cp+paste of the path.   I checked to be sure that 'scripts' takes me to /opt/rtcds/caltech/c1/scripts/.

So why does the pwd show /cvs/cds.... instead of /opt/rtcds  ?

 

  5900   Tue Nov 15 22:31:39 2011 MirkoUpdateAdaptive FilteringTowards wiener filtering and improved OAFing


[Jenne, Mirko]

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

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

 TFofTheMclLoop.pdf

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

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

MCL_round_trip.png

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

2. Wiener filtering

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

Howto:

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

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

STS1X_Wiener_filter_data_from_11-11-15.png

GUR1X:

GUR1X_Wiener_filter_data_from_11-11-15.png

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

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

  5902   Wed Nov 16 01:45:37 2011 ZachUpdateelogrestarted

Elog was hanging. Restarted it with script.

  5903   Wed Nov 16 02:36:35 2011 KojiUpdateelogrestarted

Basically, elog hangs up by the visit of googlebot.

Googlebot repeatedly tries to obtain all (!) of entries by specifying  "page0" and "mode=full".
Elogd seems not to have the way to block an access from the specified IP.
We might be able to use http-proxy via apache. (c.f. http://midas.psi.ch/elog/adminguide.html#secure)

Or can we tweak the source of elod such that it does not accept "page0"?


GET /40m/page0?mode=full&new_entries=1 HTTP/1.1
Host: 131.215.115.52:8080
Connection: Keep-alive
Accept: */*
From: googlebot(at)googlebot.com
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Accept-Encoding: gzip,deflate

 

Quote:

Elog was hanging. Restarted it with script.

 

  5904   Wed Nov 16 08:57:08 2011 SureshUpdateIOOMC WFS Servo OLG data and fits

I measured the Transfer Functions between from IN2 to IN1 on the WFS1PIT, WFS2PIT, WFS1YAW and WFS2YAW servo loops. 

Then I used the foton filter profiles of the servo filters in the loop and added another one to simulate the pendulum to generate a reasonable fit to the data.  Only the pendulum filter was hand tweaked since the PIT and YAW pendula have different resonant frequencies.

The filter modules included are:

1) Integrator: zpk([0.8],[0],0.8,"n")

2) Phase lead: zpk([0.8],[100,100],1,"n")

3) 45 deg filter: zpk([1:10],[3,30],1,"n")

4) ELP28: ellip("LowPass",5,1,50,28)

5)Pendulum: zpk([ ],0.03+i*0.82;0.03+i*0.82;],1,"n"  (for YAW)

5)Pendulum: zpk([ ],0.05+i*0.68;0.05+i*0.68;],1,"n"  (for PIT)

The data and fits are below.   The UGF is around 2 to 3 Hz and there is no servo bump at this gain setting.  The fits are poor at and below the resonance because the coherence was poor at these frequencies.  I will have to do a swept sine measurement for these low frequencies.

WFS1PITservo.png  WFS2PITservo.pngWFS1YAWservo.png  WFS2YAWservo.png

  5905   Wed Nov 16 09:21:56 2011 SureshUpdateIOOMC2 Shifted in Pitch, corrected by adjusting the pitch bias

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

  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
  5907   Wed Nov 16 10:11:20 2011 steveUpdatePSLIOO angle & pos qpd centered

Quote:

This moring I centered the IOO Angle QPD. The IOO Pos QPD was not centered. The existing layout does not allow the beam centering of the Pos qpd without misaligning the MC

input. We have to add an aditional steering mirror. I will do that tomorrow morning.

 I added the steering mirror for Pos  and centered both qpds

Attachment 1: iooqpds.png
iooqpds.png
  5908   Wed Nov 16 10:13:13 2011 jamieUpdateelogrestarted

Quote:

Basically, elog hangs up by the visit of googlebot.

Googlebot repeatedly tries to obtain all (!) of entries by specifying  "page0" and "mode=full".
Elogd seems not to have the way to block an access from the specified IP.
We might be able to use http-proxy via apache. (c.f. http://midas.psi.ch/elog/adminguide.html#secure)

 There are much more simple ways to prevent page indexing by googlebot: http://www.google.com/support/webmasters/bin/answer.py?answer=156449

However, I really think that's a less-than-idea solution to get around the actual problem which is that the elog software is a total piece of crap.  If google does not index the log then it won't appear in google search results.

But if there is one url that when requested causes the elog to crash then maybe it's a better solution to cut of just that url.

  5909   Wed Nov 16 10:25:57 2011 steveUpdateSUSPRM damping restored

The  PRM lost damping about a day ago. It was restored.

  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.

 

  5911   Wed Nov 16 12:21:33 2011 KojiUpdateeloggooglebot (Re: restarted)

- elogd itself is a sort of web server which has no freedom to put our own file, we can not put robots.txt

- If we include elog using proxy in the usual web tree of Apache, we can put robots.txt at the root.

- So far, if we prevent "page0" browse by google, we will be saved for a while.

- It seems that the indexing is set to be refused by the following meta tags. But it does not prohibit googlebot to use "page0" URL, of course.

<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
  5912   Wed Nov 16 14:34:18 2011 steveUpdatePSLIOO beam moves in pitch

C1:IOO-QPD_ANG_VERT beam movement  in 1 degree C temp change in 3 hrs

 

Attachment 1: iooqpds.png
iooqpds.png
  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.

  5914   Wed Nov 16 17:29:46 2011 kiwamuUpdateGreen LockingSome updates on the Y end green PDH
Quote from #5894

 (Things to be done)

   [DONE]   1.1 Measurement of the arm fluctuation => to allow re-designing the servo shape
   [DONE]   1.2 temporary SR560 servo
   [ONGOING]1.3 Sanity checks on the modulation depth, reflectivity, PD dark noise and etc.,
   [DONE]  1.4 Make the servo more robust
   [DONE]  1.5 Some modifications on the medm screens
   [NOTYET]   1.6 Activation of the temperature feedback through the realtime digital control

Some updates on the Y end green PDH lock

(Measurement of the Y arm fluctuation)

In order to design the PDH box's servo shape we wanted to measure the Y arm fluctuation.
Here is the spectrum taken by looking at the control signal before the laser PZT.
 
 Yarm_fluctuation.png
 The scale of the Y axis is calibrated by using the PZT response of 5 MHz/V.
Above 10 Hz the spectrum shows 1/f noise which I believe the laser frequency noise.
 

(Temporary servo setup)

 We have found that the servo shape was not enough (#5890) to well-suppress the fluctuation shown above.
 Since the Newfocus fast servo box only makes 1/f shape, the error signal wasn't suppressed within the linear range.
So I have added an SR560 in the other input of the Newfocus servo box to make the filter shape 1/f^2.
Then the lock became more solid and the reflected DC light in time series is now much flat if the alignments are good.
I will post the servo shape and diagram later.

(Sanity checks)

 I looked at the reflected DC light when the laser was kept locked.
The reflectivity of the Y arm cavity went down to about 30% and this is good because it is supposed to be 27.5% when it is locked according the spec.
This means the mode-matching is not so bad.
  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.

  5918   Wed Nov 16 21:01:08 2011 JenneUpdateTreasureeom box

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!

Notes:

* I didn't think I was going to cover the inside of the box at first, since the foam is non-fuzz-generating, but Koji suggested it would be a good idea anyway.  The foam was cut perfectly to the EOM, so adding the tape inside makes it a tight fit.  Especially height-wise...leave a little space next time.

* To cover the insides of the optical path holes, do it in 2 parts.  One half-cylinder, and then another.  Way easier than trying to do the whole thing at once.  Also, pre-cut the tabs on both sides of the foil before inserting.  Then you just have to grab the tabs with tweezers and flatten them, and they hold the aluminum tape in place. 

* Having 1" wide, 2" wide and 3" wide aluminum tape was handy.  3" to make the top, 2" for the sides, and 1" for the inside of the holes. 

  5919   Wed Nov 16 23:50:40 2011 DenUpdateAdaptive Filteringseismic noise injection

[Micro, Den]

Analyzing coherence of seismic noise and mode cleaner length we've figured out that at some days the coherence below 1 Hz is still present. For example, at Nov 13 we can see some coherence compared to most other dates when we are not able to see coherence as shown on the figure. On the top plot - psd of MC_L and GUR1_X at Nov 13 (red and blue) and Nov 15 (black and cyan). On the bottom plot is presented coherence between MC_L and GUR1_X on Nov 13 (red) and Nov 15 (black)

datespsd.jpg

datescoh.jpg

We can divide the psd plot for 2 parts - below 1 Hz and above 1 Hz. Above 1 Hz seismic noise on Nov 15 (cyan) was higher then on Nov 13 (blue) and correspondently MC_L at that region was higher on Nov 15. Below 1 Hz seismic noise was higher on Nov 13 but MC_L is still lower that on Nov 15. That is surprising. From the coherence plot we can say that once we have some more seismic noise than usually, we immediately see coherence.

Because of this we wanted to find out the level of the X noise that makes seismic noise invisible. We injected seismic noise by doing smooth physical exercises near MC_2 (1.5 m and 3 m apart). The MC_2 was in lock during the experiment.

injectionpsd.jpg

injectioncoh.jpg

In the coherence plot we can see that coherence between GUR1_X and MC_L increased with noise injection. The highest coherenced we obtained sittind down and standing up smoothly near MC_2 at distance 1.5 m. We did not want to come clother and break the lock. This measurement tells us that the X noise is approximately 3-4 times higher than seismic noise in the range 0.1 - 1 Hz. That means that it is approximately 1e-6 - 1e-8 m/sqrt(Hz) in this region. This noise goes down at frequencies from 2 Hz and not seen because of seismic noise. Actually, seismic noise can be filtered out with the Wiener filter and then we'll see the spectrum of X noise.

We now try to figure out the method to estimate the contribution of OSEM noise to the X noise.

  5920   Thu Nov 17 03:46:52 2011 kiwamuUpdateGreen LockingPSL doubling had been diabled

I found that the temperature controller of the PSL doubling oven had been disabled.

Because of that I took a little bit long time to recover the beat-note.
I have no idea why its been disabled.
I turned it on to make the PSL green beam bright,
Also the I-parameter of the PID temperature control was too big
and because of that a big overshoot in the temperature happened (overshoot of ~ 5 deg !).
So I decreased the I-parameter from 175 to 85 (250 is the maximum).
Now the intensity of the green light seems reasonably bright and stable.
  5921   Thu Nov 17 11:04:02 2011 JenneUpdateRF SystemStochmon?

Is there an update on Stochmon?  Are the signals acquired somewhere already?  What's the current deal-io?  The new EOM mount should be here later today, and I'm jazzed to start checking how my EOM box helps (hopefully) the amount of RFAM we see. 

I'll start making the adapter plate while I wait...

  5922   Thu Nov 17 11:27:58 2011 JenneUpdatePSLHEPA turned down

I was measuring things to see how big my adapter plate needs to be, and I decided that we'd had enough days of the HEPA being on full blast, so I turned it down to 50, from 100.  I think it's been on full since Katrin was working on the Y-green beat a week or so ago.

  5923   Thu Nov 17 11:35:27 2011 KojiUpdateRF SystemStochmon?

The  Stochmon channels for 11&55MHz have been reasonably working since last night.

The output is not yet calibrated as the RF power detector has a strange scaling.
I am analyzing the calibration data.

  5924   Thu Nov 17 11:51:14 2011 JenneUpdateEnvironmentIncandescent vs. fluorescent lights?

I'm just on an elog roll this morning...

Again while poking around inside the IFO room, I noticed that they have replaced all of our incandescent lights with CFLs.  Do we care?  The point of having the incandescent lights on a separate switch from the big fluorescent lights was so that we could have only 60Hz lines, not wide-band noise if we want the lights on while locking. 

I'm not sure that we actually care, because more often we just turn off all the lights while trying to do serious locking, but if we do care, then someone needs to ask the custodial staff (or someone else?) to undo the change.

  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.

 

 

  5926   Thu Nov 17 14:38:16 2011 ZachUpdateRF SystemStochmon?

It turns out that we don't have all the parts I would need to do a full prototype of the precision temperature controller. I am guessing that we won't want to sit around and wait for the parts given the upcoming TAC meeting, so I'll do the next best thing:

  • Standard DC temperature readout using an AD590.
  • More-or-less complete heater driver

Does anyone have a suggestion for how this thing will be packaged? I.e., should it be in a box or should it be mounted in a rack, etc. In the end, a real board will be printed and stuffed, so this need not be a really professional job in the short term.

 

Quote:

Is there an update on Stochmon?  Are the signals acquired somewhere already?  What's the current deal-io?  The new EOM mount should be here later today, and I'm jazzed to start checking how my EOM box helps (hopefully) the amount of RFAM we see. 

I'll start making the adapter plate while I wait...

 

  5927   Thu Nov 17 15:19:06 2011 steveUpdateSUSTi spring plunger to hold OSEM is not affortable

Our existing 300 series SS plungers from McMastercar #8476A43 are silver plated as Atm2 shows.

Problems:  1, they become magnetized after years being close to the magnets

                     2, they oxidize by time so it is hard to turn them

                    

I looked around to replace them.

Titanium body, nose and beryllium copper spring. None magnetic for UHV enviorment.

Can be made in 7 weeks at an UNREASONABLE $169.00 ea at quantity of 50

Attachment 1: 20111116111042405.pdf
20111116111042405.pdf
Attachment 2: P1080216.JPG
P1080216.JPG
  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
  5929   Thu Nov 17 17:21:22 2011 kiwamuUpdateGreen LockingY end green PDH servo : it's okay

Quote from #5914
So I have added an SR560 in the other input of the Newfocus servo box to make the filter shape 1/f^2.
I will post the servo shape and diagram later.

The Y arm green PDH servo is working fine with a sufficient amount of suppression.

(Servo filters)

 As reported on the previous elog entry (#5914) an SR560 was installed to provide one more pole-zero combination in the servo filter.
Here is a plot showing the transfer function of the latest servo filter.
   servoTF.png

And the servo configuration looks like this :

  servofilter.png

 The demodulated signal is split into two path; one goes directly to the Newfocus servo box and the other goes through SR560.
With the SR560 the two way summing path makes a pole at 1 Hz and zero at 100 Hz with when the SR560 has a gain of 100.
The overall gain is adjustable from a knob on the Newfocus servo box.
 

(the Error signal)

 One of the reasons we wanted to increase the servo gain was that :
the laser frequency has to be tightly locked to the Y arm motion because the laser frequency must represent the arm motion in our scheme.
 
Our requirement for allowing a successful ALS is : RMS < 10 pm (1/100 of the cavity linewidth)

I took a spectrum of the error signal when the laser was locked to the Y arm and found that it meets the requirement.

   err_suppression.png

 In the plot I also put a dark noise from the PD to make sure the in-loop noise is above the dark noise.
Right now the power lines at 60 Hz and 180 Hz are lifting the RMS up.
Note that the UGF was at 20-30 kHz.
  5930   Thu Nov 17 18:20:26 2011 kiwamuUpdateGreen LockingY arm ALS : 1st trial of noise budget

The noise budget on the Y arm ALS has begun.

Right now the fluctuation of the green beat-note seems mostly covered by unknown noise which is relatively white.

(Though I feel I made a wrong calibration ... I have to check it again)

 

Yarm_ALS_2011Nov16.png

(Measurement condition)

 + The Y arm is locked to the PSL laser by acting o ETMY.
 + The end green laser is locked to the Y arm.
 + The fine resolution MFD (Mixer-base Frequency Discriminator) is used to observe the beat-note fluctuation
   (We have two MFDs : fine resolution and coarse resolution.)
  5931   Thu Nov 17 21:12:09 2011 KojiUpdatePSLHEPA setting changed

[Koji, Suresh]

8:50PM HEPA@100% for the test

8:55PM HEPA@0%

9:20-35PM HEPA level varies from 0%-50%

9:35PM HEPA@40% and left it running at this level

Nov18 1:40 AM HEPA@80% for a work around the PSL table (by KI)

Nov18 4:35 AM HEPA@40% (by KI)

  5932   Thu Nov 17 22:24:19 2011 DenUpdateAdaptive FilteringMC1_COIL

Analyzing coherence between MC length and signals on MC1, MC2 and MC3 coils we have noticed that MC1 COIL signal is not coherent to MC length at all at interesting frequencies 0.1 - 1 Hz.

We try to explain this phenomena.

 

Attachment 1: MC1COIL-crop.pdf
MC1COIL-crop.pdf
Attachment 2: MC2COIL-crop.pdf
MC2COIL-crop.pdf
Attachment 3: MC3COIL-crop.pdf
MC3COIL-crop.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
  5936   Fri Nov 18 00:25:10 2011 ZachUpdateelogrestarted

 with script.

  5937   Fri Nov 18 00:36:23 2011 ZachUpdateGreen LockingY-Arm PDH box modified

I modified the Y-Arm PDH box (S/N 17) to have the same TF as the one of the temporary setup described in Kiwamu's earlier entryNote that the TF below was taken with the gain knob set to 0, so that the proper DC gain is achieved with a setting of ~4. This is desirable because it gives us wiggle room.

The changes were:

  • R14: 25 -> 50
  • R29: 1k -> 10.5k
  • R30: 1k -> 20k
  • R28: 102 -> OMIT
  • C20: 84nF -> OMIT
  • R31: SHORT -> 475
  • R16: 10k -> 48.7k
  • R24: 10 -> 5

Below is the TF along with the LISO model. They are different at low frequencies because the box must have been railing internally (though the phase shows that the result is as expected), and there is a feature around 60 kHz that probably arises from some op amp instability. I will see if adding a small cap somewhere does the trick, and then take a new TF with a lower source voltage.

pdh17_tf_vs_liso_11_17_11.png

I'll try to lock the arm with the box tomorrow.

  5938   Fri Nov 18 01:12:14 2011 SureshUpdateCDSMC1 LR dead for > 1 month; now revived temporarily

[Den, Mirko, Suresh]

    We were investigating why there is no correlation between MC1 osem signals and seismic motion.   During this we noticed a recurrence of this old problem of MC1_LR sensor being dead.  I went and pressed down the chip holders where the AA filters used to sit and which now hold the jumper wire.  The board is large and flexible it is quite likely some solder joint is broken on the MC1_LR path on this board.

   The signal came back to life and is okay now. But it can break off again any time.

 

 

Quote:

 Since the MC1 LRSEN channel is not wasn't working, my input matrix diagonalization hasn't worked today wasn't working. So I decided to fix it somehow.

I went to the rack and traced the signal: first at the LEMO monitor on the whitening card, secondly at the 4-pin LEMO cable which goes into the AA chassis.

The signal existed at the input to the AA chassis but not in the screen. So I pressed the jumper wire (used to be AA filter) down for the channel corresponding to the MC1 LRSEN channel.

It now has come back and looks like the other sensors. As you can see from this plot and Joe's entry from a couple weeks ago, this channel has been dead since May 17th.

The ELOG reveals that Kiwamu caught Steve doing some (un-elogged) fooling around there. Burnt Toast -> Steve.

bt.jpg

993190663   =      free swinging ringdown restarted again

 

  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.

ELOG V3.1.3-