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

Intro

Why RTK rover can't get RTK FIX? Or why it is too long and unstable? One of the key factors (besides rover itself) which must be checked is RTK differential corrections coming from a base. May be base is installed incorrectly? Maybe it provides low quality measurements? May be second frequency (L2) is simply missed on base? May be some vital messages are not ordered like base station position?

WAY service could help in RTCM3 data extended analysis and troubleshooting. Besides standard statistic information about detected messages, tracked GNSS / SVs / Signals on base, WAY can warn you about obvious issues w/ RTCM3 corrections in traffic-light coloring approach (GREEN - all is Good, Yellow - warning, RED - problem, BLUE - information). Each message also has own rank with points. PLUS(+) if good, MINUS(-) if bad.

Please refer to Basic RTCM3 analysis w/ WAY article for general information of how to use and run WAY service. Here (within current article) we will be mostly focused on "bad" RTCM3 streams affected by different issues and will see how WAY could help to identify them.

Issue 1: No Base Coordinates

Sounds strange, but it is still quite actual problem of RTK. Operator forgot to enter base coordinates on Base? Or may be he even entered the coords but they were invalid (say, to far from the actual base station location)? In both cases, RTK Base will not send RTCM3 messages [1005] or [1006]. No base position - RTK on rover is not possible at all. Any rover will refuse to provide RTK FIX solution.

Let's check how WAY service will rank such RTCM3 corrections. Upload to WAY the file w/ RTCM3 data but let's imagine 1005 / 1006 are missed.

Messages: RTCM3

WAY RTCM3 Simple analysis

Lack of base station coordinates is considered by WAY as CRITICAL issue marked and ranked accordingly.

Issue 2: No Receiver Descriptor

Typical problem as well. Base doesn't send RTCM3 message [1033]. The message contains information about base station receiver model. It may appear quite important factor since many RTK rovers relies on information from [1033] message. Depending on base station manufacture, RTK rover may apply concrete GLONASS differential phase biases estimated in advance between rover and base receiver models. Lack of this information applied may do RTK rover life harder.

Messages: RTCM3

WAY RTCM3 Simple analysis

Issue 3: No Antenna Descriptor

Typical problem as well. Base doesn't send any of RTCM3 message which includes information about Antenna installed on RTK Base ([1007], [1008] or [1033]). Knowledge of base antenna type allows RTK engine to use known antenna PCO & PCV calibrations (Phase Center Offsets and Phase Center Variations) what in turn may help to get RTK FIX faster or even may be the reason of too long and unstable FIX.

Messages: RTCM3

WAY RTCM3 Simple analysis

Issue 4: BaseID Change

RTK Base is characterized by numeric ID specified by base operator. RTK rover relies on this ID which is coded in every RTCM3 message. If Base ID is changed - that is serious event for RTK rover. It means that corrections are now coming from different base. What in turn usually lead to RTK engine internal reset w/ all ambiguities to be re-resolved. A user may observe it as loss of RTK FIX for some time.

It is good if Base ID change event is expected - for instance, RTK surveyor intentionally switched to another NTRIP mount point. It also could be standard behavior if Network RTK is used say VRS. In this case, VRS engine may "re-build" virtual station w/ new ID and new position as frequently as it wants.

But sometimes, Base ID change event may not be expected. Say, it is some mistake on rover side (there were no need to switch to another base station) or it could be some mistake on base side. In this case, Base ID change event must be analyzed. WAY service warns a user if there is such event in uploaded RTCM3 file detected.

Messages: RTCM3

Here we may see that WAY detected several Base ID change events. All of them are listed in "RTCM3 General Statistic" table of WAY report.

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

WAY RTCM3 Simple analysis

Issue 5: Base Coords Change

Due to some reason, base station coordinates are changed. It may be expected event - new NTRIP MountPoint was selected, or base station operator corrected the base position. It also could be standard situation in case of Network RTK or if it is moving base use-case. However, if base coordinates change is not expected - it must be pointed out and analyzed if needed. Since it directly affects rover RTK positions.

RTCM3 General Statistic

Some general statistic and information about RTCM3 stream.

X: 3918911.800
Y: 687523.900
Z: 4968545.600

X: 3918912.568
Y: 687526.320
Z: 4968541.720

WAY will show every base position on Google Map so we may check where these locations are.

WAY RTCM3 Simple analysis

Issue 6: Corrections rate

Rarely, RTK rover issues may be caused by not-optimal corrections rate coming from base. For instance, instead of standard 1 Hz corrections typically used for RTK, a base sends data too seldom. Say, once per 5 sec. In some applications it might be OK, but typically it could be the reason of RTK engine unstable operation especially in challenging environment. In any case, RTK observables coming w/ rate differ from 1 Hz are to be taken into account.

General Info

WAY RTCM3 Simple analysis

Issue 7: Low SVs availability on Base

Obvious case but it happens sometimes. Due to some unknown reason, RTK Base tracks (and /or sends in RTCM3) low number of Satellites. May be it configured incorrectly, may be there are some issues w/ installation. In results, there are low number of rover+base observables / measurements combinations available on RTK engine. Obviously, it could make RTK engine life much harder.

Min / Mean / Max SVs Tracked

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

WAY RTCM3 Simple analysis

Issue 8: Low SNR on Base

Due to wrong setup of base station or external interference / jamming (or even spoofing), SNR figures on base are too far from optimal. In turns, it affects quality of code & phase measurements so vital for effective RTK operation. WAY could analyze it and raises an alarm if average SNR on base is too low.

Max / Mean SNR

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

WAY RTCM3 Simple analysis

Issue 9: Many Corrupted Messages

Too many messages w/ wrong checksum (CRC) are detected on rover side. Usually in may appear due to data link issues. For instance, UHF radio link + external jamming. Sometimes the reason is mismatch in RS-232 baud generator frequencies or missed CTS/RTS. In any case, the more RTCM3 messages are corrupted the harder is to maintain stable RTK FIX. WAY service check this parameter as well and raises corresponding alarm if there are too many corrupted messages.

Messages: RTCM3

WAY RTCM3 Simple analysis

Issue 10: L1-Only messages

Quite rare and yet... If the base sends L1-Only data (intentionally or by mistake) - no stable RTK would be possible on distances more than few km between base and rover at all. Long TTFF (time to first fix) is also sould be expected.

Messages: RTCM3

WAY RTCM3 Simple analysis

Issue 11: Mix of RTCM3.1 & RTCM3.2

By mistake, base sends both RTCM3.1 observables (any of messages [1001-1004] and/or [1009-1012]) and RTCM3.2 MSM. It is not good for RTK rover. It has to somehow mix these data, overwrite already available SV data by a new within current epoch. In result, RTK FIX may be affected or even missed completely.

Messages: RTCM3

WAY RTCM3 Simple analysis

Issue 12: Mix of MSMs

Another type of undesired mix is mix of different MSM types. Say, RTK base sends simultaneously MSM2 and MSM4. It could be a headache for RTK rover. Do not ever mix different types of MSM in one stream if you don't want to test your RTK engine robusteness and resistance to stress.

Messages: RTCM3

WAY RTCM3 Simple analysis

Summary

The articles described different examples of "bad" RTCM3 corrections which may affect RTK rover performance. Thanks to WAY service, one may easily detect these issues in advance or speed up RTK rover trouble-shooting.

Besides standard statistic information about detected messages, tracked GNSS / SVs / Signals on base, WAY can warn you about obvious issues w/ RTCM3 corrections in traffic-light coloring (GREEN - all is Good, Yellow - warning, RED - problem).