Challenges in real-time generation of scintillation index maps

: Ionospheric scintillation affects GNSS signals that provide many essential services, making the monitoring of scintillation an important issue. This work presents a system for the real-time acquisition, generation and online dissemination of the S4 scintillation index maps covering Brazil using data from two major networks of GNSS monitoring stations, LISN and INCT. The maps are made using an innovative pre - processing and interpolation scheme. The system is already implemented and tested, being composed of a single real-time server with a database and modules that perform reception from the GNSS stations, data processing, and the online dissemination. All these tasks are executed asynchronously in a pipeline manner using the database as a central hub without any loss of data. The challenges that must be overcome to have real-time capability were: (i) to configure GNSS stations to send S4 data to a real-time server able to (ii) receive S4 data from the GNSS stations, (iii) generate sequences of S4 scintillation maps, and (iv) make these maps available in a web server. The implemented system was able to acquire data from all available stations of the monitoring networks, being robust concerning interruption of connections or different processing times of the tasks.


Introduction
Ionospheric scintillation can cause loss of lock of the GNSS signals that cross the ionosphere, with a consequent decrease in the number of available satellites and a degradation in the GNSS receiver performance (Kintner et al. 2001;Bandyopadhayay et al. 1997).Consequently, the required accuracy for aerial navigation and takeoff/landing operations cannot be reached.Scintillation affects the receiver signal by a fast phase variation that may cause a loss in the phase lock (Leick 1995;Skone, Knudsen and Jong 2001) and/or a rapid amplitude fluctuation, which weakens the signal enough not to be sensed by the loop discriminator (Humphreys et al. 2004; Kintner, Ledvina and de Paula 2005).In Brazil, GNSS augmentation systems like the Satellite Based Augmentation System (SBAS) (de Paula et al. 2007) and the Ground Based Augmentation System (GBAS) are affected by ionospheric scintillation, precluding takeoff/landing operations guided by GNSS.Typically, the monitoring of scintillation is made using maps of the amplitude scintillation index S4, stressing the need for generation of real-time accurate scintillation maps.This work presents an approach for the real-time generation and online dissemination of scintillation index maps covering the Brazilian territory.This approach was already implemented and tested, and includes the S4 scintillation index acquisition from two networks of multi-constellation GNSS monitoring stations, and all processing steps to generate the maps, including innovative pre-processing and interpolation methods.The two networks are the Low-Latitude Ionospheric Sensor Network (LISN) (Valladares and Chau 2012) and the INCT GNSS-NavAer network (Vani, Shimabukuro and Monico 2017), referred to as INCT for simplicity.A recent work by de Paula et al. (2023) provides more detailed information about the Brazilian GNSS networks for ionospheric monitoring.A single real-time server, a standard personal computer (PC), centralizes the data reception from the GNSS stations, performs all the required data processing and provides a web service for the online dissemination of the maps.Data processing at the real-time server can be divided into three steps: remote data acquisition, interpolation, and image rendering, while local data acquisition is performed locally at the GNSS stations.
The key concept of the system is to establish a pipeline for performing these tasks asynchronously and without any loss of data in the real-time server.The challenges that must be overcome to have real-time capability are related to the tasks described above: (i) to configure two types of GNSS monitoring stations to send S4-related data asynchronously without loss of data, and to configure a real-time server able to (ii) receive S4-related data from GNSS stations also asynchronously without loss of data, (iii) process S4 data in order to generate sequences of S4 scintillation maps with 1-minute resolution, and (iv) make these maps available in a web server.As a result, the implemented system was able to acquire data from all available stations of the two monitoring networks, being robust concerning interruption of connections or different processing times of the tasks.Therefore, the implemented system was able to provide real-time scintillation maps.
Additionally, the generation of more accurate scintillation maps is performed using a recent method with low computational cost and compatible with real-time demands (Martinon, Stephany and de Paula 2023).These challenges are addressed in the following sections, which detail the modules of the system implemented in the realtime server.
An overview of the implemented system hosted in the real-time server for real-time generation of scintillation maps appears in Figure 1.The adopted Database Management System (DBMS), described in Section 2, is the central module of the system, working as a data hub for the required data processing tasks/steps, which are performed by the remaining modules as consecutive stages of a pipeline.Acquisition/reception from the GNSS stations of the specific monitoring networks is implemented by the modules "INCT Data Acquisition" and "LISN Data Acquisition", detailed in Section 3. A validation was performed for the INCT real-time acquired S4 data using the default postprocessed data, as shown in Section 3.1.The S4 pre-processing and interpolation task/step is performed by the module "Scintillation Map Generation", discussed in Section 4. The image rendering task/step is carried out by the module "Scintillation Map Rendering", while resulting maps and data are made available online by the "Web Server" module, presented in Section 4. The proposed real-time system proved to be feasible, allowing to process incoming S4 data and produce scintillation maps for the Brazilian territory in less than 1-minute, thus complying to the real-time specification.

