40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 106 of 355  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  2369   Wed Dec 9 00:23:28 2009 KojiUpdateSUSfree swinging spectra of ETMY and ITMX

Where is the plot for the trend?
It can be either something very important or just a daydream of you.
We can't say anything before we see the data.

We like to see it if you think this is interesting.

... Just a naive guess: Is it just because the seismic level got quiet in the night?

 

P.S.

You looks consistently confused some words like damping, Q, and peak height.

  • Q is defined by the transfer function of the system (= pendulum).
     
  • Damping (either active or passive) makes the Q lower.
     
  • The peak height of the resonance in the spectrum dy is determined by the disturbance dx and the transfer function H (=y/x).

dy = H dx

As the damping makes the Q lower, the peak height also gets lowered by the damping.
But if the disturbance gets smaller, the peak height can become small even without any change of the damping and the Q.

Quote:

By the way I found a trend, which can be seen in all of the data taken today and yesterday.

The resonances of pitch and yaw around 0.5Hz look like being damped, because their height from the floor become lower than the past.

I don't know what goes on, but it is interesting because you can see the trend in all of the data.

 

  2370   Wed Dec 9 09:07:32 2009 steveUpdatePEMhigh seismic activity

The construction activity is shaking the tables in the control room.  The compactor- large remote controlled jackhammer is in the bottom of the 16-17 ft deep hole 15 ft east of ITMY in CES bay. The suspensions  are holding OK. PRM, MC1 and MC3 are effected mostly.

Attachment 1: seis24d.png
seis24d.png
Attachment 2: seis4h.png
seis4h.png
Attachment 3: P1050833.JPG
P1050833.JPG
Attachment 4: P1050836.JPG
P1050836.JPG
  2371   Wed Dec 9 10:53:41 2009 josephbUpdateCamerasCamera client wasn't able to talk to server on port 5010, reboot fixed it.

I finally got around to taking a look at the digital camera setup today.  Rob had complained the client had stopped working on Rosalba.

After looking at the code start up and not complain, yet not produce any window output, it looks like it was a network problem.  I tried rebooting Rosalba, but that didn't fix anything.

Using netstat -an, I looked for the port 5010 on both rosalba and ottavia, since that is the port that was being used by the camera.  Ottavia was saying there were 6 established connections after Rosalba had rebooted (rosalba is 131.215.113.103).  I can only presume 6 instances of the camera code had somehow shutdown in such a way they had not closed the connection.

[root@ottavia controls]#netstat -an | grep 5010
tcp        0      0 0.0.0.0:5010                0.0.0.0:*                   LISTEN     
tcp        0      0 131.215.113.97:5010         131.215.113.103:57366       ESTABLISHED
tcp        0      0 131.215.113.97:5010         131.215.113.103:58417       ESTABLISHED
tcp        1      0 131.215.113.97:46459        131.215.113.97:5010         CLOSE_WAIT 
tcp        0      0 131.215.113.97:5010         131.215.113.103:57211       ESTABLISHED
tcp        0      0 131.215.113.97:5010         131.215.113.103:57300       ESTABLISHED
tcp        0      0 131.215.113.97:5010         131.215.113.103:57299       ESTABLISHED
tcp        0      0 131.215.113.97:5010         131.215.113.103:57315       ESTABLISHED

 

I switched the code to use port 5022 which worked fine.  However, I'm not sure what would have caused the original connection closure failures, as I test several close methods (including the kill command on the server end used by the medm screen), and none seemed to generate this broken connection state.  I rebooted Ottavia, and this seemed to fix the connections, and allowed port 5010 to work.  I also tried creating 10 connections, which all seem to run fine simultaneously.  So its not someone overloading that port with too many connections which caused the problem.  Its like the the port stopped working somehow, which froze the connection status, but how or why I don't know at this point.

  2372   Wed Dec 9 17:51:03 2009 kiwamuUpdateSUSwatchdogs

Please do not touch the watchdogs for all SUSs except for MCs,

because I am going to measure the free swinging spectra for ITMs, ETMs, BS, PRM, SRM tonight.

Today, it is good chance to summarize those data under atmospheric pressure.

thank you.

 

  2373   Wed Dec 9 18:01:06 2009 KojiUpdateCOCWiping finished

[Kiwamu, Jenne, Alberto, Steve, Bob, Koji]

We finished wiping of four test masses without any trouble. ITMY looked little bit dusty, but not as much as ITMX did.
We confirmed the surface of the ITMX again as we worked at vertex a lot today. It still looked clean.

We closed the light doors. The suspensions are left free tonight in order to check their behavior.
Tomorrow morning from 9AM, we will replace the door to the heavy ones.

  2374   Wed Dec 9 21:09:28 2009 kiwamuUpdateSUSRe: free swinging spectra of ETMY and ITMX

Okay, now the data are attached. At that time I just wanted to say like the follower.

- - -

In the free-swinging spectra around ~0.5Hz, you can see the two resonances, which come from pitch and yaw mode of the pendulum.

Note that, the vertical and the horizontal axis are adjusted to be the same for the two plots in the figure .

And I found that

* the floor levels are almost the same (the factor of about 1.5 or something like that) compared to the past.

* however the peak heights for two resonances are several 10 times smaller than the past.

* this tendency are shown in all of the data (ITMX, ETMX, ETMY).

If such variation of the peak heights is cased by the seismic activity, it means the seismic level change by several 10 times. It sounds large to me.
 

Quote:

Where is the plot for the trend?
It can be either something very important or just a daydream of you.
We can't say anything before we see the data.

Quote:

By the way I found a trend, which can be seen in all of the data taken today and yesterday.

The resonances of pitch and yaw around 0.5Hz look like being damped, because their height from the floor become lower than the past.

I don't know what goes on, but it is interesting because you can see the trend in all of the data.

 

 

Attachment 1: Pitch-Yaw_modes.png
Pitch-Yaw_modes.png
  2375   Thu Dec 10 00:46:15 2009 KojiUpdateSUSRe: free swinging spectra of ETMY and ITMX

Well, I get the point now. It could be either seismic or change in the suspension Q.

The pendulum memorizes its own state for a period of ~ Q T_pend. (T_pend is the period of the pendulum)
If the pendulum Q is very high (>104), once the pendulum is excited, the effect of the excitation can last many hours.

On the other hand, in our current case, we turned on the damping once, and then turned off the damping.
Again it takes ~Q T_pend to be excited. 

