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):

 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. 

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.

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.

 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) 

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

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

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

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

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

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

 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.

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

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.

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.

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.

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. 

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.

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

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.

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

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

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.

[Frank, Jenne]

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

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.

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.

 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.

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!

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

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

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.

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

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.

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

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 ~10⁶. 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 10⁴ 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.

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. 

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.

 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.

 The coherence between MC_F and GUR1_X is also improved.

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.

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.

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.

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.

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.

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. 

 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.

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.

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.

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

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.

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.

After reducing the digital noise I did offline Wiener filtering to see how good should be online filter. I looked at the MC_F and GUR1_X and GUR1_Y signals. Here are the results of the filtering. The coherence is plotted for MC_F and GUR1_X signals.

We can see the psd reduction of the MC_F below 1 Hz and at resonances. Below 0.3 Hz some other noises are present in the MC_F. Probably tilt becomes important here.

OAF is ready to be tested. I added AA and AI filters and also a highpass filter at 0.1 Hz. OAF workes, MC stays at lock. I looked at the psd of MC_F and filter output. They are comparable, filter output adapts for MC_F in ~10 minutes but MC_F does not go down too much. Determing the right gain I unlocked the MC, while Kiwamu was measuring something. Sorry about that. I'll continue tomorrow during the daytime.

I succeeded in handing off the servo from that of the ALS to IR-PDH.

However the handing off was done by the coarse sensor instead of the fine sensor because I somehow kept failing to hand off the sensor from the coarse to the fine one.

The resultant rms in the IR-PDH signal was about a few 100 pm, which was fully dominated by the ADC noise of the coarse sensor.

Tomorrow I will try :

  (1) Using the fine sensor.

  (2) Noise budgeting with the fine sensor.

Here is the actual time series of the handing off.

EOM is remounted on the fancy-pants new mount that I crafted.  EOM is also aligned.  2 green mirrors (the first ones to see the beams coming onto the PSL table from the arm transmissions) had to be moved so I could fit the mount in, since the new mount is bigger than the old one.  I put them back, and approximately realigned them, but didn't do any fine alignment.  This must be done before looking at beatnotes again.

After playing with the EOM, the MC was flashing on higher order modes.  The PSL beam has been realigned to make the MC lock on TEM00, and Suresh helped me center on the WFS and MC2T.

Things look okay for now.  Next step:  Kiwamu needs to find his happy mode cleaner place, and we'll realign the PSL beam to the MC.  The PSL-MC axes were mismatched pretty badly according to Suresh anyway, so this had to be done no matter what.

 I did offline adaptive filtering with yesterday's 3 hours of MC-F and GUR1X data. It turns out that normalized-lms can strongly outperform static Wiener filtering!

This is interesting. It might be something inside MC_F that Wiener static does not see. I think the problem is either with seismometer noise or tilt.

No real progress.

Probably I spent a bit too much time realigning the beat-note optical path.

(what I did)

 This is the fone storree 

we should turn off 3977,3979 and 2351 has no function

Edit, JD:  x8925 is at the Visitor desk, and isn't on the map.

There were 2 open outputs on the splitter in the RAMmon (formerly known as Stochmon) box underneath the BS oplev table.  The input to the splitter comes from the Thorlabs PD that we're using as our RAM monitoring PD.  2 of the outputs go to the RMS detection of 11 and 55 MHz.  Now the other 2 (previously terminated) outputs go over to the LSC rack via SMA cable.  The signal on both channels is ~200mV pk-pk, so -10dBm.  One is plugged into the AS11 demod board (which didn't have a PD input yet), and the other goes to POP55's demod board, so POP55 is not what you think it is for now.

Koji is working on checking out the Rich box, which has 4 demodulators, which we will use eventually.  Right now we're just using the already-plugged-in demod boards so we can start looking at some trends of RAM.  We're going to need to find some channels when we're ready for the switchover.

Zach is nearing completion of the mini-update to the temp sensing system.  Once we have the new more sensitive temp sensor in place, we can have a look-see at the similarities between EOM temperature and RAM levels.

