40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 141 of 339 Not logged in
ID Date Author Type Category Subject
7977   Thu Jan 31 15:56:38 2013 RijuUpdate Photodiode transimpedance

Summary: Measurement and plot of shot-noise-intercept-current for PDA10CF.

Motivation:It is to measure the shot noise intercept current for PDA10CF.

Result: The final plot is attached here. The plot suggests that the value of shot-noise-intercept current is 0.21mA

Discussion:

The plot is for the measured data of Noise voltage (V/sqrt(Hz)) vs DCcurrent(A). The fitted plot to this measured data follows the noise equation

Vnoise = gdet* sqrt[ 2e (iDC+idet)] ,  where gdet= transimpedance of the PD in RF region as described in manual of PDA255 (i.e. 5e3 when it is not in High-impedance region).

To get an approximate idea of the shot noise intercept current, we may follow the same procedure described in 7946

In the present case dark-noise is 4.3e-08 V/sqrt(Hz)

Therefore dark current(in2) ~dark noise voltage/RF transimpedance = 8.6pA/sqrt(Hz)

Therefore the approximate shot noise intercept current ~ (8.6/18)^2=0.22mA

This value matches well with the fitted data.

From PDA10CF manual, NEP=1.2e-11W/sqrt(Hz) and responsivity~0.9A/W. Therefore the noise current level will be ~10pA.

Attachment 1: shotnoiseinterceptpda10cf.pdf
7984   Fri Feb 1 14:47:17 2013 RijuUpdate Photodiode transimpedance

Summary: Measurement and plot of shot-noise-intercept-current for MC REFL PD.

Motivation:It is to measure the shot noise intercept current for MC REFL PD.

Result: The final plot is attached here. The plot suggests that the value of shot-noise-intercept current is 0.041mA

Discussion:

The plot is for the measured data of Noise voltage (V/sqrt(Hz)) vs DCcurrent(A). The fitted plot to this measured data follows the noise equation

Vnoise = gdet* sqrt[ 2e (iDC+idet)] ,  where gdet= transimpedance of the PD in RF region as described in manual of PDA255 (i.e. 5e3 when it is not in High-impedance region).

To get an approximate idea of the shot noise intercept current, we may follow the same procedure described in 7946

In the present case minimum noise value is 2.03e-08 V/sqrt(Hz)

Therefore dark current(in2) ~dark noise voltage/RF transimpedance = 4.06pA/sqrt(Hz)

Therefore the approximate shot noise intercept current value is (4/18)^2 ~ 0.049mA, which is close to the fitted value.

... hard to believe these numbers. Wrong DC transimpedance? (KA)

Attachment 1: shotnoiseinterceptmcreflpd.pdf
8027   Thu Feb 7 19:24:57 2013 RijuUpdate Photodiode transimpedance

Summary: Measurement and plot of shot-noise-intercept-current for MC REFL PD.

Motivation:It is to measure the shot noise intercept current for MC REFL PD.

Result: The final plot is attached here. The plot suggests that the value of shot-noise-intercept current is 1.9mA

Discussion:

The plot is for the measured data of Noise voltage (V/sqrt(Hz)) vs DCcurrent(A). The fitted plot to this measured data follows the noise equation

Vnoise = gdet* sqrt[ 2e (iDC+idet)] ,  where gdet= transimpedance of the PD in RF region ~600

To get an approximate idea of the shot noise intercept current, we may follow the same procedure described in 7946

In the present case minimum noise value is 1.46e-08 V/sqrt(Hz)

Therefore dark current(in2) ~dark noise voltage/RF transimpedance ~25pA/sqrt(Hz)

Therefore the approximate shot noise intercept current value is (25/18)^2 ~ 1.92mA, which matches well to the fitted value.

Attachment 1: reflshotnoise.pdf
8186   Wed Feb 27 17:43:54 2013 RijuUpdate Photodiode transimpedance

Here is the transimpedance for the other PD used for MC REFL

Attachment 1: TFnewreflpd.pdf
Attachment 2: NewREFL_z.pdf
8188   Wed Feb 27 18:17:05 2013 RijuUpdate Photodiode transimpedance

 Quote: How much is the exact resonant frequency? And what's the unit of the plot? The resonant "transimpedance" in the unit of Ohm can not be ~100.

The exact resonant frequency is 29.38MHz. I ve uploaded the other plot. It was the output of Vectfit.

8189   Wed Feb 27 18:38:51 2013 RijuUpdate Photodiode transimpedance

Quote:

 Quote: How much is the exact resonant frequency? And what's the unit of the plot? The resonant "transimpedance" in the unit of Ohm can not be ~100.

The exact resonant frequency is 29.38MHz. I ve uploaded the other plot. It was the output of Vectfit.

Is the DC transimpedance now 10010 Ohm? I ve used 50 Ohm. Which one is correct?

8484   Wed Apr 24 14:24:40 2013 RijuUpdate PD frequency response

Here I am attaching the first schematic diagram of the PD frequency response set-up, I will keep updating it with relevant informations with the progress of the work.

Description: Our objective is to set-up one simultaneous transfer-function measurement system for all the RF-PDs present in 40m lab. A diode laser will be used to illuminate the PDs. The diode laser output will be divided by 1x16 fiber splitter and will be sent to all the PDs through single-mode fiber. The transfer function of the PDs will be measured using network analyzer(Agilent 4395A). The output of the PDs will be fed to network analyzer via one RF-switch. The diode laser will be controlled by the controller ILX LDC 3744C. The scanning frequency signal will be fed to this controller from network analyzer through its external modulation port. The output of the controller will be splitted  into two parts: one will go to laser diode and the other will be used as reference signal for network analyzer.

Attachment 1: PD_freq_resp.pdf
8488   Thu Apr 25 00:59:37 2013 RijuUpdateRF SystemPD frequency response

 Quote: I think you have the splitter that splits the RF signal from the network analyzer in the wrong place.  Usually you split the signal immediately after the RF Out, so that half of the signal goes to the A-input of the Analyzer, and the other half goes to your controller (here, the laser diode controller).  Then you would take the output of your controller and go straight to the actual laser diode, with no splitting in this path.

Here our device under test is the photodiode. So for the reference I wanted to retain the response of the laser diode controller. Otherwise I have to consider the transfer function of that LDC too. I may check both the options at the time of experiment.

Thanks

8492   Thu Apr 25 17:56:28 2013 RijuConfiguration PD frequency response

[Eric, Riju]

Today we have routed the fibers from 1x16 fiber splitter to POX table for POX11 PD and POP55 PD. Also we labeled the fibers on AP table, they have been fixed on the table. The photo of the table after work is attached here. We will do it for POX table tomorrow.

Attachment 1: IMG_0495.JPG
8497   Fri Apr 26 17:08:42 2013 RijuConfiguration PD frequency response

 Quote: No.... what I told was to put the roll next to the splitter, not on the table. The table area is more precious than the rack space. Koji> The slack of the fibers should be nicely rolled and put together at the splitter side.

Ok, will do it on the coming week.