In those cases, the peak height is not yet before in equilibrium, and can be higher or lower than expected. 

So, my suggestion is:
Track the peak height along the long time scale (~10hrs) and compare between the previous one and the current one.
This may indicate whether it is equilibrium or not, and where the equilibrium is.

Quote:

If such variation of the peak heights is cased by the seismic activity, it means the seismic level change by several 10 times. It sounds large to me.

 

  2376   Thu Dec 10 08:40:12 2009 AlbertoUpdateComputersFronte-ends down

I found all the front-ends, except for C1SUSVME1 and C0DCU1 down this morning. DAQAWG shows up green on the C0DAQ_DETAIL screen but it is on a "bad" satus.

I'll go for a big boot fest.

  2378   Thu Dec 10 08:50:33 2009 AlbertoUpdateComputersFronte-ends down

Quote:

I found all the front-ends, except for C1SUSVME1 and C0DCU1 down this morning. DAQAWG shows up green on the C0DAQ_DETAIL screen but it is on a "bad" satus.

I'll go for a big boot fest.

Since I wanted to single out the faulting system when these situations occur, I tried to reboot the computers one by one.

1) I reset the RFM Network by pushing the reset button on the bypass switch on the 1Y7 rack. Then I tried to bring C1SOSVME up by power-cycling and restarting it as in the procedure in the wiki. I repeated a second time but it didn't work. At some point of the restarting process I get the error message "No response from EPICS".
2) I also tried rebooting only C1DCUEPICS but it didn't work: I kept having the same response when restarting C1SOSVME
3) I tried to reboot C0DAQCTRL and C1DCU1 by power cycling their crate; power-cycled and restarted C1SOSVME. Nada. Same response from C1SOSVME.
4) I restarted the framebuilder;  power-cycled and restarted C1SOSVME. Nothing. Same response from C1SOSVME.
5) I restarted the framebuilder, then rebooted C0DAQCTRL and C1DCU, then power-cycled and restarted C1SOSVME. Niente. Same response from C1SOSVME.
 
Then I did the so called "Nuclear Option", the only solution that so far has proven to work in these circumstances. I executed the steps in the order they are listed, waiting for each step to be completed before passing to the next one.
0) Switch off: the frame builder, the C0DAQCTRL and C1DCU crate, C1DCUEPICS
1) turn on the frame builder
2) reset of the RFM Network switch on 1Y7 (although, it's not sure whether this step is really necessary; but it's costless)
3) turn on C1DCUEPICS
4) turn on the C0DAQCTRL and C1DCU crate
5) power-cycle and restart the single front-ends
6) burt-restore all the snapshots
 
When I tried to restart C1SOSVME by power-cycling it I still got the same response: "No response from EPICS". But I then reset C1SUSVME1 and C1SUSVME2 I was able to restart C1SOSVME.
 
It turned out that while I was checking the efficacy of the steps of the Grand Reboot to single out the crucial one, I was getting fooled by C1SOSVME's status. C1SOSVME was stuck, hanging on C1SUSVME1 and C1SUSVME2.
 
So the Nuclear option is still unproven as the only working procedure. It might be not necessary.
 
Maybe restating BOTH RFM switches, the one in 1Y7 and the one in 1Y6, would be sufficient. Or maybe just power-cycling the C0DAQCTRL and C1DCU1 is sufficient. This has to be confirmed next time we incur on the same problem.
  2379   Thu Dec 10 09:51:06 2009 robUpdatePSLRCPID settings not saved

Koji, Jenne, Rob

 

We found that the RCPID servo "setpoint" was not in the relevant saverestore.req file, and so when c1psl got rebooted earlier this week, this setting was left at zero.  Thus, the RC got a bit chilly over the last few days.  This channel has been added. 

 

Also, RCPID channels have been added (manually) to conlog_channels. 

  2381   Thu Dec 10 09:56:32 2009 KojiUpdatePSLRCPID settings not saved

Note: The set point C1:PSL-FSS_RCPID_SETPOINT is 37.0 on C1PSL_FSS_RCPID.adl.

Now the temp is recovering with its full speed. At some point we have to restore the value of the FSS SLOW DC as the temp change drag it up.

Quote:

Koji, Jenne, Rob

We found that the RCPID servo "setpoint" was not in the relevant saverestore.req file, and so when c1psl got rebooted earlier this week, this setting was left at zero.  Thus, the RC got a bit chilly over the last few days.  This channel has been added. 

Also, RCPID channels have been added (manually) to conlog_channels. 

 

Attachment 1: RC_TEMP.png
RC_TEMP.png
  2382   Thu Dec 10 10:01:16 2009 JenneUpdateComputersFronte-ends down

All the front ends are back up.  

Quote:

Quote:

I found all the front-ends, except for C1SUSVME1 and C0DCU1 down this morning. DAQAWG shows up green on the C0DAQ_DETAIL screen but it is on a "bad" satus.

I'll go for a big boot fest.

Since I wanted to understand once for all what's the faulting system when these situations occur, I tried to reboot the computers one by one.

1) I reset the RFM Network by pushing the reset button on the bypass switch on the 1Y7 rack. Then I tried to bring C1SOSVME up by power-cycling and restarting it as in the procedure in the wiki. I repeated a second time but it didn't work. At some point of the restarting process I get the error message "No response from EPICS".
2) I also tried rebooting only C1DCUEPICS but it didn't work: I kept having the same response when restarting C1SOSVME
3) I tried to reboot C0DAQCTRL and C1DCU1 by power cycling their crate; power-cycled and restarted C1SOSVME. Nada. Same response from C1SOSVME.
4) I restarted the framebuilder;  power-cycled and restarted C1SOSVME. Nothing. Same response from C1SOSVME.
5) I restarted the framebuilder, then rebooted C0DAQCTRL and C1DCU, then power-cycled and restarted C1SOSVME. Niente. Same response from C1SOSVME.
 
The following is the so called "Nuclear Option", the only solution that so far has proven to work in these circumstances. Execute the following steps in the order they are listed, waiting for each step to be completed before passing to the next one.
0) Switch off: the frame builder, the C0DAQCTRL and C1DCU crate, C1DCUEPICS
1) turn on the frame builder
2) reset of the RFM Network switch on 1Y7 (although, it's not sure whether this step is really necessary; but it's costless)
3) turn on C1DCUEPICS
4) turn on the C0DAQCTRL and C1DCU crate
 