Data storage and processing pipeline
The first challenge was related to the storage (database) for the acquired S4 data received from the GNSS stations and for the resulting interpolated grid point and rendered maps.As already mentioned, the DBMS database is the central module of the system, acting as a hub that provides the interchange of data between the remaining modules.It allows the execution of a pipeline of processing steps in order to generate a map for each minute of received S4 data, similarly to an assembly line employed for automobile production.
Normally, in a traditional SQL/relational database, which employs a Structured Query Language, the retrieval of stored data is performed through periodic requests (by data pulls) made by some modules to get updated data.However, these periodic requests cannot be performed frequently nor by many client modules, since they easily degrade the performance of the DBMS.Therefore, a DBMS that sends new data in real-time whenever it is updated (by data pushes) was implemented in the real-time server, the NoSQL RethinkDB DBMS (https://rethinkdb.com/),providing timely exportation of data without overcharging the DBMS.Data is stored as documents, in contrast to the tuples of standard SQL/relational databases.These documents can store JSON (JavaScript Object Notation) data or binary data, and are grouped into tables.
The implemented DBMS is a database with three tables: acquired_data, scint_map and rendered_scint_map.The documents of these tables are identified by the corresponding datetime in the format "yyyy-mm-ddThh:mm:ss" composing a sequence of consecutive 1-minute intervals.There is a direct correspondence between documents of the three tables that share the same identifier.The acquired_data table stores real-time acquired data from the GNSS stations in JSON-format documents that contain data for a particular minute.Data is stored as an array of objects, with each object having a pair key-value, as depicted in Table 1.GPS_L1CA, GLO_L1CA, GAL_L1BC, BDS_B1I, BDS_B1C or GEO_L1 The scint_map table stores the resulting matrix from the "Scintillation Map Generation" module, with each document containing the scintillation map for a particular minute, typically as a matrix of 193 x 193 real-valued S4 grid points, stored in binary format.Similarly, each document in the rendered_scint_map table contains the rendered scintillation map in raster format PNG (Portable Network Graphic) for a particular minute, also stored in binary format.
The pipeline executes some processing steps using the DBMS as a central hub, as shown in Figure 1.At every minute, modules "INCT Data Acquisition" and "LISN Data Acquisition" provide S4 data to be stored as a document of the DBMS acquired_data table, which is instantly pushed to the module "Scintillation Map Generation" that performs S4 data pre-processing and interpolation, generating the corresponding grid point matrix, and store it back as a document of DBMS scint_map table, which in turn is instantly pushed to the module "Scintillation Map Rendering" that finally performs the image rendering step for the considered minute.Therefore, consecutive sets of 1-minute S4 data feed the pipeline, each one being processed in less than 1 minute.The consecutive sets are acquired and processed concurrently and asynchronously by the different modules that form the pipeline, automatically exchanging data via the DBMS central hub.Thus, different modules can process data related to different 1-minute sets of data at about the same time, but the pipeline finishes the processing of one set of data at a time following the temporal order of the sets.

GNSS data acquisition
Amplitude scintillation is given by the S4 index, estimated from signals of L band radio frequencies acquired at 50 Hz by GNSS receivers specialized in ionospheric monitoring.The monitoring of the ionospheric scintillation over Brazil is provided by the LISN and INCT network stations appropriately placed and compatible with the 50 Hz rate.Typically, the signal intensity of 3000 samples of a 1-minute period is used to calculate the S4 index value given by the intensity standard deviation normalized by the mean intensity (van Dierendonck, Klobuchar and Hua 1993).The S4 index is calculated for each GNSS satellite-receiver link of the several constellations (GPS, GLONASS, GALILEO, BEIDOU, SBAS etc) currently available at the GNSS station location.As a consequence, the number of GNSS satellites detectable by a station can exceed 40 in the same minute.These two networks can provide data from up to 44 GNSS stations simultaneously over the Brazilian territory, or up to 70 considering South America.In addition, for a given constellation, the S4 index values are compatible between GNSS stations equipped with different GNSS receivers (de Paula et al. 2021).
Data acquisition provides the starting point for the pipeline of the implemented system, performed by modules "INCT Data Acquisition" and "LISN Data Acquisition".The related challenge was to deal with different GNSS receivers of different manufacturers of the LISN and INCT networks, respectively Novatel and Septentrio.In addition, the data acquisition process was also designed differently for these networks, affecting the way that the data acquired from each station is received at the remote real-time server, being preprocessed and stored in the DBMS of the same server.These tasks must be carried out concurrently and asynchronously in the shortest time possible to be compliant to the real-time demand, and without being subjected to network blockings that may force waiting times when several stations are trying to send data to the remote real-time server concurrently.The original FTP data transfer default schemes of both LISN and INCT networks do not meet real-time requirements, and thus required the implementation of the alternative schemes described below.Data includes not only S4 values for 1-minute intervals for all GNSS stations, but also ancillary data like datetime, identifier, azimuth and elevation angles for each satellite that was locked by the stations.
As for June 2023, there were 15 LISN and 29 INCT GNSS monitoring stations currently active in Brazil, and up to 26 LISN stations distributed in other countries of South America, as seen in Figure 2. The GNSS stations of these monitoring networks employ different electronic devices and data acquisition software.Each LISN station has a Novatel 4004B receiver connected to a local computer via USB cable, performing data acquisition by the SCINDA software (Carrano 2008), being such data transferred via FTP to a central server every 1-minute.Conversely, the INCT stations can employ two different solutions: (i) a stand-alone Septentrio PolaRx5S receiver that compresses and stores the acquired data in its internal persistent flash memory, (ii) a Septentrio PolarRxS PRO receiver connected to a local computer via USB cable running a proprietary software from Septentrio that compresses and stores the acquired data in the local computer hard disk.In both cases, the compressed data of INCT stations is transferred via FTP to a central server every 15-minute or every hour.The Novatel 4004B receiver only acquires data from the GPS and SBAS constellations measuring the S4 index only for the L1 C/A signal, while the Septentrio PolaRxS PRO and the PolarRx5S receivers acquires data from all available GNSS constellations, with each receiver computing the S4 index using the available signals of all constellations, as also explained in de Paula et al. (2021).In the case of LISN stations, the solution was straightforward, as the data is already available for each 1-minute interval.A new TCP/IP client software was developed to be executed in the station computer sending data using the HTTP protocol to the remote real-time server, which executes a TCP/IP server software in the "LISN Data Acquisition" module.
In the case of the INCT data acquisition, the default mode precludes even more the real-time operation, since it is configured to acquire consecutive sets of 15 minutes of data, compress it, send via FTP to the real-time server, and then decompress the data and post-process it to calculate the S4 index values.After exploring, implementing and testing some alternative schemes, a particular feature of the INCT Septentrio PolaRx5S receivers was employed.These receivers have an integrated TCP/IP server, which can be configured to transmit incoming data blocks received from the GNSS satellites.Thus, these data blocks are automatically transmitted via a specific TCP/IP port to the remote real-time server, which executes a new TCP/IP client software.It is worth noting that this alternative is not applicable to the remaining stations with Septentrio PolarRxS PRO receivers, since there are just a few, and are going to be replaced by the former receivers.The Septentrio PolaRx5S receivers provide local real-time calculation of the S4 index values and ancillary data in the receiver memory, contained in the corresponding ISRM and SatVisibility data blocks.The TCP/IP client software is executed at the remote real-time server, in the "INCT Data Acquisition" module that receives data in the specific TCP/IP port.The TCP/IP client software is multithreaded, and receives each incoming 1-minute dataset creating a new thread.This multithreaded software is resilient to network errors, since in case of connection errors or corrupted datasets, it keeps trying to establish a new connection.Even if the Internet connection is inaccessible to the real-time server itself, once it turns accessible the multithreaded software tries to reestablish the TCP/IP connection with all INCT stations.
Another important difference between the two monitoring networks is the time when the S4 index is calculated.INCT stations calculate the S4 index at GPS time, which occurs some seconds before the UTC time, according to the current leap seconds adjustment, which is 18 seconds, while LISN stations calculate the S4 index at UTC time.Therefore, the combined processing of INCT and LISN incoming datasets is synchronized by the reception of the LISN datasets at UTC time, and assuming that the INCT datasets correspond to the same UTC time.Despite this issue, the LISN and INCT datasets refer to the same acquired 1-minute data.In addition, in this work, scintillation maps are generated using 15-minute intervals of data, but a sliding-window advances to the next minute whenever new data is received, thus keeping compliance to the real-time requirement.

Validation of the GNSS data acquisition
An extensive validation was performed to assess the accuracy of the INCT real-time acquired S4 data using the post-processed data that corresponds to real/observed S4 values.The S4 index measured in the INCT stations is calculated by default using 15 min or 1-hour raw data files that are post-processed by a proprietary command line tool (sbf2ismr) provided by the receiver microprocessor.Nevertheless, the implemented solution shown here uses the S4 index measured in real-time by the receiver itself, being another source of differences taken into account in the validation.
The validation procedure was performed using 4 classes of amplitude scintillation severity, similarly as in the work that proposed the innovative pre-processing and interpolation approach for generating S4 scintillation maps (Martinon, Stephany and de Paula 2023).The four S4 classes were defined using the following thresholds: null [0.00-0.15],weak (0.15-0.30], moderate (0.30-0.70], or strong (0.70-1.4), being values above 1.4 changed to 1.4, since they were considered as outliers.
This validation employed data from 15 INCT stations, as detailed in Table 2, encompassing observations from 1st of January to 31 of March of 2023, a period that presented high ionospheric scintillation activity.The validation was not necessary for the LISN stations, once the SCINDA software executed in the station computer already postprocesses the real-time acquired data.The validation was restricted to the time interval between 21 UT and 9 UT, i.e., after sunset, which is the time interval with occurrences of ionospheric scintillation in Brazil ( de Paula et al. 2007).In order to filter out data of L-band signals affected by ground interference and the related multipath reflections, only satellite links with elevations higher than 30° were considered.The resulting dataset comprised 64,080 min of observations for each of the 15 INCT stations.If considering that for each 1-minute of observation the number of visible satellites to a station can reach up to 40, and thus total 1-minute samples would amount up to 64,080 x 40 x 15 or 38,448,000 samples.The adopted metrics for the validation were the Pearson Correlation Coefficient (CORR), the Mean Absolute Error (MAE) and the Standard Deviation of the Absolute Error (STD), which were evaluated for every satellite, of every constellation of every station, as shown in the summary presented in Table 3. Considering averages for all 4 classes of scintillation severity, and all the 15 stations, the overall CORR was 0.99950, the overall MAE was 0.00054, and the overall STD was 0.00402.If considering values per class for all the 15 stations, these values were, respectively for classes null, weak, moderate, and strong, as follows: overall CORR of 0.99980, 0.99992, 0.99935, and 0.99453; overall MAE of 0.00050, 0.00050, 0.00061 and 0.00165; overall STD of 0.00051, 0.00054, 0.00398, and 0.01533.It can be seen that the validation procedure demonstrated a good accuracy for any class of amplitude scintillation severity.
These results show a good agreement between real-time S4 index values and the post-processed (real/ observed) values, during occurrences of ionospheric scintillation.The complete evaluation table for all satellites of all constellations of each station is available in the Zenodo repository (https://doi.org/10.5281/zenodo.8197703), in file "Validation of the GNSS data acquisition.csv".The same repository also includes the validation datasets, with the real-time and post-processed data for the 15 GNSS stations.

Scintillation map generation and image rendering
The second stage of the implemented system pipeline is the generation of an interpolated grid from the acquired samples, performed by module "Scintillation Map Generation", while the third stage of the pipeline is performed by module "Scintillation Map Rendering" that uses the interpolated grids for every minute to render the corresponding scintillation index maps.
The already mentioned recent pre-processing and interpolation approach of Martinon, Stephany and de Paula (2023) was employed in the implemented real-time system for generation of real-time scintillation maps (S4 index maps).The making of scintillation maps requires the interpolation of the S4 values for each IPP of each satellitereceiver link considered as located in the corresponding Ionospheric Pierce Points (IPP) for the considered area and time interval.IPP locations are derived from the available elevation and azimuth angles of each satellite-receiver link.Former approaches to investigate ionospheric scintillation over the Brazilian territory include the generation of regional S4 index maps (de Rezende et al. 2007), andVani (2018), which employed a similar approach, but with modified pre-processing options.
The employed approach of Martinon, Stephany and de Paula (2023) is named GPR(VQI), since it uses the Gaussian Process Regression for interpolation of the samples of a 15-minute interval, and the specific set of preprocessing options VQI, which corresponds to use the vertical projection of S4 values reduced by the average value above the 3rd quartile for the group of 15-minute samples of the considered station.The interpolation grid has the same spatial resolution of the map (0.25° x 0.25°), spanning latitudes -39° to 9° and longitudes -78° to -30°, forming a regular grid of 193 x 193 grid points.A coarser aggregation grid with 1.0° x 1.0° resolution with square cells centered at each grid point of the map defines the grouping of the samples.An a priori time interval of 15 min is used to integrate all the samples for all stations for the interpolation, and a sliding window updates the samples for the next minute for real-time compliance.The interpolated grid points will then be used to render the scintillation maps.These interpolated grid points are generated by the module "Scintillation Map Generation" using the following assumptions: I.Only samples corresponding to satellite elevations higher than 30° are considered, in order to filter out data of L-band links affected by ground interference and the related multipath reflections; II.The ionosphere is modelled as a thin spherical shell over the Earth at the mean altitude of 350 km, which corresponds to the maximum observed Total Electron Content (TEC) values; III.The IPP for each satellite-receiver link is defined as being the intersection of the line-of-sight receiversatellite (the slant path) with the ionosphere, using the receiver coordinates and the azimuth and elevation angles of the satellite (Prol, Camargo and Muella 2017); IV.The S4 values are projected to the vertical direction in order to take into account the geometrical effects on the measurements made at different elevation angles (Spogli et al. 2009); V.An aggregation grid with 1.0° x 1.0° resolution with square cells centered at each grid point of the map is defined to group the 15-minute samples of each cell, and to reduce them to a grid point "interpolation sample", which value is given by the average of the S4 values above the 3rd quartile (top 25% values) of the samples contained in the cell of the corresponding grid point.Cells without samples are discarded; VI.The centroid of each "interpolation sample" is defined by the reduction function, in this case, the centroid of the group of samples with S4 values above the 3rd quartile; VI.The interpolation employs the "interpolation samples", each one with a reduced value and a centroid, and results in the interpolated values for the interpolation grid (0.25° x 0.25°), which are then employed to render the scintillation map.
The module "Scintillation Map Generation" was designed to receive real-time S4 data pushed by the DBMS.During its initialization, 1 hour of data is retrieved from the DBMS and buffered in memory in order to ensure data continuity.This module generates each interpolated grid from 15 minutes of S4 samples received from all GNSS stations.Every minute, a new 1-minute set of samples is received by the module, and a sliding-window that traverses the data (samples) advances 1 minute, thus disregarding the older 1-minute set of samples.This module has a multithreaded architecture allowing the concurrent tasks of data retrieval and scintillation map generation.The interpolated 193 x 193 grid points that are generated every minute are stored in a sequence of documents compacted in binary format in the scint_map DBMS table .As mentioned, in the third stage of the pipeline, module "Scintillation Map Rendering" receives real-time interpolated grids pushed by the DBMS for every minute, and employs them to render the resulting scintillation index maps, which are images in the raster format PNG.These images are stored in documents of the DBMS rendered_scint_ map table.Finally, in the fourth stage of the pipeline, the DBMS automatically pushes the rendered maps for every minute to the "Web Server" module, which makes them available online with the corresponding interpolated grids.
The "Web Server" module is an API (Application Programming Interface) that implements two HTTP (Hypertext Transfer Protocol) endpoints in order to publish every minute the maps and the corresponding interpolated grids.To optimize the speed of the TCP/IP connections of the connected clients, i.e., the users demanding maps, these endpoints use the WebSocket protocol.This protocol provides full-duplex communication channels over a single TCP/IP connection, and employ the HTTP only during the initial request/response handshake that establishes the connection between the "Web Server" module and a given client.After the connection is established, the TCP/IP connection is kept active until the "Web Server" module, or the client closes the connection.Therefore, whenever new maps are updated every minute, there is no need to open new connections to the clients.Each "Web Server" endpoint waits for the DBMS to push every new document from the scint_map and the rendered_scint_map tables.When a new document arrives, the content is instantly sent to all opened connections, i.e., to all the connected clients to the "Web Server" module.
As an example of the scintillation maps generated by the proposed/implemented approach, Figure 3 shows an hourly sequence of nine maps showing the evolution of ionospheric irregularities on the night from March 11th to 12th in 2023.

Discussion and conclusions
A system for real-time generation and online dissemination of scintillation S4 index maps covering Brazil was implemented and successfully tested.Data is acquired from two networks of multi-constellation GNSS monitoring stations, LISN and INCT.This real-time capability was achieved by configuring or adding communication application software to the GNSS stations and to remote real-time server.The system is composed of a database server (DBMS), and modules that execute data reception from GNSS stations, map generation, map rendering and web serving, being hosted on a single standard personal computer (PC), the real-time server.All these tasks are performed asynchronously, and without any loss of data.The DBMS acts as a hub that exchanges data between the modules.A data flow related to every 1-minute incoming data is processed by the modules forming a processing pipeline that generates the S4 scintillation maps and corresponding interpolated grids, being compliant to the real-time demand.The challenges that must be overcome to have real-time capability were: (i) to configure two different types of GNSS stations to send S4-related data to the real-time server, which must (ii) receive S4-related data from the GNSS stations, (iii) generate sequences of S4 scintillation maps, and (iv) make these maps available in a web server.The implemented system was able to acquire data from all available stations of the monitoring networks, being robust concerning interruption of connections or different processing times of the tasks.In this scope, real-time capability is considered as being the generation of a temporal series of S4 scintillation maps with a 1-minute resolution.
However, each new map is generated using 15 minutes of S4 data, aggregating 1 minute of newly-received data by means of a temporal sliding-window.The kernel of map generation is the module that generates an interpolated grid every minute, based on the recent work of Martinon, Stephany and de Paula (2023), which includes pre-processing and interpolation steps, using the GPR(VQI) optimal approach described in Section 4. Each interpolated grid is then used by the image rendering module to produce the corresponding scintillation map.The resulting S4 scintillation maps are accurate, smooth, and allow to compose sequences of maps suitable for animations.The employed GPR(VQI) pre-processing and interpolation schemes also minimize the occurrence of image artifacts in the maps.
It was demonstrated that the real-time generation and online dissemination of scintillation maps covering Brazil was feasible, with all acquisition and pre-processing steps demanding less than 1 second, except for the generation of the interpolated grid that took up to 12 seconds.The real-time capability involves acquiring data from all the 20 available stations of the two GNSS monitoring networks, LISN and INCT, and was achieved using a standard PC as the real-time server.It has a single Intel processor 2.4 GHz with 4 cores, main memory of 64 GBytes.Even assuming the predicted number of near 50 stations for South America in the near future, the current system still will be able to provide the proposed real-time capability.The only performance bottleneck would be a heavy demand of users downloading maps, but the web serving module could be easily executed in a separate PC.Any state-of-theart current server would have at least two processors, with at least 8 cores each one, and a memory of hundreds of GBytes, thus exceeding many times the required processing capability required for all these stations.
It is expected that the presented real-time generation of ionospheric scintillation index maps will provide warnings for several GNSS-based applications, including aerial navigation, aircraft takeoff and landing procedures, precision agriculture and positioning of offshore oil prospecting platforms.Furthermore, these real-time maps may benefit the research on ionospheric scintillation and/or be assimilated by ionospheric models.As the proposed system proved to be an excellent real-time framework, it is currently being enhanced to support the real-time generation of scintillation probability maps (Martinon, Stephany and de Paula 2022), and also ROTI (Rate-of-TEC Index) maps.Both the scintillation probability and the ROTI maps may support the prediction of occurrence of ionospheric scintillation.Furthermore, the end user deployment of this system is in progress, being expected to make real-time scintillation maps available on the Internet soon.Another further work would be the generation of real-time scintillation maps covering all South America, using all the LISN stations.It is also intended to make the system proposed here available for other institutions/countries, by publicizing the code for the real-time server modules in GitHub, including the code for S4 map generation, and also the procedure to configure the GNSS stations.

Figure 1 :
Figure 1: Modules of the system implemented in the PC-based server for the real-time generation of scintillation maps.

Figure 2 :
Figure 2: Geographic location of the GNSS monitoring stations of the LISN and INCT networks.

Figure 3 :
Figure 3: Hourly sequence of scintillation maps generated by the proposed approach showing the evolution of ionospheric irregularities on the night from March 11th to 12th in 2023.

Table 1 :
Object pair key-value entries of a DBMS document.

Table 3 :
Summary of the validation metrics by INCT station.