MEDEA as CORS GNSS receiver

This post intends to showcase the capability of MEDEA from the standpoint of  using it as a Continuously Operating Reference Station (CORS).

MEDEA Sensors Board (SB), equipped with an RF shielded ublox ZED-F9P, has been used to capture 4 hours of raw data in order to assess both positioning performance as well as GNSS measurement quality. The setup of the static acquisition is summarized as follows:

• Antenna used: Tallysman 7972 (Triple-frequency muli-constellation).
• Duration: 4 hours from 2019-05-02 13:30 CEST
• Location: MediaTIC building rooftop in Barcelona 41° 24′ 09″ N, 2° 11′ 40″ E
• Moderately opensky conditions (multi-path in low elevations)
• PPK Processing with: GARR CORS station (catnet) with baseline 24 Km
• RTK Engine used: RTKLIB

Signal-to-Noise Ratio

MEDEA SB is powered by a Ublox ZED-F9P, a multi-constellation GNSS chipset able to track 4 constellations simultaneously (GPS, GLONASS, GALILEO and BEIDOU). Its multi-frequency capabilities allows tracking GNSS signals at L1 band as well as those located in the vicinity of GPS L2 (Glonass L2 as well as Beidou B2 and Galileo E5a).

Tracking initialization sequence and signals were already analyzed in our previous post about MEDEA SB, and in particular it was noted the tracking transition from L2C medium code (L2S, in Rinex 3.03 code convention) to the L2C long (L2L) code. Positioning results show some impact in this transition using the proposed positioning engine (Rtklib).

The data gathered has been analyzed in order to assess the quality of the received signals in terms of Signal-to-Noise Ratio (SNR).  Results are as follows depending on the constellation and band:

From the plots, it is apparent a SNR drop in GPS L2 compared to GPS L1, however, in GPS L2 case, it might seem that the excursions in the SNR variation are slightly lower than GPS L1.

In general, Galileo SNR values show more stable values (i.e. with low variation, when compared to the case of GPS) and also a higher SNR values are observed for E5b, due to the higher transmitted power at this band.

In summary, SNR results are exactly as expected with MEDEA SB showing a very good performance in terms of signal-to-noise quality with moderately high elevation satellites resulting on a regular basis on SNRs above 40dB.

Note that, by default, the B2I signal is disabled and has not been included in this analysis.

Geometry-free combination

This combination, also known as ionospheric combination, is very useful to assess the data quality of the observables because the non-dispersive terms (i.e. that do not depend with frequency, e.g. geometry, troposphere, ...) are cancelled out, making more apparent, over a relatively short arc (where ionospheric delay does not vary much), the impact of the thermal noise, cycle slips, ...  The combination computed is as follows:

Also, this combination is the one used for the ionospheric community to derive Vertical Total Electron Content (VTEC) maps. Since ublox ZED-F9P is a dual frequency GNSS receiver, it could also provide with data to estimate VTEC. In this section the Geometry-free combination, proportional to the ionospheric refraction delay, is compared with the ionospheric delay modelled using Total Electron Content (contained in IONEX maps). These two terms should in principle be very similar except for a bias (due to phase ambiguity of the GNSS carrier phase). Some examples of this comparison for GPS and Galileo follow:

As expected, when adjusting the GNSS geometry free combination by a bias, both quantities (GNSS geometry-free delay and IONEX-derived delay) follow the same trend. This suggests that MEDEA could also be used as a cost-effective alternative for applications such as ionospheric monitoring using GNSS data, as done by various analysis centers that provide the IONEX maps with Vertical Total Electron Content data.

Static Positioning Results

RTKLIB has been used to compute a PPK processing (post-facto RTK) with a neighbouring CORS station from ICGC catnet network. RTKLIB configuration parameters used for the PPK processing both for the original RINEX and the cropped version not containing L2C nor Beidou measurements is as follows:

pos1-soltype=forward
pos1-tropopt=est-ztd
pos1-elmask=15.0
pos1-navsys=13
ant2-postype=xyz
pos1-frequency=l1+l2+l5
pos1-posmode=static
pos1-sateph=brdc
pos2-armode=off
pos2-gloarmode=off

Using a RINEX without Beidou measurements cropped to start at the L2L code tracking (long L2C code), thus avoiding the tracking transitory with the L2S (medium L2C code) results are as follows.

Results are in line with expectations for a static PPK processing (i.e. convergence time to under 50cm after the first few seconds), not fixing ambiguities.

L2C medium to long code transition

Results containing both medium and long L2C code were initially disappointing as they had elevated errors and extremely long convergence time. This might have been due to an improper handling of the L2C inter-code signal biases: if the engine considered both L2C codes to be the same, different code biases between medium and long codes could potentially disrupt the filter. This however is still to be investigated. In addition, the presence of single frequency Beidou signals was neither properly handled by the engine (configured to process L1+L2+L5). The results in this scenario were far from what is expected of PPK .  The following figure shows the results of the processing containing both L2C codes, showing large errors as well as extremely long convergence time:

These high errors are not explained by the impact of non distinguishing between L2C codes for precise positioning pinpoited by some authors (see Montenbruck et al 2014), where they state that the errors of non correcting for the DCBs could be around 20cm. Let us know if you had similar experiences using L2C signals for precise positioning.

Further data analysis and the capability to detect and correct cycle slips and faulty data using data from MEDEA will be carried out in the future and posted in our blog.

MEDEA as CORS

The full MEDEA receiver, i.e. the version implementing both sensors board and applications processor board will be a full navigation computer able to plug-and-play operate as a CORS receiver or a as an RTK rover with a simple web-based configuration procedure. While we wait for the full MEDEA receiver to go from current prototype to full product, we can rely on MEDEA SB to exploit its capabilities as a CORS receiver. In order to use MEDEA SB as a CORS GNSS a couple of options are rather straightforward:

• Connect it to an Internet connected Windows computer with Ublox U-center. This will allow you to stream raw observables to an external NTRIP caster.
• If you do not have Windows, you can use the str2str tool included in the RTKlib software: connect MEDEA to a RaspberryPI (or similar) with internet access and use str2str to send the data.

Rokubun is working on this and will try to provide further details in the near future. Your ideas are welcome to explore new MEDEA SB possibilities either to operate as a CORS or a as an RTK rover.

Recall that you can get your MEDEA SB here!