40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 28 of 341  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  6557   Mon Apr 23 23:20:07 2012 DenUpdatePEMmicrophones

Tonight I wanted to measure the ambient noise level using Blue Bird mics and figure out if Panasonic WM61a or Primo EM172/173 will be good enough or not. Blue Bird that is in the control room does not seem to work. May be the problem is with the pre-amplifier. The output measured by ADC/Oscilloscope is noise ( amplitude=5mV ). I will return to this issue tomorrow.

  6563   Tue Apr 24 16:15:24 2012 DenUpdatePEMmicrophones

I've installed Blue Bird microphone to listen to the acoustic noise at the PSL near PMC.

DSC_4271.JPG     DSC_4272.JPG

Coherence between MC_F and Blue Bird output (C1:PEM-ACC_MC2_Z for now) is changing from low to high value at frequencies 20 - 200 Hz with period ~1 min. Maybe HEPA works with some periodicity. Now it works pretty hard, ~80% of max.

micro_mc_low.png    micro_mc_high.png

  6564   Tue Apr 24 22:16:59 2012 DenUpdatePEMBlue Bird Pre-Amplifier

 I detached Clyde (pre-amp that was in the control room) to understand why it is not working. I seems that the board circuit is burnt near R40, R47, R45.

DSC_4273.JPG     DSC_4274.JPG

  6565   Wed Apr 25 00:20:01 2012 DenUpdatePEMacoustic noise at 40m

 Blue Bird Mic is suspended close to PMC now and outputs ~10 counts when pre-amp gain is 8 dB. This means that the mic outputs ~2.42 mV. Its sensitivity is 27 mV/Pa => acoustic noise is ~0.1 Pa or ~75 dB SPL.

If we buy Panasonic WM61A with their sensitivity -35 dB => they will output ~1.7 mV. We can amplify this signal without adding significant noise. For WM61A S/N ratio is given to be 62 dB. This is for some standard signal that is not specified. For Blue Bird mic it is specified according to IEC 651. So I assume SPL of the standard signal = 94 dB => noise level of WM61A is 32 dB (pretty bad compared to 7 dB-A of Blue Bird). But in our case for PSL S/N ratio is ~43 dB that is not too bad. PSL is noisy due to HEPA, acoustic noise level close to MC2 stack will be less. So we may want to consider Primo EM172/173 where the noise level is claimed to be 18 dB less. I think we should buy several WM61A and EM172.

  6568   Wed Apr 25 19:32:57 2012 DenUpdatePEMBlue Bird Pre-Amplifier

Quote:

Usually R is for resistors and D is for diodes. Do you think from the schematic that we should put diodes into the R slots?

 That guys are resistors.

  6569   Wed Apr 25 19:36:19 2012 DenUpdatePSLPMC aligned

[Koji, Den]

We have aligned PMC,  the WFS are not working yet.

  6570   Wed Apr 25 21:24:10 2012 DenUpdateComputer Scripts / Programsc1oaf

C1OAF model, codes and medm screens are updated. All proper files are commited to svn and updated at the new model path.

  6572   Thu Apr 26 11:56:10 2012 DenUpdatePEMBlue Bird Pre-Amplifier

Quote:

Quote:

Usually R is for resistors and D is for diodes. Do you think from the schematic that we should put diodes into the R slots?

 That guys are resistors.

 You are right, they just looked like they were too small to be resistors when I glanced at them. 

  6579   Fri Apr 27 09:27:48 2012 DenUpdateCDSsus watchdogs?

Quote:

Why are all the suspension watchdogs tripped?  None of the suspension models are running on c1ioo, so they should be completely unaffected.  Steve, did you find them tripped, or did you shut them off?

In either event they should be safetly turned back on.

 I've turned off the coils. Though non of them are on the c1ioo, who knows what can happen when we'll try to run the models again.

  6580   Fri Apr 27 12:12:14 2012 DenUpdateCDSc1ioo is back

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.

  6581   Fri Apr 27 13:32:06 2012 DenUpdatePEMseism channels

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.

pem.png

 

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.

  6593   Wed May 2 19:47:20 2012 DenUpdatePEMEM 172 nonlinearities

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

500Hz_noise.png

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.

  6594   Wed May 2 21:04:06 2012 DenUpdatePEMEM 172 coherence

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

em_coh.png

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.

  6604   Sat May 5 01:24:07 2012 DenUpdatePSLPMC

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

whitening.jpg     mcf_v.png

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.

  6606   Sat May 5 10:20:21 2012 DenUpdatePSLPMC

Quote:

I suspect that it was just unlocked when you had disconnected the cable.

There is not reflection now. It seems that it is now misaligned after the alignment work.

So what you need is "align while scanning PZT -> lock -> align".