8506   Mon Apr 29 17:26:22 2013 RijuConfigurationRF SystemPD frequency response

Today I have rerouted the fibers on AP table to remove the fiber rolls out of the AP table.  I removed the fibers one by one from both ends - from the 1x16 splitter and from the AP table - keeping the fiber roll intact, and then connected it in reverse way, i.e. the fiber end which was on AP table now is connected to the splitter (since length of the outside the roll is shorter that side) and the fiber end connected to splitter is now rerouted on AP table.

We need to keep the fibers in such a fashion so that no sharp bending occurs anywhere, and also it does not get strained due to its weight, particularly near the 1x16 splitter. Jenne suggested to use a plastic box over the splitter rack to keep the fiber rolls for time-being. We discussed a lot how this can be done nicely; in future we may use array of hooks, Koji suggested to use cable hangers and to tie the rolls using more than one hanging point, Jenne suggested to use the bottom shelf of the rack or to use one plastic box with holes. We tried to make holes on the plastic box using drill, but it developed crack on the box. So ultimately I used the opened box only and put it over the rack.

The corresponding photographs are attached herewith.

Tomorrow we will reroute the fibers for POX table.

Attachment 1: IMG_0504.JPG
Attachment 2: IMG_0503.JPG
Attachment 3: IMG_0505.JPG
Attachment 4: IMG_0506.JPG
Attachment 5: IMG_0508.JPG
Attachment 6: IMG_0509.JPG
Attachment 7: IMG_0510.JPG
8512   Tue Apr 30 19:39:14 2013 RijuConfigurationRF SystemPD frequency response

Today I have rerouted the fibers on POX table. The aim was to lay it overhead through the plastic pipe. A pipe ~50ft (~15.5m) long was taken for this purpose. I disconnected the two 25m long fibers for POP55 and POX11 PD (those had been already routed) from both of their ends - i.e. from the POX table and also from 1x16 splitter. Jenne and Koji suggested that we may have another two PDs ( POP22 and POP110) on POX table in future. So we used another 25m long fiber for these two (POP22/POP110). We could not use two fibers for these two since we have only four 25m long fibers and one of them we need for POY11 PD on POY table. Jenne and me put the three fibers inside the pipe using a copper tube. The tube then was put on the overhead rack, Manasa helped me to do it. The fiber ends were finally laid on the POX table at one end and connected to the 1x16 splitter at the other end.

The corresponding photos are attached herewith.

Attachment 1: IMG_0511.JPG
Attachment 2: IMG_0512.JPG
Attachment 3: IMG_0513.JPG
Attachment 4: IMG_0514.JPG
Attachment 5: IMG_0515.JPG
8520   Wed May 1 17:36:26 2013 RijuConfigurationRF SystemPD frequency response

Today I routed fiber from 1x16 splitter to POY table. Manasa helped me doing that. The fiber(25m) was laid on overhead rack through plastic pipe of length ~76ft. We put the fiber inside the pipe using one copper tube, and then tied the plastic pipe on the overhead rack. Finally one end of the fiber was laid on POY table and the other end was connected to the 1x16 splitter. The photographs corresponding are attached. There is no picture of splitter end, cause it was dark that time.

Attachment 1: IMG_0517.JPG
Attachment 2: IMG_0518.JPG
Attachment 3: IMG_0519.JPG
8573   Tue May 14 19:52:58 2013 RijuConfigurationRF SystemPD frequency response

[Eric, Riju, Annalisa]

Today we have cleared up the fiber spool near AP table. We have put the 1x16 fiber splitter and a box (we made two openings on it) for fiber spool on a different part of the rack. Also put a plastic tubing or the fibers coming out of AP table. Now the fibers coming out from AP table and also from POX table first enter the box through one opening and the end of the fibers come out of the other opening to get connected to to splitter. Photographs of the work are attached. I don't think enough fiber is there to make a similar loop for fiber coming from POY table.

Attachment 1: IMG_0520.JPG
Attachment 2: IMG_0521.JPG
7486   Thu Oct 4 23:01:49 2012 RijuparnaConfiguration cavitymode scan

Here I am attaching the schematic diagram of the experimental set-up for IMC cavitymode scanning. A 30- 45MHz scanning signal generated by Agilent 4395A network analyzer enters EOM, which in turn modulates the laser beam entering IMC. The cavity response can be verified from reflected/transmitted beam.

I worked with the reflected beam last days. But I got no clue about the percentage of  reflected light reaching the photodiode and also the photodiode response. I would like to measure the power reaching photodiode and also would like to perform the test with transmitted beam - on wednesday if possible.

Attachment 1: diagram1.pdf
7519   Wed Oct 10 15:31:59 2012 RijuparnaUpdate cavitymode scan

Rijuparna, Jenne

Today I checked the optical lay-out in MC REFL board of the MC REFL path on the AS table (I will put the updated diagram in a few hours), and took a record of the reflected power of unlocked MC and power entering MC REFL PD. The power coming out of MC cavity when unlocked is 1.25W and power entering REFL PD 112mW (Jenne measured these powers for me).

I also got a description of the MC demodulation board from Jenne.

(Edits by Jenne)

7537   Fri Oct 12 15:31:03 2012 RijuparnaConfiguration cavitymode scan

Rijuparna, Manasa

Today I have checked the optical layout of the MC transmission RFPD table and measured the laser powers at different points. Manasa helped me for that. I found the power entering the RF photodiode is 0.394mW while the transmitted power of the cavity is 2.46mW. (I will give the diagram later).

7351   Thu Sep 6 17:06:25 2012 Rijuparna ChakrabortyConfigurationelogCavitymode scan

Aim: to scan the cavitymodes of IMC

The circuit used:

Attachment4

Results obtained:

Attachment 1,2,3

Attachment 1: 3.pdf
Attachment 2: 2.pdf
Attachment 3: 1.pdf
Attachment 4: cavityscanconnections.pdf
7363   Fri Sep 7 15:58:29 2012 Rijuparna ChakrabortyUpdate cavitymode scan

IMC transmission photodiode has been aligned.

7368   Sat Sep 8 00:15:57 2012 Rijuparna ChakrabortyUpdate cavitymode scan

Quote:

 Quote: IMC transmission photodiode has been aligned.

Which PD?  The 'regular' DC one, or the newer one?  Why did it need realigning?  What mirrors did you touch to do the alignment?

Did you do anything else in the last 3 days?  I want to see ALL the gory details, because it can help people doing future measurements, or help us debug if something is wrong with the interferometer later.

MORE WORDS! Thanks.

No, not the "regular DC one", the "newer one"  along with the controls of the corresponding mirror only i touched.

It needed to be realigned cause last week when we fitted a longer cable there, which may reach the network analyzer, it got misaligned since it got touched.

No other component in that box except that PD and the corresponding mirror controls I touched.

For my last 2 days work, I feel my last elog is reliable.

Today other than doing this, I checked for the higher order modes of the cavity, misaligning one of the MC mirror though the software only. I didn't mention it in my elog cause although I saw the presence of the higher order modes I didn't record it, so I can not upload any picture in support of such a statement.

