Seismic monitoring systems: overview, installation, configuration
Greetings, dear Habravchane! Many of us live in seismically unstable areas, and, I believe, no one likes earthquakes. As a techie, and indeed, this topic was always interesting to me: how and where earthquakes originate, how they determine the epicenter and magnitude, how monitoring is performed, etc. And so it happened that I needed to make some kind of pilot system for monitoring in real time indicators of several seismic sensors located far enough from each other and from the center, where this data is stored and processed. If possible, I also wanted to make a WWW page, where it would be possible to view the indicators from the sensors in real time. The task turned out to be quite nontrivial, and after a certain success was achieved in this direction, I decided that it would be nice to make a review article / manual on this issue, which in the future can greatly facilitate someone’s life, especially considering that in RuNet on this issue, I did not find at all. And if so to take, in general, not a single HowTo, even on the English-language Internet, I could not find, although the general and very fragmented information is decent. Also, I did not know a single person (yes, there are not so many of them at all) who could direct them in the right direction, so I had to go all the way myself, digging Google, manuals and software with hardware.
So, this article is about how to set up Guralp seismographs, remove data from them and draw seismic sensors in real time on the WWW page. It also describes what software is used, where to get it and how to configure it.
Seismometers :
I had 2 German-made seismometers - Guralp CMG-6TD. These devices are a bundle of a set of sensors (gyroscopes, mass and temperature), ADC, a controller with a certain amount of Flash memory and packed in a sealed round case. With each sensor, you can remove data both in real time (via a COM port or an internal TCP server, which this COM port makes remotely accessible), or just bury it somewhere deeper, and then drop the data to a disk via FireWire from inside flash drives Seismometers should detect movement in 3 directions: 2 horizontal (E, N) and vertical (Z). Accordingly, when mounted on a work surface, these sensors are centered and also set on a compass. The clock time of the sensors is synchronized by GPS, which is connected directly to the sensor itself with a 15 meter cable. If there is no possibility to connect GPS, then the built-in RTC can be adjusted through the terminal.
')
And this is one of the sensors installed on a special pedestal in the basement of the seismic institution in the region, not far from Dushanbe.
Of course, the equipment is very sensitive and should be installed in a deeper place. Next to this institute (about a kilometer), in the nearby mountain there is a special adit that goes 200 meters deep into the mountain. But this is a matter for the future.
System connection diagram:
Since the sensors need to be located far enough from each other, a communication system was invented and created for transmitting data from the sensor to any node with an Internet connection. In our case, WiFi was chosen, as well as the corresponding hardware needed for communication at a distance of tens of kilometers.
The wiring diagram for one sensor is the following:
Sensor → (ethernet) → WiFi client box → (wifi link) → WiFi AccessPoint → Internet → Central server
Removal of data from sensors:
For the “sampling” of data from the sensors, the branded program “SCREAM” is used - the name of the program is very to the point, because, as it turned out, to a person who did not work with this equipment before, many things, even standard settings, are not quite obvious. Despite the fact that the manufacturer supplies both the program and the equipment with a fairly good and voluminous manual, at the time when you get to operating the system, it turns out that quite a lot of things are left behind the scenes, and have to go through a very scientific tail. In short - at times, when disassembling with the program, its next hangup, etc. - loud, native Russian speech was quite common.
SCREAM:
A universal program from the manufacturer to work with the entire line of seismological equipment Guralp. Designed to monitor the equipment for receiving and saving data from seismometers in real time. You can download it for free from the manufacturer’s website, however, the link to the download section on the website is missing, and it is sent after passing a simple registration. Available in 2 versions - under Linux and under Win. The code is closed, only binaries are distributed. Of all the zoo (in a good way) of Linux distributions, I have been using only one in 15 years - this is Debian Linux, respectively, and under it I set up the work of this software product.
Debian Linux, 64 bit: scream is available only as a tar.gz or .rpm package (the manufacturer recommends CentOS) - and only a 32 bit build. In order to run it under a 64 bit installation, you need to install the ia32libs package, which will add support for 32 bit binaries on a 64 bit system. After that, you can unpack the scream package to the directory where you plan to use it. You need to run it through the attached .sh script, because it uses its own libraries, and the script prescribes the path to them.
The SCREAM program is interactive, with a GTK interface, so you need to run it from the Xs, or under the virtual X server Xvfb - as I did if installing X on the server is not needed.
SCREAM is quite demanding of processor resources, and I spent a lot of time and nerves figuring out the reasons for its hangup, which greatly decreased when transferring the installation from the Samsung Dual-Core laptop to the dual-core Dell XEON. Although, apart from the processor on the machines, everything else was almost the same (2G memory, 250G HDD), but the situation has changed very sensitively. Therefore, you can advise, do not use a machine with a weak processor as a server for SCREAM. Although who knows, maybe he is pathologically Samsung does not digest?
We connect SCREAM and Guralp CMG-6TD:
To get data from the seismometer, you need to connect Guralp with SCREAM in one of the available ways: Through the COM port or via TCP-IP. I will describe the TCP-IP communication procedure, for short. Guralp uses a Lantronix TCP serial server and has a Telnet and WWW interface for setting parameters. By default, Guralp (when turned on) tries to get an IP address via DHCP. I will not describe in detail how to assign an address and get on the WWW interface, since this is described in detail in the manual. Focus on the intricacies and customization. You only need to access the WWW interface via Internet Explorer, because crookedly written Javascript scripts and other interface stuffing do not work in any other browser, yielding absolutely inadequate content of input fields, such as IP addresses, etc. Since I use Windows very rarely, that under Internet Exploiter everything can be fine tuned - understanding did not come right away. Another subtlety: the settings pages are cached, and on the next entry, after applying the settings, they show the old information, the update does not help. Therefore, the explorer needs to be closed, run again (well, or reset the cache, which is longer) if you need to play with the settings.
Since the DHCP device tries to get the address only after switching on, I set up a static IP address.
Now that is not described anywhere: Menu Serial Connection
Since the data is taken from the device, even if via TCP-IP you still use the TCP-Serial server, here we have the BaudRate setting - By default it is (usually) 19200 - but when using a higher SampleRate to retrieve data from Guralp, its meaning can be increase It is impossible to do this just like that, since this setting should correspond to the setting of the output com port of the device, which is configured from another menu, in a different way. If they do not correspond to each other - the WWW interface will cease to function, and it will be necessary to restore work using Telnet, port 9999, and there return speed in accordance with the speed of the internal com port of the device.
Connecion menu: Choose a connection type. The manual is described very poorly, and only in general terms.
We select the protocol (TCP) and if the local port is set to 10001, the remote port is to 1567 and the Remote Host is 0.0.0.0, then everything is fine - you can connect from any IP (in principle, these are the default settings)
Scream: Start, then right-click on Network → Configure, then in the window that opens, select the My Client tab and right-click again on the empty field of the server list → Add TCP Server → Add the IP of our device: 10001. Note that port 10001 is used on Guralp itself. Click OK, and selecting the newly added server, press Ctrl + C (Connect).
If everything is normal, within a minute our device should appear under the Network, in the left pane. When choosing a device, on the right, we will see a list of data channels - these are data from sensors that can be viewed in the form of wave graphs. If we saw the sensor, then the first part of the setup is done, and you can play a bit, see how the seismometer responds to light shocks with your fingers on the box, for example.
At this stage, the first part of the epic is over. We have SCREAM software installed, and a sensor that is actually connected to it, and gives data. Now with this data you need to do something. SCREAM can not only receive data from seismometers, but also transmit further via TCP-IP. The main thing is that the client supports the SCREAM protocol.
After spending some time looking for open source software on the Internet to process seismic data, I settled on the Earthworm system, because the system code is open, and there are hundreds of institutions around the world that use this system to collect, automate analysis and seismic data views. The flip side of the coin is that the system is quite old, poorly supported, and many of the components are frankly curved and falling. But since I did not find a free alternative, I had to deal with it. Documentation, source code and binaries can be found and downloaded from here: folkworm.ceri.memphis.edu/ew-doc
In the presence of a 64-bit assembly, but operation has shown that the 32-bit version is much less prone to drops. Information on the installation of the system is extremely fragmented, outdated and designed, rather, for a person already familiar with the system, so it took quite a long time to figure out how to run it, the whole Saturday from morning to night went from the moment of installation to the launch of drawing schedules.
EARTHWORM - “And another earthworm!” (( C ) jackal from Mowgli)
The system is built on the principle of multi-component, the kernel is the “startstop” binary, which creates the necessary Shared Memory regions for data exchange and launches and monitors other binaries. But, I organized the launch of components separately, because exceptions are poorly handled in them (in some cases, the problem of communicating with the server leads to an emergency exit). Accordingly, they must be run in a loop.
Components:
Since my basic goal is not analysis, but only data drawing, I will use only the components corresponding to this task:
scream2ew: data transfer from SCREAM server to EARTHWORM internal buffer
wave_serverV: data acquisition from internal buffer, storage on disk and return to clients over the network
heli_ewII: data drawing in the manner of a helicorder (seismograph), and presented in the form of a simple WWW page. Data is taken from wave_server
Configuration files are stored in the run / params directory and look like daemon_name.d All configuration files I used can be downloaded from the project page, which is given at the end of this review. This can be very useful, since the description of the parameters is often extremely insufficient.
So, install Earthworm:
Create an earthworm user:
Unpack the binary build - earthworm_7.4
create directories
move all files from earthworm_7.4 / params directory to run / params
edit earthworm_7.4 / environment / ew_linux.bash
for simplicity in the section # Or set your own values ​​directly
add
Then we create the symlink of the parameter file:
ln -s /home/earthworm/earthworm_7.4/envoironment/earthworm.d /home/earthworm/run/params/earthworm.d
This is necessary because different components search for the given file in different directories.
When launching, components may not start with the error “it is impossible to determine your module ID” - the modules and their IDs are registered in the earthworm.d file — just look in the module configuration as it calls itself (for example MOD_SCREAM2EW) and add it to the list of modules with the following ID - everything is intuitive there.
After that you need to create startup scripts:
#param
# startstop.sh
# scream2ew.sh
and wave_severV.sh and heli_ewII.sh - for them, simply replace the program name in the DAEMON variable of the scream2ew.sh script. The scripts are made so that the cycle is interrupted when the script_name.stop file is found in / tmp and, accordingly, they are sequentially started from the start of the script from init.d
All scripts can be downloaded on the project page, and there is no point in bringing them here.
Now you need to pay attention to the configuration files:
startstop - startstop_unix.d
The line Process "name" and Class / Priority indicates which of the binaries to run. We run only status. The rest will be started from the outside, in other scripts.
Scream2ew - scream2ew.d
Here it is necessary to remember in chaninfo that data is being imported from an external system, and data from the DUSH0 device and the stream 6817Z0 is imported into earthworm as TJ DYU - BHZ 1
Channel names TJ DYU, etc. Arbitrary, but you need to respect the number of characters of each component
wave_serverV - wave_serverV.d
Here we create so-called tanks (tanks) - the data received from the devices are stored there. They can also be requested over the network. Please note that the created channels DY BHZ TJ - just go to separate tanks. Also, the MaxMsgSize 4096 parameter is required for working with SCREAM. It is necessary to add that wave_serverV is not ideal for storing data, and in case the data blocks from the sensor are mixed, i.e. their timestamp sequence is not respected, it rejects these blocks. There is an alternative implementation of wave_server on JAVA - Winston WaveServer - the University of Alaska, the download link was found only in the archives of mail correspondence of Earthworm users, therefore I quote it at the end, in the links. It realizes some (but not all) features and bugs of the original one and stores data in the MySQL database.
heli_ewII - heli_ewII.d
Here you specify which data streams to request from wave_serverV and how to draw them. Everything is enough, intuitive. The parameter for the number of hours ago does not work, so the graph at startup will be empty, and only after a while (up to 15 minutes) the data will start to appear. When launched, this module rounds the time and often wants to continue from the next 15-minute interval. This is evident in the log output.
Now you can manually run the scripts in the following sequence:
For debugging purposes, it is better to do it in different terminals in order to see what errors are being generated and whether they work at all.
So that wave_server has enough data, it can take a couple of minutes, only then heli_ewII will find this data and be able to draw it.
Of course, there are a large number of other seismological equipment and software in the world, for example, Nanometrics, of Canadian production, makes very good, complete systems, with connection to a satellite terminal. This means that HUB VSAT is installed in the center and, in remote mountainous areas, VSATs are set to a smaller size, which periodically send data from their sensors. But this is a topic for another review.
At this point I would like to complete this topic. The topic is, of course, very large, and there is still to be dealt with the issues of automated data analysis, calculation of the epicenter and impulse magnitudes. Earthworm contains powerful tools for all this.
Project page:
http://seismo.eastera.tj
Configuration files and scripts:
http://seismo.eastera.tj/downloads
Live project helicorder:
http://seismo.eastera.tj/helicorder
Earthworm:
http://folkworm.ceri.memphis.edu/ew-doc/
Alterative implementation of wave_server on JAVA: http://www.avo.alaska.edu/Software/winston/W_Manual_SR.html
Helicorder Maryland page:
http://www.ceri.memphis.edu/seismic/stations/index.html
So, this article is about how to set up Guralp seismographs, remove data from them and draw seismic sensors in real time on the WWW page. It also describes what software is used, where to get it and how to configure it.
Seismometers :
I had 2 German-made seismometers - Guralp CMG-6TD. These devices are a bundle of a set of sensors (gyroscopes, mass and temperature), ADC, a controller with a certain amount of Flash memory and packed in a sealed round case. With each sensor, you can remove data both in real time (via a COM port or an internal TCP server, which this COM port makes remotely accessible), or just bury it somewhere deeper, and then drop the data to a disk via FireWire from inside flash drives Seismometers should detect movement in 3 directions: 2 horizontal (E, N) and vertical (Z). Accordingly, when mounted on a work surface, these sensors are centered and also set on a compass. The clock time of the sensors is synchronized by GPS, which is connected directly to the sensor itself with a 15 meter cable. If there is no possibility to connect GPS, then the built-in RTC can be adjusted through the terminal.
')
And this is one of the sensors installed on a special pedestal in the basement of the seismic institution in the region, not far from Dushanbe.
Of course, the equipment is very sensitive and should be installed in a deeper place. Next to this institute (about a kilometer), in the nearby mountain there is a special adit that goes 200 meters deep into the mountain. But this is a matter for the future.
System connection diagram:
Since the sensors need to be located far enough from each other, a communication system was invented and created for transmitting data from the sensor to any node with an Internet connection. In our case, WiFi was chosen, as well as the corresponding hardware needed for communication at a distance of tens of kilometers.
The wiring diagram for one sensor is the following:
Sensor → (ethernet) → WiFi client box → (wifi link) → WiFi AccessPoint → Internet → Central server
Removal of data from sensors:
For the “sampling” of data from the sensors, the branded program “SCREAM” is used - the name of the program is very to the point, because, as it turned out, to a person who did not work with this equipment before, many things, even standard settings, are not quite obvious. Despite the fact that the manufacturer supplies both the program and the equipment with a fairly good and voluminous manual, at the time when you get to operating the system, it turns out that quite a lot of things are left behind the scenes, and have to go through a very scientific tail. In short - at times, when disassembling with the program, its next hangup, etc. - loud, native Russian speech was quite common.
SCREAM:
A universal program from the manufacturer to work with the entire line of seismological equipment Guralp. Designed to monitor the equipment for receiving and saving data from seismometers in real time. You can download it for free from the manufacturer’s website, however, the link to the download section on the website is missing, and it is sent after passing a simple registration. Available in 2 versions - under Linux and under Win. The code is closed, only binaries are distributed. Of all the zoo (in a good way) of Linux distributions, I have been using only one in 15 years - this is Debian Linux, respectively, and under it I set up the work of this software product.
Debian Linux, 64 bit: scream is available only as a tar.gz or .rpm package (the manufacturer recommends CentOS) - and only a 32 bit build. In order to run it under a 64 bit installation, you need to install the ia32libs package, which will add support for 32 bit binaries on a 64 bit system. After that, you can unpack the scream package to the directory where you plan to use it. You need to run it through the attached .sh script, because it uses its own libraries, and the script prescribes the path to them.
The SCREAM program is interactive, with a GTK interface, so you need to run it from the Xs, or under the virtual X server Xvfb - as I did if installing X on the server is not needed.
SCREAM is quite demanding of processor resources, and I spent a lot of time and nerves figuring out the reasons for its hangup, which greatly decreased when transferring the installation from the Samsung Dual-Core laptop to the dual-core Dell XEON. Although, apart from the processor on the machines, everything else was almost the same (2G memory, 250G HDD), but the situation has changed very sensitively. Therefore, you can advise, do not use a machine with a weak processor as a server for SCREAM. Although who knows, maybe he is pathologically Samsung does not digest?
We connect SCREAM and Guralp CMG-6TD:
To get data from the seismometer, you need to connect Guralp with SCREAM in one of the available ways: Through the COM port or via TCP-IP. I will describe the TCP-IP communication procedure, for short. Guralp uses a Lantronix TCP serial server and has a Telnet and WWW interface for setting parameters. By default, Guralp (when turned on) tries to get an IP address via DHCP. I will not describe in detail how to assign an address and get on the WWW interface, since this is described in detail in the manual. Focus on the intricacies and customization. You only need to access the WWW interface via Internet Explorer, because crookedly written Javascript scripts and other interface stuffing do not work in any other browser, yielding absolutely inadequate content of input fields, such as IP addresses, etc. Since I use Windows very rarely, that under Internet Exploiter everything can be fine tuned - understanding did not come right away. Another subtlety: the settings pages are cached, and on the next entry, after applying the settings, they show the old information, the update does not help. Therefore, the explorer needs to be closed, run again (well, or reset the cache, which is longer) if you need to play with the settings.
Since the DHCP device tries to get the address only after switching on, I set up a static IP address.
Now that is not described anywhere: Menu Serial Connection
Since the data is taken from the device, even if via TCP-IP you still use the TCP-Serial server, here we have the BaudRate setting - By default it is (usually) 19200 - but when using a higher SampleRate to retrieve data from Guralp, its meaning can be increase It is impossible to do this just like that, since this setting should correspond to the setting of the output com port of the device, which is configured from another menu, in a different way. If they do not correspond to each other - the WWW interface will cease to function, and it will be necessary to restore work using Telnet, port 9999, and there return speed in accordance with the speed of the internal com port of the device.
Connecion menu: Choose a connection type. The manual is described very poorly, and only in general terms.
We select the protocol (TCP) and if the local port is set to 10001, the remote port is to 1567 and the Remote Host is 0.0.0.0, then everything is fine - you can connect from any IP (in principle, these are the default settings)
Scream: Start, then right-click on Network → Configure, then in the window that opens, select the My Client tab and right-click again on the empty field of the server list → Add TCP Server → Add the IP of our device: 10001. Note that port 10001 is used on Guralp itself. Click OK, and selecting the newly added server, press Ctrl + C (Connect).
If everything is normal, within a minute our device should appear under the Network, in the left pane. When choosing a device, on the right, we will see a list of data channels - these are data from sensors that can be viewed in the form of wave graphs. If we saw the sensor, then the first part of the setup is done, and you can play a bit, see how the seismometer responds to light shocks with your fingers on the box, for example.
At this stage, the first part of the epic is over. We have SCREAM software installed, and a sensor that is actually connected to it, and gives data. Now with this data you need to do something. SCREAM can not only receive data from seismometers, but also transmit further via TCP-IP. The main thing is that the client supports the SCREAM protocol.
After spending some time looking for open source software on the Internet to process seismic data, I settled on the Earthworm system, because the system code is open, and there are hundreds of institutions around the world that use this system to collect, automate analysis and seismic data views. The flip side of the coin is that the system is quite old, poorly supported, and many of the components are frankly curved and falling. But since I did not find a free alternative, I had to deal with it. Documentation, source code and binaries can be found and downloaded from here: folkworm.ceri.memphis.edu/ew-doc
In the presence of a 64-bit assembly, but operation has shown that the 32-bit version is much less prone to drops. Information on the installation of the system is extremely fragmented, outdated and designed, rather, for a person already familiar with the system, so it took quite a long time to figure out how to run it, the whole Saturday from morning to night went from the moment of installation to the launch of drawing schedules.
EARTHWORM - “And another earthworm!” (( C ) jackal from Mowgli)
The system is built on the principle of multi-component, the kernel is the “startstop” binary, which creates the necessary Shared Memory regions for data exchange and launches and monitors other binaries. But, I organized the launch of components separately, because exceptions are poorly handled in them (in some cases, the problem of communicating with the server leads to an emergency exit). Accordingly, they must be run in a loop.
Components:
Since my basic goal is not analysis, but only data drawing, I will use only the components corresponding to this task:
scream2ew: data transfer from SCREAM server to EARTHWORM internal buffer
wave_serverV: data acquisition from internal buffer, storage on disk and return to clients over the network
heli_ewII: data drawing in the manner of a helicorder (seismograph), and presented in the form of a simple WWW page. Data is taken from wave_server
Configuration files are stored in the run / params directory and look like daemon_name.d All configuration files I used can be downloaded from the project page, which is given at the end of this review. This can be very useful, since the description of the parameters is often extremely insufficient.
So, install Earthworm:
Create an earthworm user:
adduser earthworm su - earthworm
Unpack the binary build - earthworm_7.4
create directories
run run / datafiles run / gifs run / params run / scripts
move all files from earthworm_7.4 / params directory to run / params
edit earthworm_7.4 / environment / ew_linux.bash
for simplicity in the section # Or set your own values ​​directly
add
export EW_HOME = / home / earthworm / export EW_VERSION = earthworm_7.4 export EW_RUN_DIR = $ EW_HOME / run
Then we create the symlink of the parameter file:
ln -s /home/earthworm/earthworm_7.4/envoironment/earthworm.d /home/earthworm/run/params/earthworm.d
This is necessary because different components search for the given file in different directories.
When launching, components may not start with the error “it is impossible to determine your module ID” - the modules and their IDs are registered in the earthworm.d file — just look in the module configuration as it calls itself (for example MOD_SCREAM2EW) and add it to the list of modules with the following ID - everything is intuitive there.
After that you need to create startup scripts:
#param
#! / bin / bash HOME = / home / earthworm BIN = $ HOME / earthworm_7.4 / bin EWE = $ HOME / earthworm_7.4 / environment PARAM = $ HOME / run / params SLEEPTIME = 2 . $ EWE / ew_linux.bash ulimit -c unlimited
# startstop.sh
#! / bin / bash
DIR = `dirname $ 0`
ME = `basename $ 0`
ST = / tmp / $ ME.stop
EWENV = / home / earthworm / earthworm_7.4 / environment
DAEMON = startstop
. $ DIR / param
rm $ ST
while true; do
echo Starting $ DAEMON. $ daemon $ DAEMON
$ Bin / $ daemon
if test -f "$ ST"; then
echo $ ME exitting ...
rm $ ST
exit 0
fi
echo Restarting in $ SLEEPTIME seconds ...
sleep $ SLEEPTIME
done
# scream2ew.sh
#! / bin / bash
DIR = `dirname $ 0`
ME = `basename $ 0`
ST = / tmp / $ ME.stop
EWENV = / home / earthworm / earthworm_7.4 / environment
DAEMON = scream2ew
. $ DIR / param
rm $ ST
while true; do
echo Starting $ DAEMON. $ daemon $ DAEMON
$ BIN / $ DAEMON $ PARAM / $ DAEMON.d
if test -f "$ ST"; then
echo $ ME exitting ...
rm $ ST
exit 0
fi
echo Restarting in $ SLEEPTIME seconds ...
sleep $ SLEEPTIME
done
and wave_severV.sh and heli_ewII.sh - for them, simply replace the program name in the DAEMON variable of the scream2ew.sh script. The scripts are made so that the cycle is interrupted when the script_name.stop file is found in / tmp and, accordingly, they are sequentially started from the start of the script from init.d
All scripts can be downloaded on the project page, and there is no point in bringing them here.
Now you need to pay attention to the configuration files:
startstop - startstop_unix.d
nRing 3 Ring WAVE_RING 1024 Ring PICK_RING 1024 Ring HYPO_RING 1024 MyModuleId MOD_STARTSTOP # Module Id for this program HeartbeatInt 50 # Heartbeat interval in seconds MyClassName OTHER # For this program MyPriority 0 # For this program LogFile 1 # 1 = write a log file to disk, 0 = don't KillDelay 10 # seconds to wait before killing modules on HardKillDelay 5 # number of seconds to wait for hard shutdown Process "statmgr statmgr.d" Class / Priority OTHER 0
The line Process "name" and Class / Priority indicates which of the binaries to run. We run only status. The rest will be started from the outside, in other scripts.
Scream2ew - scream2ew.d
MyModuleId MOD_SCREAM2EW # module id for this instance of scream2ew. RingName WAVE_RING # shared memory ring for input / output LogFile 1 # 0 to turn off disk log file; if 1, do log. Verbose 1 # 1 => log every packet. 0 => don't HeartBeatInterval 30 # seconds between heartbeats PortNumber 1567 Server 192.168.88.1 # If specified name or IP number of this module ChanInfo "DUSH0 6817Z0 TJ DYU - BHZ 1" ChanInfo "DUSH0 6817N0 TJ DYU - BHN 2" ChanInfo "DUSH0 6817E0 TJ DYU - BHE 3"
Here it is necessary to remember in chaninfo that data is being imported from an external system, and data from the DUSH0 device and the stream 6817Z0 is imported into earthworm as TJ DYU - BHZ 1
Channel names TJ DYU, etc. Arbitrary, but you need to respect the number of characters of each component
wave_serverV - wave_serverV.d
MyModuleId MOD_WAVESERVERV # wave_server's module id
RingName WAVE_RING # name of transport ring to get data from
LogFile 1 # 1 = write log file to disk; 0 = don't
# 2 = write to stderr / stdout
HeartBeatInt 15 # seconds between heartbeats to statmgr
ServerIPAdr 192.168.88.1 # address of machine running wave_server: geops.geophys
ServerPort 16022 # port for receiving & receiving waves
GapThresh 1.5 # threshhold for gap declaration.
SocketTimeout 11000 # Timeout length in MILLISECONDS for socket calls
ClientTimeout 60000 # Optional. Not recommended feature but it does work.
IndexUpdate 10
TankStructUpdate 1
TankStructFile /home/earthworm/run/datafiles/p1000-1.str
# SCNL Record Logo Size File Size Size File Name New .......
# names size (TYPE_TRACEBUF2 only) (megabytes) (max breaks) (full path) Tank ......
Tank DYU BHZ TJ - 4096 INST_UNKNOWN MOD_WILDCARD 1 10000 /home/earthworm/run/datafiles/p1001.tnk
Tank DYU BHN TJ - 4096 INST_UNKNOWN MOD_WILDCARD 1 10000 /home/earthworm/run/datafiles/p1002.tnk
Tank DYU BHE TJ - 4096 INST_UNKNOWN MOD_WILDCARD 1 10000 /home/earthworm/run/datafiles/p1003.tnk
Tank DYU BHM TJ - 4096 INST_UNKNOWN MOD_WILDCARD 1 10000 /home/earthworm/run/datafiles/p1004.tnk
RedundantTankStructFiles 1
RedundantIndexFiles 1
TankStructFile2 /home/earthworm/run/datafiles/p1000-2.str
InputQueueLen 4000
MaxMsgSize 4096
SocketDebug 0
ReCreateBadTanks 1
QueueReportInterval 5
Here we create so-called tanks (tanks) - the data received from the devices are stored there. They can also be requested over the network. Please note that the created channels DY BHZ TJ - just go to separate tanks. Also, the MaxMsgSize 4096 parameter is required for working with SCREAM. It is necessary to add that wave_serverV is not ideal for storing data, and in case the data blocks from the sensor are mixed, i.e. their timestamp sequence is not respected, it rejects these blocks. There is an alternative implementation of wave_server on JAVA - Winston WaveServer - the University of Alaska, the download link was found only in the archives of mail correspondence of Earthworm users, therefore I quote it at the end, in the links. It realizes some (but not all) features and bugs of the original one and stores data in the MySQL database.
heli_ewII - heli_ewII.d
LogSwitch 1 MyModuleId MOD_HELI_EWII RingName WAVE_RING HeartBeatInt <-> 10 wsTimeout 30 # time limit WaveServer 192.168.88.1 16022 "Dushanbe" GifDir / home / earthworm / run / gifs # SCNL 04 05 06 07 08 09 10 11 12 13 14 15 Comment Plot DYU BHN TJ - 12 5 + 5 TJT 1 1 20 20 15 0.1 0.05 1 "Dushanbe Center N" Plot DYU BHZ TJ - 12 5 + 5 TJT 1 1 20 20 15 0.1 0.05 1 "Dushanbe Center Z" Plot DYU BHE TJ - 12 5 + 5 TJT 1 1 20 20 15 0.1 0.05 1 "Dushanbe Center E" Days2Save 365 # Number of days to display on web page; default = 7 UpdateInt 1 # Number of minutes between updates; default = 2 RetryCount # 2; default = 2 Clip 5 SaveDrifts Make_HTML IndexFile welcome.html Debug WSDebug
Here you specify which data streams to request from wave_serverV and how to draw them. Everything is enough, intuitive. The parameter for the number of hours ago does not work, so the graph at startup will be empty, and only after a while (up to 15 minutes) the data will start to appear. When launched, this module rounds the time and often wants to continue from the next 15-minute interval. This is evident in the log output.
Now you can manually run the scripts in the following sequence:
startstop.sh scream2ew.sh wave_serverV.sh heli_ewII.sh
For debugging purposes, it is better to do it in different terminals in order to see what errors are being generated and whether they work at all.
So that wave_server has enough data, it can take a couple of minutes, only then heli_ewII will find this data and be able to draw it.
Of course, there are a large number of other seismological equipment and software in the world, for example, Nanometrics, of Canadian production, makes very good, complete systems, with connection to a satellite terminal. This means that HUB VSAT is installed in the center and, in remote mountainous areas, VSATs are set to a smaller size, which periodically send data from their sensors. But this is a topic for another review.
At this point I would like to complete this topic. The topic is, of course, very large, and there is still to be dealt with the issues of automated data analysis, calculation of the epicenter and impulse magnitudes. Earthworm contains powerful tools for all this.
Project page:
http://seismo.eastera.tj
Configuration files and scripts:
http://seismo.eastera.tj/downloads
Live project helicorder:
http://seismo.eastera.tj/helicorder
Earthworm:
http://folkworm.ceri.memphis.edu/ew-doc/
Alterative implementation of wave_server on JAVA: http://www.avo.alaska.edu/Software/winston/W_Manual_SR.html
Helicorder Maryland page:
http://www.ceri.memphis.edu/seismic/stations/index.html
Source: https://habr.com/ru/post/125400/
All Articles