40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 8 of 341  Not logged in ELOG logo
ID Date Author Type Categorydown Subject
  16041   Fri Apr 16 11:31:00 2021 ranaUpdateelogelog stuck ~10 AM today

found it unresponsive. Restarted fine using procedure documented in wiki

  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.

 

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

Foton Matlab Error     

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

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

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

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

  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.

  6083   Wed Dec 7 20:55:44 2011 Vladimir, DenUpdatedigital noiseMatlab error

Quote:

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

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

gain_cmp.png

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

freq R_gain matlab_gain octave_gain Foton_gain
1 3.05186270655452e-24 4.8824152e-22 3.05186271e-24 3.05186e-24
10 3.04698335947093e-18 1.8268825e-16 3.04698336e-18 3.04698e-18
100 2.99910841393644e-12 2.9991084e-12 2.99910841e-12 2.99911e-12
1000 2.60247212721439e-06 2.6024721e-06 2.60247213e-06 2.60247e-06
  7021   Tue Jul 24 21:16:55 2012 DenUpdatedigital noisequantization test

I'm trying to get some intuition how digital noise due to quantization shows up in iir filters. I decided to do tests in C using Python to calculate psd and visualize. I've implemented Direct Form 1, 2, "Biquad" and "Low Noise" forms of realization of second-order iir filter from Matt's presentation. There is a typo in the "Low Noise Form" scheme - a1 and a2 gains should be switched. Other then that schemes correctly implement 2 order iir. 

The input signal to each filter was a sine wave plus white noise with small amplitude x[n] = sin(2*pi*f*t[n]) + g*random( [-1, 1] ),  g << 1, f=1kHz. Sampling frequency was 16384 Hz. All 4 forms implemented 2 order low-pass butterworth filter with cut-off frequency 0.2 Hz

iir_2.png iir_8.png

For g=1e-2 all implementations work fine. For g=1e-8 when quantization noise increases, all implementations give a lot of noise at low frequencies. I did not notice any significant difference between any of these implementations. I'll try to do more tests to figure out any difference in noise between the forms.

Quantization noise depends on the architecture of the processor, compiler and what not. But I do not think this can give a huge difference in results. We need to understand carefully digital noise during PSD estimation and all operations done at Matlab or Python.

  7031   Wed Jul 25 16:55:01 2012 DenUpdatedigital noisenotch, lowpass filters

 Direct Form 2 is noisy in the first test. This is the one similar to Matt's in his presentation. Input signal was a sine wave at 1 Hz with small amplitude white noise x[n] = sin(2*pi*1*t[n]) + 1e-10 * random( [-1, 1] ). It was filtered with a notch filter: f=1Hz, Q=100, depth=210dB. SOS representation was calculated in Foton. Sampling frequency is 16kHz.

iir_psd.png        iir_time.png   iir_coh.png

DF2 output noise level is the same if I change white noise amplitude while DF1, BQF, LNF can follow it. Time series show quantization noise of DF2. I've plotted coherence of the signals relative to DF1, because non of the signals will be coherent to it at low frequencies due to fft calculations.  

In the second test the input was white noise  x[n] = random( [-1, 1] ) It was filtered with a 2 order low-pass butterworth filter with cut-off frequency f = 0.25 Hz. SOS representation was calculated in Python. Sampling frequency is 16kHz.

iir_psd_lowpass.png         iir_time_lowpass.png      iir_coh_lowpass2.png

In this test all implementations work fine. I guess dtt works with single precision and for that reason we see disturbance in coherence when we do the same test online.

  7034   Wed Jul 25 23:03:22 2012 ranaUpdatedigital noisenotch, lowpass filters

If the problem is the precision in DTT, then why would the noise change when the corner frequency of the filter is changed?

And how about checking for filter noise in the situation we saw online? 4th order low pass at 1 Hz or 8 Hz.

  7036   Thu Jul 26 10:22:03 2012 DenUpdatedigital noisenotch, lowpass filters

Quote:

If the problem is the precision in DTT, then why would the noise change when the corner frequency of the filter is changed?

And how about checking for filter noise in the situation we saw online? 4th order low pass at 1 Hz or 8 Hz.

 This is because when we plot signals with sampling frequencies 2k and 16k with the same BW, we actually create psd/coherence using different numbers of points in FFT calculations as NFFT ~ fs/bw, fs-sampling frequency. So we secretly used 8 times more fft points for 16k signal then for 2k signal. Following plots demonstrate this effect. The first plot shows transfer function and coherence for filtering of 16k signal with butter('LowPass',4,8) and 2k signal with butter('LowPass',4,1)  when BW=0.1. There is a disturbance in coherence for 2k signal below 2 Hz. Now let's take BW=0.8 and plot transfer function and coherence for 16k signal. We can see the same effect of coherence disturbance.

same_bw.png    16384_bw0p8.png

The similar effect takes place when we change the cut-off frequency. The following plots show transfer function and coherence of two pairs of 2kHz signals. 4 order butterworth low-pass filter was used. For the first pair cut-off frequency was 1 Hz, for the second 10 Hz.  On the first plot BW=0.1 and there is a disturbance in coherence below 1 Hz. However on the second plot when BW=0.01, this effect is lost.