Thanks

7376   Wed Sep 12 19:26:08 2012 Rijuparna ChakrabortyUpdate cavitymode scan

Summary: Recorded the presence of higher order modes in IMC

What I did: Misaligned the flat mirror MC1 by small amount in both pitch and yaw (it was needed to be done cause at the beginning of the experiment no higher order modes were present)  and scanned the cavity for frequency-range 32MHz to 45MHz.

I found the presence of higher order modes around 36.7MHz (1st order)  and 40.6MHz (2nd order) along with two other strong modes near 35MHz and 42.5MHz.

Attachment 1: P120912_11.32.jpg
Attachment 2: P120912_14.13.jpg
Attachment 3: P120912_14.17.jpg
Attachment 4: P120912_11.25.jpg
Attachment 5: P120912_14.09.jpg
Attachment 6: P120912_14.30.jpg
Attachment 7: P120912_14.34.jpg
603   Mon Jun 30 14:07:26 2008 RobConfigurationPSLDon't put the bin in front of the air conditioning unit

 Quote: We spotted that the laser power was dropping.

the offending configuration:
Attachment 1: DSC_0140.png
1306   Sun Feb 15 15:53:21 2009 RobUpdateLSCLocking status

 Quote: I didn't get a chance to do much testing since the sus controller (susvme1) went nuts. In retrospect, this could be due to something in the script, so maybe we should try a burt restore to Friday afternoon next time someone wants to look at it.

I tried the burt restore today, it didn't work. Also tried some switching of timing cables, and multiple reboots, to no avail. This will require some more debugging. We might try diagnosing the clock driver and fanout modules, the penteks, and we can also try rebooting the whole FE system.
623   Wed Jul 2 13:56:10 2008 Rob, Yoichi, JohnUpdateLocking24.5 Hz resonance
Work continues on trying to reduce the CARM offset using dc signals from PO_DC. Got up to arm powers of
~35 last night.

We found that progress was stymied by an oscillation around 24 Hz. This oscillation was clearly visible
in the intensity of the light at REFL, PO and TrX.

Initially we suspected that this oscillation was due to an instability in the CARM loop. We attempted to
solve the problem by tuning the crossover frequncy of the AO and MC_L paths and shaping the MC_L loop to
reduce the impact of the 24 Hz noise.

After some quick tests we found that the 24 Hz signal was present even when dc CARM was used. It appears
that the peak is in fact due to a SOS mechanical resonance. We currently suspect a roll mode.

We're going to check that PRC, MICH and DARM have filters to attenuate the 24 Hz line. We'll also look at the
SUS_POS bandstop filters to see where they are centred.

The ISS was behaving strangely again. Constantly saturated at 5dB of gain. Someone needs to look a this.
Attachment 1: locking080702.png
630   Thu Jul 3 13:12:32 2008 Rob, Yoichi, JohnUpdateLockingMore oscillations
Bounce/ roll filters were added to the short degrees of freedom to reduce the effect of the 24Hz line seen on Tuesday night.

However last night saw the arrival of a new oscillation at ~34Hz. This may be the second harmonic of the MOS roll mode. Reducing the arm offset would cause this oscillation to ring up and break the lock (first plot). This effect was repeatable.

No signal was seen in the oplevs or osems which leads us to rule out alignment problems, at least for now.

Although one can clearly see DARM_ERR increasing as arm power increases adding a resonant gain in the DARM loop had no effect.

We also noticed that x arm transmission was significantly more noisy than the Y (second plot). And showed greater coherence with the increase in DARM noise. Investigations showed that the PD was not the source of the difference.

Turning up the MC gain seems to help a little.

We're now looking at POX as a candidate for RF_CARM (third plot).
Attachment 1: LOL.png
Attachment 2: NoisyX080702.png
Attachment 3: POXforCARM080702.png
13823   Mon May 7 20:01:14 2018 RorpheusUpdateGeneralUse anti-dewhitening + show CARMA/DARMA

example of plots illustrating DAC range / saturation

6422   Thu Mar 15 08:48:40 2012 RyanSummaryCDSSummary of Syracuse Visit to 40m Mar 5-9 2012

## JIMS Channels in PEM Model

The PEM model has been modified now to include the JIMS(Joint Information Management System) channel processing. Additionally Jim added test points at the outputs of the BLRMS.

For each seismometer channel, five bands are compared to threshold values to produce boolean results.  Bands with RMS below threshold produce bits with value 1, above threshold results in 0.  These bits are combined to produce one output channel that contains all of the results.

A persistent version of the channel is generated by a new library block that called persist which holds the value at 0 for a number of time steps equal to an EPICS variable setting from the time the boolean first drops to zero. The persist allows excursions shorter than the timestep of a downsampled timeseries to be seen reliably.

The EPICS variables for the thresholds are of the form (in order of increasing frequency):
C1:PEM-JIMS_GUR1X_THRES1
C1:PEM-JIMS_GUR1X_THRES2
etc.

The EPICS variables for the persist step size are of the form:
C1:PEM-JIMS_GUR1X_PERSIST
C1:PEM-JIMS_GUR1Y_PERSIST
etc.

The JIMS Channels are being recorded and written to frames:

The two JIMS channels at 2048:
[C1:PEM-JIMS_CH1_DQ] Persistent version of JIMS channel. When bit drops to zero indicating something bad (BLRMS threshold exceeded) happens the bit stays at zero  for >= the value of the persist EPICS variable.
[C1:PEM-JIMS_CH2_DQ] Non-persistent version of JIMS channel.

And all of the BLRMS channels at 256:
Names are of the form:
[C1:PEM-RMS_ACC1_F0p1_0p3_DQ]
[C1:PEM-RMS_ACC1_F0p3_1_DQ]

For additional details about the JIMS Channels and the implementation, please see the previous elog entries by Jim.

## Conlog

I have a working aLIGO Conlog/EPICS Log installed and running on megatron.

Please see this wiki page for the details of use:
https://wiki-40m.ligo.caltech.edu/aLIGO%20EPICs%20log%20%28conlog%29

https://wiki-40m.ligo.caltech.edu/Computer_Restart_Procedures#megatron

Please see Ryan's previous elog entries for installation details.

## Future Work

• Determine useful thresholds for each band
• Generate MEDM Screens for JIMS Channels
• Add a decimation option to channels
• Add EPICS Strings in PEM model to describe bits in JIMS Channels
• Implement a State Log on Megatron: Will Provide a 1Hz index into JIMS Channels
• Generate a single web page that allows access to aLIGO Conlog/EPICS Log and State Log

6518   Wed Apr 11 12:25:11 2012 RyanUpdateComputersUpdating aLIGO Conlog

Over the next few days, I will be working on upgrading the aLIGO Conlog install to include new bugfixes distributed by Patrick T.  The currently running conlog *should* not be affected, but please let me know if it is (ryan.fisher@ligo.org).

