Nearest MountPt, use case examples

This article provides a few practical details and comments on setting up a NEARest data stream on a SNIP node.  It follow another article which serves to introduce the new NEARest mountPt feature in SNIP.

For this article we have used the remote-relay mode to connect a SNIP node to four different networks (our own, a private party, and two government run networks) to create a local regional network of casters in the greater San Gabriel valley area.  It is located near our primary offices with eight well spaced base stations all providing RTCM3 L1/L2 data.  The San Gabriel valley is part of the Los Angles basin in California, USA.  The resulting network is shown in the map display image created by SNIP bellow:


The local freeway network (in this case using Interstate I-10) provides a convenient way to travel in a general East-West direction which we will use to demonstrate the connection of an NTRIP Client Rover device as it proceeds.  By adjusting the controls provided by SNIP, the operators can control the hand-over process by which a new Caster stream is selected to suit their needs.

Setting up a Regional NEAR stream

The purpose of this article is to cover some of the operational considerations and issues you will see when operating a NEAR network stream.  The actual process of setting up such a stream on your SNIP Caster is covered in this article where the various controls are explained.

The Base Station data streams which form any NEAR mountPt are referred in SNIP documentation to as a “pool”  This collection of stations (the pool) all share common attributes selected by the SNIP operator.   For example, an operator may want to only use station offering both GPS and GLONASS data streams.  The members of the pool are managed by SNIP as the various stream come on-line.  A data stream must be on-line and otherwise stable for ~180 seconds before it will be considered for inclusion into a pool.  This serves to prevent using data streams that may be transitory.

Typical Performance Expectations

It can be helpful to recall what the general expected performance of a rover will be when connected to a base station as the distance between them varies.  You can find many technical articles covering details of this topic at ION and elsewhere.  But in general terms – and as long as the raw data is good, nearer is better and both accuracy and precision falls off with greater distance.  Commonly stated in RTK application slang:  the rover can not can get into “fixed” mode when too far away.  Consider the radial distance lines in the image below at 10, 20, 40 and 75 kilometers from one the above base stations .


One can confidently expect that an unobstructed L1/L2 rover will be able to achieve reasonable RTK performance (that is a very large percentage of the time to be in fixed ambiguity resolution (AR) mode), even under kinematic states, out to ~40km or so (the 3rd ring shown).  With greater distances, the percentage of float behavior, increases and predominating out to the final ring at ~75km and beyond where fix mode is very unlikely to occur.  At the shorter radial distances, such devices are often able to achieve a fixed AR state in a single measurement epoch or two.  Other then advent of faster, cheaper, better devices this the stock RTK of the past two+ decades. NTRIP and SNIP just serve to make it more accessible to more users at a lower cost.

By contrast, lower cost L1-only devices (which can not therefore directly measure the ionospheric effects they are experiencing) have a more limited range where they can achieve a fixed AR mode (especially when moving),limiting their abilities.  In the above image we have drawn the cut off point at a 10km separation distance from the base station (a somewhat conservative choice of value).  At distances beyond this, the percentage of time spent fixed drops until it is not obtainable.  And the device is reduced to either a full time float mode or using DGPS type corrections (which often serve to better remove other residual error of ~1 meter which are present when only using SBAS/WAAS corrections).  Here is a typical example of what you can expect for this at a static 1km distance.

Aside: In the above discussion we presume the radio / cellular link between the rover and SNIP is working to deliver the stream of corrections. When the radio link is not reliable, SNIP has various patented and proprietary methods to overcome this, but their use is restricted to Enterprise license users.  Please contact SCSC if you have such a need.

A Review of how NEAR works

Consider a simpler network with only three base stations and the rover device moving along the simple East-West line as shown in green.


It is causally obvious that as the rover proceeds from one side of this area to the other it will find each of the three base stations to be the closest for periods of time spanning tens of minutes or more  [we presume LA traffic speeds :)].  In fact, when the rover is inside the black circles (within <10km of each base station) even an L1-only device is likely to have no problems achieving a fixed AR mode of operation and its inherent ~2cm accuracy.


The interesting question from the above is when the change to a new caster connection is best made.  And in SNIP this is handled by the concept of a Hysteresis value which is set by the operator for each of the NEAR streams.

By setting the value very low, changes to new caster will occur more often as the rover moves.  By setting the value high, such changes will occur less often.

The default value is 2km (~1.2 miles) which means that as the sets of distances are re-evaluated (every time the NTRIP Client ROVER sends in a new NEMA-183 $GGA message), then any potential new “shorter” distance has to be shorter to the proposed new base station by at least the hysteresis value before it will be used.

Aside: And by setting the hysteresis value very high, the initial base station stream to which an NTRIP Client is assigned can be made to persist indefinitely (or at least as long as that stream remains active).  This mode of operation has some value with older devices when the GNSS of the NTRIP Client is not able to change base stations on the fly. It can also be of value in some stationary rover applications or when rover movement is constrained (such as a precision agriculture in a small operating area).

The Initial Connection Point

When a NTRIP Client first connects to NEAR stream, the normal “200 Ok” reply is sent.  Then, unlike a normal stream which begins sending immediately, the Caster awaits the initial NEMA-183 $GGA message from the rovers.  [Aside, in NTRIP revision 2 the rover location can also be sent along with the initial connection]  Every time the $GGA message is sent, the Caster re-evaluates the best best stream to be used according to the current settings and connects the NTRIP Client to another stream when conditions warrant.

