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.
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.