Rolf came to the 40m today and managed to figure out what the problem is. Reading just dmesg was not enough to solve the problem. Useful log was in

>> cat /opt/rtcds/caltech/c1/target/c1x03/c1x03epics/iocC1.log

Starting iocInit
The CA server's beacon address list was empty after initialization?
iocRun: All initialization complete
sh: iniChk.pl: command not found
Failed to load DAQ configuration file

iniChk.pl checks the .ini file of the model.

>> cat /opt/rtcds/rtscore/release/src/drv/param.c

int loadDaqConfigFile(DAQ_INFO_BLOCK *info, char *site, char *ifo, char *sys)
{

  strcpy(perlCommand, "iniChk.pl ");
  .........
  strcat(perlCommand, fname); // fname - name of the .ini file
  ..........
}

So the problem was not in the C1X03.ini. The code could not find the perl script though it was in the /opt/rtcds/caltech/c1/scripts directory. Some environment variables are not set. Rolf added /opt/rtcds/caltech/c1/scripts/ to $PATH variable and c1ioo models (x03, ioo, gcv) started successfully. He is not sure whether this is a right way or not, because other machines also do not have "scripts" directory in their PATH variable.

>> cat /opt/rtcds/caltech/c1/target/c1x03/c1x03epics/iocC1.log

Starting iocInit
The CA server's beacon address list was empty after initialization?
iocRun: All initialization complete

Total count of 'acquire=0' is 2
Total count of 'acquire=1' is 0
Total count of 'acquire=0' and 'acquire=1' is 2

Counted 0 entries of datarate=256     for a total of 0
Counted 0 entries of datarate=512     for a total of 0
Counted 0 entries of datarate=1024     for a total of 0
Counted 0 entries of datarate=2048     for a total of 0
Counted 0 entries of datarate=4096     for a total of 0
Counted 0 entries of datarate=8192     for a total of 0
Counted 0 entries of datarate=16384     for a total of 0
Counted 0 entries of datarate=32768     for a total of 0
Counted 2 entries of datarate=65536     for a total of 131072

Total data rate is 524288 bytes - OK

Total error count is 0

Rolf mentioned about automatic set up of variables - kiis of smth like that - probably that script is not working correctly. Rolf will add this problem to his list.

A few weeks ago I found that GUR2_X signal is biased from 0 to 800 counts in average. I decided that the corresponding channel in the readout box is bad - adds DC voltage to the signal. I stopped using GUR2_XYZ channels of the seism readout box. Now the same thing happened with the GUR1_XYZ channels. I checked the signals coming out from the seism box with the oscilloscope and they were fine. So the problem is not in the readout box. Then I applied 1 V sine wave to the input of AA board to the GUR1_X and ACC_MC1_Z channels. GUR1_X channel still shows noise. Something is wrong with these channels inside the AA board or in the ADC.

Edited by Den: GUR1_XYZ_IN1 signals are empty though GUR1_XYZ are fine. So the problem is just that GUR1_XYZ_IN1 are not acquired for now though some of the ACC_IN1 channels contain the signal. I need to correct .ini files.

I've checked new small EM172 microphones for nonlinearities using Koji's Mac Book speakers. EM172 + Mac nonlinearities are presented at the figure

The Mac's sound frequency was specified to be 500 Hz. Harmonics are seen at 1k, 1.5k, but their amplitude is ~30 times less.

I measured coherence between 2 EM 172 microphones in a "quiet room" with SR785

High-frequency noise (>2k) is SR785 noise - I'm not using any amplifier now, the signal from microphone is sent directly to SR785 and is weak at high frequencies.

I was interested what whitening filter do we have between MC servo and ADC. The shape is in the figure below, SR provided 1 V white noise. Before the whitening filter MC_F is measured in Volts with SR and ADC (for ADC the shape is calculated using the whitening filter form):

