40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 332 of 339  Not logged in ELOG logo
New entries since:Wed Dec 31 16:00:00 1969
ID Date Author Type Categoryup Subject
  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

 

  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.

  2131   Wed Oct 21 17:12:30 2009 AlbertoUpdateelogBrowser context menu enabled on the Elog under HTM editing mode

On behalf of Steve and of the rest of the not-native-English community at the 40m willing to have their browser's spell checker working while editing the Elog, I fixed the Elog's feature that prevented Firefox' context menu (that one which pops up with a mouse right click) to work when using the HTML editing interface (FCKeditor).

That let also Firefox spell checker to get enabled.

To get the browser context menu just press CTRL right-clicking.

To make sure that the features works properly on your browser, you might have to fully clear the browser's cache.

Basically I modified the FCKeditor config file (/cvs/cds/caltech/elog/elog-2.7.5/scripts/fckeditor/fckconfig.js). I added this also to the elog section on our Wiki.

  2200   Fri Nov 6 19:29:24 2009 JenneUpdateelogelog acting up

elog was acting up again (not running), so I restarted it. 

  2201   Fri Nov 6 20:10:15 2009 JenneUpdateelogelog acting up

Quote:

elog was acting up again (not running), so I restarted it. 

 

And again.  This makes 4 times since lunchtime yesterday....something bad is up.

  2302   Thu Nov 19 16:04:48 2009 AlbertoConfigurationelogElog debugging output - Down time programmed today to make changes

We want the elog process to run in verbose mode so that we can see what's going. The idea is to track the events that trigger the elog crashes.

Following an entry on the Elog Help Forum, I added this line to the elog starting script start-elog-nodus:

./elogd -p 8080 -c /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg -D -v > elogd.log 2>&1

which replaces the old one without the part with the -v argument.

The -v argument should make the verbose output to be written into a file called elogd.log in the same directory as the elog's on Nodus.

I haven't restarted the elog yet because someone might be using it. I'm planning to do it later on today.

So be aware that:

We'll be restarting the elog today at 6.00pm PT. During this time the elog might not be accessible for a few minutes.

  2303   Thu Nov 19 18:49:55 2009 AlbertoConfigurationelogElog debugging output - Down time programmed today to make changes

Quote:

We want the elog process to run in verbose mode so that we can see what's going. The idea is to track the events that trigger the elog crashes.

Following an entry on the Elog Help Forum, I added this line to the elog starting script start-elog-nodus:

./elogd -p 8080 -c /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg -D -v > elogd.log 2>&1

which replaces the old one without the part with the -v argument.

The -v argument should make the verbose output to be written into a file called elogd.log in the same directory as the elog's on Nodus.

I haven't restarted the elog yet because someone might be using it. I'm planning to do it later on today.

So be aware that:

We'll be restarting the elog today at 6.00pm PT. During this time the elog might not be accessible for a few minutes.

 I tried applying the changes but they didn't work. It seems that nodus doesn't like the command syntax.

I have to go through the problem...

The elog is up again.

  2562   Tue Feb 2 18:15:47 2010 AlbertoUpdateelogElog restarted it

 Zach made me notice that the elog had crashed earlier on this afternoon. 

I just restarted it with the restarting script.

Instructions on how to run the last one are now in the wiki page. Look on the "How To" section, under "How to restart the elog".

  2567   Wed Feb 3 10:46:12 2010 AlbertoUpdateelogelog restarted

 Again, this morning Zach told me that the elog had crashed while he was trying to post an entry.

I just restarted it.

  2569   Thu Feb 4 00:59:52 2010 ranaUpdateelogelog restarted

 I restarted the ELOG on NODUS just now. Our attempt to set up error logging worked - it turns out ELOG was choking on the .ps file attachment.

So for the near future: NO MORE .PS files! Use PDF - move into the 20th century at least.

matlab can directly make either PNG or PDF files for you, you can also use various other conversion tools on the web.

Of course, it would be nice if nodus could handle .ps, but its a Solaris machine and I don't feel like debugging this. Eventually, we'll give him away and make the new nodus a Linux box, but that day is not today.

  2669   Fri Mar 12 13:52:18 2010 ZachUpdateelogelog restarted

 The elog was down and I ran the restart script.

  2702   Tue Mar 23 15:38:26 2010 AlbertoUpdateelogelog just restarted

I found the elog down and I restarted it.

Then, after few seconds it was down again. Maybe someone else was messing with it. I restarted an other 5 times and eventually it came back up.

  2739   Wed Mar 31 10:34:02 2010 josephbUpdateelogElog not responding this morning

When I went to use the elog this morning, it wasn't responding.  I killed the process on nodus, and then restarted, per the 40m wiki instructions.

  2758   Fri Apr 2 08:52:21 2010 AlbertoUpdateelogelog restarted

i just restarted the elog for the third time in the past 12 hours.

I checked the elog.log file to debug the problem. It doesn't contain eveidence of any particular cause, except for png/jpg file uploads happened last night.

I'm not sure we can blame Image Magic again because the last crash seems to be occurred just after an entry with e jpg picture was included in the body of the message. I think Image Magic is used only for previews of attachments like pdfs or ps.

