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.

 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.

 It is not working

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

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

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

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.

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

Just FM4 (Cheby)

 Both FM1 and FM4

 All the coherences plotted together

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.

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.

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.

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.

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

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

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

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.

 It is not obvious what is working.

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

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;  

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. 

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.

 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.

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.

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

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

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.

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.

 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.