Hint:  You can always see a report of the connected users with: the last $GGA message, a count of how many such messages have been received, the lat-long data in a more readable form, and the distance to the current base station by pressing the List Current Users… button on the Caster and Clients tab.

There are currently 2 NTRIP client connections. SNIP is feeding data to these remote points:
    MountPt: SCSC : 57259 [#C22]   'Anonymous'   Sent: 284.69 KB Connected for: 15:27.388 MIN:SEC
            LastNMEA:   $GPGGA,211621.81,3408.1987406,N,11749.8103974,W,1,00,1.0,278.503,M,-33.504,M,0.0,*78 (185th msg)
            Location:   Lat: 34.13664568 (deg),   Lon: -117.83017329 (deg),   Ht: 312.007 (m)     [1,081.5 m to base]

The very first time the $GGA message is the first moment when the stream assignment occurs.  If no $GGA message is ever sent (indicating an ill configured NTRIP Client, or one whose GNSS is no operational), then the NTRIP Client is disconnected from the Caster after a reasonable delay.  If only one $GGA message is ever sent, then that value is used, resulting in a permanent assignment to the closest stream.

Aside: If the assigned stream were to fail, the NTRIP Client will immediately be automatically re-assigned to the next closest suitable stream, see below for an example of this using the above connection.

Often cellular type radio links will fail when used in a moving vehicle.  Upon re-connection, the NTRIP Client again presents his NEMA-183 $GGA message to the SNIP Caster and the process resumes as described above.

On SNIP starting

The NEAR pool is only made up of stable data streams.  This can be an issue during the first few minutes of operation.  If the NEAR function is enabled on a SNIP node, the function will restart with each power cycle just like all the other data streams (reusing the user settings from the last run).  From a cold start it requires about three minutes to complete this process.  During the start-up time all the candidate streams are parsed and monitored to ensure they are stable, and the precise location of the data is determined. You can see a count down timer in the Nearest tab when this is occurring. Once at least one suitable stream has been selected, the NEAR pool will be created and entered into the Caster table.

During this short period time to startup, the NTRIP Clients cannot connect to the NEAR pool and there is no entry in the Caster Table for it.  Of course all of the other streams are available or connection as soon as they come online.  NTRIP Clients receive the normal Caster table (as per the NTRIP protocol) and are disconnected until the NEAR pool is published.

As new Base Station streams come and go, the pool members are evaluated and managed.  Because of this, when there is a failure in a base station which then resumes sending data, it will be automatically restored to the pool without user intervention.  The current members of the pool can displayed at any time (in both the console and the map display) by pressing the View Map button in the Nearest tab.  You can also hover over the button and the tool tip will list the current pool members.

On Base Station Failures and Hand-Offs

When any Base Station used in a NEAR pool fails, all the clients connected to it are automatically re-assigned to the next closest suitable stream.  This event is reflected in the console log.  The process is automatic and serves to provide uninterrupted services to critical users.  When a change is made, the current EFEC message for that stream is sent out first to enable the rover device to detect that the data source has changed.

This process will repeat as needed until there are no suitable streams available to be used. An event where multiple Base Station failures have occurred is typically very rare and is more often associated with regional internet failure events. Here is an example of what the log will say for a NTRIP Client connect to a near stream when five Base Stations were caused to fail in short order (this was a test case not an actual event).

[C22]:    A client Changed Stream event has just occurred, moving connection from: SCSC now --> to: SCSC02
[C22]:    A client Changed Stream event has just occurred, moving connection from: SCSC02 now --> to: AZU1_RTCM3
[C22]:    A client Changed Stream event has just occurred, moving connection from: AZU1_RTCM3 now --> to: CLAR_RTCM3
[C22]:    A client Changed Stream event has just occurred, moving connection from: CLAR_RTCM3 now --> to: P612_RTCM3
[C22]:    A client Changed Stream event has just occurred, moving connection from: P612_RTCM3 now --> to: gisar30
[gisar30]:  Client C22 disconnected, because no other suitable NEAR stream was found in NEAR3 pool


Selecting a Maximum Connection Distance

The NEAR controls allow a simple baseline distance value to be set, beyond which an NTRIP Client rover can not connect to a Base Station.  Different values can be set for the RTCM2 and RTCM3 NEAR stream to reflect the decorrelation limits you wish to allow. The default value for RTCM3 streams is 60km, a reasonable distance for L1-L2 RTK applications. See this article on the NEAR controls for further details.

Aside: If you operate a NEAR stream without a region being defined or used (that is, to allow any stream located anywhere in the world can be part of the pool), then this threshold value becomes your primary way to prevent users beyond a reasonable coverage area from connecting to the closest member of the pool. Consider a pool operating the general southeast Michigan area (Detroit) and a user in Chicago Illinois. The distance between these two points is about ~480km.  If the Maximum Baseline Distance were set to 5000km such a connection would be allowed to occur.  It is conceivable such a long baseline might be used with RTCM2 (DGPS methods) but but not with RTK.

Further Information

The NEAR MountPt Setting Dialog is explained here.

Was this article helpful?

Related Articles

Help us make this topic better...