← Back to Articles

Table of contents:

The WAY online utility automatically detects known / supported formats and protocols in uploaded file and gives statistic about detected messages and compact information about primary data parameters.

As for today (2023-Aug-28), WAY supports the following formats (completely and/or partially):

Please reffer to WAY Home Page for up-to-date status and additional information / details.

Let's demonstrate WAY features on concrete examples. For instance, there is some Compact RINEX file we'd like to check and analyze. Perfect! Let's start. As for file, let's use one concrete from BKG:

https://igs.bkg.bund.de/browseFiles

Where this station is located? How many measurements are inside in fact? Is there QZSS or IRNSS measurements? All of these questions may be easily answered by WAY.

Once the test file is downloaded from BKG server (and unzipped), let's open WAY uploading page

First one should select the file to be examined. WAY supports Compact RINEX format (both version 1 and version 3) thus no need to run RNXCMP utility in advance. Just point to UNBD00CAN_R_20231990000_01D_30S_MO.rnx file which has just been saved and unzipped.

In most of the cases, you may keep DECODER combo-box by default (AUTO). It means that WAY will detect the format on its own. However, in some specific cases when the file includes data of several GNSS formats - it makes sense to specify concrete one. For instance, there could be a file w/ NMEA and UBLOX binary (or Septentrio SBF) data logged together.

Final step - verification code is entered and one may press UPLOAD button. The file will be uploaded to the server and started to be processed. Processing time depends on file size, GNSS data format, epoch rate etc. If file is huge - please wait a little bit, it may take some time.

General statistic section inform us that we have 24h raw data collected on Septentrio POLARX5S receiver w/ FW 5.5.0 onboard. Data rate is 30 sec. GNSS measurements are presented in RINEX 4 format w/ applied Compact RINEX compression (Hatanaka compressed).

General Info

4.0
Hatanaka Compressed (CRX)

Antenna coordinates provided in RINEX header are the following:

Average Coordinates

Average Coordinates over all positions withing the file.

WAY shows us the position on interactive Google Maps what is quite convinient - we may check in details the location and its surroundings from point of GNSS obstacles and shadings.

Next, WAY process the whole file, all the epochs, collect measurements of all GNSS, satellites and siganls and forms statistic of number of tracked SVs per each GNSS.

Min / Mean / Max SVs Tracked

Min, mean and max number of tracked SVs per GNSS.

Here WAY presents details statistic of max & mean SNR per each GNSS and Signal detected over whole file. It also gives an idea about concrete signals provided in the file.

Max / Mean SNR

Max and mean SNR over all SVs of concrete GNSS and signal.

In the next table, WAY provides information about SNR (and/or Code) measurements counters. It allows to get idea what concrete satellites were tracked, what signals were tracked and how many such observables are available per each GNSS, satellite and signal.

Measurements counter (SNR)

Total number of SNR measurements for each GNSS / satellite per Signal.

This time lets' try to check RTCM3 corrections. For testing purposes, RTCM3 file is logged in advance from GOET00DEU0 mountpoint of euref-ip.net NTRIP Caster.

As usual, just choose the file w/ corrections in WAY interface, keep AUTO decoder mode (or select RTCM3 decoder if the file may contain mix of different GNSS formats), enter verification code and press UPLOAD button.

Once uploading and processing are completed, we may see WAY results. As usual, first general information about file, detected / used protocol and overal statistic about epochs is presented.

Next, one may find information about detected messages, number of good and bad CRC and messages description.

Messages: RTCM3

Base station coordinates (base position) and base ID is presented in the following table (RTCM3 General Statistic). This information is gathered from [1005] or [1006] RTCM3 messages. Depending on availability of [1007], [1008], [1033] messages, statistic is also augmented by information about base receiver model, FW version, serial number (SN) as well as base station antenna and its SN (if available).

RTCM3 General Statistic

Some general statistic and information about RTCM3 stream.

