This article deals with the several common problems using the NEAR streams that SNIP operators have experienced and how to correct them.
The symptoms often start with “…my Rover is not getting any data from the Caster’s NEAR pointPt even thought it connects to it…” The resolution process needs to first determine if the issue is on the Rover side or the Caster side. If other Rover devices are observed to be working fine, presume the issue is isolated to that rover. Otherwise presume the problem may reside at the Caster. A few common points to check for each are provided below.
NTRIP Client, Rover Side Issues
In order for the NTRIP Client device to get data from a NEAR point, it must first connect to it, and then send its approximate location in a NMEA $GGA string. From that location, the Caster will determine which data stream best suits its needs (typically the closest) and send it data from that stream. This assignment is reevaluated every time a new $GGA string is sent to it. If the location provided is too far from ANY suitable Base Station in the pool used by that NEAR stream, the user device is disconnected. If no location is provided, then after a short period time time (~15 seconds), the user device is disconnected. This assignment process creates entries in the console log the SNIP operator can review. User devices that repeatably disconnect and reconnect after a prior failure may in time be banned for a period of time depending on the Ban IP setting of the Caster.
To troubleshoot a problem NTRIP Client device, confirm the following.
Is it connecting?
If the device connecting to SNIP, you can see this in the console log. When debugging connection issues, is it best to set the console Log Threshold to Minor and enable the check box Show Connection Details (found on the Caster and Clients tab). No entry found in the logs indicates an internet connectivity issue to resolve first.
Two helpful articles that deal with the general client connection issues can be found here and here.
Is it Allowed to Connect?
If your Caster is closed, does this user device have a suitable account / password and are they using it? If the the credentials provided as “nearly correct” (such as an issue of capitalization) the log will mention this. [The user is not informed of this as doing so would be a security threat] Enure the user is connecting, and create a user account if one is needed.
Is it sending $GGA?
Is this user device sending in a suitable NMEA-183 $GGA sentence? Unless the devices reports its position to the Caster in this way, it will never be assigned to a mountPt (and hence not see any returned data).
The first five NMEA-183 $GGA sentences are report in the console log. The last reported position (as well accumulated the number of reported positions is show when a report of clients is made. If you do not see a NMEA-183 $GGA sentence listed, either the user device has not sent one, or it was ill formed.
Some user devices do not send well-formed $GGA sentences (often the final carriage return and line feed is missing, other times the accuracy is incorrect, or the msg checksum may be wrong). Some user devices do not send the $GGA sentence at the right time. In Rev 1 NTRIP, the $GGA sentences should be sent after the acknowledgment from the Caster is returned. In Rev 2 NTRIP, the $GGA sentence can also be sent in the header.
Checking the checkbox labeled Loose NMEA $GGA which is found on the Caster and Clients tab will instruct SNIP to allow such ill-formed $GGA sentences and placements to be used.
With NEAR streams, SNIP will wait for 15 seconds from the time the connection is made for the user device to send in a first $GGA sentence. If nothing is sent by that time, the user device is disconnected. There is no required rate for subsequent $GGA sentence, some device send only an initial $GGA sentence by design.
Is the $GGA location reasonable?
Examine the data in the NMEA-183 $GGA sentence from the user device. Is the location being sent reasonable for the device? In order to receive data from a NEAR stream, the device must report its position as being within the Caster coverage area for at least one Base Station in the near stream. If the distance to the closest Base Station is too far away (the Maximum Base Line Distance which set in the NEARest MountPt Settings dialog), the user device will be disconnected.
A common occurrence during initial Rover power up is that the user device connects but then reports either an invalid Lat/Lon or one centered at 0,0. As there is no suitable MountPt, the user device will be disconnected. The device then reconnects and this pattern repeats. Once the GNSS of the user device starts to provide valid data, a stable connection will occur.
It it too far way from a suitable mountPt?
The repeat from the above, if the device reports a position that is larger than the Maximum Base Line Distance to any Base Station in the NEAR pool, the user device will be disconnected. The console will note this event if it occurs. Conceivably, a device may also initially connect at the very edge of the allowed distance and then be disconnected when it reports it has moved beyond that value.
Is it then assigned to a mountPt
Every time the $GGA sentence is received by SNIP an evaluation process occurs. The distance to all members of the pool which also have certain quality metrics is computed, and the device may then be re-assigned to a different stream as conditions warrant. This is discussed further in other articles. What is of value in the process of debugging that the assignment of the user device to a given data stream is also shown in the console.
With the initial $GGA and with further $GGA messages that cause a Base Station assignment change; you will see the user device being assigned in the console. Does this assignment occur and make logical sense. You will see the user is then getting data from the assigned mountPt.
It is getting data, but data that it cannot use?
If an NTRIP Client (user device) is getting data it cannot, it typically indicates that it expect another format (RTCM3 vs CMR for example). Use the normal message viewing tools in SNIP to confirm that the data stream content what you expect. This is rarely an issue with NEAR streams and pool, as membership in the pool implies that the stream contents meet certain content features (such as being only RTCM3 messages or only RTCM2 etc.). If this is suspected, having the user device connect directly to data stream (mountPt) can be useful to confirm its use.
NTRIP Caster, SNIP Side issues
Recapping how a NEAR pool is formed… For any Base Station to be used in the pool, it requires 3 minutes of stable data from a source with a known location (either the LLH entry from the Caster table or the EFEC location from the messages must be present). It must meet any content features (such as being RTCM3 format and have L2 data messages). Therefore for RTCM3 streams (the most common), the data must be parsed. For streams SNIP does not parse and understand (such as the various flavors of CMR) the message format type in the Caster Table entry is used to determine what the stream contains.
NOTE: Running NEAR pool requires a Basic, Pro, or Enterprise license for SNIP. A Basic license may run a single NEAR pool consisting of parsed RTCM3.x message content. A Pro or Enterprise license may run up to five separate NEAR pools at once, each consisting of any content message content type desired (RTCM 3.x, RTCM 2.x, CMR, CMR+, MBEN, JPS, HEMI, LB2, Leica4G, NVS, SBF, R17, R27, uBlox, UBX, BINEX, and ‘Any’ (indicating any type is to be allowed)). For every additional ten data streams which are licensed on the node, an additional NEAR pool is also added. During Evaluation, the Basic license abilities are supported.
To troubleshoot a problems with a NEAR pool on the Caster, confirm the following.
Is the NEAR Pool Active?
Each NEAR pool requires 3 minutes to fully start. Each possible member of the a NEAR pool also requires three minutes before it can considered to join a pool. This time is used to enure that the data stream is stable, and therefore usable. If a data stream is unstable (in this case, if it were to drop offline), it will be removed from the pool until it is stable again. [Any devices assign to a dropped stream will then be re-assigned]
The Base Stations which are members of each NEAR pool can easily be seen by hovering the mouse over that slot and reading the tool tip.
Is the NEAR Pool message content correct?
If you are using NEAR streams with an Evaluation or Basic model, you are able to run a single RTCM3 pool. The Pro model can also run pools made up of other formats including (list here), and can run five or more NEAR stream at once.
The type of message content is listed in the Caster Table entry, in the same manner as any other stream. But is is possible that the NTRIP Client (user device) has connect to a stream it does not understand. Confirm the device can accept the message content found in the NEAR stream it connects to. Use the Require Specific Stream Content options in the NEARest MountPt Setting dialog to control what content members of NEAR pool must have to join.
Does the Pool contain the Expected members?
Are the Base Stations you expect to be included in the pool present (use the slots tool tip to see a list with station details)? If the closest stream to a given user is offline, SNIP will select the next closet stream. But is none of the available streams is within the baseline limit, the user will be disconnected.
If a Base Station is present and providing data, but not part of the expected pool – is that data parsed? If you have disabled parsing on an RTCM3 stream, it will not be added to the RTCM3 pool.
Is the Base Station sending and RTCM 3 message type 1005 or 1006? Use the Show Message Types right-click menu item to quickly see. These are the critical message types that inform the rover devices where the Base Station is precisely located. The rover is not able to use the message stream for RTK solution without this data. Some Base Stations will not immediately send these message when they have been reset, waiting for periods of 5 minutes before sending.
Do the member provide a common LLH/ECEF reference frame?
This issue occur when the data switch from one Base Station to another and causes the rover device to “jump” in its reported position. This is inevitably traces back to the use of by multiple reference frames between the different member so of the pool. This may also be due to incorrect or inconsistent base station location during its set up. Both effect can be removed using the PFAT translate tools to align the report positions to a common frame. Here is an article that describes how this is done
Is the Region of the Pool, and the enclosing distance, for each Member correct?
When setting up a NEAR point, a regional center point can be defined and used. This feature is most often found when using multiple disjoint NEAR regions. It is used enclose a specific set of Base Station for consideration in the the pool, while excluding those outside of the defined region. [The RTK2go.com NEAR mountPTs NEAR-JPNn and NEAR-JPNs (Japan North and Japan South) are an example of this use.]
If a regional center point has been be defined, does it make sense and is the “radius limit” setting large enough to contain (enclose) all the streams that are desired. Recall that the radius limit sets the radius of the resulting circle around the regional center point. It is independent from the Maximum Baseline Distance used to set the allow distance from the rover to a given Base Station. Setup details regarding the use of the regional center point are described further here.
The above serves to provide some advice on how to debug problems with near pool connections. General information about the use of NEAR pools can be found in this section of the knowledge base.