corners_bw0p1.png     corners_bw0p01.png

I guess my goal is to figure out when these effects come from fft calculations and when from digital filter noise.

  7041   Thu Jul 26 17:39:49 2012 DenUpdatedigital noisebiquad key is working

 I've filtered a 1 Hz sin wave excitation with a notch filter inside c1sus and c1rfm models. The biquad key is switched on in the last one, c1sus uses DF2. The results are indeed different.

df2_bqf.png    df2_bqf_spec.png

Still I do not like huge (2n+1) harmonics in the output of the biquad filter, I do not get them in the simulations. They are absent in the time series as well. So this is not a psd-estimation effect.

iir_time_notch.pngiir_psd_notch.png

 

  7042   Thu Jul 26 21:31:44 2012 DenUpdatedigital noiseonline biquad works

Quote:

   Still I do not like huge (2n+1) harmonics in the output of the biquad filter, I do not get them in the simulations. They are absent in the time series as well. So this is not a psd-estimation effect. 

 Excitation generator created these harmonics. When I applied low-pass butterworth filter, I've got the result of online filtering close to simulations. On the second graph blue is biquad filter output spectrum, red corresponds to DF2. 1 Hz sin wave was filtered with a notch filter of Q=100, depth=300 at 1 Hz.

df2_bqf_lp.png    df2_bqf_lp_spec.png

  7045   Fri Jul 27 14:30:49 2012 JamieUpdatedigital noisebiquad key is working

What is "DQF"?  Is that the biquad?  And what is the difference between DF1 and DF2?  Why don't you just write out the name, so it's more clear.

  7050   Mon Jul 30 14:24:25 2012 DenUpdatedigital noisebiquad key is working

Quote:

What is "DQF"?  Is that the biquad?  And what is the difference between DF1 and DF2?  Why don't you just write out the name, so it's more clear.

DQF - biquad form
DF1 - direct form 1
DF2 - direct form 2
LNF - low-noise form
 
The difference between them is described in Matt's slides G0900928-v1. I think, LNF coefficients are incorrect in the presentation
 
lnf.png
  7052   Mon Jul 30 16:05:36 2012 DenUpdatedigital noisefilter checker

 We decided to write a script that will check online filters for digital noise. One method can be implemented using the following algorithm:

  • calculate filter output using single precision
  • calculate filter output using double precision and assume that it is precise
  • find digital noise at the output of the filter when single precision is used
  • extrapolate the result to the double precision filter dividing by 2D-S ~ 107, D - number of bits used in double precision mantissa, S - in single precision

Restriction: Single precision filter internal variables must be checked for overflows.

I applied this method to filtering a 1 Hz sine wave with a notch filter. Precise output should also be a 1 Hz wave => at other frequencies we see noise => digital noise spectrum should coincide with filter output. The plot shows the method worked out for this example.

iir_psd_notch.png

Using this method I estimated digital noise of butter("LowPass", 2, 0.001) applied to white noise. Sampling frequency was 16 kHz. 

iir_psd_lp.png iir_time_lp.png

  7085   Sat Aug 4 17:32:31 2012 DenUpdatedigital noisefilter checker

The script estimates digital noise produces by online filters. First version of Matlab files and complied c files are in scripts/digital_noise directory.

Algorithm for 1 filter bank (max number of filters = 10):

  1.        extract sos - representation from Foton file for each filter (Matlab)
  2.        download data from corresponding DQ channel using NDS (Matlab)
  3.        find filters that are switched on (Matlab)
  4.        filter signal using Df2 and BQF with single and double precision (C)
  5.        estimate digital filter noise (Matlab)
  6.        calculate power spectral density and plot the result (Matlab)

More details on (2)

Often DQ channels have reduced sampling rate. In this case the script will upsample data adding zeros.

AI filter is not applied. But in the end only the frequency range (0, DQ RATE / 2) is analyzed.

More details on (3):

This is done by reading C1:MODEL-BANK_NAME_SW1R and C1:MODEL-BANK_NAME_SW2R channels.
 
_SW1R channel value is the sum of the following numbers:
  • input switch ON / OFF => 4 / 0
  • filters 1 - 6 ON /OFF
    • 1 => 48 / 0
    • 2 => 192 / 0
    • 3 => 768 / 0
    • 4 => 3072 / 0
    • 5 => 12288 / 0
    • 6 => 49152 / 0
    • If a switch is ON but there is no corresponding filter (one green and one red line under the switch) then the switch value is divided by 3

_SW2R channel value is the sum of the following numbers:

  • decimation switch ON / OFF => 512 / 0
  • output switch ON / OFF => 1024 / 0
  • filters 7 - 10 ON /OFF
    • 7 => 3 / 0
    • 8 => 12 / 0
    • 9 => 48 / 0
    • 10 => 192 / 0
    • If a switch is ON but there is no corresponding filter (one green and one red line under the switch) then the switch value is divided by 3

Note: as for now Matlab script assumes that input, output and decimation filters are switched ON and there are no turned ON filter switches that do not correspond to any filters