To show why Matlab is bad in filtering at small cut-off frequencies we did the same thing in Matab, Octave and R: we've taken the low-pass chebyshev filter of the type 1, order 6, ripple 1 dB, the sampling frequency was 16384 Hz and cut-off frequency varied from 1 to 1000 Hz. Here is the plot for the gain of the zpk model versus to cut-off frequency.

We can see that Matlab's gain shows surprising gains for low cut-off frequencies through for > 100 Hz it is fine. In the next table we compare gain from Foton, Matlab, R and Octave for the same filter. So Foton is also good

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

I tried to run the seismic StripTool tonight, which seems liek a simple task. But instead I fell through the rabbit hole again...

The seismic.stp couldn't be run from zita/op340m because zita doesn't have EPICS or MEDM and because the op340m version of StripTool cannot load the new file format in which rossa/pianosa save their files.

Once I got it running by sshing in to rossa, I noticed that the BLRMS trends didn't make any sense. Correctly guessed that this was because all of the BP and LP filters were off. Why? Because of bad BURT, that's why.

As it turns out (if you look through the autoburt logs), several of our FE machines haven't been correctly saving snapshots because of some channel count mismatch between old and new SNAP files. So we are not getting the settings restored correctly for these systems when they get booted. Probably, someone has got to suss out the source of the BURT snap messages; it may be that we have to rehash the snap process after any substantial model rebuild.

For c1pemepics, I did a manual restore from the time when Mirko last ELOG'd that BLRMS was trending OK (Nov 23 @ 3 AM).

Seems like we should also get some kind of auto email warning if the BURTs fail in this way. Otherwise, we'll lose a lot of work if it goes on for weeks.

Bottom line: fix the autoburt so that it doesn't fail after model rebuilds.

I have tested the left 2ch of 4ch demod board.

The left most is for 11MHz, and the next one is for the 55MHz.

I have modified the EOM temperature sensor circuit for the temperature vs. RAM long-term measurements. The only real change is that the sensor is a 100-kOhm thermistor, instead of a 100-Ohm RTD. These semiconductor thermistors (DigiKey P/N 317-1377-ND) are highly nonlinear and can be much more responsive than RTDs, but this difference is much more noticeable at low temperatures.

Frank had told me that the fractional response of the thermistors was so much higher that I could scale the bridge drive current down by the same factor as the resistance was increasing (i.e., 1 mA -> 1 uA, commensurate with 100 ohms -> 100k) and still see a marked improvement. It turns out that at room temperature for this particular sensor the gain enhancement would only be about ~10x, so I only reduced the drive current to ~10 uA, by INCREASING the drive voltage from ~0.1 V -> 1 V, improving the enhancement to ~100x.

Below is a plot of the real nonlinear response of the thermistor, along with a linear approximation at 298.15 K, which gives a coefficient of ~ -4.67 kOhms/K. The differential bridge output voltage response for the new resistance and current is ~7.5 uV/Ohm 2.5 uV/Ohm, bringing the total temperature response before amplification to ~35 mV/K 11.6 mV/K. Looking at a trend of the FSS_RMTEMP channel over a month, we saw that the maximum PSL table temperature fluctuations were ~2 K_pp, so we aimed the maximize resolution by matching +/- 2 K with +/-10 V at the ADC. This was done by using a gain of ~300 in the AD620 that amplifies the differential bridge output. We found that a gain of ~300 put it pretty close, so the grand total calibration ~ 10.5 V/K 3.5 V/K.

Edit (ZK): I screwed up with calculating the bridge response by a factor of three somehow, so I have stricken and restated the calibrations above

I took a look at the recently acquired temperature data alongside the RAMmon 11 and 55 signals, and it appears that we're seeing the same sort of fringing effects we usually see, with oscillatory RAM levels for a monotonic change in EOM temperature.The odd bit towards the end is caused by the MC losing lock. 

It is going to be very interesting to find out what causes this fringing.

Here is a trend of 11 & 55 I&Q, along with the EOM temperature and PSL RMTEMP signals. You can see that there is definitely some fringe-like behavior for monotonic changes in temperature. This is consistent with what I have seen on the gyro table in the past.

