40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 223 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  4803   Fri Jun 10 12:02:10 2011 ranaUpdateCDSSecond trends only go back 12 days


While answering a quick question by Kiwamu, I noticed we only had second trends going back to 99050000 GPS time, May 27th 2011. 

Trends (I thought) were intended to be kept forever, and certainly longer than full data, which currently goes back several months.

Jamie will need to look into this.

 Our concept is to keep second trends for 1-2 months and minute trends forever. The scheme that Alan had worked out many years ago had it such that we could look back to 1998 and that the minute trends would be backed up somehow.

If its not working, we need to get Alan's help to recover the previous configuration.

  650   Tue Jul 8 21:58:22 2008 albertoUpdateGeneralSecondaty beam aligned to the IFO beam again
Yesterday the alignment of the secondary beam to the IFO was completely lost and today I had to realign all the optics before I was able to match the two spots again. I had to reset the height of the irises and I had also to replace mirror M1 with one with a larger angular motion. Eventually I obtained the beat again. Working on the optics table I inadvertently misaligned the OSA but I didn't make in time to bring it back before the night shift people came. I'll work on that tomorrow morning.
  3489   Mon Aug 30 18:35:22 2010 JenneUpdateWienerFilteringSecret Hiding Place for Raw Data

As it turns out, data seems to fall off the 16Tb drives after ~20 days.  Which makes it a good thing that I saved all of my raw data from my good Mode Cleaner / seismic weekend for offline Wiener Filtering in the following secret place:


It's not linked to the svn, since it's a boatload of data.

  7954   Tue Jan 29 14:34:42 2013 JenneUpdatePEMSecret Seis filters


The BLRMS have been bad again, since the computer crash of last week.  Finally getting around to looking into it, I discovered that there are filter banks that have the microns/sec calibration filters, which are not accessible from the sitemap.  I have added links to them for GUR1 and GUR2.  We need to make the PEM/BLRMS screens macro-expansion-y, so that I don't have to change each screen individually.

Anyhow, the BLRMS are back.


  657   Thu Jul 10 23:27:57 2008 JohnMetaphysicsCamerasSecret handshakes
Rob and I have joined the ranks of the illuminati and exercised our power.

Osamu showed me the secret way to change the video labels for the quads and
so we fixed them. He made me swear not to divulge this art.

- Rana Adhikari
  10482   Wed Sep 10 02:35:54 2014 JenneHowToTreasureSecret scripts, revealed!

 I hereby confess to having a secret script.  But it is secret no longer!

It's a "goLock" script, and it is now in the path from any terminal.  It kills any open medm sessions (to clean up desktops), and then opens a palette of screens that I find useful.  It also starts up the CARM and DARM ALS watch scripts, and the toggle shutter scripts.  It then leaves the terminal in .../scripts/PRFPMI/ , which is where the carm_cm_up.sh script that we've been using lives.

I also made tonight a "goHome" script, but all that one does so far is set the LSC mode to OFF.  The other thing that this could / should do is restore all optics so we don't have hysteresis problems.

Also, also, my "new" misalign / restore scripts had a bug, in that they were always switching oplevs for the PRM, no matter what optic was requested.  This sometimes caused the PRM oplev to be engaged while the optic was misaligned, so the PRM would get rung up.  This has been fixed.

  5573   Thu Sep 29 00:16:35 2011 DenUpdateComputersSegmentation fault fixed.

The OAF c-code crashed because of the segmentation fault. We've created arrays of static variables

    static int pst[nDOF];
    static int isFirst[nDOF];
    static adaptive_filter_state state[nDOF];

an tried to give in the to the ITERATE - function their current values

        datOut[i] = ITERATE(iterateDatIn, iterateNIn, pst[i], isFirst[i], state[i]);

ITERATE function was declared as

double ITERATE(double *datIn, int nIn, int pst, int isFirst, adaptive_filter_state state) {}

Here the segmentation fault comes out. Static variables are meant to be created only once but here in the function ITERATE we try to create them once again in a local form, because we give the variables by their values.

Instead, we must give the variables by their pointer, then the variables won't be created again during the function call and will be changed in the function.

        datOut[i] = ITERATE(iterateDatIn, iterateNIn, &pst[i], &isFirst[i], &state[i]);

       double ITERATE(double *datIn, int nIn, int *pst_s, int *isFirst_s, adaptive_filter_state *state_s)

In order not to change significantly Matt's code and use his notations we can add in the ITERATE function

    int pst = *pst_s;
    int isFirst = *isFirst_s;
    static adaptive_filter_state state;
    state = *state_s;

..................................Matt's code.........................................

    *pst_s = pst;
    *isFirst_s = isFirst;
    *state_s = state;

I've tested the program, now it does not give any segmentation faults and conserves memory that it uses.

  295   Sun Feb 3 05:02:41 2008 ranaUpdatePEMSeism 4 day
Attachment 1: Screenshot.png
  5663   Thu Oct 13 21:44:48 2011 MirkoUpdateCDSSeismic BLRMS channels, new RMS calculation

[Rana, Koji, Mirko]

We looked into the CDS RMS block c-code as described in Rolfs RCG app guide. Seems the block uses a first order LP filter with a corner freq. / time of 20k execution cycles. There are also some weird thersholds at +-2000counts in there.

I was looking into implementing a hand-made RMS block, by squaring, filtering, rooting. The new RMS (left) seems nicer than the old one (bottom right). Signal was 141counts sinus at 4Hz.

Filters used: Before squaring: 4th order butterworth BP at given freq. & (new) 6th order inverse Chebyshew 20dB at 0.9*lower BP freq. and 1.1*upper BP freq. => about 1dB at BP freq.

                       After squaring: 4th order butterworth LP @ 1Hz.

C1PEM execution time increased from about 20us to about 45us.

Made a new medm screen with the respective filters in place of the empty C1PEM_OVERVIEW. Should go onto the sitemap.


Original RMS LP is slower than 0.1Hz, see below for single LP at 0.1Hz in the new RMS. Original RMS is faster than single LP @ 0.01Hz


Some of the channels are recorded as 256Hz DAQ channels now. Need to figure out how to record these as 16Hz EPICS channls.

  5679   Mon Oct 17 14:26:22 2011 MirkoUpdateCDSSeismic BLRMS channels, new RMS calculation


[Rana, Koji, Mirko]

We looked into the CDS RMS block c-code as described in Rolfs RCG app guide. Seems the block uses a first order LP filter with a corner freq. / time of 20k execution cycles. There are also some weird thersholds at +-2000counts in there.

I was looking into implementing a hand-made RMS block, by squaring, filtering, rooting. The new RMS (left) seems nicer than the old one (bottom right). Signal was 141counts sinus at 4Hz.

Filters used: Before squaring: 4th order butterworth BP at given freq. & (new) 6th order inverse Chebyshew 20dB at 0.9*lower BP freq. and 1.1*upper BP freq. => about 1dB at BP freq.

                       After squaring: 4th order butterworth LP @ 1Hz.

C1PEM execution time increased from about 20us to about 45us.

Made a new medm screen with the respective filters in place of the empty C1PEM_OVERVIEW. Should go onto the sitemap.


Original RMS LP is slower than 0.1Hz, see below for single LP at 0.1Hz in the new RMS. Original RMS is faster than single LP @ 0.01Hz