I also wondered if FSS or PZT servo can add noise to the mode cleaner length signal and what is their gain. It should be big, as the laser's calibration is ~1 MHz/V => to account for seismic noise of 10^-6 m at 1 Hz, the voltage given to the laser should be ~ 1 V. And it is indeed the case. The gain is ~1000. I measured the coherence between MC_F and the laser fast input. It is 1 in the range measured (0.05 - 100 Hz). FSS and PZT do not add significant noise.

Unfortunately, after the measurement when I unplugged BNS connector from the laser, I misaligned PMC. For several hours I adjusted the mirrors but could not significantly improve transmitted signal. I'll return to this issue tomorrow.

 No, no, it was unlocked after I connected the cable back. The beam was even not on the PMC. I'll try PZT -> lock -> align.

[Koji, Den]

Koji was right that I misaligned everything during the alignment work. I assumed that PMC should autolock and when I saw that it did not, I thought the laser is misaligned.

What we did:

1. Aligned mirrors to get the beam on the PD PMC REFL and PMCR camera. The PSL-PMC_RFPDDC was ~800 mV.

2. We disabled PMC servo, switching it to test position and changed "DC output adjust" by 0.01 in a loop

while true
do
    ezcawrite "C1:PSL-PMC_RAMP" -4.50
    ezcastep "C1:PSL-PMC_RAMP" "+0.01,450" -s "0.1"
    ezcawrite "C1:PSL-PMC_RAMP" 0.0
    ezcastep -s "0.1" -- "C1:PSL-PMC_RAMP" "-0.01,450"
done

3. While the script was running we adjusted the position of the beam on the far PMC mirror looking at an IR viewer. The goal is to align two steering mirrors to catch some resonances. We monitored them on the oscilloscope and on the PMCT camera.

4. We locked PMC and aligned steering mirrors.

c1sus and c1iscex computers could not connect to framebuilder, I restarted it, did not help. Then I restarted mx_stream daemon on each of the computers and this fixed the problem.

sudo /etc/init.d/mx_stream restart

I locked x,y arms and measured coherence between POS{X,Y}11_I_ERR, MC_F and seismometer signals.

Surprisingly, coherence between POSY and GUR1Y is low, but with GUR1X is relatively high. I wonder if this is due to MC that brings this x-axis noise to the arms.

I tried to figure out where additional (to seismic) noise enters to MC_F, so the coherence below 1 Hz is low (~0.2-0.5). I've examined noise in the path

PD -> DEMOD -> MC BOARD -> FSS -> PZT Controller -> LASER

• I terminated ADC and measured its noise
• connected MC BOARD OUT to ADC, terminated INPUT1 of the MC BOARD and measured noise
• connected DEMOD Q OUT to MC BOARD INPUT1, terminated PD INPUT on the DEMODULATOR and measured noise
• connected PD to DEMOD, blocked the beam incident to the PD and measured noise

 MC BOARD noise shows up only below 0.1 Hz and at 10 Hz where the whitening filter starts to work. SNR is ~2 at 4 Hz, so we might want to slightly improve whitening filter. But other then that path PD->DEMOD->MC BOARD is not responsible for additional noises below 1 Hz.

Next I connected SR785 to the laser and measured the closed loop feedback signal while MC was locked.

Coherence between MC BOARD OUT1 and feedback signal is high enough to assume that FSS and PZT controller are also not responsible for additional noise.

From the other hand MC2 SUSPOS measured by OSEMS shows good coherence with GUR1_X

That means that MC2 is indeed driven by seismic motion. In order to figure out if this is the case for MC1 and MC3, I rotated GUR2 by 45 degrees. When it will calm down, I'll measure coherence between OSEMs and seismic motion.

I've measured coherence between seismometer signals and OSEMS of MC 1,2,3

GUR1 was rotated on the angle pi / 4 relative to x arm to match suspos axis of MC1 and MC3. Coherence between MC2 and GUR2_X is high, between MC3 and GUR1_X is ~0.2 but is compensated by GUR1_Y, between MC1 and GUR1_Y below 1Hz is ~0.5 and is not compensated by GUR1_X.