6539   Tue Apr 17 10:55:50 2012 RyanUpdateComputersUpdating aLIGO Conlog

 Quote: Over the next few days, I will be working on upgrading the aLIGO Conlog install to include new bugfixes distributed by Patrick T.  The currently running conlog *should* not be affected, but please let me know if it is (ryan.fisher@ligo.org).

The upgrade to the aLIGO Conlog is completed.  The conlog is once again running on megatron in a screen session. (see http://nodus.ligo.caltech.edu:8080/40m/6396)

6373   Wed Mar 7 13:59:07 2012 Ryan FisherSummaryComputer Scripts / ProgramsAlterations to base epics install for installing aLIGO conlog:

In order to install the necessary extensions to epics to make the aLIGO conlog work, I have edited one file in the base epics install that affects makefiles:

/cvs/cds/caltech/apps/linux64/epics/base/configure/CONFIG_COMMON

Jamie said he prefers diffs, so I regenerated the original file and did a diff against the current file:

megatron:configure>diff CONFIG_COMMON.orig.reconstructedMar72012 CONFIG_COMMON.bck.Mar72012
206,207c206,210
< USR_CPPFLAGS =
< USR_DBDFLAGS =
---
> USR_CPPFLAGS = -I $(EPICS_BASE)/include > USR_CPPFLAGS += -I$(EPICS_BASE)/include/os/Linux/
> USR_CPPFLAGS += -I $(EPICS_BASE)/../modules/archive/lib/linux-x86_64/ > USR_DBDFLAGS = -I$(EPICS_BASE)/dbd
> USR_DBDFLAGS += -I $(EPICS_BASE)/../modules/archive/dbd This is saved in CONFIG_COMMON.diff.Mar72012_1 6377 Wed Mar 7 18:00:39 2012 Ryan FisherSummaryComputer Scripts / ProgramsAlterations to base epics install for installing aLIGO conlog:  Quote: In order to install the necessary extensions to epics to make the aLIGO conlog work, I have edited one file in the base epics install that affects makefiles: /cvs/cds/caltech/apps/linux64/epics/base/configure/CONFIG_COMMON Jamie said he prefers diffs, so I regenerated the original file and did a diff against the current file: megatron:configure>diff CONFIG_COMMON.orig.reconstructedMar72012 CONFIG_COMMON.bck.Mar72012 206,207c206,210 < USR_CPPFLAGS = < USR_DBDFLAGS = --- > USR_CPPFLAGS = -I$(EPICS_BASE)/include > USR_CPPFLAGS += -I $(EPICS_BASE)/include/os/Linux/ > USR_CPPFLAGS += -I$(EPICS_BASE)/../modules/archive/lib/linux-x86_64/ > USR_DBDFLAGS = -I $(EPICS_BASE)/dbd > USR_DBDFLAGS += -I$(EPICS_BASE)/../modules/archive/dbd This is saved in CONFIG_COMMON.diff.Mar72012_1

After following up with Patrick Thomas for a while trying to make the extensions to epics work within the currently installed epics, he decided that we should just start over with a fresh install of epics 3.14.10.

I am installing this in /ligo/apps/linux-x86_64/epics/base-3.14.10/

Prior to all of this, I had done a lot of installation and configuration of the packages needed to make LAMP work:

sudo apt-get install lamp-server^

I then continued to follow the instructions on Patrick's wiki:

https://awiki.ligo-wa.caltech.edu/aLIGO/Conlog#EDCU_library

I installed the c_string library into /ligo/apps/linux-x86_64/ according to his instructions.  (prior to my installs, there was no /ligo/ on this machine at all, so I made the needed parent directories with the correct permissions).

That should be everything up to installing epics (working on that now).

6387   Thu Mar 8 17:18:19 2012 Ryan FisherSummaryComputer Scripts / ProgramsAlterations to base epics install for installing aLIGO conlog:
I have the aLIGO Conlog 'working' at http://192.168.113.209/conlog/conlog.php

The process is running inside a screen on megatron.

To start it running, you need to set your environment, and then run the startup.c1conlog script :

cd /cvs/cds/rtcds/caltech/c1/target/conlog/conlogepics

source conlog_environment.txt

./startup.c1conlog

This will leave you at an epics prompt, which means the code is running. (that's why I left it running in a screen for now).

To change the list of channels when the conlog is running, you need to edit the file (s):

/ligo/caltech/data/conlog/c1/remove_channel_names

Then start up medm as follows:

cd ~/ryan/

Then click the Add channel list button or Remove channel list button.

To change the channels before running the conlog from a blank database, you would edit:
/ligo/caltech/data/conlog/c1/use_channel_names (I believe this should be read whenever the conlog is restarted, but I'm only sure it does the first time you start conlog).

Documenting the rest of the installation:

## Successful? Installation of Fresh EPICS and Extensions

### Fresh Copy of EPICS 3.14.10

* We restarted (on Patrick's suggestion) with a fresh copy of EPICS 3.14.10 in:
/ligo/apps/linux-x86_64/epics
* I had to set a clean environment:
* Then I downloaded the tarball, unpacked it, and simply ran make within it, and it worked!
* Next, I followed Patrick's wiki instructions with only modifications to the configure/RELEASE files for the archive and ioc/conlog extensions.
* Then I realized that I had to rebuild conlog ioc after adding a directory:
/ligo/apps/linux-x86_64/epics/iocs/conlog/iocBoot/iocc1_conlog
* I had to copy the files from the h1 directory and modify them so that all reference to h1 now point to c1 in the new directory
* I then rebuilt the conlog ioc (I had to make sure setenv SCRIPTS was run again because I had logged out and back in, and I reset the whole environment properly again)

## Rest of Install

* I was able to fairly trivially follow through the rest of the installation steps on Patrick's wiki, up to the "Design" section.
* Now, there is no obvious way to move forward (nothing is actually running I believe).

## New Install Instructions:

"
You want to create the EPICS IOC boot directory by doing the following:

In the top level of the IOC (.../epics/iocs/conlog) with the appropriate
paths:

/epics/base/bin/linux-x86_64/makeBaseApp.pl -i -t ioc c1_conlog
What application should the IOC(s) boot?
The default uses the IOC's name, even if not listed above.
Application name? conlog

Then you will have to update the st.cmd it creates. You can compare the
st.cmd and st.cmd.backup files in the other directories to see what needs
to be changed.

I don't know if just copying the directory will work, it might.

You will also probably want to change the following line in
/epics/modules/archive/archiveApp/src/drvArchive.c:

queue = epicsMessageQueueCreate(100000000, sizeof(struct message_type));

and reduce 100000000 to something smaller depending on the amount of ram
available to the computer. I think sizeof(struct message_type) is
something like 112 bytes. Then recompile.

You basically put a file with the list of channels to use in the directory
path for "use channel list filepath" in the following command in st.cmd:
channel list filepath>,<use channel list filepath>
I can send you the script that I currently use to generate that channel
list if you want, but it may need to be changed for your setup.

Once you start the ioc, open the medm which can be checked out from
with macro substitution for IFO: medm -x -macro "IFO=C1"
and click on the button for "Use channel list".
The number of monitored channels should increase to the number of channels
in the file.

-Patrick

...

The perl script and example file are attached, just redirect the output of
the perl script to a file. It scans autoBurt.req files in a particular
directory and its subdirectories for channel names that meet certain
criteria. All the file contains is a list of channel names, one on each
line. To start the IOC, go to the target directory and run
./startup.c1conlog.

"

{{rpfisher:scan_autoburt.pl.txt|scan_autoburt.pl.txt}}

{{rpfisher:use_channel_names.txt|use_channel_names.txt}}

### My Notes Regarding These Instructions:

* Throughout the installation instructions, it probably should have been made clear that the ifo is lowercase: eg c1 (but in the end the installation mixed C1 and c1 in different places)
* Also throughout, one should be careful to replace lho with your site (eg caltech) wherever it appears
* After running the first perl script to generate the iocBoot/iocc1_conlog directory, the goal is to rebuild the whole conlog ioc by running make from epics/iocs/conlog, but before doing that:
* I needed to change the suggested line in the archive module to match the correct RAM size of the machine I am installing on (I actually gave it just less than half the free RAM), then:
* Remake the archive module
* Change into the ioc/conlog directory, remove the iocBoot I had made before for c1, rerun the perl script above, then run make from the ioc/conlog directory.
* Once that is done, you need to edit the file st.cmd to add lines for the reading and writing of channels, such as:
drvArchive_mysql "C1_conlog","/data/mysql/C1_conlog_epics_user"
drvArchive_write_channel_list_filepaths "/ligo/caltech/data/conlog/c1/channel_names","/ligo/caltech/data/conlog/c1/monitored_channel_names","/ligo/caltech/data/conlog/c1/unmonitored_channel_names"
* I also had to rerun this set of commands once that was all done:
controls: cd /opt/rtcds/<site>/<ifo>/target/conlog/conlogepics
controls: cp -r /ligo/apps/linux-x86_64/epics/iocs/conlog/db ./
controls: cp -r /ligo/apps/linux-x86_64/epics/iocs/conlog/dbd ./
controls: cp /ligo/apps/linux-x86_64/epics/iocs/conlog/iocBoot/ioc<ifo>_conlog/envPaths ./
controls: cp /ligo/apps/linux-x86_64/epics/iocs/conlog/iocBoot/ioc<ifo>_conlog/st.cmd ./
controls: echo ./bin/linux-x86_64/conlog st.cmd > startup.<ifo>conlog
controls: chmod a+x startup.<ifo>conlog
* This set of instructions seemed to be lacking, so I added this:

cp -r /ligo/apps/linux-x86_64/epics/iocs/conlog/bin/ ./

* Now the executable runs but doesn't work:
* Fixes needed:
* Need to use root permissions and make sure the files in /data/mysql have the right names for the users the code expects and also have the right passwords. (have to match capitalization appropriately for the <ifo> tag everywhere
* Might need to go into mysql and add a new user with the proper capitalization also
* Need to edit the ld_library_path to point to the new epics libraries (see the suggested environment below)
* Now, the code seems to work, but dumps me at an "epics> " prompt, I'm asking Patrick what to do next.
* I was impatient and loaded up the medm screen, and found out that the one channel I had picked was not readable (unmonitored)
* I ran a modified version of Patrick's perl script to search autoBert files for channels, and replaced my use_channel_names file with the output of the script
* Now, the medm screen shows lots of monitored channels, and the conlog is filling up! (can see it from phpmyadmin)
* Next step: I wanted to get the php pages working, so I edited the files inside /var/www/conlog:
megatron:~/ryan>diff -u /var/www/conlog/conlog.php /var/www/conlog/conlog.php.bck.Mar82012_1
--- /var/www/conlog/conlog.php  2012-03-08 15:31:53.152547771 -0800
+++ /var/www/conlog/conlog.php.bck.Mar82012_1   2012-03-08 15:28:23.062704171 -0800
@@ -19,7 +19,7 @@
<form action="query.php" method="post">
<h3><label for="database">Database:</label></h3>
<select id="database" name="database">
-                       <option value="C1_conlog">C1</option>
+                       <option value="h2_conlog">h2</option>
</select>

<h3><label for="included_channels">Included channels:</label></h3>

megatron:~/ryan>diff -u /var/www/conlog/query.php /var/www/conlog/query.php.bck.Mar82012_1
--- /var/www/conlog/query.php   2012-03-08 15:33:45.122550303 -0800
+++ /var/www/conlog/query.php.bck.Mar82012_1    2012-03-08 15:32:31.772554679 -0800
@@ -168,8 +168,8 @@
}

$database_name =$_POST["database"];
-       if ($database_name == 'C1_conlog') { -$server = '192.168.113.209';
+       if ($database_name == 'h2_conlog') { +$server = 'cdsconlog';
}
else {
die('Unknown database.');

* Finally, the mysql server was denying access from outside queries, so I fixed that:
megatron:~/ryan>diff -u /etc/mysql/my.cnf /etc/mysql/my.cnf.bck.Mar82012_1
--- /etc/mysql/my.cnf   2012-03-08 15:35:57.122548370 -0800
+++ /etc/mysql/my.cnf.bck.Mar82012_1    2012-03-08 15:35:10.652559315 -0800
@@ -49,7 +49,7 @@
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#
# * Fine Tuning
#
megatron:~/ryan>
* Now, I think everything is working * almost:
* It seems that when you first start the conlog up, it finds all the variables and inserts values of "Null" for everything, but after that it detects changes properly!

## Conlog Environment

Need to source this to use the new environment:

megatron:~>cat ~/ryan/conlog_enviroment.txt
6391   Fri Mar 9 11:02:56 2012 Ryan FisherSummaryComputer Scripts / ProgramsAlterations to base epics install for installing aLIGO conlog:

# Too Many Fast Changing EPICS in New Conlog

I have been monitoring the new conlog, and it already has far too many rows.

I'm going through the list of channels to exclude in the update_channels script for the conlog that is currently running and removing them from
the monitored channels in the new conlog using the remove_channel_names file and the medm screen (we may want to just wipe out the tables
and start over after this is set properly, but for now I'm keeping them):
#-- Exclude a few uninteresting or obsolete categories
if ( $chan =~ m/^[BIJ]$/ ||
$chan =~ m/IOO-MC_PWR_IN/ ||$chan eq "C1:PSL-FSS_SLOWDC" ||
$chan =~ m/PSL-STAT_.*_BITS/ ||$chan =~ m/:IOO-PZTM[12]_(PIT|YAW)_BIAS$/ ||$chan =~ m/DAQ.*_cycle/ ||
$chan =~ m/DAQ.*rtSeconds/ ||$chan =~ m/C1:-.*/ ||
$chan =~ m/C1:SUP/ ||$chan =~ m/C1:SP/ ||
$chan =~ m/C1:X/ ||$chan =~ m/C1:TST/ ||
$chan =~ m/C1:RF/ ||$chan =~ m/C1:UCT/ ||
$chan =~ m/C1:DU/ ||$chan =~ m/C1:MCP/ ||
$chan =~ m/C1:MCS/ ||$chan =~ m/C1:FEC/ ||
$chan =~ m/C1:PEM/ ||$chan =~ m/C1:LSP/ ||
$chan =~ m/C1:NIO/ ||$chan =~ m/C1:WFS/ ||
$chan =~ m/C1:ASC-WFS/ ||$chan =~ m/C1:ASC-SP/ ||
$chan =~ m/C1:VG/ ||$chan =~ m/C1:IOO-DOF/ ||
$chan =~ m/C1:IOO-EO/ ||$chan =~ m/Name/ ||
$chan =~ m/DEFAULTNAME/ ||$chan =~ m/:IOO-PZT.*OFFSET/ ||
$chan =~ m/PD_VAR$/ ||
$chan =~ m/_INMON$/ ||
$chan =~ m/_EXCMON$/ ||
$chan =~ m/_OUT16$/ ||
$chan =~ m/_OUTMON$/ ||
$chan =~ m/_OUTPUT$/ ||
$chan =~ m/_RSET$/ ||
$chan =~ m/_ALIVE$/ ||
$chan =~ m/VMon$/ ||
$chan =~ m/PDMon$/ ||
_STAT|State_Bits|INDCOFFSET)/ )

With these removals, only 15493 channels are being monitored now.
6394   Fri Mar 9 15:48:56 2012 Ryan FisherSummaryComputer Scripts / ProgramsAlterations to base epics install for installing aLIGO conlog:

I decided to make a backup of the database and then delete it and make a new database:

cd ~/ryan/database_dumpMar92012
mysqldump -u root -p C1_conlog > C1_conlog.dump.Mar92012
Note: it appears this failed the first time, thankfully this wasn't a production service yet... In the future, do not trust this backup method for important data!

Next, log into mysql as root, dump the database, remake it and grant privileges again.:
(This is saved in megatron:~/ryan/restore_database.txt
megatron:~/ryan>mysql -u root -p
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 174
Server version: 5.1.41-3ubuntu12.10 (Ubuntu)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> list databases;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'list databases' at line 1
mysql> list users;      ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'list users' at line 1
mysql> use C1_conlog
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> list users;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'list users' at line 1
mysql> select User from mysql.user;                                             +------------------+
| User             |
+------------------+
| php              |
| C1_conlog_epics  |
| c1_conlog_epics  |
| root             |
| C1_conlog_epics  |
| c1_conlog_epics  |
| debian-sys-maint |
| root             |
| root             |
+------------------+
9 rows in set (0.00 sec)

mysql> show databases;                                                          +--------------------+
| Database           |
+--------------------+
| information_schema |
| C1_conlog          |
| mysql              |
+--------------------+
3 rows in set (0.00 sec)

mysql> drop database C1_conlog ;
Query OK, 2 rows affected (0.56 sec)

mysql> create database C1_conlog;
Query OK, 1 row affected (0.00 sec)

mysql> use C1_conlog ;
Database changed
mysql> SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
Query OK, 0 rows affected (0.00 sec)

mysql>
mysql> CREATE TABLE channels (
->   channel_id mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
->   channel_name varchar(60) NOT NULL,
->   PRIMARY KEY (channel_id),
->   UNIQUE KEY channel_name (channel_name)
-> ) ENGINE=MyISAM  DEFAULT CHARSET=latin1;
Query OK, 0 rows affected (0.04 sec)

mysql>
mysql> CREATE TABLE data (
->   acquire_time decimal(26,6) NOT NULL,
->   channel_id mediumint(8) unsigned NOT NULL,
->   value varchar(40) DEFAULT NULL,
->   status tinyint(3) unsigned DEFAULT NULL,
->   connected tinyint(1) unsigned NOT NULL,
->   PRIMARY KEY (channel_id,acquire_time)
-> ) ENGINE=MyISAM DEFAULT CHARSET=latin1;
Query OK, 0 rows affected (0.03 sec)

mysql> grant select, insert, update, execute on * to 'c1_conlog_epics'@'127.0.0.1';  Query OK, 0 rows affected (0.00 sec)
mysql> grant select, insert, update, execute on * to 'C1_conlog_epics'@'127.0.0.1';   Query OK, 0 rows affected (0.00 sec)
mysql> grant select, insert, update, execute on * to 'c1_conlog_epics'@'localhost';  Query OK, 0 rows affected (0.00 sec)
mysql> grant select, insert, update, execute on * to 'C1_conlog_epics'@'localhost';
Query OK, 0 rows affected (0.00 sec)

mysql> grant select on C1_conlog to 'php'@'%';
ERROR 1146 (42S02): Table 'C1_conlog.C1_conlog' doesn't exist
mysql> grant select on * to 'php'@'%';
Query OK, 0 rows affected (0.00 sec)

mysql> select * from mysql.users
-> ;
ERROR 1146 (42S02): Table 'mysql.users' doesn't exist
mysql> select User from mysql.user;
| C1_conlog_epics  |
| c1_conlog_epics  |
| root             |
| C1_conlog_epics  |
| c1_conlog_epics  |
| debian-sys-maint |
| root             |
| root             |
+------------------+
9 rows in set (0.00 sec)

mysql> Bye

Next, I decided that I want to index on the acquire_time instead of the combination of channel_id and acquire_time (I think it makes a lot of sense for several query types, and especially debugging the conlog!):
mysql> create index acquire_time_index on data(acquire_time);
Query OK, 0 rows affected (0.04 sec)
Records: 0  Duplicates: 0  Warnings: 0

## Next Fix:

The above worked well, but when I restarted the conlog, I had to re-execute the "remove_channels" from the medm, because initially all channels were being loaded (use_channel_names had all the channels still).
Additionally, there were a lot of channels with "*RMS*" in the name that were being recorded, and were changing relatively quickly, so I have added those to the remove_channel_names file.

I am going to: Backup the files in /ligo/caltech/data/conlog/c1
Edit use_channel_names to only have the good channels.
Dump the database again
Stop conlog.
Wipe the database again.
Remake the database again (with permissions and the new index).
Restart the conlog and hope!

## The fix above seems to be in place and working. The database has the initial entries for the channels it monitors and is not growing without operators changing EPICs values.

6396   Fri Mar 9 16:28:10 2012 Ryan FisherSummaryComputer Scripts / ProgramsAlterations to base epics install for installing aLIGO conlog:
I created a page on the wiki for the new EPICS log (conlog):
https://wiki-40m.ligo.caltech.edu/aLIGO%20EPICs%20log%20%28conlog%29

I also edited this with restart instructions:
https://wiki-40m.ligo.caltech.edu/Computer_Restart_Procedures#megatron
6404   Tue Mar 13 13:28:31 2012 Ryan FisherUpdateCDSDAQ restart with new ini file
Extra note: This was the ini file that was edited:
/cvs/cds/rtcds/caltech/c1/chans/daq/C1PEM.ini
7001   Mon Jul 23 07:39:55 2012 Ryan FisherSummaryComputer Scripts / ProgramsAlterations to base epics install for installing aLIGO conlog:
Note: The Conlog install instructions that I started from were located here:
https://awiki.ligo-wa.caltech.edu/aLIGO/Conlog
5729   Mon Oct 24 17:23:14 2011 SUS_DiagonalizerUpdateSUSOptics kicked
This is a cron-elog test. No optics have been kicked.
5766   Sun Oct 30 23:03:37 2011 SUS_DiagonalizerUpdateSUSSUS input matrix diagonalization complete (EXAMPLE)
New SUS input matrix diagonalization complete. Matrices have been written to the frontend. Summaries for each optic can be viewed below.

(THIS IS AN EXAMPLE---no new matrices have been written.)
Attachment 1: MC1.png
Attachment 2: MC2.png
Attachment 3: MC3.png
Attachment 4: ETMX.png
Attachment 5: ETMY.png
Attachment 6: ITMX.png
Attachment 7: ITMY.png
Attachment 8: PRM.png
Attachment 9: SRM.png
Attachment 10: BS.png
7523   Wed Oct 10 21:50:39 2012 SUS_DiagonalizerUpdateSUSOptics kicked
All suspended optics have been kicked at Wed Oct 10 21:50:39 PDT 2012. Watchdogs will be reengaged in 90 minutes.
7524   Thu Oct 11 00:22:58 2012 SUS_DiagonalizerUpdateSUSOptics kicked

 Quote: All suspended optics have been kicked at Wed Oct 10 21:50:39 PDT 2012. Watchdogs will be reengaged in 90 minutes.

New SUS input matrix diagonalization complete.
10008   Mon Jun 9 09:51:11 2014 Sai AkhilUpdateElectronicsFrequency Error Measurement of UFC-6000 RF Frequency Counter

Motivation:

To test the precision of Mini-Circuits Model UFC-6000 RF Frequency Counter which will be used for recording the beat note for the Frequency Offset Locking Loop(FOLL).

Setup:

Mini Circuits RF Frequency Counter Model UFC-6000 has three I/O ports:
1)REF IN,2)USB INTERFACE,3)RF IN.
The USB INTERFACE is connected to the PC(Windows/Linux) through a USB cable.
The test RF input from an SRS Function Generator(Model DS 345 with tested precision up to 1mHz)is fed in through RF IN using an SMA cable with an SMA-BNC adaptor to connect to the Function Generator.
The REF IN is open since we want to test the counter.

What I did:

1. First interfaced the counter with the PC with windows OS.

2. Installed the user friendly GUI on my Laptop so as to record the data from the counter into a .txt file.

3. Gave an RF input through the function generator and recorded the response of the counter for different frequencies ranging from 1MHz to 30MHz.

4.Analyzed the collected data by plotting the histograms(attached) in Matlab(script attached in .zip file)

What was Expected:

The measurement statistics of the instrument would give knowledge about the error and tolerance in the measurement which will be helpful to negotiate the error when the counter is being used in the setup.

Results:

The obtained plots(for sampling time of 1s) are attached in a figure.
The measurement error of the frequency counter for 1s sampling time is:

data file     Frequency       Mean in MHz            Standard Error(+/-)in Hz
1MH.txt            1MHz            0.999999846             0.0109
5MHz.txt          5MHz            5.000000293             0.0134
10MHz.txt       10MHz         10.00000148              0.0108
15MHz.txt       15MHz         15.0000018                0.0072
20MHz.txt       20MHz         20.00000053              0.0259
30MHz.txt       30MHz         30.00000146              0.0230

The measurement error of the UFC-6000 RF Frequency Counter is in the order of 0.01-0.02 Hz. This error varies at different frequencies as inferred from the table.
The error for different sampling times of the FC are also plotted.

Plan:

To complete interfacing the counter with the Raspberry-pi.
Make this Frequency Counter talk to EPICS through slow channels.

Attachment 1: Data_and_Script_Files.zip
Attachment 2: Error_Measurement_FC.pdf
Attachment 3: Error_freq.jpg
14058   Thu Jul 12 15:15:47 2018 SandrineUpdate Beat Note Measurements for Cavity Scans

(Gautam, Sandrine)

We calculated the expected power of the beat note for Annalisa's Y arm cavity scans.

Beat Note Measurement

We began by calculating the transmitted power of the PSL and AUX. We assumed that the input power of the PSL was 25 mW and the input power of the AUX was 250 uW. We also assumed a loss of 25 ppm for the ITM and ETM. We used T1 = 0.0138 and T2 = 25 x 10-6.

$P_{t} = \frac{t _{1}^{2}t_{2}^{2}}{1+r_{1}^{2}r_{2}^{2}-2r_{1}r_{2}}$

$t = \sqrt{T}$

$r = \sqrt{1-T-L} = {\sqrt{R}}$

The transmitted power of the PSL is approximately 100 uW, and the transmitted power of the AUX is approximately 0.974 uW.

$P_{t}^{PSL} = 100 uW$                          $P_{t}^{AUX} = 0.974 uW$

The beat note was calculated with the following:

$P_{beat} = 2\sqrt{P_{PSL}P_{AUX}} = 20 uW$

The  expected beat note should be approximately 20 uW.

14103   Wed Jul 25 14:45:59 2018 SandrineSummaryThermal CompensationETM Y Table AUX read out

Attached is a photo of the set up of the ETM Y table showing the AUX read out set up.

Currently, the flip mount sends the AUX to the PDA255. Terra inserted a razor blade so the PDA255 will witness more HOMs. The laser is also sent to the regular PD and the CCD.

Attachment 1: EY_table_.JPG
14109   Fri Jul 27 17:16:14 2018 SandrineUpdateThermal CompensationCopied working scripts for mode spectroscopy into new directory (modeSpec)

The scripts: AGfast.py, make HDF5.py, plotSpec_marconi.py, and SandrineFitv3.py were copied into the new directory modeSpec.

The path is: /opt/rtcds/caltech/c1/scripts/modeSpec

These scripts can still be found under Annalisa's directory under postVent.

15510   Sat Aug 8 07:36:52 2020 Sanika KhadkikarConfigurationCalibration-RepairBS Seismometer - Multi-channel calibration

Summary :

I have been working on analyzing the seismic data obtained from the 3 seismometers present in the lab. I noticed while looking at the combined time series and the gain plots of the 3 seismometers that there is some error in the calibration of the BS seismometer. The EX and the EY seismometers seem to be well-calibrated as opposed to the BS seismometer.

The calibration factors have been determined to be :

BS-X Channel: $\dpi{150} \small {\color{Blue} 2.030 \pm 0.079 }$

BS-Y Channel: $\dpi{150} \small {\color{Blue} 2.840 \pm 0.177 }$

BS-Z Channel: $\dpi{150} \small {\color{Blue} 1.397 \pm 0.182 }$

Details :

The seismometers each have 3 channels i.e X, Y, and Z for measuring the displacements in all the 3 directions. The X channels of the three seismometers should more or less be coherent in the absence of any seismic excitation with the gain amongst all the similar channels being 1. So is the case with the Y and Z channels. After analyzing multiple datasets, it was observed that the values of all the three channels of the BS seismometer differed very significantly from their corresponding channels in the EX and the EY seismometers and they were not calibrated in the region that they were found to be coherent as well.

Method :

Note: All the frequency domain plots that have been calculated are for a sampling rate of 32 Hz. The plots were found to be extremely coherent in a certain frequency range i.e ~0.1 Hz to 2 Hz so this frequency range is used to understand the relative calibration errors. The spread around the function is because of the error caused by coherence values differing from unity and the averages performed for the Welch function. 9 averages have been performed for the following analysis keeping in mind the needed frequency resolution(~0.01Hz) and the accuracy of the power calculated at every frequency.

1. I first analyzed the regions in which the similar channels were found to be coherent to have a proper gain analysis. The EY seismometer was found to be the most stable one so it has been used as a reference. I saw the coherence between similar channels of the 2 seismometers and the bode plots together. A transfer function estimator was used to analyze the relative calibration in between all 3 pairs of seismometers. In the given frequency range EX and EY have a gain of 1 so their relative calibration is proper. The relative calibration in between the BS and the EY seismometers is not proper as the resultant gain is not 1. The attached plots show the discrepancies clearly :
• BS-X & EY-X Transfer Function : Attachment #1
• BS-Y & EY-Y Transfer Function : Attachment #2

The gain in the given frequency range is ~3. The phase plotting also shows a 180-degree phase as opposed to 0 so a negative sign would also be required in the calibration factor. Thus the calibration factor for the Y channel of the BS seismometer should be around ~3.

• BS-Z & EY-Z Transfer Function : Attachment #3

The mean value of the gain in the given frequency range is the desired calibration factor and the error would be the mean of the error for the gain dataset chosen which is caused due to factors mentioned above.

Note: The standard error envelope plotted in the attached graphs is calculated as follows :

1. Divide the data into n segments according to the resolution wanted for the Welch averaging to be performed later.

2. Calculate PSD for every segment (no averaging).

3. Calculate the standard error for every value in the data segment by looking at distribution formed by the n number values we obtain by taking that respective value from every segment.

Discussions :

The BS seismometer is a different model than the EX and the EY seismometers which might be a major cause as to why we need special calibration for the BS seismometer while EX and EY are fine. The sign flip in the BS-Y seismometer may cause a lot of errors in future data acquisitions. The time series plots in Attachment #4 shows an evident DC offset present in the data. All of the information mentioned above indicates that there is some electrical or mechanical defect present in the seismometer and may require a reset. Kindly let me know if and when the seismometer is reset so that I can calibrate it again.

Attachment 1: BS_X-EY_X.png
Attachment 2: BS_Y-EY_Y.png
Attachment 3: BS_Z-EY_Z.png
Attachment 4: timeseries.png
1985   Fri Sep 11 17:11:15 2009 SanjitUpdateASSOAF: progress made

[Jenne & Sanjit]

Good news: We could successfully send filtered output to MC1 @ SUS.

We used 7 channels (different combinations of 3 seismometer and six accelerometer)

We tried some values of \mu (0.001-0.005) & gain on SUS_MC1_POSITION:MCL and C1ASS_TOP_SUS_MC1 (0.1-1).

C1:ASS-TOP_SUS_MC1_INMON is huge (soon goes up to few times 10000), so ~0.1 gains at two places bring it down to a reasonable value.

Bad news: no difference between reference and filtered IOO-MC_L power spectra so far.

Plan of action: figure out the right values of the parameters (\mu, \tau, different gains, and may be some delays), to make some improvement to the spectra.

** Rana: there's no reason to adjust any of the MCL gains. We are not supposed to be a part of the adaptive algorithm.

2160   Thu Oct 29 18:25:33 2009 SanjitUpdateAdaptive FilteringMore work on saving coeffs on the OAF screen

 Quote: [Sanjit,Jenne] Sanjit has been working today on trying to get the OAF coefficients to save properly.  Alex got us most of the way, but right now it's looking like the filter that is being saved is totally constant (all the values are the same).  We're poking around trying to figure out why this is.  Also, we're starting again (as we should have been for the last week or so since Alex came in to help us) to check in the TOP_XFCODE whenever we make changes to it, and when we recompile the front end code.

We are manually restarting assepics, but the terminal logs us out after sometime and ass may crash. I set autologout=0 in the terminal for the time being. Once the testing process is over, assepics will start automatically when the computer is turned on, so we wont have to worry about this.

(if ass crashes tonight, it is not unexpected!)

2171   Mon Nov 2 21:09:15 2009 SanjitUpdateAdaptive FilteringMore work on saving coeffs on the OAF screen

I made some changes in the code (all commented in the installed and SVN version) to print the filter coefficients. I got crazy output. Sometimes memory bugs lead to such crazy behavior. So far I could not find any bugs, but will have to spend more time on it.

2323   Tue Nov 24 18:24:54 2009 SanjitConfigurationAdaptive FilteringASS channels added to framebuilder

[Sanjit, Jenne, Rob, Joe]

We added and tested the following channels from "/cvs/cds/gds/param/tpchn_C3.par" to "/cvs/cds/caltech/chans/daq/C1ASS.ini" appending a "_2048" extension to the channel name (as the name of a channel in .ini and .par files must be different):

[C1:ASS-TOP_CORR_IN1_2048]
[C1:ASS-TOP_ERR_EMPH_IN1_2048]
[C1:ASS-TOP_PEM_10_IN1_2048]
[C1:ASS-TOP_PEM_11_IN1_2048]
[C1:ASS-TOP_PEM_12_IN1_2048]
[C1:ASS-TOP_PEM_15_IN1_2048]
[C1:ASS-TOP_PEM_16_IN1_2048]
[C1:ASS-TOP_PEM_17_IN1_2048]
[C1:ASS-TOP_PEM_18_IN1_2048]
[C1:ASS-TOP_PEM_19_IN1_2048]
[C1:ASS-TOP_PEM_20_IN1_2048]
[C1:ASS-TOP_PEM_24_IN1_2048]
[C1:ASS-TOP_PEM_2_IN1_2048]
[C1:ASS-TOP_PEM_3_IN1_2048]
[C1:ASS-TOP_PEM_4_IN1_2048]

These five-line entries for each channels in the .par file were manually copy pasted from the .ini file, should think about a smarter way...

The old .par file is kept as: /cvs/cds/caltech/chans/daq/C1ASS.ini.20Nov2009

The current one is also saved as: /cvs/cds/caltech/chans/daq/C1ASS.ini.24Nov2009

And, the current one is committed to the svn.

NOTE: In the first attempt, the channel names were mistakenly kept the same in both the .ini and .par files and this caused DAQ daemon to crash badly. It could only be recovered by hard reboot of the frame builder.  Important info here: Jenne's elog 2316

ELOG V3.1.3-