Maybe we should totally disable image magic.

  2817   Tue Apr 20 13:00:52 2010 ZachUpdateelogelog restarted

 I restarted the elog with the restart script as it was down.

  2853   Wed Apr 28 08:55:19 2010 ZachUpdateelogelog restarted

 Restarted the elog with the script as it was down.

  2854   Wed Apr 28 09:21:16 2010 ZachUpdateelogelog restarted

And again.

Quote:

 Restarted the elog with the script as it was down.

 

  2979   Tue May 25 07:58:23 2010 kiwamuUpdateelogelog down

I found the elog got down around 7:30 am in this morning.

So I restarted it by running the script: "start-elog-nodus" as instructed on the wiki.

http://lhocds.ligo-wa.caltech.edu:8000/40m/How_To/Restart_the_elog

  3071   Sat Jun 12 18:03:00 2010 sharmilaUpdateelogTemperature Controller

Kiwamu and I setup a serial port terminal for receiving data from TC200 via a RS-232 USB interface. It was done using a Python code. Some command definitions need to be done to get the output from TC-200.

  3181   Thu Jul 8 17:29:20 2010 Katharine, SharmilaUpdateelog 


Last night, we successfully connected and powered our circuit, which allowed us to test whether our OSEMs were working.  Previously, we had been unable to accomplish this because (1) we weren't driving it sufficiently high voltage, and  (2) we didn't check that the colored leads on our circuit actually corresponded to the colored ports on the power supply (they were all switched, which we are in the process of rectifying), so our circuit was improperly connected to the supply .  Unfortunately, we didn't learn this until after nearly cooking our circuit, but luckily there appears to have been no permanent damage .

Our circuit specs suggested powering it with a voltage difference of 48V, so we needed to run our circuit at a difference of at least 36-40 V.  Since our power supply only supplied a difference of up to 30V in each terminal, we combined them in order to produce a voltage of up to double that.  We decided to power our circuit with a voltage difference of 40V (+/- 20V referenced to true ground).  The current at the terminals were 0.06 and 0.13 A. 

To test our circuit, we used a multimeter to check the supplied voltage at different test points, to confirm that an appropriate input bias was given to various circuit elements.  We identified the direction of LED bias on our OSEM, and connected it to our circuit. We were extremely gratified when we looked through the IR viewer and saw that, in fact, the LED in the OSEM was glowing happily .

P7070240.JPG P7070242.JPG

We hooked up two oscilloscopes and measured the current through the coil, and also through the LED and photodiode in the OSEM.  We observed a change in the photodiode signal when we blocked the LED light, which was expected.  The signal at the PD and the LED were both sinusoidal waves around ~3 kHz.

P7070255.JPG 

P7070257.JPG

 

We then went back to our levitation setup, and crudely tried to levitate a magnet with attached flag by using our hands and adjusting the gain (though we also could have been watching the PD current).  The first flag we tried was a soldering tip; we couldn't levitate this but achieved an interesting sort of baby-step "levitation" (levitation .15) which allowed us to balance the conical flag on its tip on top of the OSEM (stable to small disturbances).  After learning that conical flags are a poor idea, we switched our flag to a smaller-radius cylindrical magnet.  We were much closer to levitating this magnet, but were unable to conclusively levitate it .

 P7070249.JPG
Current plan:

Adjust the preset resistors to stabilize feedback

Check LED drive circuit.

Finish calculating the transfer function, and hook up the circuit to the spectrum analyzer to measure it as well.

Observe the signal from the photocurrent as disturbances block the LED light.

Play with the gain of the feedback to see how it affects levitation.

 

Attachment 1: P7070254.JPG
P7070254.JPG
  3200   Mon Jul 12 21:26:02 2010 Katharine, SharmilaUpdateelogmaglev coils

The connection between our coil wires and BNC terminals was pretty awful (soldered wires broke off ) so we removed the old heat shrink and re-soldered the wires.  We then chose more appropriately sized heat shrinks (small one around each of the two soldered wires, a medium-sized shrink around the wires together, a large one covering the BNC terminal and the wire) and used the solder iron and heat gun to shrink them.

P7120276.JPG

 

 

  3212   Wed Jul 14 01:05:27 2010 Sharmila,KatharineSummaryelogMaglev

Yesterday we hooked up the Quadrant Maglev control to the power supply to test the components in the Input/Output part of the circuit.

The output from the buffer was an unexpected high noise signal which was caused by some circuit components.

Consequently these were replaced/removed after confirming the source of noise.

The following is a story of how it was done.


To test the components of input/output, we measured the output across TP_PD3(Test Point -Photo Diode 3).
We got a high noise signal with a frequency of several kHz.

We tested the values of various electronic components. The resistances R5 and R6 did not measure as mentioned(each had a value of 50 K in the schematic). The value of R6 was 10 K and we replaced R5 with a 10 K resistor. We still got the noise signal at 5.760 kHz with a Pk-Pk voltage of 2.6 V. The resistors in R-LED measured 1.5 K instead of the marked 2.2 K.