Then I measured coherence between GUR1_Y and MC3 OSEMS in 3 regimes :

• FEEDBACK OFF, WFS OFF
• FEEDBACK ON, WFS OFF
• FEEDBACK ON, WFS ON

Once WFS are ON, signal becomes noisy, FEEDBACK is OK. Then I measured coherence between MC_F and GUR2_X with WFS ON and OFF

Coherence between MC_F and GUR2_X is less when WFS are ON in the range 0.2 - 1 Hz and 4 - 10 Hz. Moreover PSD of MC_F seems to be higher at 10 - 100 Hz. But this may be caused by other reasons.

Then I measured the coherence between IN and OUT signals in WFS_SERVO

One filter bank adds noise to WFS signals and because of that we loose coherence between MC_F and seismic motion.

 This effect is due to C1:IOO-WFS1_PIT_LIMIT=2000. When I turned if off, coherence between C1:IOO-WFS_PIT input and output signals restored

The other thing is that WFS actuate on the angular motion, but this couples to the position motion. We need to diagonalize the actuator.

LIMIT is set manually, auto locker does not change it. I've put C1:IOO-WFS1_PIT_LIMIT=4000, it seems to be fine for now.

I wanted to switch the implementation of IIR_FILTER from DIRECT FORM II to BIQUAD form in C1IOO and C1SUS models. I modified RCG file /opt/rtcds/rtscore/release/src/fe/controller.c by adding #define CORE_BIQUAD line:

#ifdef OVERSAMPLE
#define CORE_BIQUAD      
#if defined(CORE_BIQUAD)

C1IOO model compiled, installed and is running now. C1SUS model compiled, but during installation I've got an error:

controls@c1sus ~ 0$ rtcds install c1sus

Installing system=c1sus site=caltech ifo=C1,c1
Installing /opt/rtcds/caltech/c1/chans/C1SUS.txt
Installing /opt/rtcds/caltech/c1/target/c1sus/c1susepics
Installing /opt/rtcds/caltech/c1/target/c1sus
Installing start and stop scripts
/opt/rtcds/caltech/c1/scripts/killc1sus
Performing install-daq
Updating testpoint.par config file
/opt/rtcds/caltech/c1/target/gds/param/testpoint.par
/opt/rtcds/rtscore/branches/branch-2.5/src/epics/util/updateTestpointPar.pl -par_file=/opt/rtcds/caltech/c1/target/gds/param/archive/testpoint_120507_205359.par -gds_node=21 -site_letter=C -system=c1sus -host=c1sus
Installing GDS node 21 configuration file
/opt/rtcds/caltech/c1/target/gds/param/tpchn_c1sus.par
Installing auto-generated DAQ configuration file
/opt/rtcds/caltech/c1/chans/daq/C1SUS.ini
Installing EDCU ini file
/opt/rtcds/caltech/c1/chans/daq/C1EDCU_SUS.ini
Installing Epics MEDM screens
Running post-build script

ERROR: Could not find file: test.py
Searched path: :/opt/rtcds/userapps/release/cds/c1/scripts:/opt/rtcds/userapps/release/cds/common/scripts:/opt/rtcds/userapps/release/isc/c1/scripts:/opt/rtcds/userapps/release/isc/common/scripts:/opt/rtcds/userapps/release/sus/c1/scripts:/opt/rtcds/userapps/release/sus/common/scripts:/opt/rtcds/userapps/release/psl/c1/scripts:/opt/rtcds/userapps/release/psl/common/scripts
Exiting
make: *** [install-c1sus] Error 1

Jamie, what is this test.py?

GUR1_XYZ_IN1 and GUR2_XYZ_IN1 are the same and equal to GUR2_XYZ.  This is bad since GUR1_XYZ_IN1 should be equal to GUR1_XYZ.  Note that GUR#_XYZ are copies of GUR#_XYZ_OUT, so there may be (although there isn't right now) filtering between the _IN1's and the _OUT's.  But certainly GUR1 should look like GUR1, not GUR2!!!

