40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 26 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  1866   Fri Aug 7 20:43:35 2009 Clara, Jenne, Rana, JanUpdatePEMTwo Guralps plugged in, prepped for huddle test

Both Guralps and the Ranger have been placed in our nice new insulated foam box, complete with packing peanuts, in the corner between the x and y arms. The Guralp breakout box has been reinstalled and everything is plugged in in prepartion for the huddle test. However, we're having some issues with ADC channels, which will be worked out tomorrow (hopefully) so that data can be collected over the weekend.

Currently, one Guralp is plugged into the three SEIS-MC1 channels. We made new channels for the second Guralp (GUR-EW, GUR-NS, and GUR-VERT), but had issues with those. So, EW and NS have been plugged into PEM_AUDIO-MIC1 and MIC2 for the time being.

Attachment 1: Untitled.png
Untitled.png
  12750   Tue Jan 24 17:52:15 2017 CraigUpdateOptical LeversETMY Oplev HeNe is replaced

Steve, Craig, Gautam

Today Steve replaced the ETMY He/Ne sr P919645 OpLev laser with sr P947049 and Craig realigned it using a new AR coated lenses.

Attached are the RIN of the OpLev QPD Sum channels.  The ETMY OpLev RIN is much lower than when Gautam took the same measurement yesterday.

Also attached are the pitch and yaw OLG TFs to ensure we still have acceptable phase margins at the UGF.

The last three plots show the optical layout of the ETMY OpLev, a QPD reflection blocker we added to the table, and green light to ETMY not being blocked by any changes to the OpLev.

Quote:

ETMY He/Ne body temp is  ~45 C The laser was seated loosely  in the V-mount with black rubber padding.

The enclosure has a stinky plastic smell from this black plastic. This laser was installed on Oct 5, 2016 See 1 year plot.

Oplev servo turned off. Thermocouple attached to the He/Ne

It will be replaced tomorrow morning.

Quote:

On the control room monitors, I noticed that the IR TEM00 spot was moving around rather a lot in the Y arm. The last time this happened had something to do with the ETMY Oplev, so I took a look at the 30 day trend of the QPD sum, and saw that it was decaying steeply (Steve will update with a long term trend plot shortly). I noticed the RIN also seemed rather high, judging by how much the EPICS channel reading for the QPD sum was jumping around. Attached are the RIN spectra, taken with the OL spot well centered on the QPD and the arms locked to IR. Steve will swap the laser out if it is indeed the cluprit.

 

 

Attachment 1: OpLevRIN24Jan2017.pdf
OpLevRIN24Jan2017.pdf
Attachment 2: ETMYpit_24Jan2017.pdf
ETMYpit_24Jan2017.pdf
Attachment 3: ETMYyaw_24Jan2017.pdf
ETMYyaw_24Jan2017.pdf
Attachment 4: IMG_3510.JPG
IMG_3510.JPG
Attachment 5: IMG_3513.JPG
IMG_3513.JPG
Attachment 6: IMG_3514.JPG
IMG_3514.JPG
  12842   Tue Feb 21 13:51:35 2017 CraigSummaryGeneralAlternative Calibration Scheme

We get SNR in two ways: the amplitude of applied force and the integration time.  So we are limited in two ways: stability of the lock to applied forces and time of locklosses / calibration fluctuations.

At the sites, you probably know that we blow our spectrum out of the water with the calibration lines, with SNRs of about 100 on the scale of about 10 seconds.  For us this might be impossible, since we aren't as quiet.

If we want 1% calibration on our sweeps, we'll need  0.01 = Uncertainty = sqrt( (1 - COH^2)/(2 * Navg * COH^2) ), where COH is the coherence of the transfer function measurement and Navg is the number of measurements at a specific frequency.  This equation comes from Bendat and Piersol, and is subject to a bunch of assumptions which may not be true for us (particularly, that the plant is stationary in time).

If we let Navg = 10, then COH ~ 0.999.

Coherence = Gxy^2/(Gxx * Gyy), where x(t) and y(t) are the input signal and output signal of the transfer function measurement, Gxx and Gyy are the spectral densities of x and y, and Gxy is the cross-spectral density.  

Usually SNR = P_signal / P_noise, but for us SNR = A_signal / A_noise.

Eric Q and Evan H helped me find the relationship between Coherence and SNR:

P = Pn + Pc, Pn = P * (1 - Coh), Pc = P * Coh

==> SNR = sqrt( Pc / Pn ) = sqrt( Coh / 1 - Coh )

From Coh ~ 0.999, SNR ~ 30.

Quote:

Question for Craig: What does the SNR of our lines have to be? IF we're only trying to calibrate the actuator in the audio band over long time scales, it seems we could get by with more frequency noise. Assuming we want a 1% calibration at 50-500 Hz, what is the requirement on the frequency noise PSD curve?

 

  7560   Tue Oct 16 17:13:23 2012 CzarinaSummaryGeneralvent stuff - 4 paths

I see 4+ possible paths for us to take, in terms of a possible vent in the next few weeks:

No Vent - Just do FPPRMI, using AS55

Mini Vent - Fix REFL path, nothing else.  ~1 day at atmosphere

Medium Vent - Fix REFL path, swap G&H mirrors for LaserOptik mirrors (so also resuspend passive TTs, maybe add pitch adjustment option). ~1 week or so at atmosphere - do this rather than Mini if Jan's Finesse calc says the G&H mirrors are too rough

Mega Vent - Fix all the things, do all the things.  Long time at atmosphere

The "+" is to take into account all the possible variations on "medium vent".  The No, Mini and Medium options assume we'll do the Mega option later, just not immediately.

  9855   Fri Apr 25 13:18:08 2014 Dark JamieUpdateLSClocking activity

Quote:

[ericq, Jenne, Zach]

We spent some time tonight trying to push our CARM locking further, to little avail. DARM/CARM loop oscillations kept sneaking up on us. We measured some MC2 motion -> REFL11 Transfer Functions to see if we could see CARM plant features; plots will come in the near future...

 Probably things would have worked better if you would have gotten your hair done at the same place as me.

Attachment 1: m10008_f1_bg.jpg
m10008_f1_bg.jpg
  16897   Tue Jun 7 18:32:46 2022 DeekshaUpdateElectronicsNoise Budgeting ADC (of redpitaya)

Made plots on i/p noise of redpitaya . Need to reconsider sampling frequency (to improve plot at lower freq)
 

Attachment 1: ch1_0.5V.png
ch1_0.5V.png
Attachment 2: ch2_0.0V.png
ch2_0.0V.png
  16939   Wed Jun 22 17:04:06 2022 DeekshaSummaryElectronicsCharacterising the AUX control loop

[Cici, Deekha]

Setup loop to measure transfer function of control loop - the aim is to find the open loop gain of the system using the SR785 to inject noise (a swept sine) into the system and taking observations using the scope. We tried to calculate the gain algaebraically, in order to understand what our readings meant and what we can determine from them. Need to figure out how to run python script for the SR785, but took readings from cmd today.

Included - changes/additions made to circuit; frequency reponse obtained (need to check the frequency response as it does not look like the expected result, need to correct the loop itself, or increase the magnitude of the inserted noise as its possible that the noise is currently being suppressed by the system).

To do - circuit needs to be checked + laser lock improved - laser keeps leaving resonance while trying to take readings.

 

Attachment 1: after.jpeg
after.jpeg
Attachment 2: before.jpeg
before.jpeg
Attachment 3: freq_response.png
freq_response.png
  16951   Mon Jun 27 13:39:40 2022 DeekshaUpdateElectronicsSetting up the MokuLab

[Cici, Deeksha]

On Friday Cici and I set up the Mokulab to take readings of our loop. The aim is to characterise the PZT, in a similar manner as before, by exciting the circuit using our input noise (a swept sine) and recording the corresponding changes in the output. We used the MokuLab to observe the beat note created by the signals of the AUX and PSL, as well as the ASD of the output signal. The MokuLab simplifies the entire process.

Pictured : The beat note as observed by Cici

Attachment 1: WhatsApp_Image_2022-06-24_at_5.21.28_PM.jpeg
WhatsApp_Image_2022-06-24_at_5.21.28_PM.jpeg
  16964   Thu Jun 30 17:19:55 2022 DeekshaSummaryElectronicsMeasured Transfer Functions of the Control Loop, Servo (OLTF); got Vectfit working

[Cici, Deeksha]

We were able to greatly improve the quality of our readings by changing the parameters in the config file (particularly increasing the integration and settle cycles, as well as gradually increasing our excitation signals' amplitude). Attached are the readings taken from the same (the files directly printed by ssh'ing the SR785 (apologies)) - Attachment 1 depicts the graph w/ 30 data points and attachment 2 depicts the graph with 300 data points. 

