Finally, much of the equipment used in volcano monitoring is installed in remote areas using batteries and solar panels as power sources. It is therefore desirable that the power consumption of the equipment be the lowest possible, but due to the fact the consumption of the systems shown are similar, this isn’t a feature that determine their selection.
2.1. Hardware
The basic function of the system is: (i) the digital conversion of the acquired analog signal using 16-bit resolution; (ii) the on-board storage of this data and (iii) its transmission and display. The sampling rate, the number of channels to be acquired, and other information regarding the parameters being measured are configured mainly from a purpose-built website.
For the development of the data-acquisition system, a Raspberry Pi
TM microcomputer (
Table 5) on an ARM
TM-embedded processor with the Raspbian operating system (based on Debian Linux) was chosen for its low cost and consumption. Given that it supports different GNU/Linux operating systems, it is ideal for developing a real-time measurement system and facilitates the development of applications across multiple communication protocols such as User Datagram Protocol (UDP), Transmission Control Protocol (TCP), File Transfer Protocol (FTP), and Secure Shell (SSH) and Secured File Transfer Protocols (SFTP). Moreover, since the programming uses high-level languages it is also very easy to develop applications for data manipulation.
This acquisition system consists mainly of a low-noise 16-bit A/D converter from Analog Devices (Norwood, MA, USA) and a real-time clock (RTC) from NXP Semiconductors (Eindhoven, Netherlands), which is necessary if the system loses its Internet connection and cannot be synchronized via the NTP protocol. Currently, we are testing a new version based on a 5-channel A/D converter with 24-bit resolution.
Using different sensors, an electronic signal conditioning was developed that can adapt the acquisition circuit by adjusting the measurement signal to the input range of the A/D converter, and can filter the acquired signal (
Figure 1). The applications developed based on this acquisition system are described below.
Table 5.
Main Features of Raspberry Pi.
Table 5.
Main Features of Raspberry Pi.
Raspberry Pi Model B |
---|
SoC | Broadcom BCM2835 (CPU,GPU,DSP,SDRAM,USB) |
CPU | ARM 1176JZF-S 700 MHz (ARM11) |
Instructions | RISC 32 bits |
SDRAM | 512 MiB |
USB 2.0 | 2 |
Video output | HDMI,RCA,DSI |
Storage | SD/MMC |
Network connectivity | 10/100 Ethernet |
Peripherals | GPIO,SPI,I2C,UART |
Power consumption | 200 mA @ 12V |
Figure 1.
General schema.
Figure 1.
General schema.
2.1.1. Gravity Measurement System
The sensor used for the gravimetric system was a LaCoste & Romberg (LCR, Lafayette, CO, USA) model G (
Table 6), whose working is based on the movement of a weight attached to a spring. The gravimeter’s housing is metallic, which, although providing great strength, has the disadvantage that the structure will expand and contract as the temperature changes; therefore, the temperature has to be maintained constant. The sensor’s weight, unlike the rest of the structure, is made of quartz, which is less sensitive to temperature.
Table 6.
Specifications of the LaCoste & Romberg gravimeter, model G.
Table 6.
Specifications of the LaCoste & Romberg gravimeter, model G.
LaCoste & Romberg (Model G) |
---|
Range | 7000 mGal |
Data Resolution | 0.005 mGal |
Accuracy | 0.04 mGal |
Repeatability | 0.01 to 0.02 mGal |
Drift | 1.0 mGal per month |
Length | 19.7 cm |
Width | 17.8 cm |
Height | 25.1 cm |
Weight | 3.2 Kg |
The LCR-G is a relative gravimeter, that is, it does not measure gravity directly but instead provides a value for the difference in gravity between observations in different locations or in the same place but at different times.
Due to the influence of the weather on gravimeter measurements, a weather station is used to monitor weather conditions. The weather station development is a low-cost and low-power system based on the Arduino
TM [
48] platform and consists of temperature, humidity, and pressure sensors (
Table 7).
Table 7.
Main components of the weather station.
Table 7.
Main components of the weather station.
Weather Station |
---|
Component | Description |
---|
ATMEGA328 | Microcontroller |
BMP085 | Pressure and Temperature Sensor |
SHT75 | Humidity and Temperature Sensor |
The weather station sends the acquired data to the gravity meter system via a UART. The data is also stored locally on a memory card whose acquisition time is programmable.
The weather station’s two sensors are digital and communication is performed by a microcontroller, ATMEGA328, via one I2C serial protocol for the BMP085 and one pseudo I2C for the SHT75. After acquisition, data are stored in the on-board memory and are transmitted via the UART. Both sensors have built-in temperature sensors (
Table 8).
Table 8.
Specifications of the humidity and pressure sensors.
Table 8.
Specifications of the humidity and pressure sensors.
| Humidity Sensor | Pressure Sensor |
---|
Humidity | Temperature | Pressure | Temperature |
---|
Resolution | 12 bits | 14 bits | 0.01 hPa | 0.1 °C |
Accuracy | ±3%RH | ±0.3 °C | ±0.2 hPa | ±0.5 °C |
Linearity | ±0.1%RH | ±01 °C | -- | -- |
Range | 0%–100%RH | −4 to 123.8 °C | 300 to 1100 | −40 to 130 °C |
Offset | <0.5 *RH/year | <0.04 °C/year | ±1 hPa/year | -- |
2.1.2. Measurement System for Ground Deformation
The sensor used for the ground deformation measurement system is the 701-2 tiltmeter from Jewell Instruments (Manchester, NH, USA) (
Table 9). This high sensitivity and low power-consumption tiltmeter has two analog outputs corresponding to two axes (NS and EW) and a single analog output for a temperature sensor. This sensor is mainly useful in the field of geophysics for monitoring deformation of the Earth’s surface, although it can also be used for structure monitoring.
These tiltmeters contain two electrolytic level sensors, one for each axis, which produce a change in resistance in response to a rotation of the sensor. This resistance is measured in a Wheatstone bridge; the signal is then amplified so that it can be acquired externally.
The two sensors are arranged orthogonally such that the vector is the sum of the output of both channels given the direction and magnitude of the rotation relative to the gravity vector. The temperature sensor, installed inside the tiltmeter, evaluates how the temperature changes affect the structure in which the tiltmeter is installed.
Table 9.
Specifications of the 701-2 tiltmeter.
Table 9.
Specifications of the 701-2 tiltmeter.
701-2 Platform Tilt Meter |
---|
Angular Range: low gain | ±8000 urad (±0.46°) |
Angular Range: high gain | ±800 urad (±0.046°) |
Scale Factor | 1 urad/mV |
Resolution | 0.1 urad |
Linearity | 2% of full span |
Tilt Output | ±8 V (single-ended) and ±16 V (differential) |
Temperature Output | 0.1 °C/mV (single-ended) and ±0.75 °C accuracy |
The default sampling rate of the tiltmeter is once a minute, although larger time intervals can be programed. However, the acquisition system takes samples every second and provides every minute the arithmetic mean of all samples. Thus, signal filtering is performed, which substantially improves the signal-to-noise ratio.
2.1.3. Tide Gauge Measurement System
The sensor used for the ocean tide measurement system is the SEBAPuls 30 radar from SEBA Hydrometrie (Kaufbeuren, Germany) (
Table 10). It is a non-intrusive sensor for high-precision measurement of water levels that functions by emitting microwave pulses of 26 GHz and receiving the waves reflected off the water surface. After receiving the reflected signal, the sensor calculates the distance to the water surface.
Table 10.
Specifications of the SEBAPuls 30 radar.
Table 10.
Specifications of the SEBAPuls 30 radar.
SEBAPuls 30 |
---|
Precision | ±3 mm |
Range | 0 to 35 m |
Output | 4 to 20 mA |
2.1.4. Monitoring System Using Images
This system was developed using a commercial camera (
Table 11) designed specifically for the Raspberry Pi platform. It is a low-cost system that can be implemented on any of the above systems since its interface is independent from the others. The camera interface is Camera Serial Interface (CSI) a specification designed by Mobile Industry Process Interface (MIPI), an organization that develops interface specifications for mobile phones.
Table 11.
Specifications of the camera.
Table 11.
Specifications of the camera.
Raspberry PI Camera Board |
---|
Resolution | 5 MP |
Still Picture Resolution | 2592 × 1944 |
Video | 1080p @ 30fps, 720p @ 60fps and 640 × 480p 90fps |
Interface | 15-pin MIPI Camera Serial Interface |
Size | 20 × 25 × 9 mm |
2.2. Software
The developed software consists of a set of programs written in C, PHP, HTML, Java, JavaScript, LUA, and Linux Bash shell scripts. These programs also use certain free software applications such as Gnuplot [
49] for graphical representations of various parameters; ImageMagick [
50] for editing images; libav [
51] for video editing; Apache [
52] as a web server; and the Telegram CLI [
53] instant messaging program for controlling and configuring the various systems.
The execution of most of the programs are performed using cron of Linux, which is a background process manager able to run processes at regular intervals that can be scheduled according to the type of application.
The programs are divided into those related to data-acquisition systems (tiltmeter, tide gauge, and gravimeter) and the image-capturing system. The programs and scripts for the acquisition system are as follows:
main.c,
graph.sh,
synch.sh,
meteo.c,
message.lua, and
index.php (
Table 12), while those used for the image-capturing system are:
timelapse.c,
battery.c,
bat_graph.sh,
video.sh,
buffer.sh,
synch.sh,
message.lua, and
index.php (
Table 14).
Table 12.
Data-acquisition system software.
Table 12.
Data-acquisition system software.
Software/Script | Execution Every |
---|
main.c | 1 min (default) |
graph.sh | 1 min |
synch.sh | 30 min |
meteo.c | continuously |
message.lua | continuously |
index.php | continuously |
Most of the programs in
Table 12 have a short life cycle and once finalized are quit until they are next needed. In order to avoid that two instances of the same process have been executed, each time a program is launched it checks if another process already is running, in this case, that process is forced to finalize. A detailed description of these programs, corresponding to each data-acquisition system, is presented below.
The principal program is the
main.c (
Figure 2A), which performs the analog data acquisition. It acquires the data, timestamps it, and then stores it in an external USB memory. This memory has a structure of nested folders for each piece of equipment (gravity meter, weather station, tiltmeter, and tide gauge) containing subfolders for years and further subfolders for months, in which files are stored on a daily basis. This software uses the calibration curves of each sensor and stores the data in files for raw data and for calculated data corresponding to their units of measurement. The calibration curves are located in files inside the system and can be accessed by the acquisition software during each measurement.
Using the synch.sh script, which runs every 30 min, the stored data is fully and regularly copied to a remote computer, maintaining the same structure that exists in the external memory of the system. This periodic data-copying process is configurable, as is the server address to which the user sends the data. Data transfer is performed by applying Linux rsync over SSH protocol, which allows for the synchronization of local folders and files on a remote computer. The advantage of using this form of data transmission is that it minimizes the volume of data transmitted since it makes use of a delta encoding algorithm, that only stores the bytes that have been modified since the previous version of the file.
Figure 2.
(A) Flowchart of the main.c application; (B) Flowchart of the graph.sh application.
Figure 2.
(A) Flowchart of the main.c application; (B) Flowchart of the graph.sh application.
The
graph.sh (
Figure 2B) script is the visual representation of the data that are acquired that uses the Gnuplot application tool. This is useful for generating graphs from the command line that are stored directly as a file (pdf, png, gif, jpg,
etc.). This script runs once a minute and its function is to take data from a specific period and represent them using Gnuplot. The output of this software, a PNG image, is copied to the path where the website is hosted. The period of data to be displayed is configurable by the user and before presenting any visual representation this script reads a configuration file containing the chosen period.
Both the computer settings and the display of real-time data are carried out through a web page developed in PHP (
Table 12). This website is password-protected to prevent modifications of the system configuration by unauthorized users. The sections that must be configured through the webpage are: station name, serial number of the sensor, selection of the channels to be acquired, and the sampling period. If the user wishes to transmit data, the transmission section must be activated and the server must be configured to specify the port and the remote folder in which the data should be saved. Optionally, the deployment coordinates (latitude, longitude, and altitude) can be added to the station. Other settings such as the calibration curves of the sensor are not performed directly through the website for safety reasons. The user must access the system via SSH and modify the corresponding file. If the user does not want the data transmitted in real time, they can be downloaded directly from the website.
The website information is presented both numerically and graphically. The graphic representation of the data is carried out for all parameters measured on the previous days (
Figure 3 and
Figure 4). Moreover, it provides information regarding the acquired data such as date, time, and the most recent value, and also provides a brief statistical summary of the data for the current day (minimum, maximum, and the difference between them) (
Figure 5). The configuration files generated by the website are used in the scripts described above.
Figure 3.
Image captured from the website corresponding to gravimeter measurements and battery control with the units of the depicted parameters in mV and V, respectively. A 10-day period is shown.
Figure 3.
Image captured from the website corresponding to gravimeter measurements and battery control with the units of the depicted parameters in mV and V, respectively. A 10-day period is shown.
As explained above, the developed applications are executed by the system at scheduled intervals; however, there are other programs such as those for acquiring meteorological data and the instant messaging application that run on system start-up.
The data generated by the weather station are sent from the Arduino
TM platform via the UART every minute. The
meteo.c program handles data reception, provides the timestamp, and then stores data on the USB drive in the file structure described above (
Figure 6).
Figure 4.
Image captured from the website corresponding to the meteorological data of the gravimeter system. Top: the ambient and internal temperature; middle: the relative humidity and dew point; bottom: the pressure. A 10-day period is shown.
Figure 4.
Image captured from the website corresponding to the meteorological data of the gravimeter system. Top: the ambient and internal temperature; middle: the relative humidity and dew point; bottom: the pressure. A 10-day period is shown.
The other application that runs at system start-up is the Telegram-CLI instant messaging service, an unofficial client telegram [
54] for Linux. Using scripts in
Lua language, users can interact with the messaging software and send and receive text, images, and video. This enables the status of the various pieces of equipment to be checked and configured. The
message.lua script (
Table 12) acts as a robot, answering via the messaging program commands sent by users. The commands requesting information from the station can be images, video, or text. They are received by all stations but, because each station measures different parameters and is installed in a different location, each has a specific script according to the parameters measured. For each computer connection, there is a general HELP command, executed by all, in which the response is the name of the station followed by ONLINE. To find out which commands are supported by each station, it is only necessary to type in the station’s name (
Table 13). An example of how to access various stations via instant messaging software is shown in
Figure 7.
Figure 5.
Image captured from the website corresponding to the gravimeter configuration section and metadata. Left-hand side: the configuration data; right-hand side: information regarding the gravity meter system, battery, and meteorological data.
Figure 5.
Image captured from the website corresponding to the gravimeter configuration section and metadata. Left-hand side: the configuration data; right-hand side: information regarding the gravity meter system, battery, and meteorological data.
Figure 6.
Flowchart of the meteo.c application.
Figure 6.
Flowchart of the meteo.c application.
Table 13.
Some of the commands supported by the stations. The general commands are answered by all stations.
Table 13.
Some of the commands supported by the stations. The general commands are answered by all stations.
Command | Type | Response | Station Responding |
---|
HELP | General | <station name> ONLINE | All |
<station name> | Specific | Lists the commands supported by the station | All |
CRAJI | Specific | Sends the last image captured | Camera CRAJ |
CRAJL | Specific | Sends a list of available time lapses | Camera CRAJ |
RGRAVV | Specific | Sends the graph for gravity | Gravimeter GRAJ |
RBAT | Specific | Sends the graph for batteries | Gravimeter GRAJ |
ITIGXY | Specific | Sends the graph for deformation | Tiltmeter ITIG |
IRIOXY | Specific | Sends the graph for deformation | Tiltmeter IRIO |
Figure 7.
Querying data from various stations in real time via the Telegram instant messaging application. First, the status of the stations is requested by the general command HELP and then the station to be accessed—in this case GRAJ—is specified. After receiving this command, the station will reply with the rest of the available commands supported by the station. In this example, the graph of gravity and humidity for the previous ten days has been requested.
Figure 7.
Querying data from various stations in real time via the Telegram instant messaging application. First, the status of the stations is requested by the general command HELP and then the station to be accessed—in this case GRAJ—is specified. After receiving this command, the station will reply with the rest of the available commands supported by the station. In this example, the graph of gravity and humidity for the previous ten days has been requested.
The software for the image monitoring system works in a similar way to other acquisition systems, with a number of programs being executed by
cron and others running on system start-up (
Table 14).
Table 14.
Imaging-monitoring system software.
Table 14.
Imaging-monitoring system software.
Software/Script | Execution Every |
---|
timelapse.c | 1 min (default) |
battery.c | 1 min |
bat_graph.sh | 1 min |
video.sh | Once every day |
synch.sh | 1 min |
buffer.sh | Once every day |
message.lua | Continuously |
index.php | Continuously |
The
timelapse.c application captures images: when running, it records the current UTC time, captures the image, and prints the time on it. Next, it saves the image to a USB external memory, before reducing its size and copying it to the route of the website (
Figure 8).
Figure 8.
Flowchart of the timelapse.c application.
Figure 8.
Flowchart of the timelapse.c application.
The sync.sh script saves images to a remote server, as explained above.
The buffer.sh script, executed once a day, verifies that the size occupied on disk by the images does not exceed the memory capacity. It deletes old images, thereby establishing a circular image buffer.
The video.sh script, executed once a day, records a video montage of all the images from the current day and stores it in the memory. It makes two videos, one of low quality to be downloaded via mobile devices and the other of high quality that can be downloaded from the website.
Given that the system is based on the diagram depicted in
Figure 1, one of the analog channels is used to control the system’s battery. This control is carried out by
battery.c software that continuously acquires and stores the battery value in the external memory.
The
bat_graph.sh script creates a graphical representation of the data acquired for the battery and backs it up to the route of the website, following the flowchart illustrated in
Figure 2B.
The configuration of the system and other station information is accessed via a website developed expressly for this purpose (
Figure 9). The sections that have to be configured via this website are as follows: station name; image shooting rate; buffer size of storage; server address and port; name of folder on the remote computer if the backup is activated; and the geographical location of the station. In addition, the information about the station provided on the website contains the following: previous image taken by the camera; a chart with the evolution of the battery voltage over the previous six days; external memory capacity; percentage of this memory used; and current battery voltage. As well, the high-resolution images and the videos generated can be downloaded from the website.
Figure 9.
Left-hand side: the system configuration; center: the most recent picture of Teide Volcano (Tenerife) taken from a distance of approximately 4 Km and a graph of the evolution of the battery; right-hand side: information about the system, as well as the option for downloading images using a calendar.
Figure 9.
Left-hand side: the system configuration; center: the most recent picture of Teide Volcano (Tenerife) taken from a distance of approximately 4 Km and a graph of the evolution of the battery; right-hand side: information about the system, as well as the option for downloading images using a calendar.
The images are taken at programmable time intervals of 1–59 min. If desired, they can be sent to a remote computer or downloaded from the website. At the same time, the system acquires and draws a graph with the battery voltage for every minute and updates the information regarding the device’s capacity. The system can operate in three different ways: taking pictures continuously during the day and night, using a light sensor in order to detect the daylight, and using a sunrise/sunset table, which is the default mode. By the end of the day it generates a time-lapse which can be downloaded from the website.
In an application such as this, which monitors a site via images, instant messaging software plays a very useful role since, via the use of commands, the latest image or a video consisting of all the pictures taken during the day can be downloaded as a very easy and quick daily review of all the images (
Figure 10).
Figure 10.
Querying the seasons via the Telegram instant messaging software using a smartphone. The last picture taken by the CRAJI command is sent and the battery status is checked with CRAJB command requests.
Figure 10.
Querying the seasons via the Telegram instant messaging software using a smartphone. The last picture taken by the CRAJI command is sent and the battery status is checked with CRAJB command requests.