EARTH SURFACE DYNAMICS SUPPORTING INFORMATION FOR “SHORT COMMUNICATION: MONITORING ROCK FALLS WITH THE RASPBERRY SHAKES”
1Swiss Federal Institute of Technology, Dept. of Earth Sciences, Zurich, 8092, Switzerland
2Free University of Bozen-Bolzano, Facoltà di Scienze e Tecnologie, Italy
Correspondence to: A. Manconi ([email protected])
This supplementary material provides further information on the Raspberry Shake and on its use to monitor rock fall phenomena in a test area adjacent to the Great Aletsch glacier, Swiss Alps.
The Raspberry Shake seismograph is an all-in-one, IoT plug-and-go solution for seismological applications. Developed by OSOP, S.A. in Panamá, the Raspberry Shake integrates the geophone sensors, 24-bit digitizers, period-extension circuits and computer into a single enclosure. The output is digital and the analog-to-digital path is as follows: the analog signal passes from the 4.5 Hz 380-400 Ohm geophones to an analog system where it is amplified and period-extended from the geophone’s natural frequency of 4.5 Hz down to 2 seconds, thus providing improved signal bandwidth at lower frequencies- essential for local, regional and teleseismic earthquake detection. The amplified and improved analog signal is then digitized with a 24-bit analog-to-digitizer (ADC) converter at 800 sps. Later, the signal is downsampled to 200 sps and finally to 100 sps as it passes through a series of anti-aliasing firmware and software routines.
The clip level is +/- 8,388,608 counts (24-bits) and ~22 mm/s peak-to-peak from 0.1 to 10 Hz. The minimum detection threshold is estimated at 0.03 µm/ s RMS from 1 to 20 Hz at 100 sps where the minimum detectable level is considered to be 10 dB above the noise RMS. Dynamic range is the full-scale sinusoid RMS over the noise RMS in dB. The effective bits, or those noise-free bits commonly referred to as “Dynamic range” or “RMS-to-RMS noise”, for the entire sensor, analog and ADC chain is estimated to be 21 bits (126 dB) from 1 to 20 Hz at 100 sps. The instrument self-noise is, therefore, ideal for local, regional and teleseismic earthquake detection. Additional information can be found in the online manual at: https://manual.raspberryshake.org/index.html
As a scientific-grade instrument, the Raspberry Shake is compatible with all standards in earthquake seismology: Data is transmitted in from a native SEEDlink server running on a Debian OS in miniSEED format and can be ingested directly into Antelope, Earlybird, Earthworm, GISMO, ObsPy, SEISAN, SeisComP(3,Pro) and all other mainstream data processing software packages without modification. Instrument response files are provides in dataless, inventory-xml, pz and RESP formats. All station and channel naming follow FDSN guidelines (Link to the SEED manual).
FIGURE S1: Instrumental response of Raspberry Shake model 1D V6s. The -3 dB points that define the digital signal output bandwidth are estimated at 80% of NyQuist, or 40 Hz, and 2 seconds.
FIGURE S2: N(H/L)NM – Nominal (High/Low) Noise Model. M* lines refer to typical energies for local (<10 km) seismic events. Instrument 1, 2 and 3 are Raspberry Shake model 1D V6s.
FIGURE S3. Pictures of the installation sites RS-1 and RS-2
FIGURE S4. Pictures of the installation sites RS-3. Left: Picture of the Moosfluh cable car station. The RS is installed below the ground surface (approximate location indicated by the red circle), fixed the concrete platform which is acting as foundation. Right: detail of the RS installation on the concrete platform.
FIGURE S5: Number of rock fall events vs. hour of the day during the time period July-October 2017. This preliminary analysis shows that the majority of the events have occurred over night. Future work aims at detailed analyses of the all dataset as well as correlations with environmental conditions and meteo-climatic triggers to understand the causes of this temporal distribution.
FIGURE S6: Seismic signals associated to the Piz Cengalo rock avalanche (ca. 3 million cubic meters of failed material) occurred more than 100 km away from the monitoring location. (top) Signal at RS-1. (bottom) Signal at RS-2. The station RS-3 did not recorded the signal due to major noise caused by the cable car operations.
FIGURE S7: Seismic signals associated to environmental variables (such as rainfall events), anthropic nature (for example helicopter) and/or of unclear source of the RS-1 and RS-2 stations.
FIGURE S8. Animals may also produce disturbances on seismic records. On the left, a signal classified as unknown source recorded only at the station RS-1. In the same time frame, a mountain goat was caught on camera (red circle right).
21 August 2017, h 18:33 UTC
22 August 2017, h 05:33 UTC
FIGURE S9.1. A Mobotix M25 webcam (5Mpixel resolution) is installed at the same location of RS-1, acquiring pictures every 10 minutes. The use of optical data acquired from the webcam is mainly aimed at validating (during day light, cloud-free conditions) the occurrence of rock fall phenomena when signals are detected in the seismic waveforms. These pictures are relevant to the event recorded on August 21, Figure 4.
02 September 2017, h 17:54 UTC
03 September 2017, h 08:24 UTC
FIGURE S9.2 A Mobotix M25 webcam (5Mpixel resolution) is installed at the same location of RS-1, acquiring pictures every 10 minutes. The use of optical data acquired from the webcam is mainly aimed at validating (during day light, cloud-free conditions) the occurrence of rock fall phenomena when signals are detected in the seismic waveforms. These pictures are relevant to the event recorded on September 2, Figure 4.
19 September 2017, h 16:25 UTC
20 September 2017, h 11:36 UTC
FIGURE S9.3 A Mobotix M25 webcam (5Mpixel resolution) is installed at the same location of RS-1, acquiring pictures every 10 minutes. The use of optical data acquired from the webcam is mainly aimed at validating (during day light, cloud-free conditions) the occurrence of rock fall phenomena when signals are detected in the seismic waveforms. These pictures are relevant to the event recorded on September 19, Figure 4.
TABLE S1. EARTHQUAKE CATALOGUE
|Date and time
|Lat (deg)||Lon (deg)||Depth (km)||Magnitude||Distance (km)|
DETAILS ON NTP PERFORMANCE
Under normal operating circumstances, a Shake will have access to the internet, and thus provide constant access to an NTP server. The local clock is then governed by the NTP client, responsible for maintaining the local clock as close to in-sync with the server time (i.e., real time) as possible, over all time. Connection to the internet can be assumed to not be constant over all time with Cellular connections. That is, it may come and go, where periods of disconnectedness can be either short, long, intermittent or common, with each of these varying over the course of a year. NTP client program is responsible for keeping the Shake system clock in sync with the NTP server. But, it is not necessary for the NTP client to maintain a permanent connection to the internet for it to do its job. Once it’s been up and running for about a week, it determines the average drift on the local clock and will continue to apply adjustments to keep it accurate even in the absence of a connection to an NTP server. And then once a connection is re-established, the clock will be adjusted again absolutely, while the average drift calculation is further refined. This, we assume that the NTP inaccuracy is function of the network outage. Here below, we show the results of ping tests (performed with Smokeping, see details at https://oss.oetiker.ch/smokeping/doc/reading.en.html) to check cellular connection during our period of observation. More general information can be found at: https://manual.raspberryshake.org/ntp.html#ntptiming.