Some of the channels are recorded as 256Hz DAQ channels now. Need to figure out how to record these as 16Hz EPICS channls.

 Channels are now going into EPICS channels (e.g. C1:PEM-ACC1_RMS_1_3 ). Adapted the PEM_SLOW.ini file. Channels don't yet show up in dataviewer. Probably due to other C1PEM maschine

  11316   Tue May 19 19:24:30 2015 ranaUpdatePEMSeismic BLRMS filters

I was wondering about the design of the BLRMS fitlers for the seismic channels since the STS ones seem to have so little gain compared to the Guralps.

Here are some plots of the Bode magnitude and impulse responses of the bandpass filters (before the low passing). There's a bunch of entries from Masha on this from her SURF summer. Can anyone comment on why they are all so different?

One of the old Masha entries speaks of designing the lowpass filter in an intelligent way: by adjusting the filter order until the power in the stopband is less than 1% of the power in the passband. Seems like we could do that for bandpass too. For now I have made the names reasonable and changed all of the BP filters to 4th order Butterworth.

Also, it turns out that the Vel2Vel (gain ~0.02) filters were mistakenly on in the STS BP filter banks. The GUR inputs have a gain to scale the counts to velocity, but the STS seem to already be in microns/sec (where is this gain?) so I turned off and deleted the Vel2Vel filters; in any case the gain should not be done seperately in each BP bank, but altogether before the BP filtering.

Attachment 1: BLRMS_BP.pdf
Attachment 2: BLRMS_imp.pdf
  11582   Mon Sep 7 19:46:46 2015 ranaUpdatePEMSeismic BLRMS filters

As it turned out, the "STS" BLRMS filters were all a mess, so I fixed them up today:

  • BP and LP filters were non-existent for the 2 low frequency bands: 0.01-0.03 & 0.03-0.1 Hz. The 0.01-0.03 is just seeing tilt noise (its big in X & Y, but not in Z), but the other band is able to cleanly see the primary microseism at 0.06 Hz.
  • There was some mixup and some BP filter banks had low pass filters while one of the LP banks had a BP filter.
  • There were different filters between the X, Y & Z directions.
  • The low pass filters had enough ringing in the impulse response that their outputs could sometimes go negative and make the SQRT block output NaN.

After tuning:

  • All bandpass filters are 4th order Butterworth bandpass with the corners at the band edges (e.g. 1- 3  Hz)
  • All low pass are the same, just scaled by the frequency band. They have a pair of real poles and a pair of 35 deg poles. The pole frequencies are set so that there is 40 dB of attenuation at twice the frequency of the low end of the bandpass. i.e. for the 1-3 Hz band, the low pass has > 40 dB atten at 2 Hz.
  • The 3-10 and 10-30 Hz bands use the same low pass as the 1-3 Hz band, since I don't want to see aliasing in the EPICS readouts. I don't think we need faster than 1 Hz readback of the RMS.
  • Confirmed with FOTON that the impulse response for the LP filters are positive for all t >0.

The "C1:PEM-SEIS_STS_1" filter banks are currently empty, so the signal is just in ADC counts. However, by amazing luck, this seems to be the right gain (within a factor of 2) to put the signal into units of microns / second. According the the schematic (D1000749), the default gain of 110 can be switched to make the whole box just have a gain of 2 (differential in, differential out). I wonder if anyone, like Jenne, knows if this is what we have? There's no elog I found about setting the gain switch.

According to the manual, the gain is ~1175 V/(m/s). Our ADC gain should be (2^16)/(40). So:

cal_gain = 1175 * 2 * 65536 / 40  ==>> 0.26 (m/s)/counts

I have put this into the STS_1_X,Y,Z filter modules in c1pem so that these channels are now calibrated. I also put the first few s-domain poles/zeros into the filter based on the manual so that the magnitude in the 10-30 Hz band is correct-ish now.

* Does anyone know how to center the masses on this thing?

Attachment 1: T240_150907.png
  278   Sun Jan 27 21:44:48 2008 ranaUpdateCDSSeismic BLRMS on Matlab
I wrote a matlab script to produce band limited RMS trends from our accelerometers. It mimics the code written
by Ed Daw which makes the seismic FOMs at the sites.

Here's how it works:
  • Use mDV to get data by reading directly from frames.
  • Use the Matlab pwelch function to produce a power spectrum of the channels.
  • Use the Matlab find function and rms.m to get the RMS in user-defined frequency bands.
  • Makes a tdswrite command string which writes all the values to EPICS channels.
  • The EPICS channels are just a list of simple names in a database file.
  • The channel names are (will be) added to the C0EDCU.ini file so that its all trended.

The code is in the mDV/extra/C1 directory; its ~20 lines of code (excluding comments and spaces).

Next up is to add more DMF trend channels to the database and upgrade the code to use a .conf file
instead of hardcoded channel names. We should also evaluate if the bands I used are appropriate for the 40m;
I just used Ed's choices (0.1-0.3, 0.3-1, 1-3, 3-10, and 10-30 Hz).

In the medium term, we should make this compiled (like what RW did with the linetracker), and explore if we
want it to write values faster than 1/minute.
Attachment 1: seisBLRMS.m
% Seismic BLRMS Monitor
% RA 08-01-26

% 0 for no messages, 1 for debugging
debug_flag = 1;

% ------------ Build channel list
... 82 more lines ...
  11330   Thu May 28 15:10:44 2015 ranaUpdatePEMSeismic Confusion

You are plotting the STS channels, not Guralp. These are for the Trillium 240 seismometer.

Also, you cannot tell if the seismometer is working by plotting the MEAN trend. That just gives the average and we need the fluctuations. Better off looking at the spectrum like I did last time.

And....its not good enough to just do the bubble. You have to do the mass centering procedure that you and I did last time with the breakout paddle.

  12778   Tue Jan 31 18:51:07 2017 gautamUpdateSEISeismic Rainbow Strip - myths debunked

I've been suggesting that there may be something wonky with the Seismic Rainbow Striptool on the wall for the last couple of weeks. Here are a few things that were verified today.

  1. If you want to restore the StripTools in the control room, just run /opt/rtcds/caltech/c1/scripts/general/startStrip.sh. I have verified as of today that this works, and in future, any changes to channels/limits/colors of traces etc should be reflected in this script.
  2. Though some of the BLRMS bands have looked anomalous over the last few weeks, in particular the 0.3-1Hz band. The attached 120 day trend plot suggests that there hasn't been any dramatic change recently. In fact, looking on the summary pages, Rana noticed that today was an unusually low 0.3-1Hz activity day..
Attachment 1: Seis_BLRMS.png
  7841   Mon Dec 17 19:47:15 2012 ranaUpdatePEMSeismic StripTool config updated

I have updated the Seismic Striptool display which is plotted on the wall in the control room. Please take a look and make comments. We should finalize it and not change it anymore.

By having an unchanging display, we can get used to small changes in the seismic environment which disrupt our locking.

  1. y-scale is now linear; the log-scale was suppressing the factor of 2-3 variations which are important to us.
  2. Just as the rainbow does, the colors now go from red to purple to represent the noise from 0.1 - 30 Hz: the red traces are 0.1-0.3 Hz, the green/yellow traces are 0.3-3 Hz, and the blue/purple traces are 3-30 Hz.
  3. This is just showing GUR1. Let's try to keep this seismometer working so that we can have some long term record of the seismicity here. This means don't click off the buttons, disconnect the sensor, reboot the machine, etc. When you do do these things, elog them.