Cici successfully vectfit to the data, as included in Attachment 3. (This is the vectfit of the entire control loop's OLTF). There are two main concerns that need to be looked into, firstly, the manner in which to get the poles and zeros to input into the vectfit program. Similarly, the program works best when the option to enforce stable poles is disabled, once again it may be worth looking into how the program works on a deeper level in order to understand how to proceed. 

Just as the servo's individual transfer function was taken, we also came up with a  plan to measure the PZT's individual transfer function (using the MokuLab). The connections for the same have been made and the Moku is at the Xend (disconnected). We may also have to build a highpass filter (similar to the one whose signal enters the PZT) to facilitate taking readings at high frequencies using the Moku. 

Attachment 1: TFSR785_29-06-2022_114042.pdf
TFSR785_29-06-2022_114042.pdf
Attachment 2: TFSR785_29-06-2022_114650.pdf
TFSR785_29-06-2022_114650.pdf
Attachment 3: TF_OLG_vectfit.png
TF_OLG_vectfit.png
  16974   Wed Jul 6 18:51:20 2022 DeekshaUpdateElectronicsMeasuring the Transfer Function of the PZT

Yesterday, we set up the loop to measure the PZT of the transfer function - the MokuLab sends an excitation (note - a swept sine of 1.0 V) to the PZT. The cavity is locked to the PSL and the AUX is locked to the cavity. In order to measure the effect of our excitation, we take the beat note of the PSL and the AUX. This gives us a transfer function as seen in Attachment 1. The sampling rate of the MokuLab is set to 'ultrafast' (125kHz), so we can expect accurate performance upto 62.5kHz, however, in order to improve our readings beyond this frequency, modifications must be made to the script (MokuPhaseMeterTF) to avoid aliasing of the signal. A script should also be written to obtain and plot the coherence between the excitation and our output. 

Also attached are - Attachment 2 -  the circuit diagram of the setup, and Attachment 3 - the TF data calculated.

Edit - the SR560 as shown in the circuit diagram has since been replaced by a broadband splitter (Minicircuits ZFRSC-42-S+).

Attachment 1: pzt_transfer_fn.png
pzt_transfer_fn.png
Attachment 2: ckt_diagram.jpeg
ckt_diagram.jpeg
Attachment 3: MokuPhaseMeterTFData_20220706_174753_TF_Data.txt
2.000000000000000364e+04 1.764209350625748560e+07 2.715833132756984014e+00
1.928351995884991265e+04 1.695301366919569671e+07 1.509398637395631626e+00
1.859270710016814337e+04 1.647055321367538907e+07 -2.571975165101855865e+00
1.792664192275710593e+04 1.558169995329630189e+07 6.272729335836754183e-01
1.728443786563210961e+04 1.500850042360494658e+07 -1.500422400597591466e+00
1.666524012797089381e+04 1.456986577652360499e+07 2.046163000975175894e+00
1.606822453133765885e+04 1.376167843637173250e+07 1.736835046956476614e+00
1.549259642266657283e+04 1.326192932667389885e+07 -1.272425049850132606e+00
1.493758961654484847e+04 1.283127345074228011e+07 -2.026149685362535369e+00
1.440246537538758821e+04 1.208854709974890016e+07 -3.248352694840740407e-01
... 11 more lines ...
  17031   Mon Jul 25 09:37:39 2022 DeekshaUpdateElectronicsUsing the DFD to measure PZT TF

The DFD was setup to measure the change in beatnote when excited. A long long (128in) cable goes from the SR785 near the DFD all the way to the Xend AUX which it accordingly excites and the DFD is monitored by the oscilloscope at the other end. This was completed on Friday. The wires and stand have been moved to the side but the setup is still a bit chaotic. As of writing this post, there is still atleast some minor issue with the setup as we aren't getting the expected output. 

[I will shortly update this elog with more pictures]

Edit: the SR785 was replaced by the AG 4395, and pictures added

 

Attachment 1: ag4395.jpeg
ag4395.jpeg
Attachment 2: dfd.jpeg
dfd.jpeg
  17035   Mon Jul 25 18:22:30 2022 DeekshaSummaryWikiMeasured the PZT TF Successfully

Measured the PZT beatnote using the setup mentioned in elog post 17031. Attached is the data taken from 10kHz to 1MHz, decadewise data was also taken that I'm not including in this post. A_R refers to the transfer function taken of channel A wrt the voltage reference (the swept sine we are inputting which has an IF of 30kHz). A and B correspond to the I and Q components of the signal taken from the DFD, respectively. I am currently working on plotting the data, and will shortly update this post with plots. Next steps - 

- quantify the uncertainty in the signal (I think)

- vectfit the data to find poles and zeroes

(and possibly find a better way to print/obtain data)

Edit: first pass of data plotted

Attachment 1: A_R_MAG.txt
"4395A REV1.12"
"DATE: Sep 17 2017"



"CHANNEL: 1"
"MEASURE TYPE: A/R"
"FORMAT TYPE: LOG MAG"
"NUMBER of POINTS: 801"
"SWEEP TIME:  385.3 ms"
... 811 more lines ...
Attachment 2: A_R_PHASE.txt




"CHANNEL: 2"
"MEASURE TYPE: A/R"
"FORMAT TYPE: PHASE (DEG)"
"NUMBER of POINTS: 801"
"SWEEP TIME:  385.3 ms"
... 808 more lines ...
Attachment 3: B_R_MAG.txt
"4395A REV1.12"
"DATE: Sep 17 2017"



"CHANNEL: 1"
"MEASURE TYPE: B/R"
"FORMAT TYPE: LOG MAG"
"NUMBER of POINTS: 801"
"SWEEP TIME:  385.3 ms"
... 809 more lines ...
Attachment 4: B_R_PHASE.txt




"CHANNEL: 2"
"MEASURE TYPE: B/R"
"FORMAT TYPE: PHASE (DEG)"
"NUMBER of POINTS: 801"
"SWEEP TIME:  385.3 ms"
... 807 more lines ...
Attachment 5: freq_resp_I.png
freq_resp_I.png
Attachment 6: freq_resp_Q.png
freq_resp_Q.png
  17036   Tue Jul 26 19:50:25 2022 DeekshaUpdateComputer Scripts / ProgramsVector fitting

Trying to vectfit to the data taken from the DFD previously but failing horribly. I will update this post as soon as I get anything semi-decent. For now here is this fit.

Attachment 1: data.png
data.png
Attachment 2: fit_attempt.png
fit_attempt.png
  17039   Wed Jul 27 14:39:04 2022 DeekshaUpdateElectronicsNew and improved PZT TF data from the DFD

Paco and I messed around with the attenuation of the scope and bandwidth of the IF. We also replaced the BNC T's in the circuits with RF splitters. We saw some decent improvements to the data. The data is attached and a diagram of the experiment. [We analytically calculated the impedances to avoid any mismatch taking place]. Working on fitting the data.

We also moved around the wires so that the AG4395 is closer to the PZT.

 

Attachment 1: tf_data.png
tf_data.png
Attachment 2: latest_data.zip
Attachment 3: dfd_-_new.drawio.png
dfd_-_new.drawio.png
  5573   Thu Sep 29 00:16:35 2011 DenUpdateComputersSegmentation fault fixed.

The OAF c-code crashed because of the segmentation fault. We've created arrays of static variables

    static int pst[nDOF];
    static int isFirst[nDOF];
    static adaptive_filter_state state[nDOF];

an tried to give in the to the ITERATE - function their current values

        datOut[i] = ITERATE(iterateDatIn, iterateNIn, pst[i], isFirst[i], state[i]);

ITERATE function was declared as

double ITERATE(double *datIn, int nIn, int pst, int isFirst, adaptive_filter_state state) {}

Here the segmentation fault comes out. Static variables are meant to be created only once but here in the function ITERATE we try to create them once again in a local form, because we give the variables by their values.

Instead, we must give the variables by their pointer, then the variables won't be created again during the function call and will be changed in the function.

        datOut[i] = ITERATE(iterateDatIn, iterateNIn, &pst[i], &isFirst[i], &state[i]);

       double ITERATE(double *datIn, int nIn, int *pst_s, int *isFirst_s, adaptive_filter_state *state_s)

In order not to change significantly Matt's code and use his notations we can add in the ITERATE function

    int pst = *pst_s;
    int isFirst = *isFirst_s;
    static adaptive_filter_state state;
    state = *state_s;

..................................Matt's code.........................................

    *pst_s = pst;
    *isFirst_s = isFirst;
    *state_s = state;

I've tested the program, now it does not give any segmentation faults and conserves memory that it uses.

  5740   Tue Oct 25 21:49:13 2011 DenUpdateAdaptive FilteringAdaptive filter witness and EP SNR

Quote

Coherence of seismometers to MCL:


STS1 is located at the vertex. x-axis along the x arm.
GUR1 is located at the IMC MC2 mirror. Same orientation.
Coherence.png

=> 1. Only the x-direction has good coherence (to be expected)
     2. Only good coherence at 1.5-4Hz (huh?)

So probably other noise sources are dominating. Let's look into noise projections. Remember IMC autoalignment is off.

A quick adaptive filter run with only the GUR1 and STS1 witnesses applied only to MCL didn't really do anything. Some more thought needs to be invested into the AA and shaping filters.

Indeed, only GUR1_X is reasonable. Static Wiener filtering (length = 2500) of MCL with witness channels GUR_1_X, GUR_1_Y, GUR_1_Z proves your measurements.

We need to callibrate seimometers. I think that now we see velocity, not displacement. It might be useful to amplify the seimometer singal before ADC to make sure that our signal is not ADC noise.

Attachment 1: gur1_x.jpg
gur1_x.jpg
Attachment 2: gur1_y.jpg
gur1_y.jpg
Attachment 3: gur1_z.jpg
gur1_z.jpg
  5777   Tue Nov 1 18:16:50 2011 DenUpdateAdaptive FilteringAdaptive filter witness and EP SNR

Quote:

 

Coherence of seismometers to MCL:


STS1 is located at the vertex. x-axis along the x arm.
GUR1 is located at the IMC MC2 mirror. Same orientation.
Coherence.png

=> 1. Only the x-direction has good coherence (to be expected)
     2. Only good coherence at 1.5-4Hz (huh?)

So probably other noise sources are dominating. Let's look into noise projections. Remember IMC autoalignment is off.

A quick adaptive filter run with only the GUR1 and STS1 witnesses applied only to MCL didn't really do anything. Some more thought needs to be invested into the AA and shaping filters.

The possible explanation to this effect is the following:

Seismic noise mainly consists of the Love and Rayleigh surface waves. In the simulations we've taken 2 perpendicular Love waves and 2 perpendicular Rayleigh waves that interfere under the test mirrors. This interference produces both translational and tilt movements. Then we can see the coherence between translational motion and cavity length.

translation_length.jpg

1. The coherence at big frequencies is small due to the passive isolation.

2. The coherence at 1 Hz is 0 due to the wire resonance.

3. The coherence between 1 and 10 Hz is reasonable. At the real 40m's measurements we can see only good coherence for gur1_x and sts1_x but this is the matter of adjusting seismic waves amplitude and direction. In the simulation we've assumed that all waves are of the same amplitude. The really interesting thing is that

4. The coherence below 0.8 Hz began to grow. We don't see this in real measurements.

But let's simulate the seismometer measurements. It measures not only translational motion but also tilt and with amplitude proportional to g / omega^2. On the Figure below the spectrum of translation motion, tilt and tilt as seen by seismometer is presented. We can see that at low frequencies tilt begins to dominate over the translational motion. We assumed the speed of waves in the region 30 - 60 m/sec.

trans_tilt.jpg

Let's now plot the coherence between the cavity length and seismometer signal.

seismic_length.jpg

We can see that the coherence between seismic signal from measured by seismometer and cavity length is gone below 1 Hz where tilt becomes important.

Now let's try to filter out the seismic noise from the cavity length using both static Wiener filtering and adaptive Mfxlms algorithm. For both filters we've used AA filter before the filters and also AI filter after adaptive filter. The downsampling ratio was 4, the sample frequency 256. We can see that nothing is really subtracted due to the pollution of the seismometer signal due to tilt motion.

tilt_filtering.jpg

Assume we do the same computational experiment but with the seismometers that measure only ground translational motion and tilt do not affect on them. Then we have a reasonable subraction of seismic noise at low frequencies even with the filters of the length 100 as shown on the figure below.

filtering.jpg

Let's look through an order of magnitude analysis. Assume ground motion consists of only one wave with amplitude A and only vertical movement:  z(t) = A*sin(2 pi 0.1 t). So the frequency of the wave is 0.1 Hz. If A = 10-6 m => the amplitude of the suspended mirror motion is also approximately 10-6 m, as we have no isolation at low frequencies. The tilt angle has the amplitude alpha = 2*pi*A/lambda, where lambda - wavelength of the ground wave, lambda = v/f = 40/0.1 = 400 m, v - speed of the wave, f - frequency. Then alpha = 10-8 rad. If the distance between ground and mirror suspension point is 1 m, then mirror motion amplitude due to tilt is B = 10-8 m << A. 
It turns out that tilt does not effect much on the cavity length compared to the ground translational motion, but it affects a lot on the seismometer signals, that are used as witness signals in the filtering. For that reason we need tiltmeters to filter seismometer signals in order to obtain pure translational ground motion.
  5816   Fri Nov 4 21:52:58 2011 DenUpdateAdaptive Filteringcoherence

[Mirko, Den]

We still think about the coherence between seismic noise and mode cleaner length. We beleive that

1. Below ~0.1 Hz tilt affects on the seismometers as was simulated http://nodus.ligo.caltech.edu:8080/40m/5777

2. From 0.1 to 1 Hz is an interesting region. We try to figure out why we do not see any coherence here. Tilt does not seem to dominate.

At 1 Hz coherence might be lost because of the sharp resonance. For example, if the mirror is suspended to the platform by wires with f = 1 Hz and Q = 1000, then the coherence between platform motion and mirror motion will be lost as shown on the figure below.

mirror_platform.jpg

For this reason we tried to "help" to the adaptive filter to guess transfer function between the ground motion and mirror motion by multiplying seimometer signal by the platform -> mirror transfer function. As we do not know exactly eigen frequency and Q of the wires, we did a parametric simulation as shown on the figure below

coherence.jpg

The maximum coherence that we could achieve with treak was 0.074 compared to 0.056 without. This was achieved at f=1.0011 Hz but with surprisingly high Q = 330. And though this did not help, we should keep in mind the tecnique of "helping" the adaptive filter to guess the transfer function if we partly know it.

Another unexpected thing is that we see come coherence between gur1_x and mode cleaner WFS pitch signal at frequencies 0.1 - 1 Hz

Screenshot-4.png

 

 

 From this we can suggest that either mode MC_F channel does not completely reflect the mc length at low frequencies or WFS2 shows weard signal.

  5869   Fri Nov 11 00:55:53 2011 DenUpdateAdaptive FilteringMC_F

[Mirko, Den]

Not satisfactory work of adaptive filtering make us to think about the signals that we use. Now we try to deal with mode cleaner and analize its length. We take MC_F channel. We know that MC_F is used as a feedback signal to the laser frequency and laser changes it's frequency linear to the input modulation signal up to ~1kHz. Than is MC_F is length of MC, not velocity or acceleration. If so, it's form due to seismic noise + company of other noises + stacks and wires should be approximately like the left plot. Instead we see the right plot.

mcl_sim.jpgmcl_real.jpg

 

Possibly, left-plot form signal is not possible to transmit through the wires and adc. Most signal at medium and high frequencies would be lost because of wire and adc noise. For that reason mode cleaner length signal might be amplified at frequecnies >~20 Hz by some bandpass filter.

Where is this highpass filter and what is the form of this filter?

It might be just after the photodetector in order not to transmit real mode cleaner length through the wires. But if wires and not very noisy, it could be somewhere before ADC.

But anyway, for the laser frequency feedback the corresponding low pass filter should be used.

Where is this lowpass filter and what is the form of the filter?

We followed the mode cleaner length signal up to TT FSS and measured the mode cleaner length, that is used as an input to TT FSS. As shown http://nodus.ligo.caltech.edu:8080/40m/5867 MC_F is different from the signal that is given to TT FSS. This is not clear because we do not have smth that could effect on the signal that much before branch node and recording of MC_F. The main difference is the cut off at the MC_F signal at 3 Hz. It might be a digital filter but we do not see any filters between adc_0_0 up to MC_F test point - straight line. This means that we have an analog filter somewhere between that blue box where the branch point is and ADC. We need to find it. But at least, we do not have a lowpass filter before FSS. So it is probably after it.

So, we need to find the 3 filters that we think affect on the MC_F channel in order to figure out why we have such a bad coherence between seismic signal and mode cleaner length.

  5870   Fri Nov 11 00:58:19 2011 DenUpdateelogrestarted elog

Elog suspended 2 times for 1 hour. Too high frequency.

Restarted.

  5882   Sat Nov 12 02:46:13 2011 DenUpdateAdaptive Filteringstacks and ground

We measured the coherence between the seismometer near the MC2 stack and accelerometers on the vacuum tank where MC2 is. Because accelerometers produce small signals at low frequencies, which are comparable with adc noise, we  amplified the accelerometer signal by a factor of 20. We could not do it more because though adc has 40 V range, the black box that follows the channel sockets can transmit only 2.5 V max amplitude signal. Probably, this was done because old adc accepted 2 V max amplitude.

ground_stack.jpg

ground_stack_coherence.jpg


We were able to found some coherence at 0.1-1 Hz though the accelerometer signal is rather noisy. So to consider stack as a noise source is still possible. This measurement should be better done with two seismometers, one on the floor, the other on the stack. From the figure we can also see that tilt affects the x and y seismometer signals from 0.1 Hz. Green line (z-component) is much lower that red and blue lines (x and y). Tilt affects on horisontal axes of the seismometer much more than on vertical.

What we also think about is that at low frequencies mirrors start to move approximately the same and seismometers can help us to figure out small reletive displacement of the mirrors which form the MC length. We can estimate the critical frequency by presenting the ground motion as interference of surface waves with different velocities and amplitudes. For only 1 wave we have for the relation of MC length to the seismometer read out  ~sin (2*pi*f/v*L). f - frequency of the wave, v -speed, L - length between the mirrors. We can see that below 1 Hz we have ~sin (f/2). At this point seismometer signal could lose coherence with MC length signal. We could try to subtract seismometer signals from corresponding axes, but gur1 and sts1 has different calibrations. Moreover, the noise floor of the seismometers might not allow us to measure the differential signal. We'll try to simulate this scenario and find seismometer calibration or measure it. We are basicly interested only in the ratio of calibraion fucntions of 2 seismometers.

  5919   Wed Nov 16 23:50:40 2011 DenUpdateAdaptive Filteringseismic noise injection

[Micro, Den]

Analyzing coherence of seismic noise and mode cleaner length we've figured out that at some days the coherence below 1 Hz is still present. For example, at Nov 13 we can see some coherence compared to most other dates when we are not able to see coherence as shown on the figure. On the top plot - psd of MC_L and GUR1_X at Nov 13 (red and blue) and Nov 15 (black and cyan). On the bottom plot is presented coherence between MC_L and GUR1_X on Nov 13 (red) and Nov 15 (black)

datespsd.jpg

datescoh.jpg

We can divide the psd plot for 2 parts - below 1 Hz and above 1 Hz. Above 1 Hz seismic noise on Nov 15 (cyan) was higher then on Nov 13 (blue) and correspondently MC_L at that region was higher on Nov 15. Below 1 Hz seismic noise was higher on Nov 13 but MC_L is still lower that on Nov 15. That is surprising. From the coherence plot we can say that once we have some more seismic noise than usually, we immediately see coherence.

Because of this we wanted to find out the level of the X noise that makes seismic noise invisible. We injected seismic noise by doing smooth physical exercises near MC_2 (1.5 m and 3 m apart). The MC_2 was in lock during the experiment.

injectionpsd.jpg

injectioncoh.jpg

In the coherence plot we can see that coherence between GUR1_X and MC_L increased with noise injection. The highest coherenced we obtained sittind down and standing up smoothly near MC_2 at distance 1.5 m. We did not want to come clother and break the lock. This measurement tells us that the X noise is approximately 3-4 times higher than seismic noise in the range 0.1 - 1 Hz. That means that it is approximately 1e-6 - 1e-8 m/sqrt(Hz) in this region. This noise goes down at frequencies from 2 Hz and not seen because of seismic noise. Actually, seismic noise can be filtered out with the Wiener filter and then we'll see the spectrum of X noise.

We now try to figure out the method to estimate the contribution of OSEM noise to the X noise.

  5932   Thu Nov 17 22:24:19 2011 DenUpdateAdaptive FilteringMC1_COIL

Analyzing coherence between MC length and signals on MC1, MC2 and MC3 coils we have noticed that MC1 COIL signal is not coherent to MC length at all at interesting frequencies 0.1 - 1 Hz.

We try to explain this phenomena.

 

Attachment 1: MC1COIL-crop.pdf
MC1COIL-crop.pdf
Attachment 2: MC2COIL-crop.pdf
MC2COIL-crop.pdf
Attachment 3: MC3COIL-crop.pdf
MC3COIL-crop.pdf
  5933   Thu Nov 17 23:38:40 2011 DenUpdateIOOMC unlocked

MC is unlocked to measure the free swing of the MC mirrors with the local sensors.

Autolocker is disabled.

  5934   Thu Nov 17 23:44:48 2011 DenUpdateIOOMC1_SENSOR

We've found that one of the  MC1_SENSORS does not work properly.

See the figure.

Attachment 1: MCSENSORS.pdf
MCSENSORS.pdf
  5935   Thu Nov 17 23:47:43 2011 DenUpdateIOOMC1_SENSOR

The most interesting plot did not uploaded in the previous elog.

Upload now local MC1_SENSOR signals.

Attachment 1: MC1SENSOR-crop.pdf
MC1SENSOR-crop.pdf
  5939   Fri Nov 18 01:27:04 2011 DenUpdateIOOMC locked

[Mirko, Den]

While the MC was unlocked (and the local damping off) we've measured the coherence between GUR1_X and OSEM sensors. It was rather high, close to 1 at frequencies 0.1 - 1 Hz. That means that stack does not kill all coherence between seismic noise and mirror motion.

Then we've turned on the local damping and measured the coherence again between GUR1_X and OSEM sensors. It decreased due to some noise and was on the level of ~0.5. We did reduced the motion between the mirror and the frame by local damping but it is not obvious that we lost some coherence due to this effect. Probably, actuator adds some noise.

When we locked the MC, we did not see any coherence at 0.1 - 1 Hz between GUR1_X or STS1_X and OSEM sensors of MC1 and MC3 but we did see with MC2. The MC1 sensor was fixed by Suresh.

 

Attachment 1: cohnolocalpumping-crop_4.pdf
cohnolocalpumping-crop_4.pdf
Attachment 2: cohlocalpumping4-crop.pdf
cohlocalpumping4-crop.pdf
Attachment 3: cohlock4-crop.pdf
cohlock4-crop.pdf
  5957   Sat Nov 19 01:26:16 2011 DenUpdateIOOMode cleaner noise projection

Quote:

Instead, what we want is to project how the actual OSEM noise in the presence of no signal shows up as MC length. For that we should use the old traces of the OSEM noise with no magnets and then inject that spectrum of noise into the SUSPOS filter bank with all the loops running. We can then use this TF to estimate the projection of OSEM noise into the MC length.

That's right. The easier problem arises if we consider one of  MC mirrors. The coherence between OSEM sensors and GUR1_X in free moving regime is equal to 0.9 at frequencies 0.1 - 1 Hz. But with local dumping coherence is 0.6. We have

Mirror -> Sensor -> Satellite Module -> Whitening -> ADC -> Computer -> DAC -> Dewhitening -> Satellite Module -> Actuator -> Mirror

Somewhere we produce noise that kills part of coherence. We can use this method with the injection of spectrum of noise into the SUSPOS filter bank only for one mirror and see how the coherence between OSEM sensor and GUR1_X will change. If the change is small, we deal with something else. It the coherence will change from 0.6 to ~0.4, than we have big OSEM noise.

It might be also the problem that the amplitude of COIL_OUT signal is ~25. If it is in counts we may have noise from DAC. 

  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 
  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
  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;  

 

  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. 

  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.

  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.

  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.

 

  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.

 

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

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

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

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

freqz.pdf

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

 trans.pdf

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

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

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

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

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

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

psd_sensors.jpg

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

coh_sensors.jpg

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

psd_mcl.jpg

 The coherence between MC_F and GUR1_X is also improved.

coh_mcl.jpg

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

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

coh_mcl_seis.pdf

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

sensor_locker.pdf

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

  6066   Sun Dec 4 13:56:54 2011 DenUpdateIOOWFS

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

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

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

  6067   Sun Dec 4 23:49:38 2011 DenUpdateIOOWFS

Quote:

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

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

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

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

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

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

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

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

  6075   Tue Dec 6 00:58:34 2011 DenUpdateWienerFilteringOAF current goal

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.

oaf_goal_psd.png     oaf_goal_coh.png

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.

  6078   Wed Dec 7 00:11:58 2011 DenUpdateAdaptive FilteringOfflineAF

 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!

offlineaf_psd.png 

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.

Attachment 2: offlineaf_coh.png
offlineaf_coh.png
  6093   Fri Dec 9 13:28:09 2011 DenUpdateAdaptive FilteringC1OAF

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.

  6095   Fri Dec 9 15:14:41 2011 DenUpdateCDSrelease 2.4

Alex has created a 2.4 branch of the RCD. Jamie, we can try to compile and install it. As a test a did it for c1oaf, it compiles, installs and runs once variables SITE, IFO, RCD_LIBRARY_PATH are properly defined. As we do not want to run one model at 2.4 code and others at 2.1, I recompiled c1oaf back to 2.1. Jamie, please, let me know when you are ready to upgrade to 2.4 release.

  6100   Fri Dec 9 17:53:31 2011 DenUpdateAdaptive FilteringC1OAF

[Jenne, Den]

AA filters for witness channels are added to the oaf model. It is working now and the number of memory used is not critical.  NO SYNC is not present any more.

  6110   Tue Dec 13 01:20:38 2011 DenUpdateAdaptive FilteringModifications to LSC, RFM models, added OAF model

Quote:

[Jenne, Mirko, with supervision from Jamie]

We are starting to create the new OAF model, so that it works with the new CDS system. 

 Why did you place Matt's code inside the simulink library and use the same library for all DOFs? I think this won't work out. Inside the .c code there are static variables. If all DOF use the same ADAPT_XFCODE() function, it means that they all mess there signals and coefficients with each other! Or the RCD during the compilation creates a copy of the function with the name of a library name in front? For example, ADAPT_MCL_ADAPT_XFCODE(). But then in the RCG manual it is claimed to name the .c file the same.

This problem can be fixed by creating .c files with proper names for each DOF. But here a memory question may arise. For 1 DOF we now have 28 witness channel. If we have a several minute filter, we use 28 * 104(filter length) * 3 (FIR coefficients, adapt input, corr input) * 8 (number of bytes in 1 double)  = 6.7 Mb / DoF. For 8 DOF we'll allocate ~55 Mb of memory in the kernel. The c1lsc cache size is 6 Mb per cpu. So we are definitely out of cache and it will take some time for a processor to communicate with ram. I wonder if it is OKEY for us to allocate this amount of memory as static arrays inside the kernel.

Now we use 6.7 Mb of memory because it seems to be a mistake with placing the same function for all DOF and we actually allocate for 1.

 

  6137   Mon Dec 19 17:17:02 2011 DenUpdateAdaptive Filteringfilter tap dependence

Online filter diverges. I did offline simulations with current c-code. Offline filter also diverges, even in the simplest case 

witness = randn(1e6, 1); target = witness + 0.01*randn(1e6, 1);

I tried to create a new implementation of FXLMS algorithm as a c code. Then with this c code I did offline filtering with MCL and GUR signals and compared the error signals depending on the length of the filter.

OfflineAF.png

One can see the code at the svn

adaptOnline - start here and choose algorithm

adaptive_filtering - Matlab implementation of AF

current_version.c - current version of the Filter (Matt's)

fxlms_filter.c - new version of the FXLMS filter

oaf.c - agent between Matlab and C (edited Matt's file)

Data samples can be found at nodus /users/den/wiener_filtering/data

  6199   Sun Jan 15 10:28:02 2012 DenUpdateAdaptive Filteringdelays

We can account for delays in the oaf system by compensating it in the adaptive path of the filter. But using only this procedure is not enough. Parameters mu and tau should be chosen accurately:

w = (1 - tau) * w;

w += mu * dw / norm;

NLMS algorithm without considering delays works well for mode cleaner length and gur1 seismometer signals, significantly reducing MC_F  with parameters mu=1, tau=0. These parameters are considered because nlms algorithm should converge with the highest speed when mu=1. However, if the system has a delay so at time moment n:

error_signal [n] = desired_signal [n] - filter_output [n-delay];

then the adaptive filter diverges for the same parameters mu=1 and tau=0 even for delay=1. For that reason we make the same calculations with tau = 1e-4 and tau = 1e-2 without reducing mu conserving the adaptation rate and get the same result as nlms algorithm without delays. Next figure shows MC_F signal, error after applying e-nlms filter with tau=1e-4 and tau=1e-2. "e-" is added to show that  a small number (epsilon) is added to the norm of the signal in order to prevent the filter from diverging in the beginning of the process when the norm is not well-determined yet.

2048_tau.png

The test was done offline with the sampling frequency 2048 Hz, without downsampling and any filters. We can see that tau=1e-4 is still not enough, tau=1e-3 or tau=1e-2 is as good as nlms without delays, tau=1e-1 and high are also bad.

Correctly choosing tau we have some freedom for delay compensation in the adaptation path. This is important as we do not know exactly what is the delay in the real system. We can measure it approximately. In order to figure out the range of reasonable delay errors we make a test with delay = 1, but to the adaptation path we give delays from 0 to 10. It turns out that adaptation path delays greater then 5 make the filter diverge, delays in the range 0-3 produce a reasonable error. In the figure below errors with adaptation path delays = 1 (correct) and 3 are presented.

2048_delays.png

ELOG V3.1.3-