Modernizing GNSS data acquisition, pre-processing, and distribution at volcanological observatories

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 $\mathrm{3}/\mathrm{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 (for RINEX Modification), is a lightweight utility for editing RINEX headers, renaming files, and enriching metadata. It replaces critical teqc functionalities while supporting modern RINEX $\mathrm{3}/\mathrm{4}$ conventions, long-file naming schemes, and direct sitelog integration. The second, autorino (for 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.

1 GNSS at the IPGP's Volcanological and Seismological Observatories

1.1 Introduction: deformation measurements for operational volcanological monitoring

The Institut de physique du globe de Paris (Paris' Institute of Earth Physics, IPGP) is responsible for the operational monitoring of France's four active volcanoes, all located overseas, as well as their regional seismicity, to properly issue upstream warnings to the local and national authorities. The observations of IPGP observatories are also used by Tsunami Service Providers in their respective area. For this matter, three Observatoires volcanologiques et sismologiques (Volcanological and Seismological Observatories, OVS) and one monitoring network are located on four different overseas islands:

• the Observatoire volcanologique du Piton de la Fournaise (Piton de la Fournaise Volcanological Observatory, OVPF), which is responsible for Piton de la Fournaise in La Réunion in the Indian Ocean,

• the Observatoire volcanologique et sismologique de Guadeloupe (Guadeloupe Volcanological and Seismological Observatory, OVSG), responsible for La Soufrière de Guadeloupe in the Lesser Antilles,

• the Observatoire volcanologique et sismologique de Martinique (Martinique Volcanological and Seismological Observatory, OVSM), which is responsible for Montagne Pelée in Martinique, also in the Lesser Antilles,

• the OVPF is also responsible of the maintenance and daily monitoring operation of the Réseau de surveillance volcanologique et sismologique de Mayotte (Mayotte Volcanological and Seismological Monitoring Network, REVOSIMA), to monitor Fani Maoré, an underwater volcano off the coast of Mayotte and the associated active volcanic area, North of the Mozambique Channel.

Secular surface deformation measurements are a key component of volcanic monitoring, offering essential insights into in-depth processes such as the inflation – deflation of magmatic reservoirs, magma ascent through the plumbing system, hydrothermal activity, and flank instability (Cayol et al., 2022). The value of GNSS for these purposes was quickly recognized by the volcanology community (Dzurisin, 2000; Poland et al., 2006).

At Piton de la Fournaise, GNSS observations have proven particularly effective. For instance, they revealed detailed magma ascent from deep reservoirs to shallow depths before the June 2014 eruption, followed by sustained deep-to-shallow magma transfer that fed multiple eruptions in 2015 (Peltier et al., 2016; Beauducel et al., 2020b).

In Mayotte, during the 2018 seismo-volcanic crisis, GNSS stations on the island captured the decimeter-scale deformation caused by the deflation of a deep reservoir, responsible for the formation of the previously unknown submarine volcano Fani Maoré (Lemoine et al., 2020; Peltier et al., 2023).

In the Caribbean, GNSS-derived deformation is integrated with seismic, geochemical, and other observations to anticipate volcanic eruptions of Soufrière de Guadeloupe and Montagne Pelée, currently in a state of unrest (Fontaine et al., 2025; Moretti et al., 2020; Pantobe et al., 2026). Beyond volcano’s edifices, stations located throughout the islands of Martinique, Guadeloupe and Saint-Barthélemy also monitor seismic loading and release of the active faults associated to the Lesser Antilles subduction zone (Sakic et al., 2020; Van Rijsingen et al., 2021, 2022).

Beyond the main volcanological and seismotectonic monitoring purposes for which the stations were installed, GNSS data from OVS have other applications, such as estimating the total water vapor content in the atmosphere (Bock et al., 2021) or detecting tsunami generation through observations of ionospheric perturbations (Ravanelli et al., 2021, 2024).

1.2 OVS's GNSS networks

Nowadays, the OVS's permanent GNSS stations are divided into five networks. Four of them correspond to the four main islands where volcanoes are monitored. These are:

• GL: OVSG's GNSS network in the Guadeloupe Archipelago, including La Désirade, Marie-Galante, and Les Saintes Islands, plus a station located in St Barthélemy (IPGP, 2021a, Fig. 1).

• MQ: OVSM's GNSS network in Martinique (IPGP, 2021b, Fig. 2),

• PF: OVPF's GNSS network in La Réunion (IPGP, 2021c, Fig. 3),

• QM: IPGP's GNSS stations components of REVOSIMA in Mayotte and Grande Glorieuse (REVOSIMA et al., 2021, Fig. 4).

A fifth supplementary network, WI (IPGP, 2008), comprises GNSS stations in the Antilles that also belong to GL and MQ, located outside the volcanically active areas, to monitor the subduction context. These networks have been named in the same manner as their seismological counterparts, following the FDSN's two-character convention (FDSN, 2025).

Figure 1 Map of the GL GNSS Network, managed by the OVSG at the Guadeloupe Archipelago island. (a) Guadeloupe archipelago view & (b) Soufrière de Guadeloupe volcano's vicinity. For the sake of readability, the first four characters only of the station codes are represented. SBL000BLM located in St Bartélémy is not represented.

Figure 2 Map of the MQ GNSS Network, managed by the OVSM at Martinique island. (a) Martinique Island view & (b) Montagne Pelée volcano's vicinity. For the sake of readability, the first four characters only of the station codes are represented.

Figure 3 Maps of the PF GNSS Network, managed by the OVPF at La Réunion. (a) South-East of La Réunion Island view & (b) Piton de la Fournaise volcano's vicinity (Enclos Fouqué caldera). For the sake of readability, the first four characters only of the station codes are represented.

Figure 4 Map of the QM GNSS Network, the IPGP's component of the REVOSIMA. For the sake of readability, the first four characters only of the station codes are represented. GLOR00ATF located in Grande Glorieuse is not represented.

The first permanent GPS stations of the OVS in the Caribbean were HOUZ00GLP and SOUF00GLP, deployed in 2000 at the Observatory's main site on Houëlmont Hill and at the summit of La Soufrière, respectively. They were followed by FSDC00MTQ in Martinique in January 2003, installed at the historical Morne des Cadets Observatory. At Piton de la Fournaise, the long-term GNSS network was implemented in 2004, with the permanent equipment of repetition point BORG00REU (Staudacher and Peltier, 2016). Since then, the number of stations deployed has continued to increase, as illustrated in Fig. 6. Consequently, the total number of archived RINEX files has increased quadratically, reaching more than 300 000 in 2025 (Fig. 5). The first GLONASS-compatible receivers were deployed in 2008, and the first real multi-GNSS capabilities began in 2016 with the installation of the first Galileo-compatible receivers (Fig. 7). The latest upgrade of the OVPF's PF network in 2024 enabled the deployment of latest-generation receivers that are fully multi-GNSS compatible, including BeiDou and QZSS.

Currently (mid-2025), the OVS directly operates 71 permanent stations: 27 belong to PF network, 25 to GL, 15 to MQ and 4 to QM. Depending on the sites and requirements, the three OVS also use GNSS data produced by scientific and institutional partners, such as the Institut national de l'information géographique et forestière (IGN) or the Maïdo's Observatoire de physique de l'atmosphère de La Réunion; or commercial providers like Exagone/Teria (https://www.reseau-teria.com, last access: 12 March 2026) or Précision Topo/Lél@ (https://precision-topo.com, last access: 12 March 2026).

In parallel with continuous GNSS observations, repetition campaigns are conducted to spatially densify deformation measurements by surveying standardized sealed stainless steel rods. On the two Caribbean islands, these measurements are generally performed on an annual basis (de Chabalier et al., 2024). For the 2024 campaign, for instance, 17 points in Martinique and 40 points in Guadeloupe were surveyed for at least three days. At Piton de la Fournaise, 70 points are measured using 3 min rapid-static surveys, routinely every six months or more frequently during ongoing eruptions (Staudacher and Peltier, 2016; Peltier et al., 2026).

The OVS operate a very diverse pool of instruments in terms of manufacturers and models, as illustrated in Table 1. In addition to the Trimble, Septentrio, and Leica equipments currently in use, OVS has also historically used Topcon and Ashtech equipments.

The means of data transmission are also varied: even though everything is now based on an IP protocol, data can be transmitted via direct Ethernet link (very low latency, very high bandwidth, very short range), WiFi links (low latency, high bandwidth, short range), 3G $/$ 4G cellular networks (variable latency, variable bandwidth, medium range, both highly dependent on the cellular network), terrestrial internet connections (low latency, variable bandwidth, long range, but dependent on infrastructure), or VSAT satellite links (high latency, very limited bandwidth, global range) (Anglade et al., 2015). Table 2 summarizes the different transmission means.

Figure 5 Cumulative sum of daily RINEX files produced by the OVS distributed among their four networks, from 2000 to mid-2025.

Figure 6 Cumulative sum over time of the number of GNSS stations installed among the OVS's four networks, from 2000 to mid-2025.

Figure 7 Proportion over time of the different GNSS systems recorded by OVS's GNSS receivers, from 2000 to mid-2025.

Table 1 GNSS receivers manufacturers and models currently operated by the OVS.

Table 2 Data transmission means for GNSS data retrieval operated by the OVS.

2 Evolutions in GNSS data

2.1 The RINEX format

With the advent of the space era, geodetic observations have been conducted on a global scale. Geodesists, who now collaborate from multiple institutions and universities scattered around the world, needed to share their observations. This gradually became more widespread with the arrival of space-based positioning systems in the 1980s, primarily the United States of America's (USA) Global Positioning System (GPS). At the end of this decade, the geodetic community, particularly its scientific stakeholders, developed and adopted a common data exchange standard to ensure compatibility between different brands of receivers and processing software. This standard, the Receiver Independent Exchange format (RINEX) was created by the Astronomical Institute of the University of Bern to support the large-scale EUREF-89 campaign (Gurtner and Mader, 1990). This international collaboration was one of the largest at that time, as it involved more than 60 GPS receivers from four different manufacturers. Following this campaign, RINEX was recommended as an international data exchange format during a dedicated workshop on GPS Exchange Formats during the Fifth International Geodetic Symposium on Satellite Systems in March 1989, selected among three other formats (Gurtner, 1994).

The RINEX consists of an ASCII-based standard designed to store and exchange raw GPS data, such as pseudorange, carrier-phase, Doppler, signal strength, navigation messages, and meteorological measurements. Its strength lies in the fact that it is a plain-text, human-readable file format that is independent of the receiver brand, thus greatly facilitating the exchange and processing of stored data. In this sense, it meets almost all of the optimal qualities, except for the minimum file size criterion, which could certainly have been met by selecting a binary format, but which would have been at the expense of the first two requirements, portability and readability, set out by the 1989's Symposium workshop (Gurtner, 1994).

However, since the late 1980s and the EUREF-89 campaign, the satellite positioning environment has changed considerably. While Russia modernized the Soviet Union's GLONASS system in the 2000s (Dach et al., 2011), several new global navigation satellite systems have reached full operational capability over the last ten years. Among these, the European Union's Galileo constellation achieved full operational status in 2016 (ESA, 2016), followed by China's BeiDou system in 2018 (CSNO, 2018). Additionally, USA launched the first satellite of its next-generation GPS Block III series in 2018 (USAF, 2018), marking a major milestone in the modernization of its Global Positioning System. The Indian NAVIC and Japanese QZSS regional systems reinforce coverage in the areas concerned since 2017 and 2018 respectively (Department of Space, 2017; National Space Policy Secretariat, 2018), and several Satellite-Based Augmentation Systems (SBAS) complete the picture by broadcasting signals compatible with GNSS. Thus, the navigation and geodesy community has gradually transitioned to a multi-GNSS environment.

As a result of these advances, the number of available satellite observations has increased substantially. While an average of six satellites were visible in the early 1990s (Dixon, 1991), a multi-GNSS station can now observe more than sixty. In addition to numerous supplementary satellites, the new systems also provide new frequencies (for instance, Galileo introduced the L5 frequency) which themselves come with several new signals, like the AltBOC (Galileo, 2021; Lestarquit et al., 2008).

To support these changes in scale, four versions of RINEX have been developed and published since the early years: (Janssen, 2024)

• The original version 1, which was presented and accepted in 1989 (see above).

• Version 2 was presented at the Second International Symposium of Precise Positioning with the Global Positioning System in 1990. It mainly added the possibility of including tracking data from different satellite systems (i.e. GLONASS, SBAS) with a dedicated one-letter code. Over time, it was upgraded through several sub-versions, culminating in the release of version 2.11 in 2007 (Gurtner and Estey, 2007).

• Version 3 was released in 2007. It introduces substantial changes to fully support multi-GNSS without a theoretical limit on the number of satellites. It identifies the tracking modes of each observation by introducing three-character codes (instead of two for the RINEX 2). In this sense, version 3 revives a statement already made a decade earlier by Gurtner (1994): It is important to define precisely the meanings of the observables in RINEX observation files so that they can be properly interpreted by the processing software. Version 3 also introduced a new standardized long file naming convention, intended to provide a more intuitive description of the dataset directly within the filename. The traditional 4-character station identifier was expanded to 9 characters, in particular to allow the inclusion of a country ISO code and thereby reduce ambiguities from stations sharing the same name worldwide. Over time, it was upgraded via several sub-versions, until version 3.05 (IGS/RTCM, 2020).

• Version 4 was released in 2021, mainly to support the modern multi-GNSS navigation messages. However, the RINEX observation files have not undergone any major changes compared to version 3, apart from a few additions to the header fields to enhance the metadata record possibilities. It has since been updated to version 4.02 in 2024 (IGS/RTCM, 2024).

As we have illustrated, the constant improvements of the multi-GNSS environment have rendered the legacy of RINEX 2 format, which has been in use since 1993, increasingly obsolete and insufficient for handling modern GNSS data requirements, despite recurring enhancements up to version 2.11. However, many local GNSS networks struggle to integrate these advances due to heterogeneous receiver hardware and outdated workflows.

2.2 teqc's end of life

Additionally, the year 2019 marked another significant turning point for the GNSS community: the end of development and support for teqc utility developed by UNAVCO (EarthScope since 2023) (Estey and Meertens, 1999). For decades, teqc (for translating, editing, and quality checking) had been considered the “Swiss army knife” of GNSS data processing: an indispensable, multi-purpose, and reliable tool for three different but complementary needs in GNSS data pre-processing: editing (splitting and splicing), quality control, and raw-to-RINEX conversion (or translation in teqc vocabulary). Its universality and ease of use led to its widespread adoption throughout the GNSS community over more than two decades. However, teqc was fundamentally designed to read/write RINEX version 2 at low-level, preventing its transition to version $\mathrm{3}/\mathrm{4}$. The need to have access to often confidential information from manufacturers to translate raw data, and above all, the retirement of its main developer, ultimately led to the software's demise (UNAVCO, 2016).

With its discontinuation, no single tool has fully matched its wide range of functionality. Very efficient alternatives exist for data editing and quality control, like GFZRNX (Nischan, 2016), Anubis (Vaclavovic and Dousa, 2015) or RINGO (Kawamoto et al., 2023). But for conversion, users have increasingly had to rely on OEM-provided converters (see Table 3) to produce RINEX files, particularly for new-generation receivers offering full multi-GNSS support. However, the final version of teqc remains central to many pre-processing workflows, but its legacy status has also slowed the migration to RINEX $\mathrm{3}/\mathrm{4}$. As a result, RINEX 2 continues to be widely used, limiting access to modern GNSS capabilities.

The abandonment of teqc could be perceived as a step backwards. However, returning to the use of manufacturer converters validates more than ever the statement issued 35 years ago by Gurtner and Mader (1990): The ideal case would be if the receiver manufacturers themselves developed the necessary software to translate the raw data of their receivers into RINEX because probably nobody else knows their receiver better.

3 Motivation for the present work

This evolution from RINEX 2 to RINEX $\mathrm{3}/\mathrm{4}$ has been smoothly managed by the space geodesy community over the 2010s decade, for several reasons: operators of global GNSS station networks intended for terrestrial reference system definition and for precise orbit determination are often homogeneous networks operating hardware from the same manufacturer, or even the same model. Moreover, most of these operators are federated within the International GNSS Service (IGS, Johnston et al., 2017). This international scientific association is one of the main providers of standardization within the GNSS community, or at least for its geodetic applications (Noll et al., 2009). Its efficient organization allows for clearly defined agendas with milestones for the adoption of new standards by its members (IGS Central Bureau, 2021).

However, this transition remains much more challenging for operators of regional and/or campaign-based GNSS networks. Indeed, the IGS mainly brings together players in space geodesy in its global dimension, such as state space agencies or national mapping agencies. In contrast, the personnel operating local GNSS networks belong to universities and research institutes with a more local footprint and are less aware of IGS decisions and the new standards that result from them. Technically, the equipment used within these networks is also often very heterogeneous, both in terms of manufacturers and generations of receivers.

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

Nevertheless, the OVS constitute a good example of the lasting legacy of teqc and the RINEX 2 standard. Over the past two decades, the three OVS have implemented very different approaches to downloading and pre-processing their GNSS data, as well as implementing them using different tools, despite the staff belonging to the same organization. Despite attempts to exchange methods and associated codes, geographical distance, time zone difference between the observatories and Paris and lack of dedicated human resources have led to this situation. This same geographical distance has also resulted in limited consideration of the new standards issued by the IGS, in particular by retaining infrastructure based on the RINEX 2 format, even though new multi-GNSS-compatible receivers were gradually being installed in the field.

As shown in Table 1, the wide variety of devices employed across the OVS introduces an additional layer of complexity, resulting in some observatories using hardware from certain manufacturers while others do not. This diversity necessitates a versatile and flexible approach if we want a unified pre-processing workflow.

To overcome all these limitations, we have developed two new tools, presented hereafter: The first is rinexmod, a RINEX header editing utility that substitutes this specific teqc functionality. The second tool is autorino, which is designed as an integrated workflow for automated download and conversion of raw data from the main manufacturers’ receivers based on their respective official conversion utilities. Together, these tools aim to facilitate the transition toward modern RINEX standards for heterogeneous regional and national GNSS networks, and to provide polyvalent acquisition and pre-processing solutions for a wide range of scientific GNSS infrastructures.

4 rinexmod: RINEX header editing and file management

rinexmod (for RINEX Modification) is a command-line utility developed in Python 3 designed to batch modify the headers of GNSS data files in RINEX format and rename them according to standardized conventions. It replaces a key functionality of teqc while adding support for modern GNSS formats and direct metadata handling. This tool ensures compatibility with recent GNSS workflows and the highest quality of embedded metadata.

4.1 rinexmod's main functionalities

4.1.1 State-of-the-art and legacy version handling

rinexmod natively supports the specifications of the latest RINEX 4 format and its close predecessor RINEX 3, as well as those of the older RINEX 2 format.

4.1.2 Flexible input processing

The program accepts multiple possible inputs, including individual RINEX files, batch file lists, and can browse directory structures if a folder is given as input. rinexmod directly integrates file management features, eliminating the need for scriptable overlays, which are usually required for this type of metadata editing operation.

4.1.3 Multi-source metadata integration

Metadata can be sourced from standardized and widespread IGS sitelogs, but also from GAMIT's station.info files, which is also a de facto standard for recording GNSS data. The user can also manually specify custom values using keywords specified as arguments.

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

4.1.5 Compression management

rinexmod natively supports various compression formats for both input and output: gzip, recommended as IGS standard (Romero and Ruddick, 2020) or Unix compress for legacy purposes, with integrated RINEX-specific Hatanaka compression (Hatanaka, 2008) or not. Uncompressed input or output is also possible.

4.1.6 Filename management

rinexmod can manage RINEX output file names based on data content, i.e., the definition of the start date, file period, and data frequency. Alternatively, these values can also be manually forced. rinexmod can manage the legacy short naming convention and the long name convention introduced by the RINEX 3 norm to name the modded output RINEXs. Regarding the long-naming convention, three filename modes are implemented to accommodate different operational requirements:

• Basic mode: a simple mode to apply a strict filename period (01H or 01D), being compatible with the IGS conventions.
  e.g.: FNG000GLP_R_20242220000_01D_ 30S_MO.crx.gz

• Flexible mode: the filename period is tolerant and corresponds to the actual data content, but then can be odd (e.g. 07H, 14H...). The filename start time is rounded to the hour.
  e.g.: FNG000GLP_R_20242221800_06H_ 30S_MO.crx.gz

• Exact mode: the filename start time is strictly the one of the first epoch in the RINEX. Useful for specific cases, such as splicing.
  e.g.: FNG000GLP_R_20242221829_06H_ 30S_MO.crx.gz

4.2 rinexmod's workflow

Figure 8 illustrates the rinexmod processing workflow for RINEX files. Raw RINEX datasets are ingested and converted into RinexFile objects. In parallel, metadata are provided from external sources such as sitelog(s) or GAMIT’s station.info & apriori file, yielding MetaData objects. A metadata selection step then ensures that each RinexFile is correctly linked to the corresponding MetaData for the appropriate station and epoch. The RinexFile objects are then updated based on their associated MetaData and/or user-defined manual keywords. Finally, the processed RinexFile objects proceed to the export stage, where they are renamed and compressed, producing fully “modded” RINEX outputs compliant with the external metadata.

Figure 8 Standard workflow for rinexmod.

5 autorino: GNSS data acquisition and Pre-processing

The autorino package (for Assisted Unloading, Treatment & Organisation of RINex Observations) is designed for automated download and conversion of GNSS raw data from the main manufacturers’ receivers (Leica, Septentrio, Topcon, Trimble, and the brand-independent BINEX) based on their respective official conversion utilities. It is developed in Python 3, relying on the geodezyx toolbox (Sakic et al., 2019, 2026) for elementary operations. A special focus has been put on conversion to RINEX $\mathrm{3}/\mathrm{4}$ to get rid of the outdated legacy RINEX 2 standard and near real-time capability (download frequency up to 5 min).

autorino aims to perform the following four tasks:

• download GNSS raw data from remote GNSS receivers.

• convert GNSS raw data to RINEX $\mathrm{3}/\mathrm{4}$ format using official conversion utilities from the main GNSS manufacturers.

• handle RINEX files (e.g., merging, splitting, splicing, etc.) using dedicated utilities.

• edit metadata of RINEX files (e.g., modifying header metadata, renaming filenames, editing comments, etc.) based on the rinexmod tool described above.

5.1 Multi-step workflow

autorino operates through a structured workflow composed of multiple steps. These steps are typically executed sequentially but can also be run independently. Each step may be skipped temporarily or permanently, depending on the user's requirements. 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. The steps currently implemented are described below and a standard workflow is represented in Fig. 9.

Figure 9 Standard workflow for autorino.

5.1.1 Download step

The download step handles remote data acquisition with configurable connection parameters. It supports two file discovery modes:

• Ask mode: uses interactive FTP directory exploration to locate and retrieve the desired remote files.

• Guess mode: generates predicted remote file paths and tests their existence in the receiver's file tree. This mode is primarily intended for HTTP downloads, where directory listings are not readily available.

Additional features include timeout controls, retry mechanisms, and preliminary network ping checks to enhance reliability. Local file validation and corruption detection are performed after retrieval to ensure data integrity.

5.1.2 Convert step

The convert step transforms manufacturer-specific raw GNSS files into standardized RINEX format. An automatic detection mechanism selects the appropriate converter based on input file characteristics, while manual override is also possible. autorino functions as a unified interface for GNSS data conversion, integrating a suite of external tools and supporting most major receiver manufacturers (Table 3).

Table 3 Raw file types, with associated manufacturers and converters supported by autorino.

Template-based input/output directory rules ensure consistent file organization. After conversion, rinexmod is automatically invoked to update RINEX headers and filenames based on external metadata sources (e.g., sitelogs, site configuration files). Since autorino assumes that header metadata may be unreliable, these values are always updated. For certain fields (receiver serial number, firmware version), discrepancies between the RINEX content and external metadata trigger warnings – indicating that the external metadata source should be corrected – though the header is still overwritten.

5.1.3 Splice step

The splice step merges multiple RINEX files across time boundaries to produce a single, continuous dataset. A gap-detection algorithm ensures optimal continuity and completeness, which is particularly useful for Leica receivers that create fragmented files after interruptions in data collection.

Splicing (and splitting) requires an external RINEX manipulation tool; autorino supports GFZRNX and Converto (IGN-SGM). Following splicing, rinexmod is again executed to validate and update metadata.

5.1.4 Split step

The split step is the inverse of splicing: it divides continuous RINEX files into smaller, defined time segments. Like the splice step, it relies on an external tool (GFZRNX or Converto), and it triggers an automatic rinexmod metadata update.

5.1.5 Modify step

The modify step provides a stand-alone RINEX header and filename update via rinexmod. This is useful for tasks such as downgrading a long name to the legacy short name convention – sometimes necessary for software like GAMIT, which supports RINEX $\mathrm{3}/\mathrm{4}$ but not the long name convention. While not recommended in general, this option ensures compatibility in legacy workflows.

5.2 Configuration files

autorino relies on configuration files structured in YAML format (YAML Language Development Team, 2021). They encapsulate all necessary parameters to perform the desired workflow (i.e. a set of steps) operations. The details of a configuration file are provided in the supplementary materials. The nature of YAML leads to configuration files being built in different sections:

5.2.1 Environment section

It centralizes the definition of external tool paths required for RINEX conversion and manipulation, i.e. the GNSS converter binaries. General environment settings like logging verbosity, default software preferences are specified here.

5.2.2 Station section

It is the most important in the configuration file since it defines all site-specific metadata and device parameters required for automated GNSS data preprocessing. It contains several subsections:

• Site: It contains the full site name, its 9-character site ID, the DOMES number, and the station's geocentric coordinates.

• Device: It specifies whether to extract device attributes from an external sitelog or use the values provided directly (if no sitelog is available for instance). It details the antenna type & serial number, antenna eccentricity, receiver type & serial number, and firmware version. These parameters are used to rewrite the RINEX header once the conversion is done.

• Access: It defines how the system connects to the station to retrieve raw data, including protocol (e.g., FTP), network address, authentication credentials…. The concept of “datalink” is also introduced. This is a free keyword that groups together all stations that communicate using the same technology (same VSAT link, same WiFi network, etc.). Any simultaneous downloads from the same datalink are temporarily blocked in order to limit them to one at a time, thereby saving bandwidth and avoiding download failures.

• Sessions: The configuration enables the definition of multiple, independently parameterized data processing sessions. Each session specifies temporal parameters to which the step’s actions must apply (epoch ranges and periods) and a hierarchical set of workflow steps detailed above.

5.2.3 Include section

It provides a mechanism to reference and load additional configuration files into the current one. This feature is useful for modularizing configuration and reusing common settings across different configuration files. Typically, for sites that are equipped with the same receiver models, use the same communication protocols or internal file tree structures....

Thus, with the “include” philosophy, one can distinguish three kinds of configuration files:

• main: general settings regarding autorino's environment (converters paths, etc.) and GNSS network definition: name, sitelog path, etc.

• site-specific: IP addresses, site name, and code, login & password, etc.

• profile: common settings for a group of sites (same manufacturer, same data structure, same data transfer protocol, etc.). A site can be part of several profiles.

5.3 Calling autorino for final user

For the user, autorino can be easily called up in the command line interface through three main programs:

autorino_cfgfile_run utility provides a command-line interface for orchestrating the automated processing of the autorino configuration files. It accepts parameters specifying a single configuration file as input or directories containing several. The user can customize epoch ranges, site and step selection or exclusion. Upon invocation, autorino_cfgfile_run parses the provided configuration(s), filters sites and processing steps according to user input, and executes the specified workflow steps (e.g., download, convert, split, splice, modify) for each relevant site and epoch.

autorino_convert_rnx provides standardized conversion capabilities for heterogeneous GNSS raw data formats. It constitutes the command-line interface for the convert step described above. Users can supply GNSS raw files as listed in Table 3, with the tool performing automatic format detection and backend conversion using the appropriate manufacturer-specific converter. The output RINEX destination can be customized, and the tool also offers the option to archive the raw files in a properly structured archive too. In that sense, it can serve as an effective substitute for teqc's translation functionalities, with the added benefit of automated archiving.

autorino_check_rnx is an auxiliary tool designed to perform inventory and completeness checks on RINEX files generated by autorino. It scans a directory over a specified date range and records which expected daily files are present or missing. For the existing RINEX files, it compiles a summary of their completeness ratio (recorded$/$expected epochs) in a comprehensive table. Optionally, if an output folder is specified, the tool can also save the tables, generate basic statistics, and produce a quick visualization plot.

The synopses of these functions are provided in the Supplement.

5.4 Simple use case example

As an illustration, a basic download-and-convert workflow for station ENCG00REU can be initiated with the following command:

autorino_cfgfile_run -c $AUTORINO_CFG/
sites/autorino -sp download,convert
-si ENCG00REU -ds '2025-12-31' -de
'10 days ago'

The main options used to control the workflow are:

• -si, which specifies the station name to be searched in the configuration directory provided via the -c option;

• -sp, which defines the desired processing steps (download and convert);

• -ds and -de, which define the start and end dates of the processing period. Dates may be specified either in absolute or relative form.

The logs generated for the two steps executed by this example command are provided in the supplementary materials.

6 New GNSS data acquisition and distribution pipeline

The GNSS data acquisition, preprocessing, and distribution pipeline has been completely redesigned, with autorino and rinexmod now forming its core components. The complete pipeline, illustrated in Fig. 10, can be divided into four main stages:

1. Direct acquisition and conversion of raw data at the three observatories.

2. Centralization of raw and RINEX data in Paris.

3. Distribution of data to external users via the IPGP Data Center.

4. Transversal integration of the Metadata

Figure 10 General pipeline for the acquisition, integration and distribution of GNSS Data for the IPGP's OVS.

6.1 On-site observatories acquisition and conversion

autorino was deployed in the Antilles observatories in January 2025. Using the autorino_cfgfile_run command, the acquisition runs daily between 00:15 and 02:15 UTC on the acquisition servers of the respective observatories via crontab. Separate autorino calls are executed independently for each datalink (see Sect.  Access: It defines how the system connects to the station to retrieve raw data, including protocol (e.g., FTP), network address, authentication credentials…. The concept of “datalink” is also introduced. This is a free keyword that groups together all stations that communicate using the same technology (same VSAT link, same WiFi network, etc.). Any simultaneous downloads from the same datalink are temporarily blocked in order to limit them to one at a time, thereby saving bandwidth and avoiding download failures.), ensuring that slowdowns, timeouts, or failures at individual stations do not affect the overall network acquisition. By default, acquisition requests cover the last 10 d, and steps are skipped if the desired output files already exist. Acquired and converted data are stored in the observatory archives, processed with GipsyX (Bertiger et al., 2020) to produce daily station positions (with both rapid and final latency), and analyzed with WebObs to monitor potential volcanic deformation (Beauducel et al., 2020a). A daily autorino_check_rnx call at 06:00 local time checks the network health for the previous 21 d.

At the La Réunion observatory, autorino was deployed in May 2025, with its execution orchestrated via Apache Airflow, an automated workflow management system (Boissier et al., 2024). Airflow runs on a machine separate from the acquisition server where autorino is installed, and it triggers autorino_cfgfile_run through SSH commands. Each step of a workflow is executed independently, enabling fine-grained monitoring of its progress. A set of exit codes returned by autorino_cfgfile_run allows Airflow to determine whether a step completed successfully or encountered warnings or errors. When errors are detected, Airflow can automatically retry the affected step after a configurable delay period, providing more flexible and robust handling of temporary issues.

In case of temporary transmission interruptions, local operators may manually relaunch autorino for specific stations and time span. When telemetry fails but a receiver still records, technical staff can offload data during maintenance visits and reintegrate them into the pipeline using autorino_convert_rnx, which converts and integrates raw and RINEX data into the archives.

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

Table 4 Download statistics for GL, MQ and PF network between 1 July and 31 December 2025. D+n stands for Day +n i.e. the n-th day after the corresponding recorded data. After D+10 metrics reflect manually-forced data download.

6.2 Centralization and backup

A daily synchronization between the observatories' archives and the IPGP site in Paris ensures off-site backup of the data. As soon as data are available, a backup GNSS processing runs for all four networks, also analyzed using WebObs based on GipsyX position solution and more recently with SPOTGINS (Santamaría-Gómez et al., 2025) as an alternative solution. If needed, raw data can also be reconverted in Paris. Synchronized data are then automatically transmitted daily to the IPGP Data Center (IPGP-DC) for archiving and dissemination. A 20-day latency between data recording and distribution has been decided, to allow operators to report changes in equipment in the metadata before data dissemination. Before distribution, a final rinexmod operation is run on the RINEX files to ensure that the latest metadata are included. Manual deliveries may also occur, for example, for annual distribution of certain partner network data, such as from Exagone/Teria.

6.3 Data distribution

The IPGP-DC develops and maintains the VOLOBSIS Information System (http://volobsis.ipgp.fr/, last access: 12 March 2026), to archive and distribute the data acquired by the IPGP's OVS to the national and international scientific communities (Satriano et al., 2016).

For OVS's GNSS data dissemination, a GLASS node was established in 2022 to complete VOLOBSIS capabilities (Fernandes et al., 2022). This node is integrated within EPOS (European Plate Observing System) as part of IPGP's involvement in the TCS-Volcanology framework (Cocco et al., 2022; Bailo et al., 2023). Integration into EPOS allows access to the Data Quality Monitoring Web Portal (https://gnssquality-epos.oma.be, last access: 12 March 2026), enabling long-term GNSS data quality control (Bamahry et al., 2024).

The available datasets for the different networks are:

• In RINEX 3:

  • GL (OVSG, Guadeloupe): from 1 January 2011 (DOY 2011-001).

  • MQ (OVSM, Martinique): from 1 January 2017 (DOY 2017-001).

  • PF (OVPF, La Réunion): from 1 January 2019 (DOY 2019-001).

  • QM (IPGP's component of the REVOSIMA, Mayotte): from 1 January 2022 (DOY 2022-001).

• In RINEX 2 prior to these dates.

These dates correspond to the installation of the first Galileo-compatible receivers for the PF, QM, and MQ networks, as well as a dedicated RAW-to-RINEX 3 re-conversion effort for the GL network. In both cases, a conversion was therefore carried out using the raw data to obtain RINEX 3.

6.4 Transversal metadata integration

To ensure up-to-date station metadata (e.g., hardware changes), the observatories rely directly on the M3G database of EPOS, maintained by the Royal Observatory of Belgium (ORB, Fabian et al., 2021). M3G is a system to upload, validate, and distribute GNSS station metadata such as IGS-style sitelogs. It offers a user-friendly web interface for recording station hardware modifications. On-site observatory operators can thus document changes immediately on the M3G website after on-site interventions.

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. This archive is synchronized with M3G every hour, ensuring rapid updates when modifications occur. At every stage where rinexmod and/or autorino are executed, these locally mirrored sitelogs are used to update the headers of the corresponding RINEX files.

7 Implementation and availability

rinexmod and autorino are implemented in Python 3 and distributed as open-source packages under the GNU General Public License (GPLv3). They have been developed and tested on a Linux environment (Debian or Ubuntu-like). Both are available on the Python Package Index (PyPI) and can be installed with a single command:

pip install autorino
pip install rinexmod

Their source codes are available on freely accessible GitHub repositories:

• https://github.com/IPGP/autorino (last access: 12 March 2026)

• https://github.com/IPGP/rinexmod (last access: 12 March 2026)

The autorino package is fully documented and distributed with practical examples. Its documentation is accessible at: https://ipgp.github.io/autorino (last access: 12 March 2026). More specifically, the installation procedure is described here: https://ipgp.github.io/autorino/installation.html (last access: 12 March 2026).

As mentioned above, OVS's GNSS data are available under Creative Commons Attribution 4.0 license (CC-BY-4.0) on a GLASS node through this VOLOBSIS portal's landing page: http://volobsis.ipgp.fr/data/access-gnss-data (last access: 12 March 2026).

8 Conclusions

The shift to a multi-GNSS environment has redefined both the opportunities and the challenges of geodetic monitoring. For global networks coordinated under the IGS, the adoption of RINEX $\mathrm{3}/\mathrm{4}$ and the phasing out of teqc were absorbed through coordinated strategies, standardized hardware, and centralized expertise. In contrast, regional and campaign-based networks – such as those operated by the IPGP’s volcanological observatories – have faced persistent barriers linked to heterogeneous instrumentation, limited human resources, and geographically isolated operations. These barriers historically resulted in fragmented workflows, heavy reliance on legacy RINEX 2, and limited uptake of modern standards, thereby constraining the scientific and operational potential of the networks.

The rinexmod and autorino tools presented in this work provide practical, open, and sustainable solutions to these challenges. By replacing critical teqc functionalities while fully supporting RINEX $\mathrm{3}/\mathrm{4}$ conventions, rinexmod ensures metadata consistency and compatibility with international standards. Meanwhile, autorino offers a versatile and modular workflow capable of automated raw data acquisition, manufacturer-based conversion, splicing/splitting, and systematic metadata injection – enabling a unified pre-processing chain across diverse receivers and transmission infrastructures. The Python-based development and packaging facilitate their potential integration within containerized environments (e.g., Docker, Kubernetes), enabling potential cloud deployment. The design of both tools emphasizes interoperability, reproducibility, and near real-time capability, which are critical for observatories tasked with continuous volcanic and seismic hazard monitoring.

Operational deployment in La Réunion, Guadeloupe, Martinique, and Mayotte demonstrates that these tools effectively bridge the gap between heterogeneous local infrastructures and the standardized practices required for multi-GNSS geodesy. They not only facilitate robust daily operations (including campaign surveys and near real-time monitoring), but also ensure long-term data quality and archival consistency, thereby enhancing the value of datasets for both hazard response and fundamental geoscience research.

Thus, these tools provide a foundation for scaling regional networks toward greater interoperability with international initiatives such as the IGS or EPOS, while remaining adaptable to local operational constraints. By lowering the technical barriers associated with multi-GNSS adoption, they contribute to a more inclusive and sustainable geodetic ecosystem – one where small and regional networks can fully exploit the capabilities of modern GNSS to monitor Earth processes in near real time.