One other possibility remains to be explored to avoid the Nuclear Option. And that is to just try to reset both RFM Network switches: the one in 1Y7 and the one in 1Y6.

 

  2383   Thu Dec 10 10:31:18 2009 JenneUpdateComputersFronte-ends down

Quote:

All the front ends are back up.  

Quote:

Quote:

I found all the front-ends, except for C1SUSVME1 and C0DCU1 down this morning. DAQAWG shows up green on the C0DAQ_DETAIL screen but it is on a "bad" satus.

I'll go for a big boot fest.

Since I wanted to understand once for all what's the faulting system when these situations occur, I tried to reboot the computers one by one.

1) I reset the RFM Network by pushing the reset button on the bypass switch on the 1Y7 rack. Then I tried to bring C1SOSVME up by power-cycling and restarting it as in the procedure in the wiki. I repeated a second time but it didn't work. At some point of the restarting process I get the error message "No response from EPICS".
2) I also tried rebooting only C1DCUEPICS but it didn't work: I kept having the same response when restarting C1SOSVME
3) I tried to reboot C0DAQCTRL and C1DCU1 by power cycling their crate; power-cycled and restarted C1SOSVME. Nada. Same response from C1SOSVME.
4) I restarted the framebuilder;  power-cycled and restarted C1SOSVME. Nothing. Same response from C1SOSVME.
5) I restarted the framebuilder, then rebooted C0DAQCTRL and C1DCU, then power-cycled and restarted C1SOSVME. Niente. Same response from C1SOSVME.
 
The following is the so called "Nuclear Option", the only solution that so far has proven to work in these circumstances. Execute the following steps in the order they are listed, waiting for each step to be completed before passing to the next one.
0) Switch off: the frame builder, the C0DAQCTRL and C1DCU crate, C1DCUEPICS
1) turn on the frame builder
2) reset of the RFM Network switch on 1Y7 (although, it's not sure whether this step is really necessary; but it's costless)
3) turn on C1DCUEPICS
4) turn on the C0DAQCTRL and C1DCU crate
 
One other possibility remains to be explored to avoid the Nuclear Option. And that is to just try to reset both RFM Network switches: the one in 1Y7 and the one in 1Y6.

 

 I burtrestored all the snapshots to Dec 9 2009 at 18:00.

  2385   Thu Dec 10 13:13:08 2009 JenneUpdateComputersfb40m backup restarted

The frame builder was power cycled during the morning bootfest.  I have restarted the backup script once more.

  2386   Thu Dec 10 13:50:02 2009 JenneUpdateVACAll doors on, ready to pump

[Everybody:  Alberto, Kiwamu, Joe, Koji, Steve, Bob, Jenne]

The last heavy door was put on after lunch.  We're now ready to pump.

  2387   Thu Dec 10 15:18:55 2009 JenneUpdateVACseisBLRMS

last 20 days - including the pounding from next door

Attachment 1: Untitled.png
Untitled.png
  2388   Thu Dec 10 16:51:35 2009 steveUpdateVACpumpdown will start tomorrow morning

The vacuum system is at 760 torr  All chambers with doors on and their annuloses are pumped down.

PSL output shutter is still closed. We are fully prepared to star slow pump down tomorrow.

The plan is to reach 1 torr ~ in 6 hrs  without a creating a sand storm.

  2391   Thu Dec 10 17:13:36 2009 kiwamuUpdateSUSFree swiging spectra under the atmospheric pressure

The free swinging spectra of ITMs, ETMs, BS, PRM and SRM were measured last night in order to make sure that nothing wrong have happened by the wiping.

I think there are nothing wrong with ITMs, ETMs, BS, PRM and SRM successfully.

For the comparison, Yoichi's figure in his elog entry of Aug.7 2008 is good, but in his figure somehow PRM spectrum doesn't look correct.

Anyway, compared with his past data, there are no significant changes in the spectra. For PRM which has no counterpart to compare with, its shape of spectra looks similar to any other spectra. So I think PRM is also OK. The measured spectra are attached below.

Indeed the current data are still showing smaller peak height for their pitch and yaw modes (roughly factor of 10 ).
 
Attachment 1: summary_freeswing.pdf
summary_freeswing.pdf summary_freeswing.pdf summary_freeswing.pdf summary_freeswing.pdf summary_freeswing.pdf summary_freeswing.pdf summary_freeswing.pdf
  2392   Thu Dec 10 18:27:48 2009 MottUpdateGeneralUpdated R & T Measurements

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

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

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

The mirrors are:

Y1-1037-00.50CC

Y1-2037-45S

Y1-2037-45P

Y1S-1025-0

Y1S-1025-45

 

Attachment 1: Y1S-0.png
Y1S-0.png
Attachment 2: Y1S-45.png
Y1S-45.png
Attachment 3: Y45P.png
Y45P.png
Attachment 4: Y45S.png
Y45S.png
Attachment 5: Y150CC.png
Y150CC.png
Attachment 6: Setup.png
Setup.png
  2401   Fri Dec 11 17:36:37 2009 kiwamuUpdateGeneralIFO restoring plan

Alberto, Jenne, Kiwamu

 

We together will lead the IFO restoring and the following is our plan.

- - - - -|- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

#.0     |  measuring the free swinging spectra                     (weekend by kiwamu)   DONE

#.1     |  turn ON the PZTs for steering mirror and so on.         (Dec.14 Mon.) DONE

#. 1            |    lock around PSL  DONE

#.2     |  deal with mechanical shutter                            (Dec.14 Mon.)DONE

#.3     |  lock MCs                                                (Dec.14 Mon.)DONE

#.4     |  align the IFO                                           (Dec.15 Tue.)DONE

#.5     |  lock full IFO                                           (Dec.15 Tue.)DONE

- - - - -|- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 

Thank you.

  2405   Sun Dec 13 17:43:10 2009 kiwamuUpdateSUSfree swinging spectra (vacuum)

The free swinging spectra of ITMs, ETMs, BS, PRM and SRM were measured under the vacuum-condition. The attachment are measured spectra.

It looks there are nothing wrong because no significant difference appear from the past data and the current data (under atmosperic pressure).

So everything is going well.

Attachment 1: summary_FreeSwinging_vacuum.pdf
summary_FreeSwinging_vacuum.pdf summary_FreeSwinging_vacuum.pdf summary_FreeSwinging_vacuum.pdf summary_FreeSwinging_vacuum.pdf summary_FreeSwinging_vacuum.pdf summary_FreeSwinging_vacuum.pdf summary_FreeSwinging_vacuum.pdf
  2410   Mon Dec 14 12:13:52 2009 JenneUpdateTreasureWe are *ROCKSTARS* ! IFO is back up

