40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 217 of 337  Not logged in ELOG logo
ID Date Author Type Category Subject
  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
  6024   Mon Nov 28 15:00:20 2011 kiwamuUpdateGreen LockingY arm ALS engaged
Quote from #5894

  However I couldn't close the ALS loop somehow.

 Locking activity last night:

  It became able to close the ALS loop (beat-note signal was fed back to ETMY).

The UGF was about 60 Hz, but somehow I couldn't bring the UGF higher than that.

Every time when I increased the UGF more than 60 Hz, the Y end PDH was unlocked (or maybe ETMY became crazy at first).

Perhaps it could be a too much noise injection above 60 Hz, since I was using the coarse frequency discriminator.

Anyway I will try a cavity sweep and the successive noise budgeting while holding the arm length by the beat-note signal.

Another thing : I need a temperature feedback in the Y end green PDH loop, so that the PZT voltage will be offloaded to the laser temperature.

  6023   Mon Nov 28 14:40:43 2011 KojiUpdateRF SystemEOM temp driver

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.

  6022   Mon Nov 28 14:27:35 2011 JenneUpdateRF SystemEOM temp driver

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. 

Attachment 1: EOM_temp_driver_3days.png
EOM_temp_driver_3days.png
  6021   Mon Nov 28 10:54:40 2011 ranaUpdateSUSF2A filter for MC

Our approach to making the F2A or F2P filters for the MC is to use the measured resonant frequencies and then calculating the appropriate mechanical dimensions of each suspension. This is basically because we don't have optical levers with normal incidence on these optics, but the method should be fine.

To find the formulas, I asked Gaby for her old cheat sheet: Its now in the DCC. Its only for Large optics, but you should be able to reconstruct the right ones for SOS by just changing the parameters.

  6020   Mon Nov 28 06:53:30 2011 kiwamuUpdateCDSc1sus shutdown

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

Quote from #6016

c1sus has been shutdown so that the optics dont bang around.  This is because the watch dogs are not working.

  6019   Sat Nov 26 19:37:12 2011 DenUpdateGeneralfoton files

 I've checked foton files for small numbers. There are several other filters besides "Cheby" that are presented with small numbers. For example, "BTW0.01" in the LOCKING_Q, LOCKING_I modules,  "SeisDaytime"  in the SUP_MC3_SP_NOISE and others. The output of the commands is presented below.

>chans

>cat C1???.txt | grep e-23

 

SUP_MC3_SP_Y_NOISE 2 12 4  16384      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC3_SP_YAW_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC3_SP_ROLL_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC3_SP_PIT_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC2_SP_Y_NOISE 2 12 4  16384      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC2_SP_YAW_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC2_SP_ROLL_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC2_SP_PIT_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC1_SP_Y_NOISE 2 12 4  16384      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC1_SP_YAW_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC1_SP_ROLL_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUP_MC1_SP_PIT_NOISE 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_MC3_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC3_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC3_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC3_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC3_LSC 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC2_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC2_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC2_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9978637592754149   0.9978663974923444   2.0000000000000000   1.0000000000000000

SUS_MC2_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC1_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC1_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_MC1_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_SRM_SUSYAW 3 12 4  32768      0 Cheby         1.1175580413719e-23    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000

SUS_SRM_SUSPOS 3 12 4  32768      0 Cheby         1.1175580413719e-23    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000

SUS_SRM_SUSPIT 3 12 4  32768      0 Cheby         1.1175580413719e-23    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000

SUS_PRM_SUSYAW 3 12 4  32768      0 Cheby         1.1175580413719e-23    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000

SUS_PRM_SUSPOS 3 12 4  32768      0 Cheby         1.1175580413719e-23    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000

SUS_PRM_SUSPIT 3 12 4  32768      0 Cheby         1.1175580413719e-23    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000