P7120278.JPG
We had three suspects in hand:

  • BUF634P : A buffer from the Sallen-Key filter to the LED.
  • C24 : A capacitor which is a part of the Sallen-Key filter.
  • C23 : A capacitor in the feedback circuit of the Sallen-Key filter.


BUF634P : The data sheet for the BUF634P instructed a short across the 1-4 terminals in the presence of capacitive load.  We followed this to overcome the effect(if any) of the extra-long BNC cables which we were using. The oscilloscope still waved 'Hi!' at a few kHz. We removed the buffer and also the feedback resistor R42 from the circuit, what we were testing boiled down to measuring the output of the Sallen-Key filter. The output still contained the funny yet properly periodic signal at a few kHz.      

.P7120284.JPG    


C24: Removing C24 did not do any good.

C23: As a final step C23 was removed. And ... We got a stable DC at 9.86 V(almost stable DC with a low noise at a few MHz). C24 and the buffer were replaced and output seemed fine. The output was a high frequency sine wave which was riding on a DC of 9.96 V.

 

P7120281.JPG


We rechecked if the LED was on and the infrared viewer gave a positive signal.



We went ahead obtaining the transfer function of the feedback control for which we used a spectrum analyzer.

The input for feedback system is a photo current whereas the spectrum analyzer tests the circuit with a voltage impulse.  Hence the voltage input from the spectrum analyzer needs to be converted into current of suitable amplitude(few microamps) for testing the spectrum analyzer.  Similarly the output which is a coil current needs to be changed to a voltage output through a load for feeding into the channel of the spectrum analyzer. We used a suitable resistance box with BNC receiving ends to do this. We obtained a plot for the transfer function which is shown below.

P7140292.JPG


Future plans:

- Check the calculated transfer functions with the plot of the spectrum analyzer

- Model the entire(OSEM, magnet, actuators etc.) system in Simulink and calculate the overall transfer function

- Stable levitation of the 1X1 system

  3234   Fri Jul 16 12:36:00 2010 Katharine, SharmilaUpdateeloglevitation

After last night's challenge (or inspiration), we levitated our magnet this morning.  Since the nice Olympus camera is not currently in the 40m, we had to use my less stellar camera, but despite the poor video quality you can still see the magnet returning to its stable equilibrium position.  Once we recover the better camera, we will post new videos.  Also, we haven't yet figured out how to put videos in line in the elog entry, so here are the youtube links:

 

levitation 1

levitation 2

 

We adjusted the gain on coil 1 so that the resistance from the pots was 57.1k (maximum gain of 101.2,).

currents from power supply, pre-levitation: 0.08 A and 0.34 A

post levitation: 0.08 A and 0.11 A


note: we're not sure why changing the gain on coil 3 changes the current through the power supply, so we'd like to investigate that next.

Attachment 1: CIMG0649.AVI
  3250   Tue Jul 20 11:55:15 2010 Sharmila,KatharineUpdateelogMaglev

We plotted the transfer functions for the maglev control circuit and compared them with the plots from the spectrum
analyzer. We were stuck for sometime because

1) we had wrongly entered the value of one of the resistors which was off by a factor of 2000.
2) The plots were not done in right units. So we couldn't figure out differences quite well.

The two plots are shown below. We are still off by a factor of 3 which we'll figure out soon.

P7140292.JPG

  3382   Sat Aug 7 10:47:38 2010 KojiSummaryelogelog restarted / source of the trouble eliminated

Nancy notified me that the elog crashed. It was fixed.


I restarted elog, but it kept crashing. Some of the entries on Aug 6th caused the trouble.

I tried to refresh the pictures in entries 3376, 3377, 3378. Still it kept crashing.
I started to dig into the elog file itself. (/cvs/cds/caltech/elog/elog-2.7.5/logbooks/40m/100806a.log)

FInally I found that there was some invalid reply links in the entry 3379.

Date: Fri, 06 Aug 2010 19:29:59 -0700
Reply to: 3379
In reply to: 3379

The entry is refering this entry itself. That is weird. So I deleted the reply-to and in-reply-to lines.
Then elogd got happy.

In fact, 3379 was a dupulication of 3380, so I deleted this entry.

  3390   Tue Aug 10 01:05:17 2010 ZachUpdateelogelog restarted

 Elog was down. Restarted with the script.

  3396   Wed Aug 11 02:44:37 2010 ZachUpdateelogelog restarted

You'll never guess what happened: the elog crashed!

I restarted it with the script. Yay.

  3401   Wed Aug 11 16:13:59 2010 JennaUpdateelogelog restarted

The elog crashed, so we restarted it again.

  3406   Thu Aug 12 11:39:27 2010 ZachUpdateelogelog restarted

with script

  3415   Thu Aug 12 23:17:54 2010 ZachUpdateelogrestarted

 script

  3416   Thu Aug 12 23:41:48 2010 JenneUpdateelogrestarted

Quote:

 script

 More of the same. 

Who is putting weird figures into the elog?!?!  I haven't checked lately, but this is what usually crashes the elog.  It's been happening a lot lately, and it might be the .pdf's. 

Let's play a new game.  We'll call this game "Everyone only use .png files for the next week" Ready? GO!

ELOG V3.1.3-