Looks like CDS problem, maybe some channel-hopping going on? I'm trying a restart of the c1sus computer right now, to see if that helps.....

Figure:  Green and red should be the same, yellow and blue should be the same.  Note however that green matches yellow and blue, not red.  Bad.

[Jenne, Den]

We decided to reboot C1SUS machine in hope that this will fix the problem with seismic channels. After reboot the machine could not connect to framebuilder. We restarted mx_stream but this did not relp. Then we manually executed

/opt/rtcds/caltech/c1/target/fb/mx_stream -s c1x02 c1sus c1mcs c1rfm c1pem -d fb:0 -l /opt/rtcds/caltech/c1/target/fb/mx_stream_logs/c1sus.log

but c1sus still could not connect to fb. This script returned the following error:

controls@c1sus ~ 128$ cat /opt/rtcds/caltech/c1/target/fb/mx_stream_logs/c1sus.log

c1x02
c1sus
c1mcs
c1rfm
c1pem
mmapped address is 0x7fb5ef8cc000
mapped at 0x7fb5ef8cc000
mmapped address is 0x7fb5eb8cc000
mapped at 0x7fb5eb8cc000
mmapped address is 0x7fb5e78cc000
mapped at 0x7fb5e78cc000
mmapped address is 0x7fb5e38cc000
mapped at 0x7fb5e38cc000
mmapped address is 0x7fb5df8cc000
mapped at 0x7fb5df8cc000
send len = 263596
OMX: Failed to find peer index of board 00:00:00:00:00:00 (Peer Not Found in the Table)
mx_connect failed

Looks like CDS error. We are leaving the WATCHDOGS OFF for the night.

 [Alex, Den] 

It was in vain to restart mx_stream yesterday as C1SUS did not see FB

After that C1SUS started to communicate with FB. But the reason why this happened and how to prevent from this in future Alex does not know.

Restarting DAQD process (or may be C1SUS) also solved the problem with guralp channels, now they are fine. Again, why this happened is unknown.

 ok

 From my point of view during rfm -> oaf transmission through Dolphin we loose a significant part of the signal. To check that I've created MEDM screen to monitor the transmission errors in the OAF model. It shows how many errors occurs per second. For MCL channel this number turned out to be 2046 +/- 1. This makes sense to me as the sampling rate is 2048 Hz => then we actually receive only 1-3 data points per second. We can see this in the dataviewer.

C1:OAF-MCL_IN follows C1:IOO-MC_F in the sense that the scale of 2 signals are the same in 2 states: MC locked and unlocked. It seems that we loose 2046 out of 2048 points per second.

I added PCIE memory cache flushing to c1rfm model by changing 0 to 1 in /opt/rtcds/rtscore/release/src/fe/commData2.c on line 159, recompiled and restarted c1rfm.

Jamie, do not be mad at me, Alex told me do that!

However, this did not help, C1RFM did not start. I decided to restart all models on C1SUS machine in hope that C1RFM uses some other models and can't connect to them but this suspended C1SUS machine. After reboot encounted the same C1SUS -> FB communication error and fixed it in the same was as in the previous case of C1SUS reboot. This happens already the second time (out of 2) after C1SUS machine reboot.

I changed /opt/rtcds/rtscore/release/src/fe/commData2.c back, recompiled and restarted c1rfm. Now everything is back. C1RFM -> C1OAF is still bad.

 This happened because of the code bug -

After this bug was fixed and the code was recompiled, C1:OAF_MCL_IN is OK, no errors occur during the transmission C1:OAF-MCL_ERR=0.

So the problem was in the PCIE card that could not send such amount of data and the last channel (MCL is the last) was corrupted. Now, when Alex added cache flushing, the problem is fixed.