More details on (5)

Digital noise using double precision is estimated by extrapolation of digital noise with single precision. The last is calculated by subtracting outputs of the filters with single and double precision. Then this noise is multiplied by 3 * 10-7.

This extrapolation number was achieved by printf tests of the number 0.123456789012345678 with single and double precision on C. Using type 'float' variables 10 significant numbers show up, using type 'double' - 17.

I also did 'calibration tests' to achieve extrapolation number - signal was filters with an aggresive low-pass filter. At high frequencies filter output spectrum is flat => digital noise amplitude must be the same. The plot shows GUR1_X channel filtered with low-pass chebyshev type 1 filter.

gur1x.png

However, extrapolation number is not the same for all cases. In the following example of analyzing BS_SUSPOS filter bank using extrapolation 3 * 10-7 we get noise that is slightly overestimated. In some other examples we need to take a larger number. But in average, I think, this is a good approximation.

C1SUS_BS_SUSPOS.png

To avoid extrapolation problem we can use long double precision (~19 digits). I was able to do this with gcc compiler. However, in mex compiler using long double in filter calculations, I do not get any better precision then using double precision. I'll think more about it.

  7676   Tue Nov 6 18:39:16 2012 DenUpdatedigital noiseifo checking system

Matlab version of ifo digital noise estimation code is almost ready. It estimates digital noise introduced by each filter bank in each model. I'm waiting for NDS group to complete function to download online data to Matlab. Now code downloads data from the past that is not great because not all _IN1 channels are recorded and some of them are recorded at lower frequencies.

There might be some useful functions in this code for other applications as I've heard during the meetings. This is what it does

  • reads model names from the input list
  • for each model
    • finds corresponding Foton file and extracts modules with sos filters and sampling rate of the model
    • finds corresponding MDL file and makes a search for subsystems with "top_names" tag and "biquad=1" tag
    • creates _IN1 channel names using module names and subsystems with "top_names" tag
    • for each channel inside the model
      • reads filter bank parameters (which filters are ON, switches, limit, offset...)
      • downloads data
      • calculates output and estimates digital noise
      • checks that output is less them limit if it is on
      • reports if something is wrong

NDS group plans to release the function to download online data this week. Hopefully, it will be possible to download ~30 channels at a time. Code will need a few minutes of data for each channel. So it will be possible to check the whole ifo during the night.

At this point I've checked 40m using DQ channels. We have ~40 IN1_DQ channels with non-empty filter banks. These are osems channels. Digital noise is low for them.

  1199   Sun Dec 21 13:00:06 2008 steveUpdateall down cond.vac and laser back on
There was a power outage sometimes early Saturday.

All things are down.

The Maglev was started and reached normal operating condition.
V1 was opened at P1 3.8 mTorr and cc1 is back to 3e-6 Torr now

The MOPA was turned on.
Ion pump HV on to FSS cavity.
  2025   Tue Sep 29 23:43:49 2009 ranaAoGall down cond.Cosmic

Actel1.jpg

cosmic rays in cars

  2344   Sun Nov 29 16:56:56 2009 robAoGall down cond.sea of red

Came in, found all front-ends down.

 

Keyed a bunch of crates, no luck:

Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS 

Powered off/restarted c1dcuepics.  Still no luck.

Powered off megatron.  Success!  Ok, maybe it wasn't megatron.  I also did c1susvme1 and c1susvme2 at this time.

 

BURT restored to Nov 26, 8:00am

 

But everything is still red on the C0_DAQ_RFMNETWORK.adl screen, even though the front-ends are running and synced with the LSC.  I think this means the framebuilder or the DAQ controller is the one in trouble--I keyed the crates with DAQCTRL and DAQAWG a couple of times, with no luck, so it's probably fb40m.    I'm leaving it this way--we can deal with it tomorrow.

  2345   Mon Nov 30 10:28:47 2009 AlbertoAoGall down cond.sea of red

Quote:

Came in, found all front-ends down.

 

Keyed a bunch of crates, no luck:

Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS 

Powered off/restarted c1dcuepics.  Still no luck.

Powered off megatron.  Success!  Ok, maybe it wasn't megatron.  I also did c1susvme1 and c1susvme2 at this time.

 

BURT restored to Nov 26, 8:00am

 

But everything is still red on the C0_DAQ_RFMNETWORK.adl screen, even though the front-ends are running and synced with the LSC.  I think this means the framebuilder or the DAQ controller is the one in trouble--I keyed the crates with DAQCTRL and DAQAWG a couple of times, with no luck, so it's probably fb40m.    I'm leaving it this way--we can deal with it tomorrow.

 I found the red sea when I came in this morning.

I tried several things.

  1. ssh into fb40m: connection refused
  2. telnet fb40m 8087: didn't respond
  3. shutdown fb40m by physically pushing the power button: it worked and the FB came back to life but still with a red light on the MEDM DAQ_DETAIL screen;
  4. powercycled fb40m AND C0DAQCTRL: no improvement
  5. shutdown fb40m, C0DAQCTRL, C1DCUEPICS and pushed the reset button on the RF network crate; then I restarted the computers in this order: fb40m, C1DCUEPICS, C0DAQCTRL: it worked: they came back to life and the lights eventually turned green on the MEDM montior screen