X: 3918911.800
Y: 687523.900
Z: 4968545.600

0

1

1

JAVAD TRE_3 DELTA

4.1.06-221128

0S67YR9U4JWA90QDSPVJA2QGHS

LEIAR25.R4      LEIT

10211013

Base station position is showed on interactive Google Maps what gives an idea where exactly the base station is located, what is the environment around.

Next, WAY provides analysis of RTCM3 stream and raise warnings in case of obvious issues are detected (like no base position, base ID change, low number of satellites or bad SNR etc). Please check the article:

§ 002. How WAY service may help in RTCM3 corrections analysis and RTK rover troubleshooting?

It provides many practical examples of affected RTCM3 stream which may prevent RTK rover from being FIXED. WAY may help to identify these problems.

But let's come back to RTCM3 example from Gottingen. Here all is fine, WAY didn't detect any obvious issues in RTCM3 stream. All is GREEN.

WAY RTCM3 Simple analysis

Next, we may see statistic of number of tracked GNSS detected in observables RTCM3 messages.

Min / Mean / Max SVs Tracked

Min, mean and max number of tracked SVs per GNSS.

Quite important statistic as well - maximum and average SNR per each detected GNSS and signal. Also gives information about actually available signals types. Please be aware that these tables may not appear if corrections do not include SNR (for instance RTCM3 messages of MSM3 group).

Max / Mean SNR

Max and mean SNR over all SVs of concrete GNSS and signal.

SNR (or Code) measurements counters - allow to get idea what concrete satellites are provided by RTK Base, what signals and how many such observables. May be RTK rover can't get FIX because RTK Base doesn't track L2 frequency? The table perfectly shed light on such hypothesis. This time all is fine.

WAY service is also capable of reading and decoding binary Septentrio SBF format. Let's demonstrate it on some concrete example. SBF files may be taken from GAGE UNAVCO server.

For instance, it could be the file neah0010.23_a.sbf (see illustration below).

Please, download the file from UNAVCO server and than, as usual, upload the file into WAY. Wait till processing is completed.

General info section gives us an idea that: it is indeed binary SBF file w/ data update rate of 15 sec. In total, we have about 10.5 h of data for analysis.

General Info

List of detected SBF blocks (messages) is presented below. All messages are good, no bad CRC detected.

Messages: Septentrio SBF

Interesting, looks like the receiver is running in PPP (Precise Point Positioning) mode.

Position Types

Horizontal and vertical precision definitely confirms it. Percentile 99.9% is less than 7 cm in horizontal (means that 99.9% yields within the file have horizontal positioning precision error no more than 6.78 cm).

Horizontal Precision

Horizontal positions precision against average coordinates. Has sense only for static receiver.

Vertical Precision

Vertical positions precision against average coordinates. Has sense only for static receiver.

Average coordinates (over all positions within the file) are the following:

Average Coordinates

Average Coordinates over all positions withing the file.

Thanks to position on GMap, we may see in details where the receiver is located. The receiver is installed in quite forestry place. Would be interesting to check Multipath environment (MP1 / MP2 combination) as well as satellite visibility as function of elevation. KernelSAT is planning to add in coming future TEQCMate online service specifically aimed to perform base station measurements quality assesment (similar to what UNAVCO teqc utility does).

Next, we may observe standard measurements statistic, as number of tracked satellites per each GNSS:

Min / Mean / Max SVs Tracked

Min, mean and max number of tracked SVs per GNSS.

As well as detailed statistic per each GNSS, satellite and signal. For instance, one may see that QZSS L6 signal is tracked (MADOCA or CLAS PPP)?

Max / Mean SNR

Max and mean SNR over all SVs of concrete GNSS and signal.

The article presented several examples of how to quikly check GNSS data and do minimal assesment and analysis using KernelSAT WAY online service. WAY supports many different GNSS formats and protocols - not all of them were presented in this article. Please reffer to WAY Home Page for up-to-date status of supported formats, protocols and messages.