SUS_ETMX_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_ETMX_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_ETMX_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_ETMX_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_ETMX_LOCKIN1_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SUS_ETMX_LOCKIN1_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SUS_ETMX_LOCKIN2_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SUS_ETMX_LOCKIN2_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SUS_ETMY_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_ETMY_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_ETMY_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_ETMY_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SUS_PIT_NOISE_FILT 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_ROLL_NOISE_FILT 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_YAW_NOISE_FILT 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_Y_NOISE_FILT 2 12 4  16384      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_PIT_NOISE_FILT 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_ROLL_NOISE_FILT 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_YAW_NOISE_FILT 2 21 4      0      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

SUS_Y_NOISE_FILT 2 12 4  16384      0 SeisDaytime    4.3736847644382e-23    -1.99994247406600     0.99994247737496    -0.00000000000000    -1.00000000000000

BS_LOCKIN2_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

BS_LOCKIN2_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

BS_LOCKIN1_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

BS_LOCKIN1_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

BS_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

BS_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

BS_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

BS_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMX_LOCKIN2_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMX_LOCKIN2_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMX_LOCKIN1_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMX_LOCKIN1_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMX_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMX_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMX_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMX_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMY_LOCKIN2_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMY_LOCKIN2_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMY_LOCKIN1_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMY_LOCKIN1_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

ITMY_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMY_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMY_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

ITMY_SUSYAW 3 21 4      0      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

PRM_LOCKIN2_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

PRM_LOCKIN2_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

PRM_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

PRM_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

PRM_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

PRM_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SRM_LOCKIN2_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SRM_LOCKIN2_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SRM_LOCKIN1_Q 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SRM_LOCKIN1_I 5 21 2      0      0 BTW0.01     1.351815922494362e-23  -1.9999929139431329   0.9999929139578397   2.0000000000000000   1.0000000000000000

SRM_SUSPIT 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SRM_SUSPOS 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

SRM_SUSSIDE 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

 

SRM_SUSYAW 3 12 4  32768      0 Cheby       1.117558041371939e-23  -1.9972699801052749   0.9972743606395355   2.0000000000000000   1.0000000000000000

 
> cat C1???.txt | grep e-21
 
ASS_LOCKIN9_Q 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN9_I 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN7_Q 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN7_I 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN29_Q 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN29_I 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN27_Q 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN27_I 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN24_Q 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN24_I 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN22_Q 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN22_I 0 21 2      0      0 LP          8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN14_Q 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN14_I 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN12_Q 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
ASS_LOCKIN12_I 1 21 2      0      0 LP50m       8.448680182849132e-21  -1.9999645699236510   0.9999645702913159   2.0000000000000000   1.0000000000000000
SUS_SRM_SUSSIDE 3 12 4  32768      0 Cheby         8.6572646852632e-21    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000
SUS_PRM_SUSSIDE 3 12 4  32768      0 Cheby         8.6572646852632e-21    -1.99726998010527     0.99727436063954     2.00000000000000     1.00000000000000
 
> cat C1???.txt | grep e-19
 
SUP_MC3_SP_Z_NOISE 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
SUP_MC2_SP_Z_NOISE 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
SUP_MC1_SP_Z_NOISE 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
SUP_MC1_SP_YAW_NOISE 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
SUP_MC1_SP_ROLL_NOISE 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
SUP_MC1_SP_PIT_NOISE 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
SUS_ETMX_LOCKIN1_I 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
SUS_ETMX_LOCKIN1_Q 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
SUS_Z_NOISE_FILT 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
SUS_Z_NOISE_FILT 1 21 4      0      0 StackVert     1.8769949851031e-19    -1.99887735863559     0.99888848406943     2.00000000000000     1.00000000000000
BS_LOCKIN1_Q 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
BS_LOCKIN1_I 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
ITMX_LOCKIN1_Q 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
ITMX_LOCKIN1_I 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
ITMY_LOCKIN1_Q 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
ITMY_LOCKIN1_I 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
PRM_LOCKIN1_Q 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
PRM_LOCKIN1_I 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
SRM_LOCKIN1_Q 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000
SRM_LOCKIN1_I 2 21 2      0      0 BTW0.1       1.35175496376953e-19  -1.9999291403672526   0.9999291418378861   2.0000000000000000   1.0000000000000000 
  6018   Sat Nov 26 19:07:40 2011 kiwamuSummaryGreen LockingAM trnasfer function of the Y end laser with doublin crystal