I'm now going to restart the single front -ends and burtgooey them if necessary.

  2346   Mon Nov 30 11:29:40 2009 AlbertoAoGall down cond.sea of red

Quote:

Quote:

Came in, found all front-ends down.

 

Keyed a bunch of crates, no luck:

Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS 

Powered off/restarted c1dcuepics.  Still no luck.

Powered off megatron.  Success!  Ok, maybe it wasn't megatron.  I also did c1susvme1 and c1susvme2 at this time.

 

BURT restored to Nov 26, 8:00am

 

But everything is still red on the C0_DAQ_RFMNETWORK.adl screen, even though the front-ends are running and synced with the LSC.  I think this means the framebuilder or the DAQ controller is the one in trouble--I keyed the crates with DAQCTRL and DAQAWG a couple of times, with no luck, so it's probably fb40m.    I'm leaving it this way--we can deal with it tomorrow.

 I found the red sea when I came in this morning.

I tried several things.

  1. ssh into fb40m: connection refused
  2. telnet fb40m 8087: didn't respond
  3. shutdown fb40m by physically pushing the power button: it worked and the FB came back to life but still with a red light on the MEDM DAQ_DETAIL screen;
  4. powercycled fb40m AND C0DAQCTRL: no improvement
  5. shutdown fb40m, C0DAQCTRL, C1DCUEPICS and pushed the reset button on the RF network crate; then I restarted the computers in this order: fb40m, C1DCUEPICS, C0DAQCTRL: it worked: they came back to life and the lights eventually turned green on the MEDM montior screen

I'm now going to restart the single front -ends and burtgooey them if necessary.

Everything is back on.

Restarted all the front ends. As usual c1susvme2 was stubborn  but eventually it came up.

I burt-restored all the front-ends to Nov 26 at 8am.

The mode cleaner is locked.

  2355   Sat Dec 5 14:41:07 2009 robAoGall down cond.sea of red, again

Taking  a cue from entry 2346, I immediately went for the nuclear option and powered off fb40m.  Someone will probably need to restart the backup script.

  2356   Sat Dec 5 15:20:10 2009 JenneAoGall down cond.sea of red, again

Quote:

Taking  a cue from entry 2346, I immediately went for the nuclear option and powered off fb40m.  Someone will probably need to restart the backup script.

 Backup script restarted.

  4011   Sun Dec 5 22:28:39 2010 ranaSummaryall down cond.power outage

Looks like there was a power outage. The control room workstations were all off (except for op440m). Rosalba and the projector's computer came back, but rossa and allegra are not lighting up their monitors.

linux1 and nodus and fb all appear to be on and answering their pings.

I'm going to leave it like this for the morning crew. If it

  4012   Mon Dec 6 11:53:20 2010 josephb, kiwamuSummaryall down cond.power outage

The monitors for allegra and rossa's seemed to be in a weird state after the power outage.  I turned allegra and rossa on, but didn't see anything.  However, I was after awhile able to ssh in.  Power cycling the monitors did apparently got them talking with the computers again and displaying.

