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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 Air conditioning maintenance is scheduled for tomorrow from 8 to 11am

 Jeff checked and  replaced filters  as needed. Job completed this morning.

The south end flow bench HEPA filter should be run all times. You can turn it off for a measurement or two but remember we are storing clean optics there.

The zero count bench will reach  room particle count  ~ 10,000 in one minute.

 My bad.  I turned it off last night to see if it would help make the Xgreen more stable, and then when I woke up this morning I realized that I had forgotten to turn it back on.  Bad Jenne.

Jenne and I renamed the mic channels Den created (elog 6664) to MIC_1, MIC_2, etc from the original accelerometer names to keep things clear. We then added 6 new channels (22-27) for the accelerometers, named ACC_MC1_X, Y, Z, ACC_MC2_X, Y, Z, etc. (See the screenshot below). We also added a DAQ channel block and listed out the IN1 channel of all the sensors. We compiled and started the model, and checked that all the channels were there in DataViewer.

Hi everybody,

Last night I (with the help of Jenne and Jenne's advice - not to implicate her in this or anything) changed the filters for GUR1, GUR2, and STS in C1:PEM-RMS, adding a butterworth bandpass filter at each corresponding frequency band as well as a gain to convert from counts to micros/sec, and then adding a low pass filter in case of aliasing upon squaring.

Currently the seismic signals are going crazy, and producing "Nan" output on the strip graph (which leads to the instantaneously sharp spikes - which leads to the entire signal being filled on the visualizer on the wall). I checked the DataViewer output and the tdsdata output using both grep and wc, and it seems that both every single signal point is present and is a real number (also not a small real number, thereby debunking floating-point error). I'm currently not sure why seismic-strip reads out 'Nan' - perhaps because it's taking the log of 0, taking a negative log, taking the root of a negative number, or dividing by zero.

Does anyone know if the seismic-strip Nan issue is a program bug? If it's not (and therefore a filter bug), please let me know as well.

I'll be in lab for the rest of the night changing the butterworth filters to odd-order elliptic filters (at Rana's suggestion), as well as changing the cut-off frequency for the low-pass filters.

I'll E-log about it when I'm done.