Quote from #5980

 As a part of the ALS noise budgeting we took a look at the Y end PDH setup to see if we are limited by an effect from the RF Amplitude Modulation (AM).

The AM transfer function of the Y end laser has been measured again, but using the frequency-doubled laser this time.

Here is the latest plot of the AM transfer function. The Y-axis is calibrated to RIN (Relative Intensity Noise) / V.

IFBW (which corresponds to a frequency resolution) was set to 100 Hz and the data was averaged about 40 times in a frequency range of 100 kHz - 400 kHz.

Also the zipped data is attached.

AMTF_lightwave.png

It is obvious that out current modulation frequency of 179 kHz (178850 Hz) is not at any of the notches.

It could potentially introduce some amount of the offset to the PDH signal, which allows the audio frequency AM noise to couple into the PDH signal.

Currently I am measuring how much offset we have had because of the mismatched modulation frequency and how much the offset can be reduced by tuning the modulation frequency.

Attachment 2: AMTF_cailbrated.bod.zip
  6017   Sat Nov 26 10:55:40 2011 ranaUpdateCDSBeware of fancy filter modules

 

 Could be that what we're seeing is the noise floor of the Direct Form II filter structure (see Matt's 2008 elog) which shows an example (also see G0900928-v1 ).

 

  6016   Sat Nov 26 07:22:20 2011 sureshUpdateComputers 

c1sus has been shutdown so that the optics dont bang around.  This is because the watch dogs are not working.

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

What I did:

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

 

The Problem:

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

The solution:

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

b) retune the lockin servo phases to minimise Q phase

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

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

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

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

 

Current state:

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

To be done:

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

 

Attachment 1: WFS_err_20111127.png
WFS_err_20111127.png
Attachment 2: cioo_20111127.png
cioo_20111127.png
  6014   Sat Nov 26 02:15:42 2011 MirkoUpdateSUSNot adaptive, still cool

[Rana, Mirko]

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

The result is pretty awesome!

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

PendulumQ0.1HzWithElip2comma5HzLpWfsOnCorrectedShape.pdf

Filter shape:

VirtualPendulumFilterShape.pdf

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

 

 

Attachment 3: SetupVirtualPendulumV2.png
SetupVirtualPendulumV2.png
  6013   Sat Nov 26 02:05:43 2011 MirkoUpdateCDSBeware of fancy filter modules

 

We replaced the complicated Cheby filter module with three separate filter modules. Probably the filter doesn't need to be so complicated, but rather not change too many things at once. The new filter modules are called:
Ch1, Ch2, Ch3 and are in filter module 3,9, and 10 of the C1:SUS-MC?_SUSPOS filters. The coherence with these filters is fine. Someone should look into the possibility of simplifying these filters.

It would be good to check for numerical problems in other filters!

  6012   Fri Nov 25 23:25:24 2011 MirkoUpdateIOOF2A filter for MC

Quote:

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

 [Rana, Mirko]

I redid this calculation. The idea behind it is to get rid on any pitch that is introduced by applying longitudinal feedback to the mirrors. This coupling happens because the center of percussion for pitch , which is identical with the point where the wires lift off of the mirror, is above the center of mass.

With the same values as before, just less faulty math and Q = 2 instead of 10 we end up with the following filters:

For the lower coils (red), compared to corresponding preexisting BS filters (black):

F2aForMCcomparedToBS.pdf

The upper coils' TF is just mirrored at the 0dB magnitude axis, and have a corresponding frequency response.

I switched the F2a filters on for all MC mirrors. For convenience they are split into F2aZeros and F2aPoles. Everything seems fine. The F2a filters seem to be off for ( all ?) other mirrors.

ELOG V3.1.3-