I had to power cycle the c1sus and c1iscex machines (they probably booted faster than linux1 and the fb machines, and thus didn't see their root and /cvs/cds directories).  All the front ends seem to be working normally and we have damped optics.

The slow crates look to be working, such as c1psl, c1iool0, c1auxex and so forth.

Kiwamu turned the main laser back on.

Quote:

Looks like there was a power outage.

 

  4013   Mon Dec 6 11:57:21 2010 KojiSummaryall down cond.power outage

I checked the vacuum system and judged there is no apparent issue.

The chambers and annulus had been vented before the power failure.
So the matters are only on the TMPs.

TP1 showed the "Low Input Voltage" failure. I reset the error and the turbine was lift up and left not rotating.
TP2 and TP3 seem rotating at 50KRPM and the each lines show low pressur (~1e-7)
although I did not find the actual TP2/TP3 themselves.

Quote:

Looks like there was a power outage. The control room workstations were all off (except for op440m). Rosalba and the projector's computer came back, but rossa and allegra are not lighting up their monitors.

linux1 and nodus and fb all appear to be on and answering their pings.

I'm going to leave it like this for the morning crew. If it

 

  10019   Tue Jun 10 11:54:36 2014 ZachConfigurationWikiDokuWikis are still down

Not sure if someone is already on this, but the nodus DokuWikis are still down (AIC, ATF, Cryo, etc.)

I get:

DokuWiki Setup Error

The datadir ('pages') does not exist, isn't accessible or writable. You should check your config and permission settings. Or maybe you want to run the installer

  10021   Tue Jun 10 19:11:27 2014 EvanConfigurationWikiDokuWikis are back up

As of this writing, the DokuWiki appears to be working.

As you and I suspected, it looks like this was a clusterwhoops with the permissions for the NFS mount. Let's recap what happened in the past 24 hours:

  1. Yesterday, 8 PM: I restart the Apache server, thereby resurrecting the SVN (now conveniently located at /export/home/svn). The DokuWikis remain borked.
  2. Yesterday, 7 to 11 PM: Zach, Rana, and Jenne perform deep magic to get the front-end machines up and running again. This should be irrelevant for this Apache/SVN/DokuWiki witchcraft.
  3. Today, morning: the townsfolk happily resume their svn up and svn ci festival.
  4. Today, ca. 3 PM: Zach runs stopapache.sh to bring down Apache, thinking he can bring it back up momentarily with startapache.sh. But NFS is a jealous and vengeful god, and Apache now complains that it doesn't have permission to write to its logfiles, and therefore can't start httpd.
  5. Today, 5 PM: "How can this be?", Zach and I ask. Apache had no problem starting up yesterday night, and to our knowledge nobody futzed with chiara's NFS mount of /home/cds. This change remains mysterious to us.

Despite the aforementioned mystery, Zach and I pressed on and tried to diagnose the permissions issue. We found that even if you are logged into nodus or pianosa or rossa or whatever as the controls user, the NFS mount saw us as the user nobody (in the group nogroup). If we created a file on the NFS mount, it was owned by nobody/nogroup. If we tried to modify a file on the NFS mount that was owned by controls/controls or controls/staff, we got a "permission denied" error, even if we tried with superuser privileges.

It turns out this has to do with the vagaries of NFS (scroll down to gotcha #4). We have all_squash enabled in /etc/exports , which means that no matter your username or group on nodus, rossa, pianosa, or harpischordsa, NFS coerces your UID/GID to chiara's nobody/nogroup. Anyway, the fix was to go into chiara's /etc/exports and change this

/home/cds 192.168.113.0/255.255.255.0(rw,sync,no_subtree_check,all_squash,insecure)

to this

/home/cds 192.168.113.0/255.255.255.0(rw,sync,no_subtree_check,all_squash,anonuid=1001,anongid=1001,insecure)

where 1001/1001 are the UID/GID for chiara's controls/controls (as opposed to 65534/65534 for chiara's nobody/nogroup). That way, the NFS mount sees you as chiara's controls/controls.
 
In order to make chiara's NFS daemon aware of the new /etc/export settings, I ran sudo exportfs -r based on the answer to this StackOverflow question. As with all the best StackOverflow questions, the moderators closed it for being "off-topic".
 
[Edit, 2014-06-11, 11 AM: I've repeated the above anonuid/anongid change for the /home/cds/caltech/home/controls mount, so that nodus's /home/controls is writeable as well. I've also added a .screenrc for nodus in order to maintain sanity.]
  10022   Wed Jun 11 05:16:14 2014 ZachConfigurationWikiDokuWikis are back up

It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.

Quote:

As of this writing, the DokuWiki appears to be working.

 

  10024   Wed Jun 11 10:15:15 2014 EvanConfigurationWikiDokuWikis are back up

Quote:

It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.

Quote:

As of this writing, the DokuWiki appears to be working.

 

I went into local.php and changed $conf['useacl'] = 1; to $conf['useacl'] = 0; and it looks like the auth issue goes away (I've changed it back). This isn't a fix (we want to use access control), but it gives us a clue as to where the problem is.

  10029   Wed Jun 11 20:09:37 2014 ZachConfigurationWikiDokuWiki situation

I have been looking into the DokuWiki situation, with no great progress so far.

The problem is with authentication. When you try to access the wiki, you get: "User authentication is temporarily unavailable. If this situation persists, please inform your Wiki Admin."

 As Evan points out, this goes away if you turn off ACL (Access Control Lists), but---as he also mentions---that just means that authentication is disabled, so the wiki becomes open. All signs point to this being a problem with the authentication mechanism. We use the 'authplain' plaintext method, where the usernames and hashed passwords are stored in a plaintext file.

Evan and I have both done plenty of testing with the config settings to see if the problem goes away. Even if you restore everything to default (but enable ACL using authplain and the existing user file), you still get an error.

I went as far as installing a brand new wiki on the web server, and, surprisingly, this also exhibits the problem. Interestingly, if I install an old enough version (2012-10-13), it works fine. After this revision, they transitioned their authentication methods from "backends" to "plugins", so this is a clue. As a side note, the other wikis on nodus (ATF and Cryo) are running earlier versions of DokuWiki, so they have no problems.

As it stood, our options were:

  1. No wiki (not even read-only, since the issue prevents logging in and also prevents anonymous reading, somehow)
  2. No ACL = open wiki. Also not good.

So, I created a temporary read-only version of the wiki using the aforementioned earlier DokuWiki release. It has a soft link to the real wiki data, but I deleted the user database so no one can log in and edit (I also disabled registration). It can be found at https://nodus.ligo.caltech.edu:30889/wiki_ro/.

I also created a backup of the real wiki as wiki_bak to avoid any potential disasters.

The simplest thing to do would be to just roll the wiki back to this working version, but that doesn't sound so smart. Clearly, it was working with the plugin structure before our snafu, and somehow our fixing everything else has broken it.

Quote:

Quote:

It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.

I went into local.php and changed $conf['useacl'] = 1; to $conf['useacl'] = 0; and it looks like the auth issue goes away (I've changed it back). This isn't a fix (we want to use access control), but it gives us a clue as to where the problem is.

 

  10355   Fri Aug 8 16:45:40 2014 NichinUpdateWikiPDFR wiki updated

 The PDFR system has been documented in the 40m wiki and all the relevant information about making changes and keeping it updated have been mentioned.

https://wiki-40m.ligo.caltech.edu/Electronics/PDFR_system

This pretty much wraps up my SURF 2014 project at the 40m lab. 

  10366   Mon Aug 11 23:50:38 2014 ranaConfigurationWikiDokuWikis are back up

Quote:

Quote:

It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.

I went into local.php and changed $conf['useacl'] = 1; to $conf['useacl'] = 0; and it looks like the auth issue goes away (I've changed it back). This isn't a fix (we want to use access control), but it gives us a clue as to where the problem is.

 There was still some residual permissions issue. This is now bypassed and so the ACL is ON and all seems to be back the way it was. I've tested that I can login and edit the wiki.


Some useless knowledge follows here. Please ignore.

After some hours of reading unhelpful DokuWiki blogs, I just put the backup wiki into the local disk on NODUS and then made a soft link to point to that from /users/public_html/wiki/. So this implies that the new NFS setup on chiara is different enough that it doesn't allow read/write access to the apache user on the NODUS/Solaris machine.

  10393   Thu Aug 14 20:52:36 2014 ranaUpdateWikiViolin Mode table added to Wiki

Mech Resonance Wiki

I've updated the wiki by trawling the elog for violin entries. Please keep it up to date so that we can make violin notches.

 

  12935   Mon Apr 10 15:22:46 2017 ranaConfigurationWikiDokuWikis are back up

AIC Wiki updated to latest stable version of DokuWiki: 2017-02-19b "Frusterick Manners" + CAPTCHA + Upgrade + Gallery PlugIns

  13767   Thu Apr 19 09:57:03 2018 gautamUpdateWikiAP and ETMX tables uploaded to wiki

The most up to date pictures of the AP table and ETMX table that Steve took have been uploaded to the relevant page on the wiki. It seems like the wiki doesn't display previews of jpg images - by using png, I was able to get the thumbnail of the attachment to show up. It would be nice to add beam paths to these two images. The older versions of these photos were moved to the archive section on the same page.

  13776   Fri Apr 20 16:25:08 2018 SteveUpdateWiki ETMX table layout uploaded to wiki

ETMX table layout uploaded with beam paths to the wiki.   laugh

  13785   Tue Apr 24 15:59:23 2018 SteveUpdateWiki AP table layout 20180328
Quote:

ETMX table layout uploaded with beam paths to the wiki.   laugh

The pdf file is uploaded into the wiki.

Attachment 1: DSC00668AP20180328.png
DSC00668AP20180328.png
  14173   Tue Aug 21 09:16:23 2018 SteveUpdateWiki AP table layout 20180821

 

 

Attachment 1: 20180821.JPG
20180821.JPG
  15429   Wed Jun 24 22:47:21 2020 YehonathanUpdateWikiUpdated phase maps webpage
I uploaded the new phase maps measurements made by GariLynn to nodus and updated the optics phase maps page.
I also added MetroPro and Matlab analysis for these phase maps.
  15614   Tue Oct 6 07:37:20 2020 yehonathanUpdateWikiNew TIS measurements of 40m Optics

LiYuan has kindly done some Total Integrating Sphere (TIS) measurements on ITMU01 and ITMU02. A summary of the measurement is attached. I uploaded the measurements and some analysis script to nodus at /home/export/home/40m_TIS. I created a Wiki page for the measurements and linked to it from the core optics page.

These TIS measurements look very similar to the TIS of the LIGO optics. Further analysis shows that the scatter loss is 10+/-1.7 ppm for ITMU01 and 8.6+/-0.4 ppm for ITMU02.

In this calculation, a gaussian beam the same size bouncing off the 40m ITMs is assumed to scatter from the mirrors. The error is calculated by moving the beam around randomly with STD of 1mm.

In LiYuan's setup, TIS is measured for scattering angles between 1 and 75 degrees. If we go further and assume that the scatter is Lambertian we can extrapolate that the total loss is 10.9+/-1.9 ppm for ITMU01 and 9.2+/-0.5 ppm for ITMU02.

These measurements complete the loss budget nicely since with the 6ppm loss predicted from the phase maps, the total loss in the arm cavities would be 6+10+10=26ppm which is very close to the 28ppm loss that was measured after the arm cavity optics were cleaned.

Attachment 1: ITMU_sn01-02_tis_1.pdf
ITMU_sn01-02_tis_1.pdf ITMU_sn01-02_tis_1.pdf
  16614   Mon Jan 24 12:33:41 2022 ranaConfigurationWikiAIC Wiki: txz files allowed

I updated the mime.local.conf file for the AIC Wiki so as to allow attachments with the .txz format. THis should be persistent over upgrades, since its a local file.

  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
  2425   Thu Dec 17 02:57:08 2009 JenneUpdateWienerFilteringL1 DARM Static Wiener Filtered data

This is perhaps best put in the LLO elog, but I'm not yet a 'person' there, so I can't write to their elog (yet another thing for the eternal to-do list).  So for now, we're putting things here...

This isn't totally finalized, but I do want to get what I have posted before I hop on a plane in the morning.  Mostly it just needs more time to run, to make the plot longer.  Hopefully I'll be able to edit this in the morning and have a longer-duration plot. 

What's plotted:

This spectrogram shows the amplitude spectra of L1:LSC-DARM_CTRL, after being subtracted via a Static Wiener Filter.  Each spectra is normalized by the very first one, which was created from the same data that was used to determine the Wiener Filter.  The X-axis is time.  The Y-axis is frequency, and the Color/Z-axis is amplitude in dB.  I'm only looking at Science Mode time, so other times when the IFO isn't in science mode, I plot a black stripe to fill in the plot.  The start time of the plot is 83675598, which is Jul 08 2006 06:33:04 UTC. 

Why?

The idea is to see that the filter does equally well a long time after it was created, as when it was initially made.  This will help tell us how often it is useful to recompute the Wiener filters.  Less often is nice, because redoing the Wiener filters may also include remeasuring the high precision transfer functions...if the filter isn't working as well anymore it may be because the transfer function has changed ever so slightly. 

How the plot is created / the background story:

I use one hour of DARM_CTRL data and the following seismometer channels to create an optimal Wiener Filter (pem indicates L0:PEM- , sei indicates L1:SEI- , and lsc indicates L1:LSC- ) :

chans = {[pem 'EX_SEISX'],...
         [pem 'EX_SEISY'],...
         [pem 'EX_SEISZ'],...
         [pem 'EY_SEISX'],...
         [pem 'EY_SEISY'],...
         [pem 'EY_SEISZ'],...
         [pem 'LVEA_SEISX'],...
         [pem 'LVEA_SEISY'],...
         [pem 'LVEA_SEISZ'],...
         [sei 'LVEA_STS2_X'],...
         [sei 'LVEA_STS2_Y'],...
         [sei 'LVEA_STS2_Z'],...
         [sei 'ETMX_STS2_X'],...
         [sei 'ETMX_STS2_Y'],...
         [sei 'ETMX_STS2_Z'],...
         [sei 'ETMY_STS2_X'],...
         [sei 'ETMY_STS2_Y'],...
         [sei 'ETMY_STS2_Z'],...
         [lsc 'DARM_CTRL']};

I then apply this one filter to ten minute chunks of science mode data, for some long period of time.  The game plan is to have a month long plot, but it takes a while to fetch all of the data in separate 10min intervals (~45sec per iteration, times ~3000 iterations), so this plot isn't a full month.  Even if I don't get a chance to plot a full month by Thursday morning, it'll go up here within the next few days. The particular times chosen have the most science mode data within a 30 day period.  I can easily run the code for some other time, if there is a known time (or season) which might be more interesting.  For the spectrogram plot, I then normalize each amplitude spectra by the first one, which comes from the first ten minutes in the hour which was used to make the filter.  This makes it easier to see how the filter's efficacy changes over time.

The analogous analysis for Hanford is in the 40m elog: 1606.  The Hanford stuff in the elog has some cool BLRMS plots also, but I'm not sure that they're so helpful when I only have a few days of L1 data so far.  I'll do those and add them later.

Conclusions:

I can't really say anything yet about the long-term efficacy of a Wiener Filter for LLO yet, since my code hasn't finished filtering my one month of S5 L1 data.  It definitely looks like (so far) that there was a big seismic event around the (arbitrarily defined) 'Day 4'. 

Attachment 1: L1darmCompPlot_17Dec2009_4daysLong.png
L1darmCompPlot_17Dec2009_4daysLong.png
  2426   Thu Dec 17 07:47:29 2009 JenneUpdateWienerFilteringL1 DARM Static Wiener Filtered data

This surface plot is the same as the previous one, with a little more data than I had previously. 

This time around, I also include the "BLRMS" plots for this data.  The first one takes each residual and normalizes it by the DARM_CTRL signal at that time, separates the spectra into bands, and integrates underneath the spectra within that band.  The second one is the raw DARM_CTRL signal's spectra at each time, and integrates under the spectra for each band, and the third BLRMS plot does the same thing for the residuals.  Unfortunately, these plots don't have the same handy black stripe during time which I don't analyze that the spectrogram utilizes.

From the second BLRMS plot we can see that the large red splotch in the spectrogram is due to higher noise in the DARM spectrum, and that (by looking at the Ratio BLRMS plot) the Wiener filter still does a pretty good job during this time.  I expect that for later times when the seismic (or something) event is gone, the Wiener filter will continue performing almost as well as it had been initially.

Again, once the script finishes applying the filter to the many ten minute chunks (the huge time drain is the data fetching, so this shouldn't be a limiting factor for using Wiener filters online), I'll post a final plot.

Attachment 1: L1darmComp_17Dec2009_6day_residualsNormSurfacePlot.png
L1darmComp_17Dec2009_6day_residualsNormSurfacePlot.png
Attachment 2: L1darmComp_17Dec2009_6day_ratioBLRMS.png
L1darmComp_17Dec2009_6day_ratioBLRMS.png
Attachment 3: L1darmComp_17Dec2009_6day_rawBLRMS.png
L1darmComp_17Dec2009_6day_rawBLRMS.png
Attachment 4: L1darmComp_17Dec2009_6day_residualsBLRMS.png
L1darmComp_17Dec2009_6day_residualsBLRMS.png
  2475   Tue Jan 5 01:31:09 2010 JenneUpdateWienerFilteringNew Wiener Filters installed in PEM IIR matrix on OAF screen

Using the techniques employed at LLO, and then by Rana here at the 40m a few weeks ago, Wiener filters have been installed on the inputs of all of the PEM IIR channels which are hooked up to the 110B PEM ADCU.  Some slight modifications have taken place to the code, and it's all been checked in to the 40m svn. 

I have installed the filters into:  All 6 Wilcoxon accelerometers, the Ranger seismometer, and one of the Guralps (GUR1).  The other Guralp is currently connected through the ASS/OAF machine's ADC, so it's not used in this test. The filters are all labeled "Wiener", and are FM1 in the C1:ASS-TOP_PEMIIR_## filter banks.

The first figure below is the output of the Wiener Filter calculation program.  It shows the uncorrected MC_L (black) and the corrected MC_L (red), using the optimal wiener filter.  This is as good as we should be able to do with these sensors in these positions.

The second figure is a DTT shot of me trying out the nifty new filters.  They seem to maybe do a teensy bit on the microseism, but otherwise it's a bit unremarkable.  Hopefully I'll get better subtraction during the day, when the base level for MC_L is higher.  Here, Black is uncorrected MC_L, Red is the corrected MC_L, Blue is the actuation channel, and green is an example seismometer channel to illustrate the ground motion at the time.

 

For posterity, since it's not all in one elog that I can find, the order of operations to install a Wiener Feed Forward filter is as follows:

1.  (When you can borrow the IFO) Take a very careful TF of the plant, between your actuation point and your error signal readout.  At the 40m, this means between C1:ASS-TOP_SUS_MC1_EXC and C1:IOO-MC_L, since we actuate by pushing on the MC1 coils.  At the sites / future 40m, this would be between the HEPI (or STACIS) and the error signal.  The limit of how good your Feed Forward can do will depend heavily on how good this TF is.  Coherence should be above ~0.95 for all points.  Export this data from DTT as a .txt file, using units "Complex (abs/rad)". 

2. Run fitMC12MCL.m (or equivalent wrapper file) to fit the transfer function you just took with some Poles and Zeros.  Make sure to edit the wrapper file with your new .txt file's name so you're getting a fresh TF (if you've just taken one).

3. (Again, when you can borrow the IFO) Run getMCdata.m (or equivalent) to fetch witness channel data and error signal data.  At the 40m, this usually means C1:IOO-MC_L, and witness sensors which are around the MC chambers.  This data should be taken at a time when the cavity is locked, but pretty much on it's own. (i.e. probably shouldn't have Common Mode feedback on the MC - so the MC should be locked, but not the full IFO, for example.)

4.  Run c1winoiir.m (the main program here, which contains some of these notes). This will take in the TF data you've fit, and the witness channel data you have, and calculate the optimal combination of Wiener filters for your witness channels.  It pre-filters your witness data by your TF, then calculates the Wiener filter.  The resulting FIR filters are saved in a file.

5.  Run firfit.m  This will take the FIR Wiener filters you've just created, and convert them conveniently to IIR filters, in a format to be copied directly into Foton.  For each witness channel, you'll get the IIR filter in 2 formats:  the first is for copying into the Foton .txt file (ex ASS.txt), and the second is for copying into the Foton gui, in the "Command" box on the filter design screen.  The "o" at the end of the copy-able filter indicates to Foton that it is a Z-Plane Online filter.  Copy filters appropriately (there should be a line preceding each set of SOS filter formats to indicate which channel this Wiener filter is for...these channel names are extracted from your getMCdata.m)

6. Save your Foton file, and update your Coefficients in MEDM.  Enable your outputs to actuators, and watch magic happen!

 

On the To-Do list:

Check the transfer of signal btwn PEMIIR matrix and the 9x1 'matrix' that sends the signals to the SUS inputs.  In the SimuLink, the input to the 9x1 matrix is a bundle of 8 numbers (the 8 outputs of the PEMIIR matrix), but it looks like it only pays attention to the first one.  Need to figure out how to make it realize that it's a bundle, not a single number. 

Also, the OAF up / down scripts don't seem to be working on any of the control room computers.  This needs to be checked in to / fixed (but not tonight....)

Attachment 1: MCwino-FFtest_4Jan10_sameFiltersAsinEPICS.png
MCwino-FFtest_4Jan10_sameFiltersAsinEPICS.png
Attachment 2: OAF-FF_test_4Jan10.png
OAF-FF_test_4Jan10.png
ELOG V3.1.3-