Just to be sure that my numbers are correct - The STS, GUR1, and GUR2 channels all have gain 10, right? (I parsed through the e-log, and these seem to be the most recent numbers

Thanks for your help,

Masha

UPDATE: I changed all of the GUR1Z channels to order-5 elliptic filters. I approximated the attenuation for each one by setting the integral from _CutoffFrequency to 10^3 Hz of 10^(-Percent(f)/20) df to 0.01, where Percent(f) is a linear approximation of the relationship between the log of the frequency and the dB level (with the attenuation defining one of the points). Right now the Nan problem continues to persist, even after I loaded the coefficients. In Dataviewer, the channels look relatively normal for the past 10 minutes, as does the data when viewed with tdsdata.

 FIGURED IT OUT - THERE WAS A PROBLEM WITH THE LOW PASS FILTERS (TOO HIGH ORDER). FIXING IT NOW, SHOULD BE GOOD IN AN HOUR. 

Hi everybody,

Sorry for flooding the ELOG about the PEM channels. Today I

- Changed all of the GUR1 and GUR2 filters to elliptic, and lowered the orders of their low-pass filters.

- Lowered the order of the low-pass filters on the STS channels

- Changed the parameters in seismic.strip, which I saved as MashaTemplate2.

Attached is the most recent status of the channels as seen with StripTools:

I'm not currently sure how to apply my template to seismic.strip shown on the wall (I saved it as seismic.strip on Pianossa and copied the old file to seismic.stripOld). I understand the job is being run on Megatron. I'll play around with this later tomorrow. (In other words, the display currently on the wall, while it does not have the Nan spikes like yesterday and this morning does not currently display the template I made).

The RMS signals generated by the updated filtering process are now on the wall. The NaN issue is gone it seems, and the template has been changed. Thanks for your help, Jenne. 

[Masha, Jenne]

Masha is moving the seismometers, so they are all off right now.  Were they on, they would see a bunch of noise from the guy outside the 40m front door who is installing a safety shower.

phone: 626-395-2465

 Masha and Yaakov - this is an excellent opportunity for you guys to test out your triangulation stuff!  Also, it might give a lot of good data times for the learning algorithms.

Maybe you should also put out the 3 accelerometers that Yaakov isn't using (take them off their cube, so they can be placed separately), then you'll have 6 sensors for vertical motion.  Or you can leave the accelerometers as a cube, and have 4 3-axis sensors (3 seismometers + accelerometer set).

I noticed on DataViewer today that GUR2 was outputting only noise (somewhere around 2 counts). Jenne suggested that GUR 2 might not be plugged in. I turned off the ADC, and tried several times to plug GUR 2 back in. I thought something might be wrong with the cable, but when I plugged the GUR1 cable into GUR2, there was still no readout (although the GUR1 cable works fine when I plug it into GUR1). Perhaps I'm just inept at plugging in GUR2, or perhaps there's another issue. Either way, I'll ask Jenne about it tomorrow and try again.

Yaakov and I investigated the GUR 2 problem. It turns out that the ADC channels that GUR 2 was plugged into, ADC channels 6 through 8 (on the actual ADC they are C7 through C9), did not correspond to the channels labelled "GUR 2" in the PEM, ADC channels 3 through 5. We modified them so that GUR 2 is now plugged into ADC channels 3 through 5 (on the ADC it's +1).

Before we discovered that this was the problem, we attempted to take the cover off of GUR 1 to check the gains, and discovered a stripped Allen screw on the side by the "Vertical" pot, which we removed.

Now the GUR 2 readout looks good, and we will give it more time to settle down before we take data.

It seems that the STS-1 ADC channels had the same mismatch issue as the GUR-2 channels. The PEM_MONITOR has STS_1 listed as channels 6, 7, 8 (+1 on the actual ADC) whereas it was plugged into channels 13, 14, 15 (+1 on the actual ADC as well) with nothing in channels 6, 7, 8. Thus, I moved the cables and reset STS_1. The readout, however, is still only a magnitude of ~10 counts (I checked, however, that this is indeed the readout when the seismometer is plugged in vs. when it is unplugged), but hopefully it will stabilize during the day, as did GUR 2.

Den and investigated the STS-1 problem (which is currently plugged into ADC channels 13, 14, and 15, which correspond to the STS-3 channels in dtt). It turns out that I had plugged in the power to the monitor in the host box rather than the remote. The X, Y, and Z readout is currently approaching a mean of zero, and I will let it continue to do so overnight (pressing auto-zero as necessary). Attached is a plot of the coherence with GUR 1, and the time-domain signals.

The Streckeisen is currently plugged into ADC channels 13, 14, and 15 (corresponding to STS-3 in the channels). The X, Y, and Z components are correct. The signals is zeroed (it's been so for at least the past 10 hours), the coherence with GUR1 looks decent, and the signal looks similar to the GUR1 signal.

I realized what the ADC channel mismatch was, and apologize for plotting a terrible coherence in log scale. The channels are now properly matched (there is decent coherence between GUR1_X/STS_X, etc.).

I did a raw calibration of MCL and GUR. Accuracy is a factor of 2.

GUR path : 800 V/m/s => readout box (G~100) => ADC (0.7 mV/count)

MCL path : laser 1 MHz / V, cavity length ~ 25 m

I measured feedback signal before the laser with SR and avoided whitening filters for MC_F.

Rana and I traced the cables that ran from c1pem1 to the Weather Station monitor.  We found that the flat blue cable that is plugged into c1pem1 was not connected to the black cable from the Weather Station.  We don't know why they are unplugged, but the Weather Station had been inactive since 2010.  Rana plugged them back in (they are now connected via a sketchy connector that had its pins askew) and now the channels are outputting correct data!  Everything else seems to be in good order and now I can use the data from the Weather Station for the summary pages!

To get the code to run on c1pem1, we had to move the old target back into the /cvs/cds/caltech/target/ directory.  It is in /cvs/cds/caltech/target/c1pem1/.

JoeB had apparently moved it into some other area called 'oldfe' and this was why the weather station has not been running for years.    Joe is at LLO now, but he's not beyond our reach...

Once the code had been moved back I started it up. I also rebooted it from the telnet prompt to ensure that it worked on reboot. It did.

The cable issue that Liz mentions probably happened during the PSL table lifting and cable cleanup. It looks like someone yanked the ethernet cable out of its adapter and broke it...

Today I worked with the BLRMS channels, re-triangulated the seismometers (the STS is now on the very end of the Y-arm, while the GUR2 is on the X-arm - this GUR2 cable will need to be either extended or replaced - Jenne and I will look at parts tomorrow), and added 0.01 - 0.03 Hz and 0.03 - 0.1 Hz RMS channels (However, the MEDM files for these are not yet complete - I will finish these tomorrow) in order to be able to better see earthquakes. I also did some things for the neural network project, including beginning Simulink tutorials so that I can run my code by applying a force on a damped harmonic oscillator + white noise until it stops.

I will explain the methodology behind the new RMS filters tomorrow morning, when the seismometers have settled down and I can make coherence plots.

I'll post a better E-log tomorrow when it's not 2 in the morning.

As Jenne suggested last night, I changed the C1PEM overview in Epics. Previously, the C1PEM_OVERVIEW.adl screen had two separate visualizations, one for LP and one for BP for each channel. I changed the format so that there is only one frame per RMS channel, showing all of the input and output as before, but continuously, to demonstrate the actual RMS process.

First, the input is bandpass filtered, then multiplied by itself (squared), then lowpass filtered, and then square rooted to yield the final output. I have kept the previous files, but have applied this new format to all of the RMS ACC*, GUR1, GUR2, and STS1 channels. 

As Rana suggested yesterday, I made channels for 0.01 - 0.03 Hz and 0.03 - 0.1 Hz, and created filters for them, which I will work on some more now.

RMS Filters

How Den, Rana, and I chose RMS filters:

- Because filter ring-down generates negative outputs, which then show up as NaN when the log is taken in StripTool, we decided to only use low-pass filters with real poles (using ZPK in Foton).

- The band-pass filters were chosen by looking at the dB drop from the cutoff frequencies to the next (usually aiming for 40 dB, or 99%), and checking that the BP_IN and BP_OUT had a coherence of 1 in the pass-band.

- The low-pass filters were chosen by finding the lowest filter order at which there was coherence of ~1 in the passband between the input signal to the filter and the filter output. The cutoff frequencies were chosen to be lower than the first passband frequency, in order to get rid of the cos(2*\omega*t)/2 terms that arise during the squaring of a signal of the form Asin(\omega*t) and to assure that only terms related to A^2/2 were kept. A plot of the 3-10 region is attached - in the Coherence plot, the coherence in ~1 in the 3 to 10 hZ region. Likewise,

PEM Sitemap

My previous post had digital zeros in two of the BLRMS channels. Jenne figured out that this was because the file Csqrt.c, which performs the square root operation in the root-mean square processing only accepted 5 inputs. I modified and committed the code so that it now accepts 7 inputs (for our 7 frequency bands) and returns 7 outputs. The new PEM sitemap seems to currently work.

StripTool

I have modified the StripTool file in order to show our new 0.01 Hz - 0.03 Hz and 0.03 Hz - 0.1 Hz channels.

We have a Trillium for several days from Vladimir. I've put seismometer inside the foam box on linolium. I was not able to level the seismometer on granite as this Trillium does not have level screws. Does anybody know where they are?  Readout box stands on the foam box as seismometer cable is short (~2 meters).

Cables go to STS1 inputs (7-9) on ADC 3.

I checked the connections specified in the old Gulap Pin Map and found that they do not correspond to the current values. I mapped out the current connections (in this case, the letter refers to the labeled pin on the mil/spec while the number refers to the pin on the 37 pin DSub, labeled consecutively):

A-1, B-2, C-3, D-4, E-5, F-6, G-7, H-Unused, J-8, K-unused, L-9, M-10, N -11, P-12, S-13, T-Unused, U-14, V-15, W-16, X-17, Y-18, Z-Unused, a-Unused, b-19, c-20, UnlabeledPin-Unused.

There are 20 pins in use of 26 total, which is good because that means Jenne and I can use the ~70m long 24 wire cable to make a new Gurlap 1 cable.

The parts Jenne and I ordered arrived today, so we made a long cable for Guralp 1 using a 24 + 1 wire 70 meter long cable, a female 37-pin DSub, and a 26-pin milspec. The pin map is the same as the one I specified in my previous E-log. I soldered both the milspec attachment and the DSub attachment, and used a Multimeter to check the connectivity of the cables. 20 of 20 connections worked (beeped), so I plugged  the cable into the Gurlap 1 seismometer and the Guralp box.

The time series comparison for the two cables

Old cable:

New cable: (I had to move GUR 1, so it's still stabilizing in the X and Y time series)

 New

The current signal spectrum

The BLRMS on the seismic strip also look similar using the two cables - it's more visible on the wall, but I will include a StripTool picture:

New Cable BLRMS (similar to old cable BLRMS)

Den and I moved the Streckeisen, Guralp 2, and Trillium seismometers to the isolation box in order to measure the noise of the Streckeisen while we have the Trillium.

As we do not have legs for Trillium, I was advised to use shims to adjust the levels. However, they produce extra resonance at ~30 Hz + harmonics. Coherence is lost at these frequencies.

 Brian Lantz / Dan Clark are looking around their lab to see if they forgot to ship the feet with the T-240.  They had taken the feet off to put it in a pod. 

Den and I installed a module in the c1pem model which has a feedforward neural network to classify seismic disturbance (10 means quiet, 20 truck, 30 earthquake). There is a channel SEIS_CLASS which should specify the class of the seismic signal. The code works for signals sampled at 256 Hz, so an anti-aliasing filter must be installed in order to decimate from the 2048 model.

The models were compiling slowly, so Alex removed the archiving feature (gzip and tar were taking a lot of time).

Den and I also had trouble with a simple for loop in our model, so we talked to Alex who noted that the -O3 compiler unravels for loops in a buggy way. Thus, we have compiled c1pem using the -O compiler.

PS: the Trilium seismometer now has legs.

Alex also modified RCG script to generate -O in the Makefile for c1pem model:

controls@pianosa:/opt/rtcds/rtscore/release/src/epics/util 127$ svn diff
feCodeGen.pl 
Index: feCodeGen.pl
===================================================================
--- feCodeGen.pl (revision 2999)
+++ feCodeGen.pl (working copy)
@@ -3183,7 +3183,12 @@
print OUTM "\n";
}
print OUTM "ALL \+= user_mmap \$(TARGET_RTL)\n";
+# do not optimize c1pem
+if ($skeleton eq "c1pem") {
+print OUTM "EXTRA_CFLAGS += -O -w -I../../include\n";
+} else {
print OUTM "EXTRA_CFLAGS += -O3 -w -I../../include\n";
+}
print OUTM "EXTRA_CFLAGS += -I/opt/gm/include\n";
print OUTM "EXTRA_CFLAGS += -I/opt/mx/include\n";

 Using Guralp, STS-2 and Trillium I compared Gur and STS-2 self-noise assuming that Trillium noise is not worse then STS-2 noise.

Interesting that STS-2 (or Trillium if its noise is worse) noise is not too much better then Guralp noise.

STS-2 - end of X arm

GUR 2 - isolation box

TRILLIUM - 1Y3 (DC power supply uses 1Y3 AC power, please do not close the door completely)

GUR 1 - end of Y arm

Now we have several "triangular seismic antennas". Different configurations can be chosen to compare the results.

I fixed up the seismic.stp file for the StripTool display:

1. All BLRMS channels now have a y-axis range of 3 decades. So they all are displaying the same relative changes.
2. So the 0.01-0.1 Hz band which is all over the place is real, sort of. Masha says that it is due to the seismometer signal being dominated by noise below 0.1 Hz. She is going to fix this somehow.
3. I changed the samping time from 1 sec. to 10 sec. to make the traces less fuzzy.
4. We (Masha / Liz) should harmonize the colors of this file with what's on the summary pages.

Den and I measured the differential motion of the x and y arms using Guralp 1 at the end of the y arm, Guralp 2 at the beamsplitter, and the Streckeisen at the end of the x arm.

I calibrated the Streckeisen to the Guralp by calculating the relative gain of the seismometer signals at the microseism. The Guralp 1-y amplitude was 1.0237 times Guralp 2-y and Guralp 2-x was 38.54 times STS-x. The Guralp calibration (to go from counts to meters) I used was 0.61/1000/800/80/(2*pi*f) m/count.

The differential motion should keep decreasing at low frequencies because the ground will move together at such large wavelengths. It goes up because the seismometer noise begins to dominate at low frequencies (below about 0.5 Hz). Another possible error source could be that the seismometers are not perfectly aligned along the arm.

I estimated the transfer function of the seismic stacks using a rough model I made based on the LIGO document LIGO T000058 -00. I used a Q of 3.3 for the viton springs, and resonant frequencies of 2.3, 7.5, 15, and 22 Hz (measured in that document for the horizontal motion). I multiplied the simple mass-spring transfer function four times for each layer of metal/spring, with the respective resonant frequency for each. The pendulum suspending the test masses has a resonant frequency of 0.74 and a Q of 3, according to the same document.

When I multiply the net transfer function (pendulum included, the green line above) by the differential motion of the x arm that I measured in eLog 7186, I find the differential motion of the test mass (NOTE: I converted the differential motion to displacement by multiplying by (1/2*pi*f)).

It agrees within an order of magnitude to the seismic wall from the displacement noise spectrum hanging above the control room computers.

Finally, I looked at how the geophone and accelerometer noise spectra looked compared to the ground differential motion (any STACIS sensor signal will also be multiplied by the stack/pendulum transfer function, so I'm comparing to the differential motion before it goes through the chamber). Below about 1 Hz, it is clear from the plot below that the STACIS could never be of any benefit, even with accelerometers rather than geophones as the feedback sensors.

 I made the plots a little nicer and added new sensor noises (from Brian Lantz's scripts and measurements). Click to enlarge.

The last plot shows that these other sensors' noises are lower than the differential ground motion below 1 Hz.  Though 3 seismometers per STACIS is impractical, this shows that such seismometers could be used as feedforward sensors and provide isolation against differential ground motion. At these noise levels, the noise of the high voltage amplifier circuit in the STACIS would probably be the limiting factor.

Den and I decided to try to classify seismic signals in the frequency domain rather than the time domain. We looked at amplitude spectral density plots of all of the data in our set, and noted that there were noticeable differences in the frequency domain for midnight quiet, trucks, and earthquakes.

For example, here is the time series of quiet, midnight seismic noise as compared to the seismic noise at the peak of an earthquake - the earthquake signal is noticeably higher in the 1 - 3 Hz region. Likewise, for the truck signal, there are noticeable bumps that arise at 10 and 30 Hz during the peak of the truck's motion due to the resonant frequency of the truck bouncing on its wheels.

We investigated this potential means of classification further by considering the linear separability of the power of our signals in various frequency bands. Below is a plot of the power of a normalized signal in the 0.1 - 3.0 Hz region vs. the power of the normalized signal in the 3.0 - 30.0 Hz region - calculated by means of fft and separation of the discrete resulting frequencies (in short, an ideal filter).

There is rather clear linear separability of the normalized signals in this case, as two lines could potentially be drawn to separate trucks from quiet and earthquake in this case (with a few misclassified points due to quiet - since the lab isn't actually empty and quiet in the middle of the night, and man-made seismic disturbances to occur). The reason we have to normalize our signals lies in the fact that the data set had different gains for various seismometers at different times. Normalization not only allows us to use our data set for training effectively, but it also assures that the online classification, if the online signals are also normalized, will allow for variable seismometer gains in the future and still be able to classify signals.

I looked at the linear separability of our training set using various combinations of frequency bands, and deduced that the current separation in the BLRMS preforms best (coincidentally, since the BLRMS separations are just decades), which meant that we could use the current BLRMS system we have for online classification of seismic noise.

Thus, I built a neural network which performed classification with the following parameters:

- One hidden layer of 20 neurons

- Gradient descent backpropagation with learning parameter mu = 0.175

- Sigmoidal activation functions for each neuron (computationally achieved by a parametrized hyperbola rather than an actual hyper-tangent in order to save on computation time). 

- 5 inputs - the normalized fft^2 of the signal (since the root of a signal doesn't add linearly to 1) in the following frequency regions: 0.1 - 0.3, 0.3 - 1.0, 1.0 - 3.0, 3.0 - 10.0 and 10.0 - 30.0 Hz. Since this division was done through the (frequency, fft value) return in Matlab, the signal was essentially filtered ideally into these frequency bands.

- 3 output neurons representing an output vector, with desired output vectors of [1, 0, 0] for earthquake, [0, 1, 0] for truck, and [0, 0, 1] for quiet.

- 1,600,000 training epochs (batch backpropagation on all of the data)

Below is the best learning curve for this network, representing the total amount of inputs misclassified out of 224. The best result achieved was 30 misclassified signals out of 224. Obviously this is not ideal, but our data is not totally linearly separable. This could, however, be reduced with further iterations, but given the close to 0 slope of the learning curve between iteration number 1,000,000 and number 1,500,000, this could take a very long time.

Thus, I trained the network, generated the weight vectors and optimal activation function parameters, and was ready to implement a feed-forward neural network (with no online training). My next e-log (Part 2) will be about this system and will be posted shortly.

As promised in previous e-log, this log is all about the current online seismic noise classification system.

While we had the BLRMS system already in place (which I helped make), Den realized that we would need better filters for the BLRMS channels, as we wanted a strong cut-off, but we also wanted a short step-response so that we could quickly classify seismic signals. Likewise, having a step response which oscillates is also undesirable as this could lead to false classifications of post-truck signal as trucks as a filter adjusts and then dips back down. Thus, after experimenting with many different filters, Den chose to use a combination of

chebyl("LowPass", 1, 1, 0.03)*chebyl("LowPass", 1, 1, 0.03)

as our low-pass filter. The step response and bode plot are below.

 The next step was to write C code that would implement the feedforward neural network with my newly generated weights.

Next, I had to implement the code in the c1pem model, and normalize the inputs. Below is an overview of the model, and a close up of the C block section.

The above close-up includes the process of normalization (dividing by the square of the incoming signal), feeding through the neural network, and classifying.

Each seismometer channel set (GUR1X, GUR1Y, GUR1Z, GUR2X, GUR2Y, GUR2Z, STS1X, STS1Y, STS1Z) now has channels (and corresponding DQ channels) of the following form:

SEIS_CLASS : The class of seismic noise 1.0 means Earthquake, 0.5 means Quiet, and 0.0 means Truck. (There are only these 3 digital values).

SEIS_CLASS_EQ, SEIS_CLASS_TRUCK, SEIS_CLASS_QUIET: These channels represent the confidence of the neural network's classification. The class of the current signal will have an output of 1, where the other two channels will have an output between 0 and 1 representing the ratio of the neural network's output in that class neuron to the output in the classification vector neuron. To simply - suppose the neural network classified an earthquake. Ideally, the neural network output neurons would have the value [1, 0, 0], and SEIS_CLASS would equal 1.0 for earthquake. However, the output neurons probably read something along the lines of [0.9, 0.3, 0.5] - SEIS_CLASS is still 1.0, but SEIS_CLASS_EQ would be 1.0, and SEIS_CLASS_TRUCK would be 0.5 / 0.9 and SEIS_CLASS_QUIET would be 0.3 / 0.9. The lower the other two signals are, the better - this means that we are more confident in our classification.

The MEDM screen for this system (in the RMS system) has the following form for all seismometer channels (this one is GUR1X):

These are the screens I edited earlier in the summer, with modifications. The bottom filter banks represent the norm of the seismometer signal, which we use to normalize the inputs to the neural network.

Here a close-up of the most important part:

The orange meter on the right points to the current signal type. Here it reads truck - this is ok because it's the middle of the day, and there are a lot of trucks around. The left side represents our confidence in the signal - the signal is classified as a truck, so the "Truck" bar is saturated. The quiet signal bar is very low, which is good since it means that the neural network thinks that it's definitely not quiet. The earthquake bar has some magnitude, since earthquake signals and trucks have some degree of linear non-separability.

How has this been performing? Firstly, all of the seismometer channels have the same classification readout, which is good. Last night, all of the classes were "quiet", with an "earthquake" which occurred when Den jumped around GUR1 to simulate an EQ. This morning it was on "truck" as expected. The filters are still not fine enough to detect individual trucks, but I will continue to monitor the performance over the coming days.

If anyone has ideas on how better to represent this information, please let me know. This was the first thing that came into my head that would work with my MEDM monitor options, and I'm open to suggestions!