Attachment 1: SeismicRainbow.png
  16783   Mon Apr 18 14:52:47 2022 Ian MacMillanSummarySEISeismic Study of Buildings and Caltech Campus

[Ian, JC]

I want to take measurements of seismic noise at different places on Caltech's campus and in different buildings. I will try to use the accelerometer in my phone for this but first I must calibrate it (Against the 40m accelerometers). 

I placed my iPhone 11 pro next to the seismometers at the 40m MC as seen in Attachment 1.

The calibration from the instrument was done using cts/rthz * 1V/16384cts * 1/ampgain * g/10V * 10m/s^2/g. The ampgain for all was 100.

Next, I took 100 seconds of data on both the iPhone and the three orthogonal Wilcoxon accelerometers.

The ASD for both of the total acceleration is shown in Attachment 2

The ASD for the individual directions acceleration is shown in Attachment 3

The coherence between the individual directions acceleration and the 40m's individual directions is shown in Attachment 4. For this calculation, the 40m data were downsampled to roughly match the phone's sample rate. This coherence is not very good. It should be higher. Because the phone and 40m sensors were picking up the same data as the phone. Because of this I also looked at the coherence between the individual 40m sensors.

In Attachment 5 I look at the coherence between the individual 40m sensors. This should give me a good idea of whether this is some other issue giving me mow coherence. This plot shows that the coherence between the individual 40m sensors is much better than between the phone and the 40m sensors.

Now I wanted to see what kind of data the iPhone could get from real-world tests. I placed it in a number of locations described below and plotted their ASDs in Attachment 6. The locations are thus:

Identifier  Location Notes
QIL QIL Lab in the Sub-basement of west bridge In sub-basement not much activity when taking measurements.
WBSH West bridge sub-basement hallway on floor in hallway no activity around
WB1H West Bridge 1st floor Hall placed on the floor near pillar near stairs to LIGO offices on the ground floor of west bridge
40m desk on my desk at the 40m placed on the desk while people were walking around and I had my feet on the desk. should be noisy

Notice how at the low end the amplitudes follow the relative amplitudes I would expect. QIL and WBSH are the lowest then WB1H is noisier and 40m desk is the noisiest. However, this is only true up until about 0.5 Hz then they all overlap. Since I would expect the 40m desk should be much noisier at all frequencies I suspect that the phone accelerometer is not suitable for measurements higher than 0.5 Hz.

Possible Problems:

One possible problem with my measurement is that my phone was in a leather case. this may have damped out higher frequencies. Also, my phone was not weighed down or bolted to the floor. this stronger connection would make it better at detecting higher frequencies. I could repeat the experiment with no case and a weight on top of my phone.

What's next:

Since I don't think the phone can give me accurate data above 0.5Hz for quiet environments. It may not be suitable for this task. It would seem that the right instrument is the Wilcoxon 731A but it requires an amplifier that I can't track down.


I included all the data and code in the zip file in attachment 7


Attachment 1: IMG_0513.jpg
Attachment 2: tot_acc_cal.pdf
Attachment 3: indiv_acc_cal.pdf
Attachment 4: dec_Coherence.pdf
Attachment 5: 40m_self_Coherence.pdf
Attachment 6: tot_acc_testsites.pdf
Attachment 7: Calibration.zip
  16798   Thu Apr 21 17:32:35 2022 Ian MacMillanSummarySEISeismic Study of Buildings and Caltech Campus

[Rana, Ian]

We built a power supply for the accelerometer shown in Attachment 1 based on the diagram shown in the Wilcoxon manual and shown in attachment 2. We used a 9V power supply and a capacitor value of 680uF. We did not use a constant current diode. 

When hooked up to an oscilloscope we saw vibrations from hitting our hands on the table but we did not see the same amplitude in the negative and positive directions. For example, when I held the accelerometer and moved it down you would see a dip then a peak as the accelerometer accelerated down then accelerated up when I stopped the down word movement. But weirdly when I did the opposite (moved the accelerometer up the same dip then a peak appeared. This is a little concerning because it should be the opposite. it should be a peak then a dip. This in addition to the seemingly decreased sensitivity in one direction make me think that the accelerometer is broken.

I labeled the box with "might be broken" before I returned it to the cryo lab.

Attachment 1: IMG_1820.jpg
Attachment 2: Screen_Shot_2022-04-21_at_5.52.51_PM.png
  12906   Fri Mar 24 19:04:18 2017 gautamUpdateIMCSeismic feedforward and WFS

[valera, gautam]

On Wednesday at the meeting, we were discussing why we aren't able to achieve more seismic feedforward subtraction in MCL. We spent some time thinking about this yesterday, and this elog is meant to be a summary of the stuff we tried. 

  1. We let the WFS loops run for a while and settle, and then turned the input gain down to zero so that the integrators held the outputs to the suspension at a "good" alignment. If the WFS loop bandwidth is ~0.1 Hz, then they aren't helping us at 1Hz anyways. We then looked at coherence between the seismometer signals in this state compared to when the WFS loops were running, and noticed negligible difference. It doesn't seem like the WFS loops are injecting noise into MCL at ~1Hz.
  2. We decided agains implementing the WFS sensing matrix I measured on Wednesday evening, as we found that the relative magnitudes of the matrix elements are virtually the same as in Koji's measurement back in December 2016. But looking at matrix elements like MC1P->WFS1P compared to MC3P->WFS1P - there is a difference of a factor of ~3. Why should there be? The response should be completely symmetric to MC1 and MC3?
  3. While looking at the OSEM channels (i.e. SUSPIT_IN1_DQ, SUSYAW_IN1_DQ etc) for each of the MC optics, we noticed a dramatic difference between MC1 (factor of ~10 higher) and the other two MC optics.
  4. Looking at coherence between MCL and the seismometer channels, we felt that there is less coherence at low frequencies (1Hz and lower) now than there was back in January when I took a measurement. However, there was coherence between the OSEM signals and the seismometers - so it doesn't look like the seismometer is to blame. To make an apples-to-apples comparison, I compared the MCL and Seismometer channel spectra from January to now (for the latter, at two different settings of the damping loop gains on the MC suspensions), and also the maximum predicted achievable subtraction (using EricQs frequency domain multicoherence tool). The two changes I can think of since January are that the MC1 satellite box has been interchanged with the SRM satellite box, and the IMC servo gains have been reallocated since the RF upgrade. My findings are summarized in attachments #1 and #2.

The seismometer spectra look similar enough to be explained by time of day variations, so perhaps the culprit is MC1. The ambient MCL spectrum is almost an order of magnitude higher above 4Hz now, with the nominal damping loop gains, as compared to back in January. I think the damping loops on MC1 need to be tweaked.


Attachment 1: MCL_comparison.pdf
Attachment 2: seis_comparison.pdf
  15282   Tue Mar 24 19:41:57 2020 gautamUpdateWienerSeismic feedforward for MCL


I think the feedforward filters used for stabilizing MCL with vertex seismometers would benefit from a retraining (last trained in Sep 2015). 


I wanted to re-familiarize myself with the seismic feedforward methodology. Getting good stabilization of the PRC angular motion as we have been able to in the past will be a big help for lock acquisition. But remotely, it is easier to work with the IMC length feedforward (IMC is locked more often than the PRC). So I collected 2 hours of data from early Sunday morning and went through the set of steps (partially).

Attachment #1 shows the performance of a first attempt.

  • 1 hour of data was used as a training set, and another hour to validate the trained filter.
  • All the data was downsampled to 64 Hz.
  • The number of FIR filter taps was 32 seconds * 64 Hz. 
  • Going through some old elogs, there were a number of suggestions from various people about how the training should be done
    • There was a suggestion that pre-filtering the target signal by the (inverse) actuator TF (i.e. TF from MC2 drive to MCL) is beneficial, presumably because it gives the Wiener filter fitting fewer parameters to fit.
    • There was also suggestions that some frequency-dependent weighting of the target signal should be done (e.g. by bandpassing MCL between 0.1 Hz - 10 Hz) to emphasize subtraction in this band.
    • For this particular example, in my limited paramter space exploration, I found that neither of these measures had particularly significant impact.
  • In any case, the time-domain FIR filtering seems to approach the theoretical best possible performance (based on coherence information). 
  • I have not yet checked what the theoretical limit on subtraction will be based on the seismometer noise ASD.

Attachment #2 shows a comparison between the filter used in Attachment #1 and the filters currently loaded into the OAF system. 

  • In the band where significant subtraction is possible, there is some difference in the shape of the filter.
  • Why should this have changed? I guess there are multiple possibilities - seismometer recentering, signal chain changes, ...

Attachment #3 is the asd after implementing a time domain Wiener filter, while Attachment #4 is an actual measurement from earlier today - it's not quite as good as Attachment #3 would have me expect but that might also be due to the time of the day. 

Conclusions and next steps:

On the basis of Attachments #3 and #4, I'd say it's worth it to complete the remaining steps for online implementation: FIR to IIR fitting and conversion to sos coefficients that Foton likes (prefereably all in python). Once I've verified that this works, I'll see if I can get some data for the motion on the POP QPD with the PRMI locked on carrier. That'll be the target signal for the PRC angular FF training. Probably can't hurt to have this implemented for the arms as well.

While this set of steps follows the traditional approach, it'd be interesting if someone wants to try Gabriele's code which I think directly gives a z-domain representation and has been very successful at the sites.

* The y-axes on the spectra are labelled in um/rtHz but I don't actually know if the calibration has been updated anytime recently. As I type this, I'm also reminded that I have to check what the whitening situation is on the Pentek board that digitizes MCL.

Attachment 1: IMCseisFF.pdf
Attachment 2: filterComp.pdf
Attachment 3: oldFilter_v_proposed.pdf
Attachment 4: MCL_ff_performance.pdf
  5856   Wed Nov 9 20:35:58 2011 MirkoUpdateAdaptive FilteringSeismic noise injection into the MC

Very elaborated measurement ;-)

