40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 224 of 344  Not logged in ELOG logo
ID Date Author Type Category Subject
  6074   Tue Dec 6 00:26:00 2011 kiwamuUpdateLSCALS became robust : UGF = 100 Hz

Eventually the instability in the Y end PDH servo turned out to be some kind of an alignment issue.

After carefully realigning the green beam to the Y arm, the UGF of the ALS loop became able to be at more than 50 Hz.

With this UGF it became able to suppress the arm motion to the ADC noise level (few 100 pm in rms).

Now I am scanning the arm length to look for a TEM00 resonance.

 

(the Story)

I have noticed that the spatial fringe pattern of the reflected green light was very sensitive to the pitch motion of ETMY when the green light was locked to the Y arm.

So I realigned the last two launching mirrors to minimize the reflected light. Indeed the misalignment was mainly in the pitch direction.

I basically translated the beam upward by a couple of mm or so.

The amount of the DC reflection is about 2.4 V when it is unlocked and it is now 0.77 mV when the green light is locked.

Quote from #6072

I guess this could be one of the reasons of the unstable behavior in the Y end PDH lock (#6071). (But still it doesn't fully explain the instability).

  6073   Mon Dec 5 19:38:38 2011 JenneUpdateRF SystemEOM mount getting closer....

I have drilled all the holes necessary, and have tapped all but 4 of the holes for the new EOM mount.  The adapter plate is finished and ready to go (including a 10-min iso sonic bath).  The riser that goes between the table and the 9082 mount is drilled but not yet tapped.

  6072   Mon Dec 5 19:21:55 2011 kiwamuUpdateLSCcoarse beat note signal : ADC limited above 30 Hz

The signal observed by the coarse frequency discriminator was actually dominated by the ADC noise above 30 Hz.

It means that once increasing the UGF more than 30 Hz the servo will feed the ADC noise to the test mass and shake it unnecessarily.

I guess this could be one of the reasons of the unstable behavior in the Y end PDH lock (#6071).

(But still it doesn't fully explain the instability).

 

 To improve the situation I am going to do the following actions:

   (1) Installation of a whitening filter (probably use of SR560s)

   (2) Redesign of the servo filter

 

Here is a brief noise budget of the coarse sensor.

Yarm_ALS_coarse.png

Gray curve: free running noise when no servo is applied

Green curve : in-loop noise when the ALS loop is closed with the coarse frequency-discriminator. The UGF was at 30 Hz.

Red curve : ADC noise of the coarse discriminator

Quote from #6071

 So far I still kept failing to increase the UGF of the ALS servo for some reason (see #6024).

  6071   Mon Dec 5 17:44:41 2011 kiwamuUpdateGeneralmy plan tonight

I am going to try handing off the ALS servo to the IR PDH servo on the Y arm and measure the noise.

 - first I need to investigate why the Y end PDH servo becomes unstable when the ALS is engaged with a high UGF.

 

(some notes)

 So far I still kept failing to increase the UGF of the ALS servo for some reason (see #6024).

Every time when I increased the UGF more then 50 Hz, the Y arm PDH lock became unlocked. It needs an explanation and a solution.

Another thing: During several trials in this evening I found the ETMY_SUSPOS_GAIN had been set to 1, so I reset it to 20, which gives us the damping Q of about 5.

 

(Temperature feedback activated)

 As planed in #6024 I have activated the temperature feedback, so that the PZT control signal is offloaded to the temperature. And it seems working fine.

Currently the gain is set to 0.03, which gives us a time constant of ~30 sec for offloading the control signal.

  6070   Mon Dec 5 10:13:13 2011 JenneUpdateAdaptive FilteringC1OAF

Quote:

I've added filter banks for correction path in the C1OAF model to use AA filters.  I compiled and installed the new version. I runs but does not sync. Probably, I've made a mistake in the some names of epics channels. Leave it for now, figure out tomorrow. If someone needs an old version, it is in the /opt/rtcds/caltech/c1/userapps/trunk/isc/c1/models/c1oaf_BACKUP20111204.mdl file. Corresponding medm screen is in the /opt/rtcds/caltech/c1/userapps/trunk/isc/common/medm/OAF_OVERVIEW.adl file.

 The general rule in the 40m is that if it's not an 'emergency', i.e. something is wrong with the computers and preventing the main locking work, no model recompiling-type activities at nighttime. 

Also, if you do things and recompile, you need to do an svn check-in.  That's where backups are kept.  We don't want to clutter folders with backups anymore.

  6069   Mon Dec 5 09:46:21 2011 ZachMetaphysicsRF SystemRAM diagnosis/suppression plan?

Since no one has made any comments, I will assume that everyone is either 100% satisfied with the outline or they have no interest in the project. Under this assumption, I will make decisions on my own and begin planning the individual steps in more detail.

In particular, I will assume that our goal comprises BOTH characterization of RAM levels and mitigation, and I will try to find the best way that both can be achieved as simultaneously as possible. 

  6068   Mon Dec 5 02:55:30 2011 DenUpdateAdaptive FilteringC1OAF

I've added filter banks for correction path in the C1OAF model to use AA filters.  I compiled and installed the new version. I runs but does not sync. Probably, I've made a mistake in the some names of epics channels. Leave it for now, figure out tomorrow. If someone needs an old version, it is in the /opt/rtcds/caltech/c1/userapps/trunk/isc/c1/models/c1oaf_BACKUP20111204.mdl file. Corresponding medm screen is in the /opt/rtcds/caltech/c1/userapps/trunk/isc/common/medm/OAF_OVERVIEW.adl file.

  6067   Sun Dec 4 23:49:38 2011 DenUpdateIOOWFS

Quote:

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

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

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

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

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

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

  6066   Sun Dec 4 13:56:54 2011 DenUpdateIOOWFS

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

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

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

  6065   Sat Dec 3 18:29:20 2011 DenUpdateAdaptive Filteringcoherence

I've looked through the coherence between the MC length and seismometers after the if-statement problem was fixed. Coherence improved for all seismometers but is still not 1. It is possible that contribution from X, Y, Z directions split the coherence between them but at ~0.2-03 Hz we do not see much coherence for all these directions.

coh_mcl_seis.pdf

I looked at the coherence between MC2 OSEM signal and MC_F when the AUTO LOCKER is ON and OFF. I thought that we'll ses the same coherence for both regimes as laser is locker to the MC length. However, I figured out the coherence is worse when AUTO LOCKER is ON at frequencies 0.2-0.3 Hz.

sensor_locker.pdf

The first idea that comes to mind is that when feedback to the laser is provided, the pressure to the mirrors from the laser beam is changed.

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

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

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

psd_sensors.jpg

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

coh_sensors.jpg

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

psd_mcl.jpg

 The coherence between MC_F and GUR1_X is also improved.

coh_mcl.jpg

  6063   Fri Dec 2 20:16:41 2011 DenUpdatedigital noisefirst order transition

In order to verify our theory about coherence corruption in linear systems due to the line

if((new_hist < 1e-20) && (new_hist > -1e-20)) new_hist = new_hist<0 ? -1e-20: 1e-20;  

in the /opt/rtcds/caltech/c1/core/release/src/include/drv/fm10Gen.c in the iir_filter function I've changed -20 to other numbers and watched at the coherence input and output of the digital filter cheby1("LowPass", 3, 0.1, 0.5)cheby1("LowPass", 6, 1, 1.5). The sampling rate was 2K. The frequency responce of the filter presented in this figure.

freqz.pdf

The next plot shows psd and coherence of the signal for different numbers in the if-statement line : 1e-20 , 1e-25, 1e-100.

 trans.pdf

We can see that for present value coherence between input and output signals is small even for low frequencies. The psd of the output signal is also corrupted because at low frequencies it should have the same psd as input signal. For 1e-25 and 1e-100 we can see that coherence is close to 1 at low frequencies so if-statement does not work and we have a first order transition from bad to good filter performance with discontinious jump of coherence.

However, for 1e-25 and 1e-100 data is still corrupted by the round-off error. Lack of coherence for high frequencies can be explained by the fact that dtt tools use single precision for data analysis and output is too small to plot a right coherence. But the coherence is also not precisely 1 for low frequencies. Actually, it is 0.99 for this aggresive filter. We use double precision in the real-time code but still for such kinds of filters round-off error is present. As wrote Daniel Sigg for Cheby filter:  "You need a lot more digits than you may naively suspect. In the 8th order example, the output of each SOS is amplified by ~106. This regardless of the fact that the coefficients are all of order 1. If you require a level of 10-3 attenuation in the stop band, you would have lost 9 digits already. Then, add the fact that you have to do of order 104 subtractions to get from 16kHz to 12Hz, loosing another ~2 digits. On top, the high Q section is probably 10 worse than the others and you lost 12 digits. In a real example this may stack up even worse."

Next we need to figure out what effects does round-off error introduce in the performance of the interferometer.

  6062   Fri Dec 2 17:43:46 2011 ranaUpdatedigital noiseFoton error

It would be useful to see some plots so we could figure out exactly what magnitude and phase error correspond to "gross" and "miserable".

  6061   Thu Dec 1 18:30:39 2011 Vladimir, DenUpdatedigital noiseFoton error

Foton Matlab Error     

We investigated some more the discrepancy between Matlab and Foton numbers. The comparison of cheby1(k, 1, 2*12/16384) was done between versions implemented in Matlab, R and Octave. Filters created by R and Octave agree with Foton.

Also, we found that Matlab has gross precision errors for cutoff frequencies just smaller than used in our fitler, for example cheby1(6, 2*3/16384) fails miserably.

  6060   Thu Dec 1 17:33:18 2011 kiwamuUpdateSUSwatchdogs fixed

The watchdogs' issue has been solved and they are now working fine.

It was just because one of the Sorensens had been off.

The Sorensen is the one supplying +5 V in the 1X5 rack.
This +5 V is actually used as a pull-up-current to properly drive the MAX333As (CMOS analog switch) in the coil drivers (D010001).
So this was it.

Quote from #6010

Tonight we noticed that, in fact, the watchdogs don't work for any of the corner optics (I confirmed that they do work for the ETMs).

  6059   Thu Dec 1 12:27:51 2011 ZachMetaphysicsRF SystemRAM diagnosis/suppression plan?

It seems like there is some confusion---or disagreement---amongst the lab about how to proceed with the RAM work (as Rana mentioned at the TAC meeting, we will henceforth refer to it only as "RAM" and never as "RFAM"; those who refuse to follow this protocol will be taken out back and shot).

I would like to provide a rough outline and then request that people reply with comments, so that we can get a collective picture of how this should work. I have divided this into two sections: 1) Methodology, which is concerned with the overall goal of the testing and the procedure for meeting them, and 2) General Issues, which are broadly important regardless of the chosen methodology.

1. Methodology

There are two broad goals:

  • Characterization of extant RAM
    • Measuring the RAM levels existing in an aLIGO-type interferometer without any suppression systems
    • Modeling to estimate the effect on IFO control and corroboration with measurements where possible
      • DC RAM levels contributing offsets to IFO operating point
      • Quasi-DC RAM levels affecting long term detector tuning (e.g., sensing matrix, MICH -> DARM feedforward, etc.)
      • Audio-frequency RAM contributing noise directly via error point modulation
    • Modeling to scale/adapt results from 40m -> aLIGO
  • Mitigation
    • Developing and assessing systems for suppressing RAM
      • Passive: thermal shielding and isolation
      • Active: EOM temperature control
        • Simple temperature stabilization
        • RAM error signal

The question is: which is our goal? The first, the second, or both? If both, what priority is given to which and can/should they be done in parallel? Also, task distribution.

 

2. General Issues

These are loosely related, so they are in random order:

  • Sensing
    • Temperature
      • What is the priority/urgency of a precision AC-bridge-readout temperature sensor?
      • If priority/urgency is low, what is the priority/urgency of upgrading breadboard controller to protoboard version? The common answer will be "make the protoboard version now", but if the urgency of the final AC sensing is high, it may make sense to focus on finalizing that design (after all, other experiments are waiting on a precision temperature controller, and it is not cost-effective to make many temporary controllers as I have done for the 40m).
      • Sensor noise issues
        • What is the sensor-noise-limited temperature stabilization level?
        • What is our willingness to tolerate the thermal low-passing of the EOM can itself (i.e., what is our sensitivity to gradients)?
        • To answer the above questions, we need to perform stabilization tests with several sensors on the same can, with some in loop (averaged) and some out of loop.
        • If we determine that gradients are a problem, we may need to:
          • Design a casing for outside the EOM (inside the foam box) to make the heating uniform, or
          • We may be able to get away with a more customized heater (instead of heating the can from one side as we do now).
    • Optical RAM
      • Stochmon is a nice diagnostic tool, but do we want something better? In particular, we want to have linear signals about a zero-DC-RAM point, which requires phase
        • Where will this sensor be located?
        • What kind of PD will it be? Broadband? Multi-resonant?
        • What sort of electronics will we need? If we are going to use this as an error signal for controlling the EOM temperature, it is just as important as any other IFO readout, since it may couple into all of them.
          • RF pickup is a BIG ISSUE HERE
          • How will the demodulation phases be selected? It should be possible to take TF measurements in certain misaligned (i.e., non-resonant) conditions and adjust the relative phase between the RAM readouts and standard IFO RF readouts such that they are in phase, but this will require some thinking.
          • Lots more, I'm sure
  • Control
    • Method (overlaps some with methodology portion)
      • What is better, simple temperature stabilization or RAM feeback? (More likely, "how much better is RAM feedback?")
      • If RAM feedback is difficult or impossible to implement effectively (see below), is temperature stabilization good enough?
    • Regime
      • Depending on extant RAM levels and on achievable sensing noise, it will be unwise and/or unnecessary to have a RAM control bandwidth above some relatively low frequency (~sub Hz)
        • Gain where RAM suppression is not needed only injects noise into the system
        • This cutoff frequency is largely determined by the thermal response of the system, but additional filtering will likely be necessary to reduce higher-frequency noise coupling (e.g., nonlinear downconversion of high-frequency signals into heater dissipation, etc.)
    • Efficacy
      • If we do RAM feedback, which signal (i.e. which frequency and quadrature) do we minimize?
        • Do we achieve large common-mode reduction across all RF signals, or is there some differential component?
        • In particular, do we make some or all other control signals noisier by stabilizing/minimizing RAM in one channel?
        • If the answer is yes, can we derive an effective control signal from a linear combination of some or all individual RAM signals?

 

There are probably many other issues I have neglected, so please comment on this rough draft as you see fit!

  6058   Thu Dec 1 11:25:10 2011 steveUpdatePEM40m infrastructure holds up well in strong wind condition

 Santa Anna wind speed was locked around 60 kmph last night on campus. The strongest in 30 years.  The lab hold up well. We did not lose  AC power either.

Threes and windows were blown out and  over on campus.

We have 4 sliding glass windows without "heavy-laser proved" inside protection.

We should plan to upgrade ALL  sliding glass windows with metal protection from the inside.The strongest in 30 years.

Attachment 1: santaannawind.png
santaannawind.png
Attachment 2: wind.png
wind.png
  6057   Thu Dec 1 03:27:39 2011 MirkoUpdateSUSNot adaptive, still cool

Quote:

[Rana, Mirko]

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

The result is pretty awesome!

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

PendulumQ0.1HzWithElip2comma5HzLpWfsOnCorrectedShape.pdf

Filter shape:

VirtualPendulumFilterShape.pdf

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

 

 

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

  6056   Thu Dec 1 01:24:56 2011 JenneUpdateRF SystemEOM temp stabilization at PSL lab

[Frank, Jenne]

Activities in a far, far away land called PSL lab...

EOM_Temp_stab_30Nov2011.png

We are looking at the RFAM from the detuned ACAV refl pd in the red trace.  Red trace is the demodulated RFAM output.  RCAV was locked, so on a ~min time scale the freq drift follows, so we stay detuned. 

Heater and temp sensor are taped to EOM, no foam box.

Around when the red trace starts, we turn on the heater to stabilize the temp.  After a while we reach the set point (no longer railing the heater), and start seeing temp stabilization.  The RFAM fluctuations clearly go down.  Neato. 

No calibrations, no RIN, no nothing.  Get over it.

Green trace is the DC level of a different PD, which should also be sensitive to RFAM.

This is using a fancy-pants temp controller chip that Frank found.  It works, so that's handy.

  6055   Wed Nov 30 22:09:20 2011 ZachUpdateRF Systemsome final EOM stabilization efforts

First, things that were done:

  • I was troubled by the odd-looking noise in the EOM temperature signal, so I investigated the circuit with a probe and found that there was quite a bit of line pickup, which I traced to the wires going to and from the RTD (if I placed a dummy resistor directly on the board, it went down markedly).
    • I put a 3-Hz RC LPF between the AD620 and the driver input buffer, which reduced the line noise significantly
    • The error signal looks much cleaner and there are no longer strong peaks in the error spectrum at ~1+ Hz and harmonics
  • I had tried earlier to increase the gain of the servo at the driver input stage. It seemed to stay stable. Since I knew the error signal  with the loop closed was at the level of the ADC noise, I decided to push my luck with increasing the servo gain and juice up the AD620 gain from 100 to 990.
    • The servo stayed stable and the error signal level is now manageable.

Things that I noticed:

  • With the latest increase in gain, I measured that the error signal was suppressed with the loop closed (the suppression is below ~0.1 Hz, and the reason that the high-frequency level is different is because it has been amplified above the ADC noise by the time of the second trace).

 EOM_temp_stab_and_unstab_new_11_30_11.pdf

  • Despite the above, the Stochmon signals remained unchanged no matter what I did. I noticed that the Stochmon signals, too, were fluctuating basically at bit-level. I terminated the 11-MHz signal and compared it to the normal level---it is not exactly the same, but only a factor of 2-3 lower, which is not great. Of course, the RMS detector is logarithmic, but I think we still want the dark noise to be at least an order of magnitude lower here.
    • I tried to amplify the signal with an SR560, but since the DC level is supposed to be ~1-2 V, I could only get about 2x gain---not enough.

 11MHz_wandwo_ctrl_and_adc_noise_11_30_11.pdf

Conclusion

I think there are two things that could be happening here, given the above information:

  1. We are limited by the noise of the temperature sensing circuit, which would explain why the in-loop error signal is suppressed while the RAM levels appear not to be. This should be easy enough to test (though there's not enough time right now) with an out-of-loop sensor.
  2. The RAM is not dominated by temperature noise here. With the loop open, one would expect to see coherence between the RAM signal and the temperature sensor, if indeed one was the cause of the other. Instead, we see that---while the 11- and 55-MHz signals ARE pretty coherent with each other---there is no appreciable coherence between the temperature and the Stochmon signal.
  6054   Wed Nov 30 14:12:53 2011 JenneUpdateRF SystemNew EOM mount almost ready

The new EOM adapter plate and riser just got back from the shop.  I just had Mike do the milling, and I'll drill and tap them tomorrow after the TAC.  Then we can remount the EOM to see if stiffening the mount helps at all.

  6053   Wed Nov 30 13:52:09 2011 ZachUpdateRF SystemEOM temp stabilization ineffectual

This recent off/on run proved what I was afraid of: the temperature stabilization setup appears to do nothing except very near DC. The plot that Kiwamu posted is misleading because the "uncontrolled" data stretch at the beginning actually had the heater injecting random noise (since the circuit was broken). Below are some plots (sorry in advance for their crappiness---the plot tools wouldn't let me print to file for some reason):

Time series of the temp monitor, the heater monitor, and the 11- and 55-MHz RFAM monitors. The heater was disconnected at ~2:20 UTC, and the temperature is seen to equalize to the surroundings (note that the TEMP_MON is inverted, so positive change means decreasing temperature). The heater was reconnected by Kiwamu around 10:40 UTC, and you can see the temperature being driven back to the zero point by the loop. Note that the temperature was still decreasing at a fair rate when the heater is re-engaged---this could mean that we really need to take longer samples.

Screen_shot_2011-11-30_at_1.31.44_PM.png

 

Spectra and coherence of the 11- and 55-MHz RFAM monitors before and after the control was re-engaged. It appears that the 11-MHz signal is unaffected while the 55-MHz signal actually gets worse. This also seems evident from the noisiness in the time series for that signal above (top right). Bad, bad, bad. 

Screen_shot_2011-11-30_at_1.29.48_PM.png

 

Spectrum of the EOM temperature signal before and after control was re-engaged. There seems to be no change whatsoever. Of course, as mentioned before, this signal seems to be close to the digitization noise level as seen in DV. I am not sure what the ADC noise looks like at these low frequencies. In case someone knows, the magnitude of this signal in counts is ~0.1 ct/rHz at 10 mHz; is this too low? Another thing to note is that the noise level in K is pretty low! I would be surprised if the RTD can really see 10 uK/rHz at and below 10 mHz.

 

Screen_shot_2011-11-30_at_1.21.16_PM.png

 

I need to try and increase the gain of the servo to see if I can get it much higher without it becoming unstable.

  6052   Wed Nov 30 11:36:12 2011 DenUpdateCDSFiltering Noise issue tracked down ???

Quote:

 if((new_hist < 1e-20) && (new_hist > -1e-20)) new_hist = new_hist<0 ? -1e-20: 1e-20;

20 is indeed a random number. We can change it to 300. Alex said that during that iir filter calculations sometimes numbers are very small and if they are less then 1e-308 then a very slow code in the processor is executed and this will crash the online system. For single precision this number is 1e-38 and may be 10 years ago it was not decided for sure what to use - float or double. 20 will be "OK" for both but as we can see causes other problems.

Anyway, Alex removed this line from the code and added another code that sets the two proper bits in the MXCSR register and prohibits to the CPU to run the slow code. As far as I understand if the numbers are less then 1e-308 they become 0. Roughly, this is equivalent to 

 if((new_hist < 1e-308) && (new_hist > -1e-308)) new_hist = 0;

This is in 2.4 release. It is in the svn. I think we can install it and figure out if the problem is gone.

 

  6051   Wed Nov 30 11:04:26 2011 josephbUpdateCDSFiltering Noise issue tracked down ???

Quote:

For now, I suppose we can just change this number to 1e-40 or so. I don't know how to calculate what the right number should be. Not sure why this underflow is not an issue for the BiQuad, however.

According to the RCG SVN logs, the reason it was removed was a more general change done to the compiled code, not specific to just the biquad.  Basically, the ability to have an underflow number (subnormal) has been turned off completely by having any number that underflows set to zero. I'm not positive, but from a quick search looks that the smallest number before hitting is an underflow as a double is 2.2250738585072014e-308.

Alex's entry from the SVN log for 2663:

Added new fz_daz() function to turn on two bits in the FPU SSE control register.
Bits FZ (flush underflows to zero) and DOZ (denorms are zeros) are set to
avoid runaway code on float/double denorms (really small numbers).
Ref: http://software.intel.com/en-us/articles/how-to-avoid-performance-penalties-for-gradual-underflow-behavior/

SVN log 2664:

Removed +- 1e-20 limiting code, this is taken care of by setting FZ/DOZ bits
in the CPU SEE control register (see mathInline.h)

SVN log 2665:

Kill the underflows and roll down float denorms to zero,
see fz_doz() in mathInline.h.

  6050   Wed Nov 30 03:01:55 2011 kiwamuUpdateRF SystemRFAM fluctuation reduced

Okay I have turned ON the temperature control at 2:40 AM and will leave it ON for a while.

Quote from #6047

I was hesitant to claim that this is definitely true without the control data we were taking after the heater was turned off today. This is because before I replaced the malfunctioning op amp last night, the heater was actually ON and injecting temperature noise into the system that would not be there with it off. I think the best idea is to compare the data from today (heater on vs. heater off, but with functioning circuit).

 

  6049   Wed Nov 30 02:04:26 2011 rana, den, jenne, kiwamu, jzweizigUpdateCDSFiltering Noise issue tracked down ???

 You can read through all of our past tests to see what didn't work in tracking things down. As Den mentions, there was actually a lot of evidence that there was some double->single precision action in the filter calculation causing the noise we saw.

However, it turns out that this is NOT the case.

This afternoon I was so confused that I enlisted JZ to help us out. He came over and I tried to replicate the error. When looking at the time series, we noticed that it wasn't random noise; the signals seem to be getting clipped as they crossed zero. Sort of like a stiction problem. JZ left to go replicate the error on an offline system.

This turned out to be the important clue. As we examine the code we find this inside of fm10Gen.c:

if((new_hist < 1e-20) && (new_hist > -1e-20)) new_hist = new_hist<0 ? -1e-20: 1e-20;

this is line is basically trapping the filter history at 1e-20, to prevent some kind of numerical underflow problem (?). Seems reasonable, except that some filters which have higher order low passing in them actually have an overall scale factor which can be small (even as small as 1e-23, as Den pointed out).

So the reason we saw such weird behavior is that the first filter in SUSPOS is an AC coupling filter. This takes the OSEM signal and remove the large mean value. Then the next filter multiplies it by 1e-23 before doing the filtering and you end up with this noise in the filter history.

I looked and this line is commented out in the new BiQuad code, but as far as I can tell this issue has been around in aLIGO, eLIGO, iLIGO, etc. for a long time and could have been causing many cases of excess noise whenever we ended up a tiny gain factor in an IIR filter. At the 40m, there are easily a hundred such cases.

For now, I suppose we can just change this number to 1e-40 or so. I don't know how to calculate what the right number should be. Not sure why this underflow is not an issue for the BiQuad, however.

  6048   Wed Nov 30 01:35:49 2011 JenneUpdateCDSOSEM noise / nullstream and what does it mean for satellites

I'm picking points off of this no-magnet OSEM plot, and I thought I'd write them down somewhere so I don't have to do it again when I lose my sticky note...

1e-2 Hz        1.05e-2 um/rtHz

1e-1 Hz        3.4e-3 um/rtHz

1 Hz            1.3e-3 um/rtHz

10 Hz          2.5e-4 um/rtHz

60 Hz          7.5e-5 um/rtHz

100 Hz        7e-5 um/rtHz

400 Hz        7e-5 um/rtHz

  6047   Tue Nov 29 23:03:34 2011 ZachUpdateRF SystemRFAM fluctuation reduced

I was hesitant to claim that this is definitely true without the control data we were taking after the heater was turned off today. This is because before I replaced the malfunctioning op amp last night, the heater was actually ON and injecting temperature noise into the system that would not be there with it off. I think the best idea is to compare the data from today (heater on vs. heater off, but with functioning circuit).

Quote:

 

Indeed the fluctuation of the RFAM became quieter with the temperature control ON.

  6046   Tue Nov 29 22:54:49 2011 DenUpdatedigital noisesingle precision

 In the previous elog we've proved that signals C1:SUS-MC3_LSC_EXCMON and  C1:SUS-MC3_LSC_OUTMON are in single precision. Now we try to understand if the precision is lost when the signals enter dtt tools or in the online code. For this measurement we just switch on one of the filters between the signals. By this we add mathematical operations inside the online code. If double precision is used there, then we'll see the same error as before, because the real error is still very small (~10-15) and dtt tools add this 10-7 error. But if the digital error will increase then no matter what kind of precision use dtt, online code uses single precision. At least at some points.

Test 1.   cheby1("LowPass",6,1,12) 

filter_coherence.jpg

 

Test 2.  cheby1("Lowpass",2,0.1,3)

chby1_coherence.jpg

 Test 3. butter("LowPass",8,10)

butter8_coherence.jpg

Test 4.  butter("LowPass",2,10)

butter2_coherence.jpg

We can see that coherence become worse. And longer filter - more digital error. This means that single precision is used in calculations.

 

  6045   Tue Nov 29 22:19:26 2011 DenUpdatedigital noisestraight line

 I tried to understand what part of the signal is corrupted while passing through a digital straight line without any filters. From here we can figure out what precision is used.

I analysed coherence between C1:SUS-MC3_LSC_EXCMON and C1:SUS-MC3_LSC_OUTMON without any filters between them. 

real_coherence.jpg

I did the simulation in Matlab using single and double precision. Basically, I took a random signal, made some operations with it to obtain some digital error:

signal1 = randn(1e6, 1);          signal2 = randn(1e6, 1);         signal3 = signal1+signal2;          signal4 = signal3 - signal2;

Then I plotted coherence between signal1 and signal4 that are actually the same signal but signal4 has some digital error. This was done both for single (left red plot) and double (right blue plot) precision.

float_coherence.jpg        double_coherence.jpg

From here we make a conclusion that C1:SUS-MC3_LSC_EXCMON and C1:SUS-MC3_LSC_OUTMON has single precision. The signal might be converted from double to single in the dtt tools but if dtt works with double precision then the problem is with signals.

  6044   Tue Nov 29 22:10:18 2011 kiwamuUpdateRF SystemRFAM fluctuation reduced

Quote from #6035

I left the EOM stabilization running overnight, so we can finally see how the EOM temperature stabilization does over long periods of time.

The controller was turned on at ~8:40 UTC, and you can see that the Stochmon signals quiet down a lot right at that time. 

Indeed the fluctuation of the RFAM became quieter with the temperature control ON.

However the absolute value of the RFAMs stayed at relatively high value.

I guess we should be able to set the right temperature setpoint such that the absolute value of the RFAM is smaller.

Here is the calibrated RFAM data (for 5 hours around the time when Zach activated the temperature control last night):

RFAM_withEOMheater_edit.png

  6043   Tue Nov 29 19:08:53 2011 ZachUpdateRF SystemEOM heater disconnected

I disconnected the heater at ~2:20 UTC, leaving the sensor circuit operational. Don't be fooled by the apparent railing of the heater in the monitor trace below---the heater has been physically disconnected, so there is no current flowing even though the servo is railed (since the error signal is huge with the loop open).

Kiwamu and I also restarted c1sus and locked the MC so that we can get some uncontrolled Stochmon data. I think he is planning to reconnect the heater some hours from now so that we can get yet another controlled data stretch (since the first one was cut short by c1sus's going down).

Screen_shot_2011-11-29_at_7.03.36_PM.png

  6042   Tue Nov 29 18:54:29 2011 kiwamuUpdateCDSc1sus machine up

[Zach / Kiwamu]

 Woke up the c1sus machine in order to lock PSL to MC so that we can observe the effect of not having the EOM heater.

  6041   Tue Nov 29 18:31:40 2011 DenUpdatedigital noiseFoton error

 In the previous elog we've compared Matlab and Foton SOS representations using low-order filter. Now we move on to high order filters and see that Foton is pretty bad here.

We consider Chebyshev filter of the first type with cuf off frequency 12 Hz and ripple 1 dB. In the table below we summarize the GAINS obtained by Matlab and Foton for different digital filter orders.

Order Matlab Foton
2 5.1892960e-06 5.1892960e-06
4 6.8709377e-12 6.8709378e-12
6 5.4523201e-16 9.0950127e-18
8 5.3879305e-21 1.2038559e-23

 

 

 

 

 

We can see that for high orders the gains are completely different (ORDER of 2!!!). Interesting that besides of very bad GAIN, SOS-MATRIX Foton calculates pretty well. I checked up to 5 digit - full coincidence. Only GAIN is very bad.

The filter considered is cheby1("LowPass",6,1,12) and is a part of the bad Cheby filter where we loose coherence and see some other strange things.

  6040   Tue Nov 29 18:17:27 2011 ZachUpdateRF SystemEOM temp stabilization performance

Quote:

 It is not obvious what is working.

 

It should be. As I mentioned, you can only trust the Stochmon signals between 0840 and 1130 UTC; before this time, the temperature controller was not connected, and after this time, c1sus is shut down and the MC is not locked, as you can see in your DV plot.

Within this time frame, the Stochmon signals are relatively stabilized (though there is some residual common-mode-ish drift since we are not using RFAM as the error signal---i.e., other things like laser power and frequency can mix in). Also, anytime after 0840, the controller signals behave as they should (these are unaffected by the status of c1sus):

  • The EOM temperature signal (error signal) is stabilized to a value very near zero
  • The heater drive signal (control signal) moves around in such a way as to null the error signal, and you can confirm that it looks roughly like the opposite of the FSS_RMTEMP signal, as it should.

I am concerned with the other issues that I mentioned in my previous post, namely:

  1. Error signal dominated by digitization noise above some low frequency despite 100x amplification
  2. Strange ~0.01-Hz level disturbances in error signal.
  6039   Tue Nov 29 17:10:39 2011 DenUpdatedigital noiseSOS creation

One of the possibilities that we see a large low-frequency digital noise is due to Foton. I've checked the SOS coefficients that saves Foton with a Matlab coefficients. I used a 3 order low-pass cheby1 filter cheby1("LowPass",3,0.1,3) 

In matlab I generated SOS model using 3 approaches 


[A,B,C,D]=cheby1(3,0.1,3/1024) % create SS form

[sos,g]=ss2sos(A,B,C,D)  % convert to SOS form


[z, p, k]=cheby1(3,0.1,3/1024) % create ZPK form

[sos,g]=zp2sos(z,p,k)  % convert to SOS form


[b, a]=cheby1(3,0.1,3/1024) % create TF form

[sos,g]=tf2sos(b,a)  % convert to SOS form


As this is a 3 order filter, in the SOS representation we'll get 2 by 6 SOS - matrix. It is presented below. In each matrix place there 4 numbers - from the Foton file and obtained using these 3 methods.

GAIN

1.582261654653329e-07

1.582261654653329e-07

1.582261654653329e-07

1.582261655030947e-07

SOS-MATRIX

1              1.0000000000000000      #           0                                              #       1      #         -0.9911172660954457     #       0

1              1.0005663179617605      #           0                                              #       1      #         -0.9911172660954457     #       0

1              1.0000000000000000      #           0                                              #       1      #         -0.9911172660954457     #       0

1              0.9999894976396830      #           0                                              #       1      #         -0.9911172660997303     #       0

############################################################################################################

1              2.0000000000000000      #          1.0000000000000000         #       1      #        -1.9909750803252266      #      0.9911175825477769

1              1.9994336820732397      #          0.9994340026283055         #      1       #       -1.9909750803252262       #     0.9911175825477765

1              2.0000000000000000      #          1.0000000000000000         #      1       #       -1.9909750803252262       #     0.9911175825477765

1              2.0000105023603174      #          1.0000105024706190         #      1       #       -1.9909750803209423       #     0.9911175825434912

 

It seems that smth analog to zp2sos is used in Foton. We can see that due to representation error we have derivations in the 4 and 6 digits for SS and TF forms. This means that a pretty big mistake can run due to digital transforms even using double precision as in the Matlab test.

Alex Ivanov said that he'll fix that single precision problem and in the 2.5 release we won't have any FLOAT variables. Though we still do not understand how that variables declared as FLOAT can cause filter calculations. 

  6038   Tue Nov 29 15:57:43 2011 DenUpdateCDSlocation of currently used filter function

 

We are interested in the following question : Can the structures defined in fm10Gen.h (or some other *.c *.h files with defined as FLOAT variables) create single precision instead of double in the filter calculations?

 

typedef struct FM_OP_IN{
  UINT32 opSwitchE;     /* Epics Switch Control Register; 28/32 bits used*/
  UINT32 opSwitchP;     /* PIII Switch Control Register; 28/32 bits used*/
  UINT32 rset;          /* reset switches */
  float offset;         /* signal offset */
  float outgain;        /* module gain */
  float limiter;        /* used to limit the filter output to +/- limit val */
  int rmpcmp[FILTERS];  /* ramp counts: ramps on a filter for type 2 output*/
                        /* comparison limit: compare limit for type 3 output*/
                        /* not used for type 1 output filter */
  int timeout[FILTERS]; /* used to timeout wait in type 3 output filter */
  int cnt[FILTERS];     /* used to keep track of up and down cnt of rmpcmp */
                        /* should be initialized to zero */
  float gain_ramp_time; /* gain change ramping time in seconds */
} FM_OP_IN;  

 

  6037   Tue Nov 29 15:30:01 2011 jamieUpdateCDSlocation of currently used filter function

So I tracked down where the currently-used filter function code is defined (the following is all relative to /opt/rtcds/caltech/c1/core/release):

Looking at one of the generated front-end C source codes (src/fe/c1lsc/c1lsc.c) it looks like the relevant filter function is:

filterModuleD()

which is defined in:

src/include/drv/fm10Gen.c

and an associated header file is:

src/include/fm10Gen.h
  6036   Tue Nov 29 15:25:29 2011 steveUpdateRF SystemEOM temp stabilization performance

 It is not obvious what is working.

 

Attachment 1: 2days.png
2days.png
  6035   Tue Nov 29 14:22:03 2011 ZachUpdateRF SystemEOM temp stabilization performance

I left the EOM stabilization running overnight, so we can finally see how the EOM temperature stabilization does over long periods of time.

Here are both long-term (~13-hr) and short-term (1-hr) trends of the EOM temperature and the heater drive level. From the long trend you can see that the heater departed the steady value of ~7.8V that I observed last night to accommodate the diurnal heating of the lab in the morning---the temperature was held near zero offset.

From the short-term trend, there are 2 things to notice:

  1. We are still very close to the digitization noise level for both signals. This is bad, because we want to look at the residual noise level, etc.
  2. There appears to be some strange sort of disturbance of f~0.01-0.02 Hz. I'm not sure what causes the strange shape

Screen_shot_2011-11-29_at_1.33.50_PM.png Screen_shot_2011-11-29_at_1.34.06_PM.png

 

Finally, here is a trend over the last ~24 hours of the EOM temperature, heater drive level, and the 11- and 55-MHz Stochmon signals. I believe that the abrupt shelves noticeable on the Stochmon trends are when c1sus was turned on and shut down, respectively (I'm not sure why that causes the signals to die, but the times seem right, and nothing obvious happens to the EOM temp stabilization signals at either time). The controller was turned on at ~8:40 UTC, and you can see that the Stochmon signals quiet down a lot right at that time. There is some residual drift (common-mode to both RF frequencies), which is most likely caused by a drift in some other parameter (e.g. laser frequency or power).

Screen_shot_2011-11-29_at_1.41.03_PM.png

I took some relatively inconclusive power spectra and coherence measurements, but I'd rather wait until we have an uncontrolled data stretch with which to compare. I think what we should do now is disconnect the controller and then let it sit for a while.

 

  6034   Tue Nov 29 07:45:56 2011 rana, joshSummaryComputer Scripts / Programs40m Daily News web pages

 As part of the initiative to get a good daily summary page for aLIGO commissioning, Josh is spearheading his Detector Characterization group to produce such web pages for the 40m.

They're starting out with this launching point and then we can add all kinds of other information and plots as we want (e.g. Vac, PEM, Weather, coffee status). If you have suggestions/ideas, just edit this entry and add them, or email Josh directly.

  6033   Tue Nov 29 04:47:49 2011 kiwamuUpdateCDSc1sus shut down again

I have shut down the c1sus machine at 3:30 AM.

  6032   Tue Nov 29 02:09:15 2011 ZachUpdateRF SystemEOM temp stabilization fixed

I inspected the temperature stabilization circuit today to see why it wasn't working. It didn't make sense that it just kept railing the heater even though the error signal was negative (which should turn the heater current OFF).

It turns out that the LF356 (FET-input op amp) that serves as the filter stage for the heater driver was broken---I measured a full, railed positive output even though the input was negative. We didn't have any more LF356s, so I replaced it with an OPA604 (Burr-Brown FET-input), and all seemed to work fine.

Since we were having too much digitization noise, I also added a temperature monitor buffer using a non-inverting OP27 circuit with G=99. This makes the overall calibration ~7.6 V/K into the ADC.

Below is a time series showing that it is working. The circuit was turned on near the beginning, and you can see that the heater is railed at +10V until shortly after the error signal goes negative, at which point it adjusts and ultimately approaches a steady-state value of ~7.8V.

EOM_temp.png

I have no figures to demonstrate this, but it seems that even with this 100x increase in monitor gain, the error signal is still below the ADC noise level. This could be because the ambient temperature fluctuations are just that small on timescales of less than a few hours. I'm not sure if we really need to be able to see the temperature noise level above a few mHz, but if we do we will have to find some way to increase our dynamic readout range. 

Also, Koji told me where he stashed the nice protoboards, so I will get onto transferring this circuit onto one ASAP. Since it is working now, I think I'll leave it until after the TAC.

  6031   Mon Nov 28 22:09:24 2011 ranaUpdateCDSBeware of fancy filter modules

To see what might be causing the problem, I used a version of the filter noise test matlab code that Matt had in the elog.

To see if it was a single precision problem, I just recast the input data:   x = single(x)

This is not strictly correct, since some of the rest of the operations are as double precision, but I think that attached plot shows that a casting from double to single is close to the right amount of noise to explain our excess noise problem in the 0.1-1 Hz region.

Den is going to interview Alex to find out if we have some kind of issue like this. My understanding was that all of our filter module calculations were being done in double precision (64 bit), but its possible that some single stuff has crept back in. Currently the FIR filtering code IS single precision and in the past, the SUS code which didn't carry the LSC signals (meaning ASC and damping) were done in single precision.

Attachment 1: noise.pdf
noise.pdf
  6030   Mon Nov 28 19:24:51 2011 JenneUpdateCDSBeware of fancy filter modules

[Rana, Jenne]

Some of the funniness is some kind of mysterious interaction between 2 filter modules in the filter banks.  Just FM1 (30:0.0) or just FM4 (Cheby, which is 2 cheby1's) has reasonable coherence.  Both FM1 and FM4 together doesn't do so well - the coherence goes way down.

Just FM1 (30:0.0)

SUSPOS_ETMY_30and0_measured_vs_idealTF.pdf

Just FM4 (Cheby)

SUSPOS_ETMY_Cheby_measured_vs_idealTF.pdf

 Both FM1 and FM4

SUSPOS_ETMY_30and0andCheby_measured_vs_idealTF.pdf

 All the coherences plotted together

SUSPOS_ETMY_30and0andCheby_compareCoherence.pdf

You'd think that the signal encounters FM1, gets filtered, and that result is the signal sent to the next active filter module, FM4, so the 2 filter modules shouldn't interact.  But clearly there's some funny business here since engaging both makes things crappy. 

Matlab investigations to replicate this behavior offline are in progress.

Attachment 4: SUSPOS_ETMY_30and0andCheby_compareCoherence.pdf
SUSPOS_ETMY_30and0andCheby_compareCoherence.pdf
  6029   Mon Nov 28 18:53:35 2011 DenSummaryWienerFilteringseismic noise substraction

There is still a problem why GUR, STS signals are poorly coherent to MC_L.  But at least we can see coherence at 2-5 Hz. It might be useful to do something with adaptive filtering because it does not work at all for a long time. We start with Wiener filtering. I still doubt that static filtering is useful. Adaptive filter output is linear to its coefficients, so why not to provide adaptive filter with a zero approximation equal to calculated Wiener filter coefficients. Then you automatically have Wiener filter ouput + adaptively control coefficients. But if Wiener filter is already present in the model, I tried to make it work. Then we can compare performance of the OAF with static filter and without it.

I started with GUR1_X and MC_F signals recorded 1 month ago to figure out how stable TF is. Will the same coefficients work now online? In the plot below offline Wiener filtering is presented.

gur1_x.jpg

 

This offline filtering was done with 7500 coefficients. This FIR filter was converted to IIR filter with the following procedure:

1. Calculate frequency responce of the filter. It is presented below.

filter_response.jpg

2. Multiply this frequency response by a window function. This we need because we are interested in frequencies 0.1-20 Hz at this moment. We want this function to be > 1e-3 at ~0Hz, so that the DC component is filtered out from seismometer signal. From the other hand we also do not want huge signal at high frequenies. We know that this signal will be filtered with aggresive low-pass filterd before going to the actuator but still we want to make sure that this signal is not very big to be filtered out by the low-pass filter.

The window function is done in the way to be a differential function to be easier fitted by the vectfit3. Function is equal to 1 for 0.5 - 20 Hz and 1e-5 for other frequencies except neighbouring to the 0.5 and 20 where the function is cosine.

window.jpg

3. I've used vectfit3 software to approximate the product of the frequency response of the filter and window fucntion with the rational function. I've used 10 complex conjugate poles. The function was weighted in the way to make deviation as small as possible for interesting frequencies 0.5 - 10 Hz. The approximation error is big below 20 Hz where the window function is 1e-5 but at least obtained rational function does not increase as real function do at high frequencies.

filter_fitting.jpg

I tried to make a foton filter out of this approximation but it turns out that this filter is too large for it. Probably there is other problem with this approximation but once I've split the filter into 2 separate filters foton saved it. Wiener21 and Wiener22 filters are in the C1OAF.txt STATIC_STATMTX_8_8 model.

I've tested how the function was approximated. For this purpose I've downloaded GUR and MC_F signals and filtered GUR singla with rational approximation of the Wiener filter frequency response. From power spectral density and coherence plots presented below we can say that approximation is reasonable.

zpk_wiener.jpgzpk_wiener_coh.jpg

Next, I've approximated the actuator TF and inverted it. If TF measured in p. 5900 is correct then below presented its  rational approximation. We can see deviation at high frequencies - that's because I used small weights there using approximation - anyway this will not pass through 28 Hz low-pass filter before the actuator.

 actuator_fitting.jpg

I've inverted this TF p->z , z->p, k->1/k. I've also added "-" sign before 1/k because we subtract the signal, not add it. I placed this filter 0.5Actuator20 to the C1OAF.txt SUS-MC2_OUT filter bank.

The next plot compares online measured MC_L without static filtering and with it. Blue line - with online Wiener filtering, red line - without Wiener filtering.

wiener_mcl-crop.pdf

We can see some subtraction in the MC_L due to the static Wiener filtering in the 2-5 Hz where we see coherence. It is not that good as offline but the effect is still present. Probably, we should measure the actuator TF more precisely. It seems that there some phase problems during the subtraction. Or may be digital noise is corrupting the signal. 

Attachment 4: filter_fitting.jpg
filter_fitting.jpg
  6028   Mon Nov 28 18:19:53 2011 kiwamuUpdateIOOStochmon seems working

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

RFAM_48hours.png

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

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

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

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

So it seems the StochMon is working fine.

Quote from #6009

 New RFAM mon calibration

  6027   Mon Nov 28 16:51:57 2011 kiwamuUpdateLSCmodulation frequency reset

I reset the modulation frequency to 11065910 Hz (#5530). It had been at 11065399 Hz probably since the power shut down.

  6026   Mon Nov 28 16:46:55 2011 kiwamuUpdateCDSc1sus is now up

I have restarted the c1sus machine and burt-restored c1sus and c1mcs to the day before Thank giving, namely 23rd of November.

Quote from #6020

I have restarted the c1sus machine around 9:00 PM yesterday and then shut it down around 4:00 AM this morning after a little bit of taking care of the interferometer.

  6025   Mon Nov 28 15:43:36 2011 steveUpdateRF SystemEOM temp zoomed

Quote:

Quote:

Here is 5 days of trend of the EOM temp sensor and the heater driver monitor.  Unfortunately, it looks like we're regularly railing the heater.  Not so awesome. 

Can you zoom the temp mon? (V= -0.1 ~ +0.1)
The crystal was too cold and I tried to heat the PSL table by the lighting. But it seemed in vain.

 It is not working

Attachment 1: eomtempmon.png
eomtempmon.png
ELOG V3.1.3-