Quote:

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.

  6608   Sat May 5 20:42:59 2012 DenUpdatePSLPMC

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

  6609   Sun May 6 00:11:00 2012 DenUpdateCDSmx_stream

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

  6610   Sun May 6 01:41:55 2012 DenUpdatePEMseismic in x,y arms

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

coh_xyf.png

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.

  6611   Mon May 7 01:07:58 2012 DenUpdateIOOseismic in mcf

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

pd-mcf.jpeg

 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.

fb.png     coh_err_fb.png

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

mc2_suspos.jpg

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.

  6612   Mon May 7 12:57:34 2012 DenUpdateIOOWFS noise in MC

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

gur_suspos_coh.png

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

mc1_gur.png

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

mcl_wfs.png

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

wfs_servo.png

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

  6613   Mon May 7 17:28:29 2012 DenUpdateIOOWFS noise in MC

Quote:

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

wfs_limit.png

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

  6615   Mon May 7 20:15:37 2012 DenUpdateIOOWFS noise in MC

Quote:

OK. Then we should make this number bigger such that the coherence is still completely maintained.
Is this set in the auto locker? Or manually set?

Quote:

  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

 

 

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.

  6616   Mon May 7 21:05:38 2012 DenUpdateCDSbiquad filter form

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?

  6618   Mon May 7 21:46:10 2012 DenUpdateCDSguralp signal error

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.

guralps.png

 

 

  6619   Mon May 7 22:39:37 2012 DenUpdateCDSc1sus

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

  6623   Tue May 8 09:58:17 2012 DenUpdateCDSSUS -> FB

 [Alex, Den] 

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

controls@c1sus ~ 0$ /opt/open-mx/bin/omx_info 

Open-MX version 1.3.901
 build: root@fb:/root/open-mx-1.3.901 Wed Feb 23 11:13:17 PST 2011
Found 1 boards (32 max) supporting 32 endpoints each:
 c1sus:0 (board #0 name eth1 addr 00:25:90:06:59:f3)
   managed by driver 'igb'
Peer table is ready, mapper is 00:60:dd:46:ea:ec
================================================
  0) 00:25:90:06:59:f3 c1sus:0
  1) 00:60:dd:46:ea:ec fb:0                           // this line was missing
  2) 00:14:4f:40:64:25 c1ioo:0
  3) 00:30:48:be:11:5d c1iscex:0
  4) 00:30:48:bf:69:4f c1lsc:0
  5) 00:30:48:d6:11:17 c1iscey:0
 
At the same time FB saw C1SUS:
 
controls@fb ~ 0$ /opt/mx/bin/mx_info
 
MX Version: 1.2.12
MX Build: root@fb:/root/mx-1.2.12 Mon Nov  1 13:34:38 PDT 2010
1 Myrinet board installed.
The MX driver is configured to support a maximum of:
8 endpoints per NIC, 1024 NICs on the network, 32 NICs per host
===================================================================
Instance #0:  299.8 MHz LANai, PCI-E x8, 2 MB SRAM, on NUMA node 0
Status: Running, P0: Link Up
Network: Ethernet 10G

MAC Address: 00:60:dd:46:ea:ec
Product code: 10G-PCIE-8AL-S
Part number: 09-03916
Serial number: 352143
Mapper: 00:60:dd:46:ea:ec, version = 0x00000000, configured
Mapped hosts: 6

                                                        ROUTE COUNT
INDEX    MAC ADDRESS     HOST NAME                        P0
-----    -----------     ---------                        ---
   0) 00:60:dd:46:ea:ec fb:0                              1,0
   1) 00:30:48:d6:11:17 c1iscey:0                         1,0
   2) 00:30:48:be:11:5d c1iscex:0                         1,0
   3) 00:30:48:bf:69:4f c1lsc:0                           1,0
   4) 00:25:90:06:59:f3 c1sus:0                           1,0
   5) 00:14:4f:40:64:25 c1ioo:0                           1,0
 
For that reason when I restarted mx_stream on c1sus, the script tried to connect to the standard 00:00:00:00:00:00 address, as the true address was not specified.
 
Alex restarted mx on FB. Note, DAQD process will not allow one to do that until it runs, at the same time, you can't just kill it, it will restart automatically. For that reason one should open /etc/inittab and replace respawn to stop in the line
 
daq:345:respawn:/opt/rtcds/caltech/c1/target/fb/start_daqd.inittab
 
then execute inittab using init q and restart mx on the FB
 
controls@fb ~ 0$ sudo /sbin/init q
controls@fb ~ 0$ sudo /etc/init.d/mx restart
 

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.

 

  6624   Tue May 8 10:43:42 2012 DenUpdateCDSbiquad filter form

Quote:

Quote:

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)

 I am really not ok with anyone modifying controller.c.  If we're going to be messing around with that we need to change procedure significantly.  This is the code that runs all the models, and we don't currently have any way to track changes in the code.

