the Creative Commons Attribution 4.0 License.
the Creative Commons Attribution 4.0 License.
Modernizing GNSS Data Acquisition, Pre-Processing, and Distribution at Volcanological Observatories
Abstract. In recent years, the field of geodetic monitoring is undergoing a profound transformation driven by the transition from GPS-only positioning to a fully multi-GNSS environment. With Galileo, BeiDou, and modernized GPS & GLONASS constellations now operational, a wealth of new signals and frequencies provides enhanced opportunities for high-precision positioning and real-time monitoring. However, these advances present challenges: the integration of heterogeneous receivers across local and campaign-based networks, the continued reliance on outdated RINEX 2 workflows, and the discontinuation of the teqc utility in 2019 have all disrupted well proven, long-standing GNSS pre-processing pipelines. While the International GNSS Service (IGS) community has smoothly adopted RINEX 3/4 and alternative pre-processing tools, smaller research-oriented networks have often struggled to keep pace, leaving a gap between available technology and operational monitoring practices.
In this paper, we present two complementary tools designed to address these challenges in the context of volcanological and seismological observatories. The first, rinexmod, is a lightweight utility for editing RINEX headers, renaming files, and enriching metadata. It replaces critical teqc functionalities while supporting modern RINEX 3/4 conventions, long-file naming schemes, and direct sitelog integration. The second, autorino (Assisted Unloading, Treatment and Organization of RINEX Observations), implements a flexible multi-step workflow for automated acquisition of raw GNSS data from heterogeneous receivers and conversion to a common standard RINEX format. By integrating official manufacturer converters, handling file splicing/splitting, and linking directly with rinexmod, it provides a unified pipeline capable of near real-time operation (down to 5-minute intervals). Together, these tools modernize GNSS workflows across networks that are both technically diverse and geographically remote, ensuring interoperability with IGS standards while preserving operational robustness in challenging field conditions.
We illustrate their deployment at the Institut de physique du globe de Paris's volcanological observatories and monitoring networks in Guadeloupe, Martinique, La Réunion, and Mayotte, where they enable continuous monitoring of volcanic and tectonic processes. Beyond local applications, these tools contribute to bridging the gap between global GNSS standards and regional network realities, supporting the long-term sustainability of GNSS-based geo-hazard monitoring.
- Preprint
(2611 KB) - Metadata XML
-
Supplement
(163 KB) - BibTeX
- EndNote
Status: final response (author comments only)
-
RC1: 'Comment on egusphere-2025-5147', Anonymous Referee #1, 05 Dec 2025
-
AC1: 'Reply on RC1', Pierre Sakic, 26 Jan 2026
Dear reviewer,
Thanks a lot for your valuable comments. The answers of the different sections of your review are addressed below.
Introduction and motivation
The general context has been refocused. Thus, we added a new paragraph line 190:
This situation is not specific to the IPGP’s OVS, but is shared by many regional GNSS infrastructures worldwide, including those operated in tectonic, volcanological, or environmental monitoring contexts (e.g. Lee et al., 2025). Comparable challenges have been identified and addressed in other large-scale initiatives such as EarthScope/ex-UNAVCO in North America (Zawacki et al., 2025), homonym GeoNet in Japan (Tsuji et al., 2013, 2017) & New Zealand (Gentle et al., 2016; Hanson et al., 2024), or regional reference networks coordinated within federative frameworks like Geosciences Australia’s one in Australia (Brown et al., 2020), or EUREF in Europe (Bruyninx et al., 2019; Kenyeres et al., 2019).And a new sentence line 209:
Together, these tools aim to facilitate the transition toward modern RINEX standards for heterogeneous regional and national GNSS networks, and to provide polyvalent acquision and pre-processing solutions for a wide range of scientific GNSS infrastructures.Software architecture and implementation
The description of this suggested diagram corresponds to us to the figure Standard workflow for autorino already present (Figure #9).
The YAML configuration files are provided in the supplementary materials.We added a new sentence line 275:
By design, a log for each step is automatically written to a dedicated folder, allowing the operator to subsequently verify that the automated workflow has been executed correctly, or, a contrario, identify any warnings or errors.See also the section Metadata and interoperability which also address this section's comments
Performance evaluation
Indeed such performance information are valuables. We added some statistics in a Table commented in a new paragraph line 405:
Table 4 summarizes performance statistics for raw data downloading between 1 July and 31 December 2025 for the GL and PF networks. The success rate, although above 90%, may seem relatively low at first glance, as ideally we would want it to be very close to 100%. However, it refers exclusively to data availability on Day + 1. This behavior is largely attributable to the harsh power supply and transmission conditions at several stations. Moreover, as noted above, autorino is designed with an automatic re-download mechanism, allowing missing data to be recovered in subsequent days when transmission conditions improve.Metadata and interoperability
We added some precision on line 448:
On all acquisition servers at the observatories and in Paris, a local archive of sitelogs is maintained, in order to keep access to metadata even if the internet connection is lost.And extra paragraph on line 230:
Metadata consistency and traceability
A security mechanism is implemented to verify that the external metadata and the content of the “a priori” header's content before modification are consistent. An equivalence comparison is performed on the receiver's model and serial number values, which in theory should always be identical, to detect any discrepancies. If this is the case, a warning message is issued. To ensure the traceability of metadata written by rinexmod, the sitelog's timestamped name is written as a comment in the RINEX header.Figures and examples
We added a new section Simple use case example (line 366) with a command example, and corresponding logs in the supplementary materials.
Table 3, which partially described software dependencies, supported formats, and platforms, has been completed.
Discussion and outlook
We added the sentence line 480:
The Python-based development and packaging facilitate their potential integration within containerized environments (e.g., Docker, Kubernetes), enabling potential cloud deployment.However, we prefer not to mention the topic of automated quality control or machine-learning-based anomaly detection, which we consider to be far beyond our needs and development capabilities.
Technical corrections
This point has been addressed
Citation: https://doi.org/10.5194/egusphere-2025-5147-AC1 -
AC3: 'Reply on RC1 - Addenum', Pierre Sakic, 28 Jan 2026
We slightly modified the new paragraph line 405 related to statistics:
Table 4 summarizes performance statistics for raw data downloading over the period from 1 July to 31 December 2025 for the GL, MQ and PF networks. Detailed statistics by network and station are presented in the supplementary materials. The Day + 1 success ratio for all stations, although close to or above 80%, may initially appear relatively low, since an ideal value would be near 100%. However, this metric refers exclusively to data availability on Day + 1. It therefore reflects more the harsh weather, power supply, and transmission conditions at several station sites rather than limitations of the acquisition process itself.
As mentioned above, autorino is designed with an automatic re-download mechanism that allows missing data to be recovered in subsequent days. Over the 10-day retry period, the success ratio increases to more than 90%. Only about 7% of the data require manual forced download after this period, typically once transmission conditions have improved.
For the GL network, the very high mean and maximum download times observed over the period are mainly explained by data transmitted via VSAT links, whose transfer rates are often on the order of a few hundred bytes per second. Nevertheless, autorino successfully retrieves the data in the vast majority of cases.
Conversion steps proceed smoothly in almost all situations; the very rare failures are subsequently corrected through manual intervention (e.g., re-downloading data or checking read/write access permissions).Citation: https://doi.org/10.5194/egusphere-2025-5147-AC3
-
AC1: 'Reply on RC1', Pierre Sakic, 26 Jan 2026
-
RC2: 'Comment on egusphere-2025-5147', Giorgi Khazaradze Tsilosani, 16 Dec 2025
I read the article with great pleasure. It was written clearly, well-structured and with an excellent English. The tables, diagrams and figures are also of an excellent quality.
Most importantly, I really appreciated the importance of the developed software, since I myself often find myself in the same position, where old tools (e.g. TEQC) force me to use Rinex 2 files, while the new receivers and needs require Rinex 3 or 4. I believe that many researcher and operators of the ever-growing GNSS networks will find the RINEXMOD and AUTORINO software very usual in their day-to-day work.
In my opinion, the manuscript needs few corrections. The biggest is probably the bibliography style, since the authors have omitted DOIs, which according to the Geoscientific Instrumentation, Methods and Data Systems journal instructions (https://www.geoscientific-instrumentation-methods-and-data-systems.net/submission.html#references) are necessary. Apart from this, there were some minor formatting issues, which I have highlighted in the attached pdf file.
Congratulations to the authors and good luck operating so many stations in such a geographically widely spread area.
-
AC2: 'Reply on RC2', Pierre Sakic, 26 Jan 2026
Thanks a lot for your positive and encouraging feedback. We have corrected the typographical errors you identified, added the relevant web links and citations, and reworded expressions where necessary. The bibliography has been corrected by implementing the correct Copernicus template: the DOIs are now visible.
Regarding the list of networks around line 60, we prefer to maintain the current bullet point format, which we find more suitable given the difference in line length.
The compatibility of converters with Linux has been added to Table 3.
The duration of the rapid-static surveys in La Réunion has been added and the number of points measured has been updated: 70 points over 3 minutes.
Citation: https://doi.org/10.5194/egusphere-2025-5147-AC2
-
AC2: 'Reply on RC2', Pierre Sakic, 26 Jan 2026
Viewed
| HTML | XML | Total | Supplement | BibTeX | EndNote | |
|---|---|---|---|---|---|---|
| 356 | 76 | 33 | 465 | 54 | 18 | 23 |
- HTML: 356
- PDF: 76
- XML: 33
- Total: 465
- Supplement: 54
- BibTeX: 18
- EndNote: 23
Viewed (geographical distribution)
| Country | # | Views | % |
|---|
| Total: | 0 |
| HTML: | 0 |
| PDF: | 0 |
| XML: | 0 |
- 1
General comments
The paper is clearly structured, methodologically transparent, and supported by a solid background describing both the evolution of GNSS formats and the specific operational needs of IPGP networks. The combination of software development, workflow optimization, and integration with open data infrastructures provides a comprehensive overview of a scalable solution for GNSS data management. However, although implementation aspects are clearly presented, the paper would benefit from a more detailed quantitative assessment of system performance, for example, download success rates, latency statistics, or processing throughput before and after implementation. Such indicators would strengthen the demonstration of increased efficiency and operational robustness. Overall, the article fits well within the scope of Geoscientific Instrumentation, Methods and Data Systems (GI) and will be of interest to both operational and research communities.
Specific comments
Introduction and motivation
The introduction clearly establishes the need for modernized GNSS workflows at volcanological observatories. However, it might be beneficial to better highlight the international relevance of these tools beyond the IPGP networks — e.g., how rinexmod and autorino could be applied in other regional or national GNSS infrastructures. The section could briefly mention other similar initiatives (e.g., UNAVCO’s EarthScope Data Services, GeoNet, or EUREF projects) to situate this work within the broader global context.
Software architecture and implementation
The modular design of rinexmod and autorino is well presented. Still, a diagram showing interdependencies between modules and external tools (e.g., manufacturer–specific converters, rinexmod calls, YAML configuration) would improve the readability of the workflow. The description of metadata handling is thorough, but it would help to specify how version control and error logging are managed in long-term operation. These aspects are critical for reproducibility and data provenance in automated systems.
Performance evaluation
The authors describe near real-time operation (5-minute intervals) and daily acquisition tasks but do not provide quantitative validation of performance (e.g., average latency, file success rate, or downtime statistics). Including even a short benchmark table or summary of system reliability would make the results more convincing
Metadata and interoperability
The integration with EPOS’s M3G database and VOLOBSIS/GLASS nodes is a major strength. However, the paper could clarify whether metadata synchronisation is fully automated and if there are fallback mechanisms when M3G or network links are unavailable. It might also be relevant to discuss how rinexmod ensures consistency between header metadata and site log information across updates or firmware changes.
Figures and examples
It would strengthen the paper to include a short practical example of a real conversion pipeline (e.g., from a Trimble receiver raw file to RINEX v3.04 output, with processing time and resulting file naming convention). Adding a table summarizing software dependencies, supported formats, and platforms (Linux, Windows, etc.) would be useful for practitioners.
Discussion and outlook
The conclusion rightly emphasizes interoperability and long-term sustainability. The authors could extend this discussion to potential integration with cloud-based or containerized environments (e.g., Docker, Kubernetes), which are increasingly used in GNSS data processing pipelines. Future work might also explore automated quality control or machine-learning-based anomaly detection within the autorino framework to enhance real-time monitoring capabilities.
Technical corrections
Recommendation and conclusion
The paper successfully integrates methodological rigor with practical implementation, offering reproducible open-source solutions that bridge the gap between local observatory needs and international GNSS standards. The manuscript would benefit from the inclusion of quantitative performance analyses and minor textual refinements, but its overall structure, clarity, and scientific contribution are strong.
I therefore recommend the manuscript for publication after **minor revision**, provided that the authors address the specific and technical comments listed above.