On 11-11-08:
18:40 Stomp near STS1 for 2mins
18:47 Jump near GUR1 for 2mins
18:52 Walk from MC2 approx. half-way to vertex for 2mins

Tried to see if jumping / stomping the ground near STS1 / vertex or GUR1 / MC2 would show up in the seismometer or MC length data.
In GUR1 jumping / stomping clearly shows up in the timeseries. Also it clearly shows up as a low frequency signal if you walk to a position near MC2. E.g. walk from the vertex to MC2. Stop near the cones. Gives a big dip on GUR1X, that recovers in 10-20sec if you remain stationary. Big "hill" if you come from x-arm end and stop on the x side of MC2. So probably lots of tilt to GUR1X coupling at low frequencies.

Nothing was really visible in spectra (see below).


There appear to be a lot of resonances in the 10-20Hz range, see e.g. 1st attached pic.


Looking at the coherence of difference axis of the seismometers. Kind of dirty measurement, could have all kinds of reasons.
Quite a bit of coherence in STS1 at 5-6Hz. Possibly limiting the STS1X to MC-F coherence to up to 4Hz?



Attachment 1: Inj_spectra_at_GUR1_all_DOFs.fig
Attachment 2: Inj_spectra_at_GUR1_all_DOFs.png
Attachment 3: Inj_spectra_at_STS1_all_DOFs.fig
Attachment 4: Inj_spectra_at_STS1_all_DOFs.png
Attachment 7: Coherence_GUR.fig
Attachment 8: Coherence_STS1.fig
  13146   Thu Jul 27 22:42:24 2017 gautamUpdateSUSSeismic noise, DAC noise, and Coil Driver electronics noise


Yesterday at the meeting, we talked about how the analog de-whitening filters in the coil driver path may be more aggressive than necessary. I think Attachment #1 shows that this is indeed the case.


I had done some modeling and measurement of some of these noises while I was putting together the initial DRMI noise budget, but I had never put things together in one plot. In Attachment #1, I've plotted the following:

  1. Quadrature sum of seismic noise (from GWINC calculations) for 3 suspended optics (I'm sticking to the case of 3 optics since I've been doing all the noise-budgeting for MICH - for DARM, it will be 4 suspended optics).
  2. The unfiltered DAC noise estimate. The voltage noise was measured in this elog. To convert this to displacement noise for 3 suspended optics, I've used the value of 1.55e-9/f^2 m/ct as the actuator coefficient. This number should be accurate under the assumption that the series resistance on the coil driver board output is 400 ohms (we could increase this - by how much depends on how much actuation range is needed).  
  3. Coil driver board and de-whitening board electronics noises (added in quadrature). I've used the LISO model noises, which line up well with the measured noises in elogs 13010 and 13015.
  4. The DAC noise filtered by the de-whitening transfer function, separately for the cases of using one or both of the available biquad stages. This cannot be lower than the preceeding trace (electronics noise of de-whitening and coil driver boards), so should be disregarded where it dips below it. 

It would seem that the coil driver + de-whitening board electronic noises dominate above ~150Hz. The electronics noise is ~10nV/rtHz at the output of the coil driver board, which is only a factor of 100 below the DAC noise - so the stopband attenuation of ~70dB on the de-whitening boards seems excessive.

We can lower this noise by a factor of 2.5 if we up the series resistance on the coil driver boards from 400ohm to 1kohm, but even so, the displacement noise is ~1e-18 m/rtHz. I need to investigate the electronics noises a little more carefully - I only measured it for the case when both biquad stages were engaged, I will need to do the model for all permutations - to be updated. 

Attachment #2 has an iPython notebook used to generate this plot along with all the data.

Edit 28 Jul 2.30pm: I've added Attachment #3 with traces for different assumed values of the series resistance on the coil driver board - although I have not re-computed the Johnson noise contribution for the various resistances. If we can afford to reduce the actuation range by a factor of 25, then it looks like we get to within a factor of ~5 of the seismic noise at ~150Hz. 

Attachment 1: noiseComparison.pdf
Attachment 2: deWhiteConfigs.zip
Attachment 3: noiseComparison_resistances.pdf
  5986   Wed Nov 23 02:34:28 2011 MirkoUpdatePEMSeismic spectrum & Striptool

The Striptool for the BLRMS seismic channels is running now. Channels are ( still ) recorded as slow EPICS channels.

A big peak in the 0.1 - 0.3Hz seismic region in both GUR1 and STS1 irritated us for a while. I added an extra LP filter @ 0.05Hz to the RMS_LP modules.



  2638   Wed Feb 24 16:11:15 2010 JenneUpdatePEMSeismic witnesses near MC1 tank moved

Since we're going to open the MC1 tank tomorrow, I've moved the MC1 accelerometers and the Guralp over to underneath MC2 for the vent.  I'll reconnect them later.

  2661   Sun Mar 7 23:05:39 2010 ranaUpdatePEMSeismic witnesses near MC1 tank moved