Some other notes:

• The EOM temperature (or at least the sensor temperature) seems to track RMTEMP almost exactly when there is no foam box on the EOM. I have verified that the max-min swing here is the same for both signals (~0.77 K).
• Something crazy appears to happen at ~10:15, and all the RAM signals get much noisier. Does anyone know what happened at this time (2:15am local)?

We ought to get to the bottom of the fringing. The CTE of LiNbO3 is ~2 ppm/K, so given that the wavelength is on the order of 0.5 K, this is probably not caused by the etalon effect (2ppm/K * 0.5K * ~1cm << 1064nm).

 I temporarily diverted the output of the RAMmon PD to a spectrum analyzer (4195 in Spectrum Analyzer mode), and tweaked the EOM alignment until I minimized the 11 and 55 MHz peaks as much as possible.  It was possible to get each individual peak to disappear into the noise (about -70dBm), but to get both minimized simultaneously I wasn't able to get both down into the noise.  I left the 11MHz at about -55dBm, and the 55MHz at about -60dBm.  If Kiwamu's simulation tells us that one is more significant than the other (55, because we use it for MICH?), then we can decide to favor putting that peak in the noise and sacrifice ~10dB in the other peak. 

When I first plugged the PD into the analyzer, I saw 22MHz and 44MHz (small) peaks, but they went away after the first bit of tweaking.

Before having used the analyzer, I was trying to minimize the demodulated signals via StripTool, but that was a slow process.  The spectrum analyzer was obviously much faster.

The PD has been returned to the regular RAMmon electronics.

Next up: putting in the new demod box that Koji tested last night.

So far:

* New demod box has been placed in the LSC rack.

* An extra set of +\- 24V has been prepared at the terminal block where all the Crates get their power on the LSC rack.  The grounds were all connected up, but the hot wires weren't.  So there were extra spots available, but none that were pre-wired with my voltages.

     * To do this I turned off all the power supplies in the short rack, since I decided to be a live chicken rather than a dead duck.  After hooking up the new terminal block slots, I turned on the power supplies.

 * Make a power cable to go from the terminal block to the box

Still to do:

 * Connect the spare 55MHz LO and the POP (or POX or POY) unused 11MHz LO to the back of the box

 * Move the PD inputs to the new demod box rather than the borrowed AS11 and POP55 boards

 * Plug the I & Q outs for each freq into some spare ADC channels - must first make sure we have 4 open channels.

 * See if it works.

Since the c1lsc machine became frozen I restarted the c1lsc machined and daqd.

Then I burtrestored c1lsc, c1ass and c1oaf to this evening. They seem running okay.

1) Linearity Test

LO input level was +10dBm. The LO freq was 11MHz and 55MHz for CH1 and CH2 respectively.
The IF frequency was fixed at 10kHz.

The amplitude of the RF input was swept from -50dBm to +15dBm.
Basically I and Q output of CH1 and CH2 was quite linear in this amplitude range.

2) Freqency Response

RF input was fixed at -20dBm and the IF frequency was swept from 1kHz to 1MHz.

The response was flat upto 100kHz, and have sensitivity upto 300kHz.

3) Output noise

Noise floor of the output is ~20nV/rtHz. All of the channels behave in the same way.
1/f start from 100Hz.

I tried to figure out why red NO SYNC label became present in the C1OAF_GDS_TP screen after I added AA filters to the C1OAF model.

C1OAF model contains 8 libraries C1OAF_ADAPT for 8 DOF. I changed C1OAF_ADAPT library to C1OAF_ADAPT_AA library where I added 28 AA filters for 28 witness channels. It turns out that if I use this library for all 8 DOF then I see NO SYNC label, if only for one DOF (MCL) then I see green IOP label. This means that using AA filters for each DOF too much channels of filters are created for online system to operate. I think there is some number inside the code that one can not exceed. Analyzing compilation output after "make c1oaf" I figured out that without using AA filters we have 632 filters and using AA we have 856 filters.

For now I'll use AA filters for MCL only.