[Jenne, Kiwamu, Koji]

We got the IFO back up and running!  After all of our aligning, we even managed to get both arms locked simultaneously.  Basically, we are awesome. 

 This morning, we did the following:

*  Turned on the PZT High voltages for both the steering mirrors and the OMC.  (For the steering mirrors, turn on the power, then hit "close loop" on each.  For the OMC, hit Output ON/OFF).

*  Looked at the PZT strain gauges, to confirm that the PZTs came back to where they had been.  (Look at the snapshot of C1ASC_PZT_Al)

*  Locked all components of the PSL (This had already been done.)

*  Removed beam dump which was blocking the PSL, and opened the PSL mechanical shutter.  Light into the IFO!

*  Locked the Mode Cleaner.  The auto-locker handled this with no problem.

*  Confirm that light is going through the Faraday.  (Look at the TV sitting on top of MC13 tank...it shows the Faraday, and we're hitting the input of the Faraday pretty much dead-on).

*  Look at IP_ANG and IP_POS.  Adjust the steering mirrors slightly to zero the X&Y readings on IP_ANG.  This did not change the PZTs by very much, so that's good.

*  Align all of the Core Optics to their OpLev positions.

*  On the IFO_Align screen, save these positions.

*  Run the IFO_Configure scripts, in the usual order.  (Xarm, Yarm, PRM, DRM).  Save the appropriate optics' positions after running the alignment scripts.  We ended up running each alignment script twice, because there was some residual misalignment after the first iteration, which we could see in the signal as viewed on DataViewer (Either TRX, TRY, or SPOB, for those respective DoFs).

*  Restore Full IFO.

*  Watch the beauty of both arms and the central cavity snapping together all by themselves!  In the attached screenshot, notice that TRX and TRY are both ~0.5, and SPOB and AS166Q are high.  Yay!

Conclusions: 

*  The wiping may have helped.  While aligning X and Y separately, TRX got as high as ~1.08, and TRY got as high as 0.98  This seems to be a little bit higher than it was previously.

*  Since everything locked up in pretty short order, and the free swinging spectra (as measured by Kiwamu in elog 2405) looks good, we didn't break anything while we were in the chambers last week.  Excellent.

*  We are now ready for a finesse measurement to tell us more quantitatively how we did with the wiping last week.

 

Attachment 1: Jenne14Dec09_IFOlocked.png
Jenne14Dec09_IFOlocked.png
  2411   Mon Dec 14 13:08:33 2009 KojiUpdateTreasureLOCKSTARS

Good job guys. What I did was saying "I don't know", "Maybe", and "Ants...".

Now you can proceed to measurements for the visibility and the cavity pole! 

Quote:

[Jenne, Kiwamu, Koji]

We got the IFO back up and running!  After all of our aligning, we even managed to get both arms locked simultaneously.  

  2412   Mon Dec 14 13:17:33 2009 robUpdateTreasureWe are *ROCKSTARS* ! IFO is back up

 

 

Attachment 1: two-thumbs-up.jpeg
two-thumbs-up.jpeg
  2413   Mon Dec 14 14:16:14 2009 AlbertoUpdateTreasureLOCKSTARS

Quote:

Good job guys. What I did was saying "I don't know", "Maybe", and "Ants...".

Now you can proceed to measurements for the visibility and the cavity pole! 

Quote:

[Jenne, Kiwamu, Koji]

We got the IFO back up and running!  After all of our aligning, we even managed to get both arms locked simultaneously.  

 I'm going to do it right now.

  2414   Mon Dec 14 15:18:18 2009 JenneUpdatelorearmLoss script ran....results confidential

I ran the armLoss script for both Xarm and Yarm.  The results are confidential, pending the completion of Alberto's cavity pole/finesse measurement due to the 'bet' as to what the new losses are after the drag wiping.

If you're the kind of person who likes to look at their Chrismas presents, the log files with the results are in the usual place for this script: /scripts/LSC/loss-ARM-GPStime.log  (loss-Y-944865071.log and loss-X-944865946.log)

  2415   Mon Dec 14 19:33:04 2009 AlbertoUpdateGeneralArm Cavity Poles measured again after cleaning the optics last week

Last week we vented and we cleaned the main optics of the arm cavities.

I measured the frequency of the cavity poles for both the arm cavities to see how they changed (see previous elog entry 2226). These the results:

fp_X = 1616 +/- 14 Hz

fp_Y = 1590 +/- 4 Hz

The error is the statistical error that I got with the Matlab NonLinearLeastSquare fitting function.
 
I calculated the cavity pole frequencies by measuring the transfer function between a photodiode located at the end of the arms (either X or Y) and another photodiode placed after the mode cleaner. Both diodes where Thorlabs PDA255.
(Last time, I had measured that the pair of diode had a flat calibration).
 
With the SR785 I measured the transfer function by exciting the OMC_ISS_EXC input cable.
For both arms I set to 1V the excitation amplitude. I repeated the measurements for different excitation amplitudes without observing any changes.
I then fitted the data with the NonLinearLeastSquare function of matlab. The script I wrote to do that is attached to this entry in a compressed file.
The files also contains the PDF with the output plots and the data from both set of measurements performed before and after the cleaning.
The data is commented in a file called measurements.log.
 
In the end I disabled again the test switch on the ISS MEDM screen.
I disconnected the excitation cable from the OMC_ISS_EXC input cable.
I removed the photodiode that measured the Mode Cleaner transmission from the PSL clearing the way for the beam to get back to its path to the RFAM photodiode.
Attachment 1: XarmTF01_fit.pdf
XarmTF01_fit.pdf
Attachment 2: YarmTF01_fit.pdf
YarmTF01_fit.pdf
Attachment 3: ArmCavityFinesseMeasurment.tar.gz
  2416   Mon Dec 14 22:32:56 2009 KojiUpdateGeneralArm cavity loss ~ result

I like to ask someone to review the calculation on the wiki.

In the calculation, the round trip loss and the front mirror T are the unknown variables.
The end mirror T of 10ppm was assumed. (End mirror T)+(Round trip loss) is almost invariant, and T_end does not change the other results much.

Arm cavity loss measurement (Dec. 14, 2009)

X Arm:
  • Arm visibility (given): 0.897 +/- 0.005 (20 pts) (2.5%UP!!)
  • Cut off freq (given): 1616 +/- 14 [Hz] (2.1%UP!!)
  • Finesse (derived): 1206 +/- 10 (2.1%UP!!)
  • Round Trip loss (estimated): 127 +/- 6 [ppm] (28%DOWN!!)
  • Front Mirror T (estimated): 0.00506 +/- 0.00004
Y Arm:
  • Arm visibility (given): 0.893 +/- 0.004 (20 pts) (2.1%UP!!)
  • Cut off freq (given): 1590 +/- 4 [Hz] (8.2%UP!!)
  • Finesse (derived): 1220 +/- 3 (8.2%UP!!)
  • Round Trip loss (estimated): 131 +/- 6 [ppm] (37%DOWN!!)
  • Front Mirror T (estimated): 0.00500 +/- 0.00001 

Previous measurement (Oct 07, 2009 & Nov 10, 2009)

X Arm:  

  • Arm visibility (given): 0.875 +/- 0.005 (34 pts)
  • Cut off freq (given): 1650 +/- 70 [Hz]
     
  • Finesse (derived): 1181 +/- 50
  • Round Trip loss (estimated): 162 +/- 10 [ppm]
  • Front Mirror T (estimated): 0.0051 +/- 0.0002

Y Arm: 

  • Arm visibility (given): 0.869 +/- 0.006 (26 pts)
  • Cut off freq (given): 1720 +/- 70 [Hz]
     
  • Finesse (derived): 1128 +/- 46
  • Round Trip loss (estimated): 179 +/- 12 [ppm]
  • Front Mirror T (estimated): 0.0054 +/- 0.0002
  2417   Tue Dec 15 00:02:10 2009 ranaUpdatePEMNoise of the Ranger SS-1 Seismometer

I wanted to see what the noise of the Ranger seismometer should be. I used LISO and file ranger.fil (in our LISO SVN) to calculate the voltage noise referred to the input. In this model, we represent the EMF from the moving magnet in the coil as a voltage source at 'nin' which drives the coil impedance. This is the same approach that Brian Lantz uses in his noise modeling of the GS-13 (PDF is on our Ranger wiki page).

In the simulation, I used the OP27 as a placeholder for the SR560 that we use (I don't know the current noise of the SR560). To do this, I use the new 'inputnoise' feature in LISO (its in the README, but not in the manual).

You can see that we would be limited by the input current noise of the OP27. So we would do a lot better if we used an FET based readout amp like the AD743 (or equivalent) or even better using the new multi-FET readout circuit that Rich Abbott has developed. Clearly, its also silly to have a load resistance in there - I put it in because the manual says to do it, but all it does is damp the mass and reduce the size of the signal.

#  Noise sim for the Ranger SS-1 seismometer
#
#                            \
#                           | \            
#           n2- - - ----  - |  \          
#            |    |         | op1>-- n4 - r4 -- no
#           Rg   RL     n3- |  /     |           
#       n1 - |    |     |   | /      |                
#           Lg    |     |    /       |                        
#            |    |     | - - - R2 - -                    
#           nin  gnd   R1 
#                       |
#                      gnd

We previously measured the Ranger's self noise by locking it down.

The 1/f^3 noise that we see below 1 Hz is roughly consistent with the noise model: to get from my plot into meters you have to multiply by:

(1 + f)^2

----------

340 * f^2

P.S. Secret PDF handshake: You can make your non-compliant applications like LISO or DTT produce a thumbnailing PDF by using Acrobat to open the file and export it as PDF/A.

In the second attachment, I have used an OPA827 (new low-noise FET input amp from TI) as the readout amplifier. This seems like a good choice - main drawback is that Digikey backordered my OPA827s by 19 weeks!

Attachment 1: rangerx.pdf
rangerx.pdf
Attachment 2: ranger827.pdf
ranger827.pdf
  2418   Tue Dec 15 05:29:31 2009 AlbertoUpdateGeneralArm Cavity Poles measured again after cleaning the optics last week

 

 The Y arm cavity pole moved down by 130 Hz, whereas the X arm moved by only 34 Hz. I wonder if that is because Kiwamu spent much more time on cleaning ITMY than on any other optic.

  2419   Tue Dec 15 17:16:22 2009 KojiUpdateGeneralTable distance measurements

During the vent we have tried to measure the distances of the optical tables for BS-ITMX and BS-ITMY.
We need to take into account the difference between the AutoCAD drawing and the reality.

X direction distance of the table center for BS and ITMX:
84.086" (= 2135.8mm)
(This is 84.0000" in AutoCAD drawing)

Y direction distance of the table center for BS and ITMX:
83.9685" (= 2132.8mm)
(This is 83.5397" in AutoCAD drawing)

We used two scales attached each other in order to measure the distance of the certain holes on the tables.

We got more numbers that were estimated from several separated measurements.
I think they were not so accurate, but just as a record, I also put the figure as an attachment 2.

Attachment 1: Table_distance_by_metal_scale.pdf
Table_distance_by_metal_scale.pdf
Attachment 2: Table_distance_by_chambers.pdf
Table_distance_by_chambers.pdf
  2420   Tue Dec 15 21:39:34 2009 AlbertoUpdateABSLbrief summary of this afternoon's measurements
I took measurements of the open loop gain of the AbsL PLL with the old Universal PDH Box.
I Also measured the filter shape of both the new and the old PDH box.
I'm going to plot the results in a nice form tomorrow morning.
For who's interested, the PLL UGF was at 10KHz.
 
I can't lock the PLL with the new PDH box. Measuring its filter's shape, as suggested by Koji, I found out that it differs from the old one. That despite the fact that the two boxes should share the same circuit schematic. O,r at least, that is what it looks like from the schematics in the DCC.
I need to understand whether that is intentional and, if that was the case, what kind of use  Rich Abbott designed it for.
 
Tomorrow I'm going to post in the elog the filter's transfer functions too.
 
Before leaving the lab I closed the auxiliary laser's mechanical shutter.
  2421   Wed Dec 16 11:21:20 2009 AlbertoUpdateABSLUniversal PDH Box Servo Filters
Yesterday I measured the shape of the servo filter of both the old and the new Universal PDH boxes.
Here they are compared.

NewandOlfFilterTF.png

The way the filter's transfer function has been measured is by a swept sine between the "SERVO INPUT" and the "PIEZO DRIVE OUTPUT" connection on the box front panel. The spectrum analyzer used for the measurement is the SR785 and the source amplitude is set at 0.1V.

The two transfer functions are clearly different. In particular the old one looks like a simple integrator, whereas the new one already includes some sort of boost.

That probably explains why the new one is unable to lock the PLL. Indeed what the PLL needs, at least to acquire lock, is an 1/f filter.

I thought the two boxes were almost identical, at least in the filter shapes. Also the two schematics available in the DCC coincide.

Attachment 1: NewandOlfFilterTF.png
NewandOlfFilterTF.png
  2422   Wed Dec 16 11:46:25 2009 AlbertoUpdateABSLAbsl PLL Open Loop Gain

Yesterday I measured the Open Loop Gain of the PLL in the absolute length experiment. The servo I used was that of the old Universal PDH box.

The OLG looks like this:

OldBoxOLTF.png

The UGF is at 10 KHz.

  2423   Wed Dec 16 11:55:47 2009 ranaUpdateABSLUniversal PDH Box Servo Filters

 

 To me, they both look stable. I guess that the phase has to go to -180 deg to be unstable.

Why does the magnitude go flat at high frequencies? That doesn't seem like 1/f.

How about a diagram of what inputs and outputs are being measured and what the gain knob and boost switch settings are?

  2424   Wed Dec 16 20:29:08 2009 ranaUpdateCOCETM Coating study

This plot shows the Transmission for 532 and 1064 nm as a function of the thickness of the SiO2 layer.

i.e. the thickness is constrained so that the optical thickness of the SiO2 and Ta2O5 pair is always 1/2 of a wavelength.

The top layer of the mirror is also fixed in this plot to be 1/2 wave.

This plot shows the result for 17 pairs. For 16 pairs, we are unable to get as low as 15 ppm for the 1064 nm transmission.

Attachment 1: layerfrac.png
layerfrac.png
  2425   Thu Dec 17 02:57:08 2009 JenneUpdateWienerFilteringL1 DARM Static Wiener Filtered data

This is perhaps best put in the LLO elog, but I'm not yet a 'person' there, so I can't write to their elog (yet another thing for the eternal to-do list).  So for now, we're putting things here...

This isn't totally finalized, but I do want to get what I have posted before I hop on a plane in the morning.  Mostly it just needs more time to run, to make the plot longer.  Hopefully I'll be able to edit this in the morning and have a longer-duration plot. 

What's plotted:

This spectrogram shows the amplitude spectra of L1:LSC-DARM_CTRL, after being subtracted via a Static Wiener Filter.  Each spectra is normalized by the very first one, which was created from the same data that was used to determine the Wiener Filter.  The X-axis is time.  The Y-axis is frequency, and the Color/Z-axis is amplitude in dB.  I'm only looking at Science Mode time, so other times when the IFO isn't in science mode, I plot a black stripe to fill in the plot.  The start time of the plot is 83675598, which is Jul 08 2006 06:33:04 UTC. 

Why?

The idea is to see that the filter does equally well a long time after it was created, as when it was initially made.  This will help tell us how often it is useful to recompute the Wiener filters.  Less often is nice, because redoing the Wiener filters may also include remeasuring the high precision transfer functions...if the filter isn't working as well anymore it may be because the transfer function has changed ever so slightly. 

How the plot is created / the background story:

I use one hour of DARM_CTRL data and the following seismometer channels to create an optimal Wiener Filter (pem indicates L0:PEM- , sei indicates L1:SEI- , and lsc indicates L1:LSC- ) :

chans = {[pem 'EX_SEISX'],...
         [pem 'EX_SEISY'],...
         [pem 'EX_SEISZ'],...
         [pem 'EY_SEISX'],...
         [pem 'EY_SEISY'],...
         [pem 'EY_SEISZ'],...
         [pem 'LVEA_SEISX'],...
         [pem 'LVEA_SEISY'],...
         [pem 'LVEA_SEISZ'],...
         [sei 'LVEA_STS2_X'],...
         [sei 'LVEA_STS2_Y'],...
         [sei 'LVEA_STS2_Z'],...
         [sei 'ETMX_STS2_X'],...
         [sei 'ETMX_STS2_Y'],...
         [sei 'ETMX_STS2_Z'],...
         [sei 'ETMY_STS2_X'],...
         [sei 'ETMY_STS2_Y'],...
         [sei 'ETMY_STS2_Z'],...
         [lsc 'DARM_CTRL']};

I then apply this one filter to ten minute chunks of science mode data, for some long period of time.  The game plan is to have a month long plot, but it takes a while to fetch all of the data in separate 10min intervals (~45sec per iteration, times ~3000 iterations), so this plot isn't a full month.  Even if I don't get a chance to plot a full month by Thursday morning, it'll go up here within the next few days. The particular times chosen have the most science mode data within a 30 day period.  I can easily run the code for some other time, if there is a known time (or season) which might be more interesting.  For the spectrogram plot, I then normalize each amplitude spectra by the first one, which comes from the first ten minutes in the hour which was used to make the filter.  This makes it easier to see how the filter's efficacy changes over time.

The analogous analysis for Hanford is in the 40m elog: 1606.  The Hanford stuff in the elog has some cool BLRMS plots also, but I'm not sure that they're so helpful when I only have a few days of L1 data so far.  I'll do those and add them later.

Conclusions:

I can't really say anything yet about the long-term efficacy of a Wiener Filter for LLO yet, since my code hasn't finished filtering my one month of S5 L1 data.  It definitely looks like (so far) that there was a big seismic event around the (arbitrarily defined) 'Day 4'. 

Attachment 1: L1darmCompPlot_17Dec2009_4daysLong.png
L1darmCompPlot_17Dec2009_4daysLong.png
  2426   Thu Dec 17 07:47:29 2009 JenneUpdateWienerFilteringL1 DARM Static Wiener Filtered data

This surface plot is the same as the previous one, with a little more data than I had previously. 

This time around, I also include the "BLRMS" plots for this data.  The first one takes each residual and normalizes it by the DARM_CTRL signal at that time, separates the spectra into bands, and integrates underneath the spectra within that band.  The second one is the raw DARM_CTRL signal's spectra at each time, and integrates under the spectra for each band, and the third BLRMS plot does the same thing for the residuals.  Unfortunately, these plots don't have the same handy black stripe during time which I don't analyze that the spectrogram utilizes.

From the second BLRMS plot we can see that the large red splotch in the spectrogram is due to higher noise in the DARM spectrum, and that (by looking at the Ratio BLRMS plot) the Wiener filter still does a pretty good job during this time.  I expect that for later times when the seismic (or something) event is gone, the Wiener filter will continue performing almost as well as it had been initially.

Again, once the script finishes applying the filter to the many ten minute chunks (the huge time drain is the data fetching, so this shouldn't be a limiting factor for using Wiener filters online), I'll post a final plot.

Attachment 1: L1darmComp_17Dec2009_6day_residualsNormSurfacePlot.png
L1darmComp_17Dec2009_6day_residualsNormSurfacePlot.png
Attachment 2: L1darmComp_17Dec2009_6day_ratioBLRMS.png
L1darmComp_17Dec2009_6day_ratioBLRMS.png
Attachment 3: L1darmComp_17Dec2009_6day_rawBLRMS.png
L1darmComp_17Dec2009_6day_rawBLRMS.png
Attachment 4: L1darmComp_17Dec2009_6day_residualsBLRMS.png
L1darmComp_17Dec2009_6day_residualsBLRMS.png
  2430   Thu Dec 17 23:27:23 2009 ranaUpdatePEMRanger Noise: sim w. Rai FET box as readout

I have started measuring the low frequency noise of the FET front end + LT1128 low noise preamp from Rai Weiss. It has a very low input current noise because its FET based, which is not surprising. It is also a fairly low voltage noise box - the best measured ones have an input referred noise of ~0.35 nV/rHz.

Today I measured the noise of the one we have down to 0.1 Hz. It looks like a good candidate for a Geophone readout (e.g. Ranger or GS-13 or perhaps the L-4C). Because I didn't thermally shield any of this stuff, the broadband noise is ~0.8 nV/rHz. The low frequency corner is ~15 Hz.

I attach the LISO simulation of the voltage noise referred to the input. The circuit is described in this entry.

We can probably do better than this if we package it a little better or give it time to warm up or use metal film resistors inside. Even as it is, however, it would allow us to reach the thermal noise of the Ranger (or GS-13) down to 0.1 Hz.

This should be ~1.5 or 2x better than the LT1012 based readout at 1 Hz and 10x better down at 0.1 Hz (c.f. T0900457).

Attachment 1: ranger.pdf
ranger.pdf
  2431   Fri Dec 18 15:40:33 2009 KojiUpdateIOOMC2 spot centered / MCT QPD issue

This afternoon I felt like saying hello to the input mode cleaner. So I decided to center the spot on MC2.

Motivation

MC has 6 alignment dofs. 4 of them are controlled by the WFSs. Remaining 2 appears at the spot position on MC2.
If the spot on the MC2 is fixed, the beam hits the same places of three mirrors. If the mirrors are completely fixed
in terms of the incident beam, I suppose the reflected beam is also fixed. This makes the WFS spots more stable.
Then I feel better.

Today's goal is to confirm the behaviour of MC such as dithering amplitude, response of the couplings to the alignment,
behavior of the WFS, and the transmitted power.


Method

1) Turned off MC auto locker. Turned off MC WFS as the WFS servos disturbs my work.
2) Dithered MC2 in Pitch and Yaw using DTT. There looks elliptic filter (fc=28Hz) in the ASC path, I used 20Hz-ish excitations.
- C1:SUS-MC2_ASCPIT_EXC 100cnt_pk@19Hz
- C1:SUS-MC2_ASCYAW_EXC 100cnt_pk@22Hz
3) Looked at C1:SUS-MC2_MCL_OUT to find the peaks at 19Hz and 22Hz. These are caused by alignment-length coupling.
If they are minimized I assume the spot is somehow centered on MC2.
Note: This may not be the true center. The suspension response should be investigated. But this is a certain reporoducible spot position.
Note: I should use ezcademod in order to obtain the phase information of the dither result.

4) Move MC2 Pitch for certain amount (0.01cnt) by the alignment slider. Align MC1/MC3 to have max transmittion.
5) If the Pitch peak got lower, the direction of 4) was right. Go further.
5') If the Pitch peak got higher, the direction of 4) was wrong. Go the other direction.