Since we're going to open the MC1 tank tomorrow, I've moved the MC1 accelerometers and the Guralp over to underneath MC2 for the vent.  I'll reconnect them later.

 I've put both Guralps next to the Ranger and connected them to the breakout box. The data is now good.

I found that the Ranger was not centered and so it was stuck (someone kicked it in the last 2 weeks apparently). I recentered the mass according to the procedure in the manual. Its now moving freely.

In order to do a better huddle test, I increased the gain of the Ranger's SR560 preamp to 100 from 10 and put it on the low noise setting. I also enabled a 2x lowpass at 3 kHz for no good reason.

I couldn't find what the actual value of the gain of the Guralp breakout box is, but I assume its 10. With this assumption the calibrations are this:

Guralp: 800 V/(m/s)  *  10  (V/V)   *  16384  cts/V   =>    7.63e-9  (m/s)/count           (0.03 - 40 Hz)

Ranger:  345 V/(m/s)  * 100 (V/V)  *  16384 cts/V   =>     1.77e-9  (m/s)/count          (above 1Hz)

To account for the fact that I am not damping the Ranger with an external damping resistor, I have changed the calibration poles and zeros: in DTT we now use 2 poles @ 0 Hz and a complex pair at 1 Hz:

G = 1.77e-9

Poles = 0, 0

Zeros = 0.15 0.9887

I think that the Guralp gain is too high by a factor of 2. To really do this right, we should attach a known voltage to the input pins of the Guralp breakout and then read off the amount of counts.

Attachment 1: seis.png
  11268   Sun May 3 01:04:19 2015 ranaSummaryPEMSeismo signals are bad


Looks like some of our seismometers are oscillating, not mounted well, or something like that. No reason for them to be so different.

Which Guralp is where? And where are our accelerometers mounted?

  13777   Fri Apr 20 23:36:28 2018 KevinUpdatePEMSeismometer BLRMs

Steve secured the GPS time server in the rack above the AA board and removed the wooden block that it was resting on. The new rack is shown in attachment 1.

I then opened the AA board to see why the channels aren't working. Even though the board was powered and outputting 4.6 V, none of the chips were getting power. I must have shorted something while trying to diagnose this and the board is no longer powered either.

The schematic is given in D990147. The D68L8EX filter is bypassed on all the channels, as can be seen in attachment 3, so the board isn't really doing anything. Rana suggested that we could just bypass the whole circuit by wiring the IN channels directly to the OUT channels going to the ADC. I'll try that next for a single channel.

Attachment 1: front.jpg
Attachment 2: back.jpg
Attachment 3: detail.jpg
  13787   Tue Apr 24 21:19:08 2018 KevinUpdatePEMSeismometer BLRMs

In the ongoing attempt to recover the seismometer BLRMS, I removed the AA board from the rack and modified the BS seismometer Z channel. The BS_Z BLRMs seem to be recovered after this modification.

I removed the three resistors from the output of the circuit and wired the input and from the seismometer directly to the input to the ADC. The modified schematic is shown in attachment 1. Attachments 2 and 3 show the top and bottom of the modified board. The board is doing nothing now other than serving as a connector for this channel.

I put the board back in the rack and injected a 2 Vpp signal into the BS_Z channel and saw +/- 1600 cts in C1PEM-SEIS_BS_Z. I then plugged the seismometer back into the board and took the spectrum shown in attachment 4. This shows the working Z channel giving a reasonable seismic spectrum. Note that X and Y are not modified yet.

If there are no objections, I will modify all the other channels on the board in the same way tomorrow.

Attachment 1: modified_schematic.pdf
Attachment 2: top.jpg
Attachment 3: bottom.jpg
Attachment 4: BS_Seis_PSD.pdf
  4774   Tue May 31 16:07:57 2011 Larisa ThorneConfigurationElectronicsSeismometer Box Update

 (Continuation of this)


I plugged the circuit into the LISO program to generate the graphs below....the first graph is a plot of frequency (f, in Hz) versus gain (in dB), and frequency (f, Hz) versus phase (in degrees). Also included is the second graph, which is a noise plot of all circuit parts which contribute to the total noise of the circuit.


The only issue I had was that two of the op amps I'd picked (see third attachment for the original circuit diagram) for the circuit were not in LISO's op amp library. So I replaced THS4131 (from the voltage buffer part) and AD826 (from the ADC driver part) with AD797 and LT1037, respectively in order to generate the plots below....   


There are notes calling the AD797 "ultra low noise, low distortion", whose data sheet can be found here: AD797 

Notes also call LT1037 "low noise, high speed precision op amp", whose data sheet can be found here: LT1037


I've put these in temporarily only, as I don't know if they are appropriate choices for the job or even if we have them. Suggestions?

Attachment 1: SeisBoxLISOplot1.pdf
Attachment 2: SeisBoxLISOplot2.pdf
Attachment 3: STS2diagram_original.pdf
  4785   Sat Jun 4 15:26:04 2011 Larisa ThorneUpdateElectronicsSeismometer Box Update

 (continuation of this)


Here are the transfer function and noise plots of the seismometer box, using the op amps that are actually indicated on the original plan (THS4131, AD826). I added them to the LISO op amp library (can be found in /cvs/cds/caltech/apps/linux64/liso/filter/opamp.lib)

Next step is to compare the noise graph below to the seismic noise curve of the interferometer to verify that the seismometer box configuration won't affect the curve...

Attachment 1: SeisBoxLISO_transfer.pdf
Attachment 2: SeisBoxLISO_noise.pdf
  4807   Fri Jun 10 20:23:56 2011 Larisa ThorneUpdateElectronicsSeismometer Box Update/graphs

 (continuation of this)


The noise graphs relating total noise of the Seismometer circuit (GURALP stuff) to the LIGO seismic noise curve have been completed started.



I apparently harbor hate towards Matlab (you may have notice I do everything in Mathematica)....I will try to change my ways  DX

Attachment 1: SeisNoiseGraphs.jpg
  4810   Mon Jun 13 16:27:10 2011 JenneUpdateElectronicsSeismometer Box Update/graphs

Quote from elog 4807:

The noise graphs relating total noise of the Seismometer circuit (GURALP stuff) to the LIGO seismic noise curve have been completed started.

 What Larisa meant to post (I'm sure) is something more like this (sorry it's a little squished...I put too many words in the legend):

I've only included the 2 noise contributions from the LISO model that seem to dominate the sum noise.  The plot gets a little crazy if you include all of the non-important sources.


So, what's the point??

First, the new box design doesn't have any crazy-special op-amps in it, so the noise of the new box is probably comparable to the old box.  So, if that's true, the old box may not have been limiting the differential seismic noise.  This definitely needs to be checked out.  I'll make a quickie LISO model of the old Guralp breakout box, to see what its noise actually looks like, according to LISO.  If it wasn't ever the breakout box that was limiting us, what the heck was it??

Second, the current box design seems to be better than the Guralp Spec sheet noise by ~a factor of 10.  It would be nice if that number were more like a factor of 100.  Or at least 30.  So some work needs to be done to find a lower-noise op amp for the voltage buffer (the first op amp in the circuit).

Next steps:

Since Larisa is now starting her SURF project with Tara and Mingyuan, I'll look into improving the design of this box by a factor of 3 or 10. 

Then I'll need to make a mock-up of it, and test it out. 

