5:15 PM - 6:30 PM
[STT35-P04] Construction of real-time data transfer system for seismic SEED records and time correction for a station with GPS failure
Keywords:seismic observation, seismic interferometry
The real-time data transfer of seismic observation enables us to obtain and analyze seismic data without frequent data acquisition trips. In Japan, WIN format is usually used for transferring data from stations to central servers. This study constructed a real-time data transfer system for IRIS SEED format using REF TEK data recorders, mobile routers, and a central Linux server. The observation project is called BC-DENSE after the Broadband Campaign for Deep Extent of Nankai Slow Earthquakes. In this experiment, we installed 14 stations in 2019 and 2020 in the Shikoku, Kii, and Tokai regions as a part of "Science of Slow Earthquakes" project. We used broadband seismometers, CMG-3T (100 s and 120 s), to record broadband signals of slow earthquakes, especially the very low-frequency earthquakes at a period range of 20-100 s.
Since available data recorders were REF TEK RT130, not famous in Japan, we needed to construct the real-time data transfer system by try and error. We (i) constructed Ubuntu 18.04 LTS virtual central server on the Sakura VPS service (2GB memory and 100 GB storage) with a static IP address, (ii) installed RTP (REF TEK Protocol) software available from REF TEK company to the virtual server, (iii) installed the strongSwan software to the virtual server for IPSec-VPN connection, (iv) set NXR-G100/NL mobile router with a DTI SIM card for a dynamic IP address and IPSec-VPN connection, and (v) set RT130 to connect the virtual server for transferring data in real-time. The data is in the IRIS SEED STEIM2 format. The data size is compressed compared to the STEIM1 format in our environment. For both STEIM1 and STEIM2, any high-speed mobile connection is not required. We use a low-price plan of ~500 yen per month for each station. We needed to set a VPN connection to recover data in the CF card by FTP when the mobile connection is temporarily lost because the RAM of RT130 can only hold 1-2 hour records and the RTP only transfers data on RAM. This data recovery by FTP connection happened several times a month in total for 14 stations except for the case below.
We experienced GPS failure at one station, BC17, in the Shikoku region. In this station, the mobile connection to the data recorder was lost from January 2020 although the connection to mobile router remained. The connection was recovered in September 2020 by rebooting the data recorder by a local electrician. We then found GPS failure from May 2020. In November 2020, we finally recovered all the data by fieldwork, and replaced the GPS antenna, the GPS cable and the mobile antenna. By changing the mobile antenna from FMSP800W-D-2.5M-BPMIMO to two RTA827-5-SMAPs, the response time of ping command from the central server became stable and improved ~3 times (~60 ms for 56 bytes compared to ~200 ms before). There is no data recovery by FTP for this station after the antenna replacement at least for ~2.5 months.
To quantitatively estimate the clock shift during the GPS failure, we prepared records of five nearby BC-series stations operated by the Earthquake Research Institute, the University of Tokyo. We then calculated ambient noise cross-correlation functions (CCFs) between the BC17 station and the five stations every one-day. By cross-correlating the CCFs and the CCFs for the period with GPS acquisition and stacking all the CCFs of CCFs each day, we could measure the one-day time shift with a standard deviation of ~0.01 s. The clock delayed ~0.3 s from May to September, not in a constant speed: slower in the first half and gradually getting faster in the latter half. Although the speed roughly correlates with the temperature of the data recorder, the correspondence is not one-to-one. At the timing of reboot in September, the clock advanced ~62 s. We will correct these time shifts and analyze the records to detect slow earthquakes in the future.
Since available data recorders were REF TEK RT130, not famous in Japan, we needed to construct the real-time data transfer system by try and error. We (i) constructed Ubuntu 18.04 LTS virtual central server on the Sakura VPS service (2GB memory and 100 GB storage) with a static IP address, (ii) installed RTP (REF TEK Protocol) software available from REF TEK company to the virtual server, (iii) installed the strongSwan software to the virtual server for IPSec-VPN connection, (iv) set NXR-G100/NL mobile router with a DTI SIM card for a dynamic IP address and IPSec-VPN connection, and (v) set RT130 to connect the virtual server for transferring data in real-time. The data is in the IRIS SEED STEIM2 format. The data size is compressed compared to the STEIM1 format in our environment. For both STEIM1 and STEIM2, any high-speed mobile connection is not required. We use a low-price plan of ~500 yen per month for each station. We needed to set a VPN connection to recover data in the CF card by FTP when the mobile connection is temporarily lost because the RAM of RT130 can only hold 1-2 hour records and the RTP only transfers data on RAM. This data recovery by FTP connection happened several times a month in total for 14 stations except for the case below.
We experienced GPS failure at one station, BC17, in the Shikoku region. In this station, the mobile connection to the data recorder was lost from January 2020 although the connection to mobile router remained. The connection was recovered in September 2020 by rebooting the data recorder by a local electrician. We then found GPS failure from May 2020. In November 2020, we finally recovered all the data by fieldwork, and replaced the GPS antenna, the GPS cable and the mobile antenna. By changing the mobile antenna from FMSP800W-D-2.5M-BPMIMO to two RTA827-5-SMAPs, the response time of ping command from the central server became stable and improved ~3 times (~60 ms for 56 bytes compared to ~200 ms before). There is no data recovery by FTP for this station after the antenna replacement at least for ~2.5 months.
To quantitatively estimate the clock shift during the GPS failure, we prepared records of five nearby BC-series stations operated by the Earthquake Research Institute, the University of Tokyo. We then calculated ambient noise cross-correlation functions (CCFs) between the BC17 station and the five stations every one-day. By cross-correlating the CCFs and the CCFs for the period with GPS acquisition and stacking all the CCFs of CCFs each day, we could measure the one-day time shift with a standard deviation of ~0.01 s. The clock delayed ~0.3 s from May to September, not in a constant speed: slower in the first half and gradually getting faster in the latter half. Although the speed roughly correlates with the temperature of the data recorder, the correspondence is not one-to-one. At the timing of reboot in September, the clock advanced ~62 s. We will correct these time shifts and analyze the records to detect slow earthquakes in the future.