6) Repeat 4)&5) for Yaw.


Result

After the adjustment, the couplings got lower about 10 times. (Sorry! The explanation is not so scientific.)
Next time I (or someone) should make a script to do it and evaluate the coupling by the estimated distance of the spot from the center of the mirror (the center of the rotation).
I have not seen visible change in the spectrum of C1:SUS-MC2_MLC_OUT.


MCT QPD issue

By the spot centering, I could expected to see some improvement of the transmittion. But in reality, there was no change.
In fact, the transmittion power was getting down for those weeks.

I checked WFS and MCT paths. Eventually I found that a couple of possible problems:
1) MCT Total output varies more than 10% depending on the spot position on MCT QPD.
2) Just before the QPD, there is a ND1 filter.
This may suggest that:
a) Four elemtns of the MCT QPD have different responses.
b) The ND filter is causing a fringe.

So far I aligned the ND filter to face the beam. The reflection from the filter was blocked at a farther place.
Still the output varies on the spot position. Probably I have to look at the QPD someday.

So far the spot on the QPD was defined so that I get the maximum output from the QPD. This is about 8.8.
As I touched the steering mirrors, the X and Y outputs of the QPD are no longer any reference.

For now, I closed the PSL table. The full IFO was aligned.

  2433   Sun Dec 20 14:34:24 2009 KojiUpdateSUSETMY watchdog tripped Sunday 5:00AM local

