There are two simple navigation filters provided by SNIP which are used to view the corrections data stream in the spatial domain. These filters can be used to quickly visualize how coherent a given corrections data stream is. The resulting 4 dimensional positional estimate (LLH and time) can be plotted on various coverage maps and common navigation analysis plots from within SNIP.
You can right-click on the “Graphical Views” menu item for any stream to start these filters. From that point you can change the filter type as well as the style of plot image displayed. The Save button allows saving the current plot image. The Map button opens a Google style base map and and displays the current location.
The two simple navigation filters are described further in this article.
Aside: It is also very common to connect “better” navigation filters to a SNIP node as common NTRIP Clients and then perform much more exact filtering with various RTK and state space methods.
The Least Squares Navigation Filter (LSF)
SNIP provides a classical least squares L1-only navigation filter using the code data and broadcast data products for orbits and clocks. It uses 1001~1004 type messages. A very simple Hatch filter with a basic Saastamoinen troposphere model is used with GPS signals as the only GNSS type. As a result solution data will iterate about one meter further offset from ground truth depending on the local daily ionospheric effects. As the SVs in the constellation come and go, a new average and offset time will be observed.
The Precise Point Positioning Filter (PPP)
SNIP provides a trivial Precise Point Positioning navigation filter using broadcast data products for orbits and clocks.
Because the SNIP PPP filter is using only the broadcast ephemeris from the RTCM3EPH stream (providing GPS + GLO + GAL + BDS + QZS + SBAS), some would claim it is not a PPP filter at all. It does not use SP3 or any rapid orbital products, nor any real time clock data. It is however a PPP style filter in that it makes extensive use of the smoothed carrier phase (rather than code). It presumes a stationary observer (as does the LSF mode above). It does not model troposphere or slant angle ionosphere effects (and only trivial vertical TEC models are used).
Its primary value to a SNIP operator (like the other filter above) is to ensure that the filter converges at all, not that the resulting solution is “correct” by any particular figure of merit.
Aside: There is no reason that you cannot pass high precision IGS data products (Orbit, clock, and various TEC products) into SNIP and create more robust PPP filters when needed. Several open source and/or public tools provide navigation filters to do this with SNIP (or any other Caster). In a similar way it is common to run RTK filters from one base station to another using such tools.
In order to perform ranging off of any SV in any GNSS system (and hence to navigate to a positional solution) one also needs to have suitable ephemeris data (orbital data). It is common to provide this data in an NTRIP Caster stream called “RTCM3EPH” Places like IGS, and Natural Resources Canada provide such streams.
You can also obtain this data from our open Caster machine at the URL:
ntrip.use-snip.com:2101 : RTCM3EPH
This stream is provided on ntrip.use-snip.com:2101 but it originates from the IGS tracking centers and contains broadcast ephemeris data for these systems: GPS, GLONASS, GAL, BDS, QZS, and SBAS-WAAS (US) – all repeating at a 5 second rate.
If you are interested in creating a Caster with the various high accuracy data products from IGS, start here. Of course, all of the real time data products can also be send thorough SNIP with no issues.