We should spend some more attention to such problems. This time 2046 out of 2048 points were lost per second. But what if 10-20 points are lost, we would not notice that in the dataviewer, but this will cause problems.

ADC 3 INPUT 4 (#3 in the c1pem model if you count from 0) is bad. It adds DC = ~1 V to the signal as well as noise. I plugged in GUR2 channels to STS1 channels (7-9).

Already for the second time today all computers loose connection to the framebuilder. When I ssh to framebuilder DAQD process was not running. I started it

controls@fb ~ 130$ sudo /sbin/init q

But I do not know what causes this problem. May be this is a memory issue. For FB

Mem:   7678472k total,  7598368k used,    80104k free

Practically all memory is used. If more is needed and swap is off, DAQD process may die.

I've compared offline Wiener filtering with online static + adaptive filtering for MC_F with GUR1_XYZ and GUR2_XYZ as witness signals

Note: online filter works up to 32 Hz (AI filter at 32 Hz is used). There is no subtraction up from this frequency, just MC_F was measured in different times for online and offline filtering. This difference in MC_F in frequency range 20-100 Hz showed up again as before with microphone testing.  One can see it in 1 minute. Smth is noisy.

Reasons why online filter is worse then offline:

1. FIR -> IIR conversion produces error. Now I'm using VECTFIT approximation with 16 poles (splitting into 2 filter banks), this not enough. I tried to use 50 and split them into 5 filter banks, but this scheme is not working: zpk -> sos conversion produces error and the result filter works completely wrong.

2. Actuator TF. VECTFIT works very good here - we have only 1 resonance. However, it should be measured precisely.

3. Account for AA and AI filters that rotate the phase at 1-10 Hz by ~ 10 degrees.

I've soldered EM172 microphones to BNC connectors to get data from them.

Then I've build an amplifier for them. The circuit is

I've build 6 such circuits inside 1 box. It needs +15 V to A3 and GND to A2. A1 power channel is not used.

LISO model for this scheme was created and simulation results were compared to measurement of each channel

Measured noise curve (green) is the SR785 own noise.

I've started to create channels and an medm screen to monitor the errors that occur during the transmission through the RFM model. The screen will show the amount of lost data per second for each channel.

Not all channels are ready yet. For created channels, number of errors is 0, this is good.

I've created transmission error monitors in rfm, oaf, sus, lsc, scx, scy and ioo models. I tried to get data from every channel transmitted through PCIE and RFM. I also included some shared memory channels.

The medm screen is in the EF STATUS -> TEM. It shows 16384 for the channels that come from simulation plant. Others are 0, that's fine.

I've put 5 EM172 microphones close together and measured there signal and coherence. They are plugged in to accelerometer channels.

Then I've suspended microphones around the MC - 2 at MC2, 2 at MC1,3 and 1 at PSL. The amplifier box is above STS readout box.

Microphone close to PSL gave a strong coherence with MC_F, as we already saw it using Blue Bird Microphone.

ACC_MC2_XY channels <=> MC2 microphones

ACC_MC1_XY channels <=> MC1,3 microphones

ACC_MC1_Z channel <=> PSL microphones

 I wrote auto-locker for PMC. It is called autolocker_pmc, located in the scripts directory, svn commited. I connected it to the channel C1:PSL-PMC_LOCK.  It is currently running on rosalba. MC autolocker runs on op340m, but I could not execute the script on that machine

op340m:scripts>./autolock_pmc
./autolock_pmc: Stale NFS file handle.

I did several tests, usually, the script locks PMC is a few seconds. However, if PMC DC output has been drift significantly, if might take longer as discussed below.

The algorithm:

       if autolocker if enabled, monitor PSL-PMC_PMCTRANSPD channel
       if TRANS is less then 0.4, start locking:
               disengage PMC servo by enabling PMC TEST 1
               change PSL-PMC_RAMP unless TRANS is higher then 0.4 (*)
               engage PMC servo by disabling PMC TEST 1
       else sleep for 1 sec
 

(*) is tricky. If RAMP (DC offset) is specified then TRANS will be oscillating in the range ( TRANS_MIN, TRANS_MAX ). We are interested only in the TRANS_MAX. To make sure, we estimate it right, TRANS channel is read 10 times and the maximum value is chosen. This works good.

Next problem is to find the proper range and step to vary DC offset RAMP. Of coarse, we can choose the maximum range (-7, 0) and minimum step 0.0001, but it will take too long to find the proper DC offset. For that reason autolocker tries to find a resonance close to the previous DC offset in the range (RAMP_OLD - delta, RAMP_OLD + delta), initial delta is 0.03 and step is 0.003. It resonance is not found in this region, then delta is multiplied by a factor of 2 and so on. During this process RAMP range is controlled not to be wider then (-7, 0).

The might be a better way to do this. For example, use the gradient descent algorithm and control the step adaptively. I'll do that if this realization will be too slow.

I've disabled autolocker_pmc for the night.

Mic in the PSL showed that fluctuations in the MCL in the frequency range 10 - 100 Hz are due to acoustic noise. I've measured MCL, MCL / PSL mic coherence 2 times with interval 300 seconds.

Surprisingly, acoustic noise level did not change but MC sometimes is more sensitive to acoustic noise, sometimes less.

The main page of connection error monitor can be a scheme of computers and models with connections. If there is an error in connection, the corresponding arrows turns from green to red.

Each arrow is a line to a more detailed information about the channels.

HEPA filter was running at 90% of max. I reduced it to 20%. Acoustic noise moved down

The range of MCL oscillations has also decreased but fluctuations in the frequency range 10-100 are still present.

MCL is much more stable now.

I've terminated input to AA filters and measured signal to coils C1:SUS-MC3_??COIL_OUT.

I compared this noise to the signal when OSEM are connected to ADC.

I made BNC -> LEMO board such that all LEMOs have the same signal equal to BNC signal. I provided excitation of 50 mV as white noise to the input of the AA filter and measured coherence between excitation and MC3 coil driver. The path is

AA -> ICS 110 -> Pentium -> Pentek -> AI -> Univ Dewhitening -> Coil Driver

As all inputs have the same signal, matrices that recombine the signals should not affect coherence. But what I got for coherence between AA IN / Dewhitening OUT is

AA IN -> COIL DRIVER IN transfer function for MC3

I've provided excitation to the AA input, the same for all OSEM channels. In the digital domain coherence between C1:SUS-MC3_ULSEN_INMON / C1:SUS-MC3_ULCOIL_INMON and other channels OSEM -> COIL is 1 starting from 0.1Hz.

The only thing left to understand is why the coherence AA IN / COIL DRIVER IN measured in the analog domain is not 1 in the frequency range 0.1 - 1 Hz. It does not look like just SRS noise. I've connected Ch 1 and 2 to the source, coherence is close to 1.

 MC_F low frequency noise might be due to local damping electronics. I did not measure OSEM noise, but even without it electronics (AA -> ICS 110 -> ADC) provide sufficient amount of noise. 

These 2 image show electronics noise and coherence between OSEM signal / seismic

From these 2 plots we might think that SNR > 10 and coherence OSEM / GUR is high at the frequency range 0.1 - 10 Hz and this is not a big problem.

However, at low frequencies the length of seismic waves becomes large enough and relative oscillations of MC2 and MC13 decrease.

For 1 wave ( u(MC2) - u(MC1) ) / u(MC2) = sin(2 * pi * L  * f  / c), L - distance between MC1 and MC2 where 2 seismometers are located. So MC123 move according to seismic motion and electronics noise is not seen unless we look at MC Length. Here this noise is seen, because mirrors move in a synchronistic manner. 

To check this I measured seismic noise with 2 guralps at distance 12 meters - at MC1 and MC2. Then I've computed the difference between these signals. And indeed at low frequencies, relative motion is much less.

Green, blue - GUR1,2_X

Red - differential motion GUR1_X - GUR2_X

The following plot illustrates how electronics noise effects MC_F. Green is the signal to coils. Red - electronics noise. Blue, black, cyan - simulated contribution to MC_F for different seismic waves speed. Most probably seismic waves have waves in the range 50 - 800 m/s, others are deep. The plot shows that electronics noise is big enough to disturb coherence between MC_F and seismic noise. 

Here is a rough calculation of the seismic waves speed. The following plot shows the ratio of psd of differential MC2-MC1 motion to MC2 motion.

If seismometers would be very far, ratio would be 1 if we neglect the difference in transfer function SEISMOMETER -> ADC for each channel. The drift of the ratio from 1 to 1.3 demonstrates this effect. Ratio starts to decrease at 15 Hz according to sin (2*pi*L*f/c) ~ 2*pi*L/c * f. So 2*pi*L/c * f_0 = pi/2 => c = 4 * L * f = 600 m / sec.

As I've mentioned in yesterday's elog MC mirrors start to move in a synchronistic manner. I've plotted DELTA_GUR = GUR1_X - alpha * GUR2_X, where alpha = const to make the transfer functions SEISMOMETER -> ADC equal for each channel. I've noticed that DELTA_GUR decreases below 10 Hz compared to GUR1_X as theoretically predicted. But starting from 1 Hz DELTA_GUR starts to increase. I decided that this is Guralp noise floor. Today I checked this, this is indeed the case.

In the frequency range 0.01 - 1.5 Hz Gur noise is comparable to the signal DELTA_GUR. For that reason we see low coherence between MC_F and GUR1_X in this frequency range. 

Guralp noise floor was determined by placing 2 seimometers close to each other and subtracting by Wiener filtering.

Conclusion: To filter seismic noise out of MC_F we need more sensitive seimometeres.

I measured relative motion of 2 seismometers separated by 4, 18 and 38 feet.

Relative motion for difference distances between seismometers is presented below.

Al frequencies f < f_crit relative motion becomes smaller then motion of each point. At these frequencies, the ratio relative / absolute motion can be approximated as ratio = C f^a . The following table summarizes f_{crit, C and a for different length between seismometers.}

_{Using this approximation we can estimate the desired noise floor of the seismometer to subtract seismic noise from MC_F}

Desired seismometer noise should be 100 times less then Guralp's. ADC noise is still less then this level, so this will not be a problem.

Note: for longer cavities condition for seismometer noise becomes more week as f_{crit decreases with length.}

I've looked through the Guralp manual to figure out what noise do they declare. They present it in acceleration units in dB relative to 1 m² / s⁴ / Hz. I've converted my measurements to this units and got

They declare much better noise. May be linoleum makes an effort. Do we have any isolation boxes?

I wondered if linoleum is a reason of high Guralp noise. I measured Guralp noise in 3 cases: they stand on a very soft piece of paper, linulium and stone.

I've calibrated the noise to units m/s/sqrt(Hz). Using soft paper we get the worst noise, stone - the best, but noises do not differ that much and still much worse then declared noise in the manual.

I measured the frequency response of the Guralp readout box and noise by providing sin signal of amplitude 50 mV at 15 Hz for channels 1-3.

It turns out that the gain is ~250, while my liso model simulated it to be 200. This is because it is hard to approximate AD620 amplifier.

Noise of the box does not seem to be too bad at low frequencies.

I've connected Guralp output to the ADC without readout box. I've got the same noise at low frequencies and even worse noise at high frequencies. However, readout box was still used as DC supply and the signal was read from INPUT test points. I'll do the same experiment without touching readout box at all.

STS readout box seems to be partly broken. I've terminated inputs from the seismometer and measured the output. I could not do this for vertical channel because it outputs 7 V DC + 500 mV AC signal. All the switches work fine, 5 V DC is indeed shown when auto zero, calibration, 1 sec resp, sig select are enables. The box has AC power supply that seems to work ok, all measured DC values are equal to the labels. Something is wrong with amplification.

I've noticed several CDS problems:

1. Communication sign on C1SUS model turns to red once in a while. I press diag reset and it is gone. But after some time comes back.
2. On C1LSC machine red "U" lamp shines with a period ~5 sec.
3. I was not able to read data from the SR785 using netgpibdata.py. Either connection is not established at all, or data starts to download and then stops in the middle. I've checked the cables, power supplies and everything, still the same thing.

I've checked whether the Guralp noise that we see comes not from seismometer but from ADC or readout box. I did 2 separate measurements . First, I've split 1 signal from Guralp into 2 before the input to AA board and subtracted one from another using Wiener filter. Second, I've connected inputs of channels 1 and 4 of the seismometer readout box and put the signal from seismometer to channel 1.

The plot shows that ADC and readout box do not contribute too much to the Guralp noise.

When I've put Guralps inside the isolation box, the signal from seismometers increased and was out of AA board range. I've reduced the gain of the readout box by a factor of 2. Now R2 for channels 1-6 is (2000, 1050, 1050, 2000, 1050, 1050) Ohm.

The signal increased in the frequency range 30-50 Hz. Guralp noise become better. That's good. However, it is still worse then in the manual.

As Yuta is dancing on the isolation box, Guralp signal is most time out of the AA board range. So I calculated the noise based on 5 min data. This may be enough, but I'll repeat the experiment later with 30 min data.

I've put Guralps into the Steve's 2 box isolation system. Noise got better, coherence between 2 seismometers improved. We still need better performance. Probably, one device is noisy and we can not determine which one using these 2 seismometers. We need more seismometers. Sadly, STS-2 readout box is not working.

We have 2 sts-2 readout box - pink and blue. Pink outputs 12 DVC - this a problem of amplifier. This box has a rectifier (the box works from AC power) and an amplifier for velocity channels. Mass positions, calibration channels are connected by a wire from input to output. The amplifier for velocity channels does not work properly, so I connected velocity channels directly to the output - the signal from sts-2 is large enough even without amplification. When I plugged sts-2 to pink readout board, on the velocity output I saw ~4 VDC. Sts-2 was needed to be recentered. I pressed AUTOZERO command, but this did not work out. Before I had checked that this readout box indeed gives an autozero logical signal - 5VDC for ~2 sec. I think it does not provides sts-2  with enough current, seismometer needs 0.1 A in autozero regime.

Blue readout box after switching it to 1 sec regime and zeroing sts-2 started to output reasonable signal for gains = 10. I tried gains = 100, X velocity channel started to output noise. Now the gain is 10 and the response is 120 sec. But at least this box works. Still performance is not clear as well as noise level. To determine this I've put sts-2 to isolation box.

After I've put Guralps in the isolation and waited for a couple of days, Guralp noise has been improved a little more.

From now all models calculate iir filters using biquad form. I've added biquad=1 to cdsParameters to all models except c1cal, built, installed and restarted them.

All PEM and IOO DQ channels disappeared. These channels were commented in C1???.ini files though I've uncommented them a few weeks ago. It happened after these models were rebuild, C1???.ini files also changed. Why?

I added the channels back. mx_stream died on c1sus after I pressed DAQ reload on medm screen. For IOO model it is even worse. After pressing DAQ Reload for C1IOO model DACQ process dies on the FB and IOO machine suspends.

I rebooted IOO, restarted models and fb. Models work now, but there might be an easier way to add channels without rebooting machines and demons.

I thought we rewrite auto lockers once per year, but this time it took us only a month. I wrote it for PMC on May 24. Is it not working?

Could someone make it more clear why some scripts are written on bash, others on sh or python? I think we should elaborate a strict order. Masha and I can work on it if anyone else considers this issue as a problem.