If successful, then I'll draw it up in Altium and have it made.  Recall that there should be 2 outputs per seismometer channel, one with high gain, one with low gain.  Then 3 seismometer channels per seismometer (X, Y, Z), and perhaps multiple seismometer inputs per box.  So lots and lots of stuff all in the same box.  It's going to be pretty cool.

  4061   Wed Dec 15 18:29:59 2010 JenneUpdatePEMSeismometer Channels Being Recorded Again

The Seismometer channels are once more being recorded.  Alastair brought Gur1 back from the ATF the other day, and today I put it in its place below MC2 (yeah, the numbers are backwards.  But they always have been.) 

I checked the matching between BNC inputs on the breakout box to the ADC channels as labeled in the SimuLink diagram.  To do this I had all 32 channels activated, and I put a 1Hz, 1Vpp sine wave into various BNC inputs to see what channel they showed up as.  At first things were a bit backwards (BNC channels 1-16 going to ADCs 16-31, and BNCs 17-32 going to ADCs 0-15), but then Joe quickly flipped the cables on the adapter board in the back and things are in the correct order now.  Channel 1 on the BNC board corresponds to channel 0 on the ADC, etc. 

I checked that jumping near each seismometer made the signals spike, which they did. 

I then changed the channel names in the c1pem.mdl SimuLink diagram to match the old channel names for the Guralps and the accelerometers, and deleted all of the other channels that aren't being used.  There's a table in the diagram to indicate what goes with what, as of today.  If you do anything to the PEM diagram, please update the table so it's easy to look things up.

I recompiled the code, but have not yet restarted the frame builder since Zach and Kiwamu are working on some things in the chamber, and I don't want to be annoying (so the channels aren't actually being recorded quite yet). 

Edit, 7:15pm:  Just kidding.  Something didn't work, and I have to track down what.  I'm not getting any data yet.

  826   Mon Aug 11 19:09:28 2008 JenneDAQPEMSeismometer DAQ is being funny
While looking at the Ranger seismometer's output to figure out what our max typical ground motion is, Rana and I saw that the DAQ output is at a weird level. It looks like even though the input to the DAQ channel is being saturated, the channel isn't outputing as many counts as expected to Dataviewer.

Sharon and I checked that the output of the seismometer looks reasonable - sinusoidal when I tap on the seismometer, and the the output of the SR560 (preamp) is also fine, and not clipping. If I stomp on the floor, the output of the SR560 goes above 2V (to about 3V ish), so we should be saturating the DAQ, and getting the max number of counts out. However, as you can see in the first figure, taken when I was tapping the seismometer, the number of counts at saturation is well beneath 32768counts. (16 bit machine, so the +-2V of the DAQ should have a total range of 65536. +2V should correspond to +32768counts.) The second figure shows 40 days of seismometer data. It looks like we saturate the DAQ regularly.