It seemed that the ETMY watchdog tripped early Sunday morning.
The reason is not known. I just looked at ETMX, but it seemed fine.

I called the control room just in case someone is working on the IFO.
Also I did not see any elog entry to indicate on going work there.

So, I decided to reset the watchdog for ETMY. And it is working fine again.

Attachment 1: Y.png
Y.png
  2434   Sun Dec 20 21:39:40 2009 rana, jenne, kiwamuUpdateASSOAF Model update and build instructions

After a lot of headache, I got the OAF working again - read on for details.....................

Sometime last week, Jenne, Kiwamu, and I tried to update the OAF model to include the IIR "feed-around" path.

This path is in parallel to the existing FIR-based adaptive FXLMS stuff that Matt put in earlier. The reason for the

new path is that we want to try emulating the same FF technology which has been successful lately at LLO.

 

However, we were unable to make the ASS work after this work. Mostly, the build stuff worked fine, but we couldn't get DTT

to make a transfer function. The excitation channels could be selected and the excitation would actually start and get all the

way into MC1, but DTT would just hang on the first swep-sine measurement with no time-out error. Clearly our ASS building

documentation is no good. We tried using the instructions that Koji gave us for AAA, but that didn't completely work.

 

In particular, the 'make-uninstall-daq-ass' command gave this command:

[controls@c1ass advLigo]$ make uninstall-daq-ass
grep: target/assepics/assepics*.cmd: No such file or directory
Please make ass first
make: *** [uninstall-daq-ass] Error 1

re-arranging the order to do 'make-ass' first fixes this issue and so I have fixed this in the OAF Wiki.

 


The there's the whole issue with the tpchn_C3.par file. This contains all the test point definitions for the ASS/OAF machine. The main

IFO numbers are all in tpchn_C1.par and the OMC is all in tpchn_C2.par. When we do the usual build, in the 'make install-daq-ass' part:

[controls@c1ass advLigo]$ make install-daq-ass
Installing GDS node 3 configuration file
/cvs/cds/caltech/target/gds/param/tpchn_C3.par
Updating DAQ configuration file
/cvs/cds/caltech/chans/daq/C1ASS.ini

we get this .par file installed in the target area. The ACTUAL param file seems to actually be in /cvs/cds/caltech/gds/param  !!

 


Of course, it still doesn't work. That's because the standard build likes to point to /cvs/cds/caltech/gds/bin/awgtpman and the one that runs on

linux is actually /opt/gds/awgtpman. So I've now made a file called startup_ass.cmd.good which runs the correct one. However, the default build

will try to start the wrong one and we have to fix the 'startass' script to point to the correct one on each build. Running the correct awgtpman