Did you change it back?  If not, do so immediately and stop messing with it.  Please consult with us first before embarking on these kinds of severe changes to our code.  This is the kind of shit that other people have done that has bit us in the ass in the past.

Futhermore, there is already a way to enable biquad filters in the new version with out modifying the RCG source.  All you need to do is set biquad=1 in the cdsParameters block for you model.

DO NOT MESS WITH CONTROLLER.C!

 ok

  6632   Wed May 9 10:46:54 2012 DenUpdateCDSOAF model not seeing MCL correctly

Quote:

Den noticed this, and will write more later, I just wanted to sum up what Alex said / did while he was here a few minutes ago....

 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.

oaf_rec.png

  6633   Wed May 9 11:31:50 2012 DenUpdateCDSRFM

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.

  6635   Wed May 9 15:02:50 2012 DenUpdateCDSRFM

Quote:

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.

 This happened because of the code bug -

// If PCIE comms show errors, may want to add this cache flushing
#if 1
if(ipcInfo[ii].netType == IPCIE)
          clflush_cache_range (&(ipcInfo[ii].pIpcData->dBlock[sendBlock][ipcIndex].data), 16); // & was missing - Alex fixed this
#endif
 

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.

  6638   Thu May 10 21:13:01 2012 DenUpdateElectronicsADC 3

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

  6639   Thu May 10 22:05:21 2012 DenUpdateCDSFB

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.

  6642   Fri May 11 23:33:41 2012 DenUpdateAdaptive Filteringoffline vs online

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

off_on.jpg

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.

  6651   Sun May 20 19:57:51 2012 DenUpdatePEMmicrophones

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

DSC_4287.JPG    DSC_4285.JPG

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

scheme.png

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.

DSC_4284.JPG     DSC_4286.JPG

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

freq_resp.png   noise.png

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

  6655   Tue May 22 00:23:45 2012 DenUpdateCDStransmission error monitor

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.

 Screenshot.png

  6661   Tue May 22 20:01:26 2012 DenUpdateCDSerror monitor

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.

  6664   Tue May 22 23:36:02 2012 DenUpdatePEMmircophones

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

close_micro.png

 

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.

 DSC_4288.JPG           DSC_4299.JPG       DSC_4304.JPG      DSC_4302.JPG

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

5_mic.png

 

  6670   Thu May 24 01:17:13 2012 DenUpdateCDSPMC autolocker

Quote:

 

  • SCRIPT
    • Auto-locker for PMC, PSL things - DEN

 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.

  6671   Thu May 24 02:55:36 2012 DenUpdatePEMacoustic noise in MCL

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.

audio_noise.png

  6673   Thu May 24 12:23:00 2012 DenUpdateGeneralconnection error monitor for the website

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.

errors_overview.png

 

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

errors.png

  6674   Thu May 24 13:28:38 2012 DenUpdatePEMHEPA

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

psl_acoustic.png

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.

mcl_90.png        mcl_20.png

 

  6680   Fri May 25 02:56:44 2012 DenUpdateSUSMC3 local damping

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

DSC_4305.JPG

 

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

    osem_noise.png

 

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

osem_coil.png

  6681   Fri May 25 13:24:48 2012 DenUpdateSUSMC3

AA IN -> COIL DRIVER IN transfer function for MC3

freq_resp.png

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.

test_dig.png

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.

  6689   Sat May 26 00:08:41 2012 DenUpdateIOOMC_F low frequency noise

 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

osem_noise.png           gur_suspos_coh.png

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

dgur.png

 

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. 

mc_noises.png

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.

ratio.png

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.

  6691   Sat May 26 15:59:19 2012 DenUpdateIOOGuralp noise is high

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. 

gur_noise.png    MCF_GUR.png

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

DSC_4306.JPG

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

 

  6692   Sat May 26 20:40:48 2012 DenUpdatePEMexperiments with seismic noise

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

DSC_4307.JPG         DSC_4308.JPG

Relative motion for difference distances between seismometers is presented below.

    psd_distance.png        ratio.png

 

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

 

L, ft fcrit, Hz
C a
4 45 0.0074 1.30
18 30 0.0057 1.52
38 15 0.0208 1.43

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

sim_delta.png

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 fcrit decreases with length.

  6693   Sat May 26 23:57:11 2012 DenUpdatePEMGuralp noise

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 m2 / s4 / Hz. I've converted my measurements to this units and got

noises.png

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

  6695   Sun May 27 23:15:22 2012 DenUpdatePEMexperiments with seismometers

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.

DSC_4309.JPG               DSC_4310.JPG                  DSC_4311.JPG

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.

loc_noise.png

  6696   Tue May 29 00:35:57 2012 DenUpdatePEMguralp readout box

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.

1_3.png

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.

  6697   Tue May 29 00:39:52 2012 DenUpdatePEMGuralp noise

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.

in_out.png

ELOG V3.1.3-