I did a check of the DAQ using an HP6236B power supply. I sent in 1V, 2V and 2.2V (measuring the output of the power supply with a 'scope), and measured the number of counts output on the DAQ.

Input Voltage [V]Counts on DataviewerExpected counts from 16 bit machine

I'm not sure why the +1V output more than the expected number of counts (unless I mis-measured the output from the power supply).

Moral of the story is...when the DAQ is saturated, it is not outputting the expected number of counts. To be explored further tomorrow...
Attachment 1: SeisDAQ.png
Attachment 2: SeisData.png
  12160   Thu Jun 9 09:57:06 2016 AakashUpdateGeneralSeismometer Enclosure Development
Me and Gautam yesterday opened the tilt-free seismometer enclosure to see if we could use the thermocouples and
other things previously used by Megan. But we are planning to get new four-wire RTDs for our work.
For the next day or two, I will be trying to set up Acromag Busworks terminal so that the data logging during
this enclosure development experiment becomes perfect and easy. Johannes has sent me the wiki page URL for the same.
  12224   Tue Jun 28 22:54:43 2016 AakashUpdateGeneralSeismometer Enclosure Development | SURF 2016

The existing enclosure for seismometer at LIGO 40m lab is a cylindrical stainless steel can placed upside down over the seismometer. It has more empty space between the seismometer and the internal surface of enclosure which is not desirable(I'll quantitatively elaborate this statement once my temperature measuring setup is ready).


Stainless steel has a thermal conductivity in the range of 16.3 to 16.7 W/m/K and magnetic permeability 1.260e-6 H/m.Assuming an ambient temperature 298K, and the temperature inside the enclosure as 295K, as well as substituting all the values for dimesions and material properties of existing enclosure,
k=16.4 W/mK, μ=1.260e-6 H/m, L=2ft=0.6096m, b=r2 =0.5ft=0.1524m, thickness=5mm, a=r1 =0.1474m.
So by using the textbook relations(I have mentioned them in my report), the value of attenuation coefficient is 5.953584e-05 and the value of rate of heat transfer= 5.64913 kW. The attenuation coefficient value is quite better for steel but proper care needs to be taken to avoid heat transfer. For studying the variation of rate of heat transfer and attenuation with the thickness of enclosure material, I have plotted the following attached graphs for different materials which include hardened stainless steel, aluminium, pure iron and nanoperm-muMetal.



About Data Acquisation

I have already invested a lot of time to configure and use acromag busworks card over ethernet. So now I have made an arrangement to measure temperature by AD592CNZ temperature transducer IC. I would be using raspberry pi for acquiring data untill I figure out a way to use acromag busworks card for the same. This setup of acquiring logging temperature using raspberry pi is mostly ready except the calibration part.

  12236   Fri Jul 1 01:52:54 2016 AakashUpdateGeneralSeismometer Enclosure Development | SURF 2016

I have transferred most of the temperature measurement stuff from the front area to seismometer at the end of Y-arm.  While arranging the components I have taken all care that they will not interfere with existing system. Also, I have temporarily taken a monitor from the front area to the area near same seismometer as I couldn't talk to Rpi via ssh. For next twelve hours, I am now recording temperature inside as well as outside the seismometer enclosure. Some temperature sensors are inside the enclosure while some are outside the seismometer enclosure.


  12253   Wed Jul 6 16:40:09 2016 AakashUpdateGeneralSeismometer Enclosure Development | SURF 2016

I am using AD592CNZ temperature transducer ICs for measuring temperature inside as well as outside the enclosure. It is a  current output IC which outputs current proportional to temperature. As mentioned in the data sheet of AD592, I am using the following two schematics:


Though I still need to calibrate these temperature transducers, I did some measurements. I have temperature readings, and now my goal in few days is to find a transfer function of temperature fluctuations inside the enclosure to outside the enclosure.


About data acquisition:

We have re-configured the raspberry pi(B8:27:EB:70:D0:D8) on martian network. It's new ip address is Also, we have added the Acromag Busworks card(00:01:C3:00:9F:C8) on the martian network and its ip address is   

  12256   Wed Jul 6 20:51:00 2016 KojiUpdateGeneralSeismometer Enclosure Development | SURF 2016

Circuit1: It is nice to receive the voltage across the transimpedance resistor with a high impedance buffer (or amplifier), as close to the resister as possible. This amplifier needs to have low numbers for input bias current, input offset current, and input current noise. These current noise becomes the noise of the temperature reading. On the top of that, the input voltage noise of the buffer will be added to the output. The typical noise model can be found in http://www.analog.com/media/en/technical-documentation/application-notes/AN-940.pdf

The good candidates for the buffer is LT1128, ADA4004, OPA140, and LT1012. If the application is not too sensitive to the total noise, OPA604 is a good choise with easier handling.

Circuit2: With the same reason, AD741 is an old generic amp that is not a great choise for this purpose. The current noise is more significant because of the higher transimpedance here. The same noise model as above can be used to analyze the performance.

  2237   Wed Nov 11 12:50:10 2009 JenneUpdatePEMSeismometer Noise Characteristics

The attached plot shows the spectra of the 3 Z axes of the 3 seismometers we have (this data is from ~20Aug2009, when the Ranger was in the Z orientation) in Magenta, Cyan and Green, and the noise of each of the sensors in Red, Blue and Black.  The noise curves were extracted from the spectra using the Huddle Test / 3 Corner Hat method.  The Blue and Black traces which are just a few points are estimates of the noise from other spectra.  The Blue points come from the Guralp Spec Sheet, and the Black comes from the noise test that Rana and I did the other day with the Ranger (elog 2223).  

I'm not really happy with the black spectra - it looks way too high.  I'm still investigating to see if this is a problem with my calibration/method....

Attachment 1: HuddleTest_Aug2009data.png
  2833   Thu Apr 22 20:28:40 2010 JenneUpdatePEMSeismometer Noise Characteristics

Quote from elog 2237, 11 Nov 2009:

The attached plot shows the spectra of the 3 Z axes of the 3 seismometers we have (this data is from ~20Aug2009, when the Ranger was in the Z orientation) in Magenta, Cyan and Green, and the noise of each of the sensors in Red, Blue and Black.  The noise curves were extracted from the spectra using the Huddle Test / 3 Corner Hat method.  The Blue and Black traces which are just a few points are estimates of the noise from other spectra.  The Blue points come from the Guralp Spec Sheet, and the Black comes from the noise test that Rana and I did the other day with the Ranger (elog 2223).  

I'm not really happy with the black spectra - it looks way too high.  I'm still investigating to see if this is a problem with my calibration/method....

 So, as it turns out (surprise), I'm a spaz and forgot a 2*pi when calibrating the Guralp noise spectra from the spec sheet.  I noticed this when redoing the Huddle Test, and comparing my Spec Sheet Guralp noise with Rana's, which he shows in elog 2689.  When going from m/s^2, the units in the spec sheet, I just tilted the line by a factor of frequency.  Koji pointed out that I needed a factor of 2*pi*f.  That moves the Guralp spec line in the plot in elog 2237 (to which this entry is a reply) down by ~6, so that my measured noise is not, in fact, below the spec.  This makes things much more right with the world.

In other news, I redid the Huddle analysis of the 2 Guralp seismometers, ala Rana's elog 2689. The difference is now we are on the granite slab, with soft rubber feet between the floor and the granite.  We have not yet cut holes in the linoleum (which we'll do so that we're sitting directly on the 40m's slab).

Rana> this seems horrible. Its like there's a monster in there at 6-7 Hz! Either the seismos are not centered or the rubber balls are bad or Steve is dancing on the granite slab again.


Attachment 1: Gur1_Gur2_noise.png
  13850   Wed May 16 21:47:17 2018 KevinUpdatePEMSeismometer Noise Spectra

Earlier today Kira and I reconnected the EX seismometer. I just took some spectra of all three seismometers, shown in the attachments, to compare with past data and to do a rough check of the calibration.

This elog has a spectra from 2010 (GUR1 is now EY) and this elog has one for BS at lower frequencies from 2017. Note that the EX seismometers now have strong peaks that are not at 60 Hz harmonics. Other than these peaks, these old spectra roughly match up with the ones taken today, so the callibration is still roughly the same. I couldn't find any old data for EX (GUR2) though so I don't know for sure that these peaks weren't there before.

gautam 20180517 0930: In 2017, Gur2 (now EX) looked like this. Still peaky, but the peaks seem shifted in frequency. Steve also informed me that the Gur1 and Gur2 cables were swapped n times, so perhaps we shouldn't read too much into that.

Attachment 1: BS_vel.pdf
Attachment 2: EX_vel.pdf
Attachment 3: EY_vel.pdf
  3354   Tue Aug 3 11:50:16 2010 JenneUpdatePEMSeismometer Problem Tracked down

After some cable swapping this morning, I have determined which cable is bad.  It's the Gur1 cable between the seismometer and the breakout box.  This is a milspec -> 37pin d-sub cable.  I'll pull out the cable and have a look at it after lunch.

  5200   Thu Aug 11 19:14:22 2011 Ishwita , ManuelUpdatePEMSeismometer STS2(Bacardi, Serial NR 100151) moved near ETMX

We moved the STS2(Bacardi, Serial NR 100151) to his new location and laid his cable from rack 1X7 to ETMX. The seismometer was below the mode cleaner vacuum tube before.

Now, (since 6:05pm PDT) its placed near the ETMX.



  3351   Tue Aug 3 01:51:01 2010 JenneUpdatePEMSeismometer Update: Still not good, but perhaps getting better


Today's seismometer diagnosis activities are still underway, this is just an update (since I did some reboots):

Problem 1: X and Z channels on both seismometers were flipped.  I unplugged an X cable (East/West on the cable labels) and the Z channel (vert) would go to floating ADC zero.  Rana suggested that the ADCs sometimes have random channel hopping, and that a reboot of the c0dcu1 computer which handles the PEM ADCU should fix this problem.  I keyed the c0dcu1 / c0daqawg crate, those computers came back just fine, and the channels were no longer flipped.  This is a good thing.  Although now it's actually the Z channels that were / are bad on both seismometers, not the X's.

While rebooting those computers, c1iovme, c1sosvme, c1susvme1 and c1susvme2 crashed.  I rebooted them, although for the first few power cycles c1susvme1&2 couldn't mount /cvs/cds/caltech.  Eventually they did, and life is good again.  Except that the seismometers are still funny.

 Some more progress, but still not complete:

Jan and I looked at all of the Gur channels on a 'scope (battery, so as not to be grounded), and 5 of the 6 looked good.  We were looking at the BNCs just as they go into the ADC.  The one which still looks bad is Gur1Z.  The 'scope just doesn't see any signal on that channel. 

In addition, the ADC's BNC input #4 (which normally has Gur2Z) looks totally shot.  When it's floating, the signal on dataviewer definitely doesn't look floating.  I'm probably going to have to move over to another channel, and just give that one up (this ADC already has several channels which have been declared bad, so maybe it's not a surprise that this can happen?)

Since one of the Gur signals looks bad (Gur1Z) and one of the ADC channels looks bad (usual Gur2Z), I switched the Z channels on the ADC board, so the channel being saved as Gur1Z is in fact Gur2Z.  This is valid as of ~1:15am until further elog notice.

During my investigations into why Gur1Z is funny, I also looked at the signal on the BNC octopus cable coming straight from the output of the Guralp Breakout Box (this is the cable which goes from "ADC Out" on the back of the box which is a 37 pin D-sub to 9 differential BNCs), and sometimes I saw zero on the 'scope, but sometimes there was a signal which would coincide with jumping tests.  Whenever there was a signal however, it was always a way lower amplitude (at least by a factor of 10?) than the other channels.

All of this craziness led to me pulling the Guralp box to investigate. 

Upon opening the box, I recalled that the channels go in order: Vert, NS, EW.  The Gur1Z channel is that first vert channel, and it's the one which always had a blue input capacitor rather than a surface mount one.  Being suspicious of Frank and Alastair, since they seemed unhappy with my capacitor choices, I wondered if they had wiggled the blue cap, and tore something loose.  Just in case, and to make things seem more uniform, I replaced the blue cap with a surface mount 1uF cap.  (Actually its 0.909uF, replacing the 0.905uF blue cap, according to the black DMM that measures capacitance.) While I was in there, since it had been a problem in the past (elog 2811), I relflowed the solder on some of the resistors, especially near the output op amp. 

Anyhow, none of that may have been necessary.  All 6 of the Gur channels were examined on a 'scope, using clip doodles to measure the various Test Points on the circuit.  I looked at all of the TPs in Gur1Z, and I didn't find that any particular stage was any noisier than the others.  Also, all 6 of the Gur channels seemed totally fine in terms of sending a good signal to the output of the box, including Gur1Z which is currently under investigation.  All of the channels passed the "output looks ~20x the input" test, and for approximately equal thumping on the ground all 6 channels seemed to have similar amplitude outputs.  The Z channels on both channels one and channels two were a little bigger than the X's or Y's, but the 2 Z channels were about the same.  This test was done using Guralp2 and the Gur2 cable on both channels 1 and 2, and then checked with Guralp 1, using the Gur2 cable on channels 1.  The Vert1 channel always seemed good.

I now am suspicious of one or more of the cables: either the Gur1 cable from the seismometer to the box, or the Vert1 channel of the octopus cable.  I'm satisfied that the BNC cables running through the cable tray are okay (although it might not hurt to check that they all successfully send a sine wave...)  I opened up the backshell of the Gur1 cable, on the end that connects to the breakout box.  Nothing seemed amiss.  I still need to Beep the cable to check its connections, and look at the octopus cable. 

Recap / Current Status:  Breakout Box is reinstalled, both seismometers hooked up.  The Z channels on the seismometers are swapped at the ADC input. The dataviewer channels Gur1_X, Gur1_Y, Gur1_Z (which is actually Z of Gur2 seismometer) and Gur2_X, Gur2_Y are all good.  Nancy is going to leave the MC in a happy place, and note the time when she's done. Tomorrow I'll check out the cables for the Gur1Z seismometer channel. 

  3349   Mon Aug 2 18:02:46 2010 JenneUpdatePEMSeismometer Update: Still not good, but perhpas getting better

Today's seismometer diagnosis activities are still underway, this is just an update (since I did some reboots):

Problem 1: X and Z channels on both seismometers were flipped.  I unplugged an X cable (East/West on the cable labels) and the Z channel (vert) would go to floating ADC zero.  Rana suggested that the ADCs sometimes have random channel hopping, and that a reboot of the c0dcu1 computer which handles the PEM ADCU should fix this problem.  I keyed the c0dcu1 / c0daqawg crate, those computers came back just fine, and the channels were no longer flipped.  This is a good thing.  Although now it's actually the Z channels that were / are bad on both seismometers, not the X's.

While rebooting those computers, c1iovme, c1sosvme, c1susvme1 and c1susvme2 crashed.  I rebooted them, although for the first few power cycles c1susvme1&2 couldn't mount /cvs/cds/caltech.  Eventually they did, and life is good again.  Except that the seismometers are still funny.

  10948   Wed Jan 28 08:53:01 2015 SteveUpdatePEMSeismometer Vertex is covered



I have just put the seismometers back into their nominal positions, on the concreted slabs.  The T-240 is in the vertex, and the 2 Guralps are at the end stations.

The vertex location doesn't have a spaghetti pot right now.  There is an aluminum support for cable trays that is welded to the supports under the beam tube that is in the way.  The pot looks like it will fit barely, if it were slid totally horizontally into place.  However we can't do that with the seismometer in place.  I'll chat with Steve this afternoon about our options. 

Since I don't know that we are planning on ever putting a cable tray on the inside of the beamtube, perhaps we can cut ~6 inches of this piece away. 

Aluminum support beam removed and seismometer is covered.

  10976   Wed Feb 4 19:21:45 2015 JenneUpdatePEMSeismometer Vertex is covered

I opened up the spaghetti pot over the vertex seismometer, and taped the cable to the slab.  The way the cable is coiled, it was touching the underside of the seismometer.  Now the only connection is at the cable connector.  There is a ~few inch bit of cable, then it's taped down. 

  10368   Tue Aug 12 13:31:58 2014 JenneUpdatePEMSeismometer cables in place, ready for sensors

[TaraV, Jenne]

The short cable from the slab to the sensor has been assembled and installed for the Trillium slab at the corner station.  The corner still needs the sensor and the long cable, both of which are in use by the gyro experiment.

The STS-2 cable that was running to the Xend was pulled, and the new long Guralp cable that Den made was installed with help from Andres.  The Xend just needs the sensor itself, which is also in use in gyro-land.

So, once we get the 2 seismometers and the one cable back from Zach, we should have 3 sensors nicely on the slabs that Den and Steve designed.

  13575   Wed Jan 24 13:55:04 2018 KiraSummaryPEMSeismometer can insulation test

Gautam and I set up the insulated seismometer can in the lab today. I had previously wired up the two heaters I placed onto the sides of the can in parallel to get a total resistance of 12.5 ohms and then I wrapped the whole can in 3 layers of insulation (k-factor 0.25). We placed it on a large sheet of insulation as to not crush the wires leading out the bottom of the can. I stuck on one of my AD590 sensors to the inside of the can onto the copper lining using duct tape, though this is only a temporary solution. In the future, it would be nice to have some sort of thermal clamp to secure the sensor to the can. To provide power to the heater circuit board and the temperature sensor board, we got a powerstrip and plugged in two power supplies and a function generator into it. The heater circuit (attachment 3) is powered by one of the power supplies and the function generator, while the temperature sensor (attachment 5) is stuck to the side of the can and is powered by the second power supply. The heater circuit's MOSFET (IRF640, attachment 4) is placed on a metal block and sandwiched between two more to make sure it doesn't move around. The temperature sensor is connected by a long BNC cable to the channels in attachment 6.

gautam: we plugged the BNC output of Kira's temperature sensor circuit to J7 on the AA input chassis in 1X2 - this corresponds to ADC1 input 12 in c1ioo. I then made a "PEM" namespace block inside the c1als model, and placed a single CDS filter module inside it (this can be used for calibration purposes). The filter module is named "C1:PEM-SEIS_EX_TEMP", and has the usual CDSfilt channels available. I DQ'ed the output of the filter module (@256 Hz, probably too high, but I'm holding off on a recompile for now). Recompilation and model restart of c1als went smoothly. 

2 bench power supplies are being used for this test, we can think of a more permanent solution later.

**25 Jan noon: Added another filter module, "C1:PEM-SEIS_EX_TEMP", to which Kira is hooking up a second temperature sensor, which will serve as a monitor of the "Ambient" lab temperature. Added DQ channel for the output of this filter module, fixed sampling to 32Hz. Compile and restart went smooth.

Attachment 1: IMG_20180124_124209.jpg
Attachment 2: IMG_20180124_124202.jpg
Attachment 3: IMG_20180124_124224.jpg
Attachment 4: IMG_20180124_124229.jpg
Attachment 5: IMG_20180124_124236.jpg
Attachment 6: IMG_20180124_124156.jpg
ELOG V3.1.3-