allows us to get the TP data using tools like tdsdata, so far no luck with DTT.\

 


UPDATE (23:33): It turns out that it was my old nemesis, NTPD. c1ass had a /etc/ntp.conf file that was pointing at an ntp server called rana113. I

am not an NTP server; I don't even know what time it is. I have fixed the ntp.conf file by making it the same ass c1omc (it now points to nodus). After

this I set the date and time manually (sudo date -s "20 DEC 2009 23:27:45") and then restarted NTPD. It should now be fine even when

we reboot c1ass.

 

After all of this nonsense, I am able to get TP data from c1ass and take transfer functions between it and the rest of the world !

  2435   Sun Dec 20 23:42:44 2009 JenneUpdateIOONew Input Mode Matching Telescope

I've got most of the new Mode Matching Telescope figured out.  The scripts and an example result are at: MMT09 wiki  (Rather, the scripts are in the svn: MMT svn)

Issues still to be resolved: 

* We're getting pretty iffy 'angles' between tilt and translation when using the mode matching mirrors for steering.

* I haven't taken into account the astigmatism which occurs when you tilt the mode matching mirrors. 

The nifty thing about these scripts is that they take a look at the mode matching overlap:  For each possible mode matching solution it adds noise to all of the distances and radii of curvature during ~10,000 iterations and plots a histogram of the overlap so that we can see which solutions have a better chance of giving us the optimal overlap, even if we place the optics in slightly the wrong place.

 

I'd like to update the overlap part of the script with the astigmatism business:  do we lose goodness of overlap if we tilt the mirrors by a bit?  I think this will require redoing the overlap part with the X and Y directions separate.  Koji has done this in the past.  My current code assumes that the beam is always symmetric in X and Y. 

  2437   Mon Dec 21 02:22:31 2009 rana, jenne, kiwamuUpdateASSOAF Model update and build instructions

This allowed measuring the MC1 -> MCL TF finally. Its mostly flat. Data saved as Templates/OAF/OAF-MCLTF.xml

Attachment 1: Untitled.png
Untitled.png
  2438   Mon Dec 21 07:30:58 2009 ???UpdateASSOAF Model update and build instructions

 What does OAF stand for? The entry doesn't say that. Also the acronym is not in the abbreviation page of the wiki.

Can anyone please explain that?

  2440   Mon Dec 21 10:09:06 2009 jenneUpdateASSOAF Model update and build instructions
OAF stands for Online Adaptive Filtering. We use the same computer which was once the ASS. One of these days, we'd like to completely be rid of all things which refer to ASS, and make even the computer's name OAF.
  2441   Mon Dec 21 19:24:29 2009 ranaUpdateASSOAF Model update and build instructions

I fit the MC1 -> MCL TF using vectfit4.m (from mDV). The wrapper file is mDV/extra/C1/ fitMC12MCL.m.

Plotted here are the data (RED), the fit (BLUE), and the residual x10 (GREEN).

For the magnitude plot, residual is defined as ------   res = 1 - fit / data

For the phase plot the residual is defined as -------    res =  phase(data)-phase(fit)

You can see that the agreement is very good. The phase match is better than 5 deg everywhere below 10 Hz.

This TF is so smooth that we could have probably done without using this, but its good to excercise the method anyway.

Attachment 1: mc12mcl.png
mc12mcl.png
  2442   Tue Dec 22 02:50:09 2009 rana, kiwamu, jenneUpdateASSOAF Feedaround ON and doing something good

Kiwamu made the OAF screen functional today - screenshot attached.

After this, I used the measured TF of the MC1 to MCL to filter the signals from the Wilcoxon accelerometers and feed them into the MC.

The noise at 3 Hz went down by a factor of ~3. There's a little excess created at 100 Hz. Its good to see that our intuition about feed-forward is OK.

I did all of the filter calculations by adapting the scripts that Haixing, Valera, and I got going at LLO. They're all in the mDV/extra/C1 SVN.

 

The Wiener code predicts much better performance from using more than just 2 horizontal accelerometers, but I was too lazy to do more channels today.

I also added the Rai box to the Ranger readout today - the noise at 0.1 Hz went down by a factor of 10 and the noise at 1 Hz is close to 10^-11 m/rHz.

Attachment 1: oaf.png
oaf.png
Attachment 2: oaf.png
oaf.png
  2444   Tue Dec 22 11:23:51 2009 kiwamu, SteveUpdateIOOMC relocked

In this morning I found MC unlocked.

Steve restored the watchdogs before I found that.

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

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

 

  2446   Tue Dec 22 15:49:31 2009 kiwamuUpdateGenerale-log restarted

I found the e-log has been down around 3:40pm, then I restarted the e-log. Now it's working.

Thanks.

ELOG V3.1.3-