{"id":5332,"date":"2018-06-11T17:39:16","date_gmt":"2018-06-11T17:39:16","guid":{"rendered":"https:\/\/www.use-snip.com\/kb\/?post_type=ht_kb&p=5332"},"modified":"2020-06-13T21:39:28","modified_gmt":"2020-06-13T21:39:28","slug":"near-stream-serves-no-data","status":"publish","type":"ht_kb","link":"https:\/\/www.use-snip.com\/kb\/knowledge-base\/near-stream-serves-no-data\/","title":{"rendered":"NEAR stream serves no data"},"content":{"rendered":"

This article deals with the several common problems using the NEAR streams that SNIP<\/strong><\/span> operators have experienced and how to correct them.<\/p>\n

The symptoms often start with “…my Rover is not getting any data from the Caster’s NEAR pointPt even thought it connects to it…<\/em>”\u00a0\u00a0 The resolution process needs to first determine if the issue is on the Rover side or the Caster side.\u00a0 If other Rover devices are observed to be working fine, presume the issue is isolated to that rover.\u00a0 Otherwise presume the\u00a0 problem may reside at the Caster.\u00a0 A few common points to check for each are provided below.<\/p>\n

NTRIP Client, Rover Side Issues<\/h2>\n

In order for the NTRIP Client<\/a> device to get data from a NEAR point, it must first connect to it, and then send its approximate location in a NMEA $GGA<\/a> string.\u00a0 From that location, the Caster will determine which data stream best suits its needs (typically the closest) and send it data from that stream.\u00a0 This assignment is reevaluated every<\/em> time a new $GGA string is sent to it.\u00a0 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.\u00a0 If no location is provided, then after a short period time time (~15 seconds), the user device is disconnected.\u00a0 This assignment process creates entries in the console log the SNIP<\/strong><\/span> operator can review.\u00a0 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.<\/p>\n

To troubleshoot a problem NTRIP Client device, confirm the following.<\/p>\n

Is it connecting?<\/h3>\n

If the device connecting to SNIP<\/strong><\/span>, you can see this in the console log.\u00a0 When debugging connection issues, is it best to set the console Log Threshold to Minor<\/em> and enable the check box Show Connection Details<\/em> (found on the Caster and Clients<\/em> tab).\u00a0 No entry found in the logs indicates an internet connectivity issue to resolve first.<\/p>\n

Two helpful articles that deal with the general client connection issues can be found here<\/a> and here<\/a>.<\/p>\n

Is it Allowed to Connect?<\/h3>\n

If your Caster is closed, does this user device have a suitable account \/ password and are they using it?\u00a0 If the the credentials provided as “nearly correct”\u00a0 (such as an issue of capitalization) the log will mention this.\u00a0 [The user is not informed of this as doing so would be a security threat]\u00a0 Enure the user is connecting, and create a user account<\/a> if one is needed.<\/p>\n

Is it sending $GGA?<\/h3>\n

Is this user device sending in a suitable NMEA-183 $GGA<\/a> sentence?\u00a0\u00a0 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).<\/p>\n

The first five NMEA-183 $GGA sentences are report in the console log.\u00a0 The last reported position (as well accumulated\u00a0 the number of reported positions is show when a report of clients is made.\u00a0 If you do not see a NMEA-183 $GGA sentence listed, either the user device has not sent one, or it was ill formed.<\/p>\n

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).\u00a0 Some user devices do not send the $GGA sentence at the right time.\u00a0 In Rev 1 NTRIP, the $GGA sentences should be sent after<\/em> the acknowledgment from the Caster is returned.\u00a0 In Rev 2 NTRIP, the $GGA sentence can also be sent in the header.<\/p>\n

Checking the checkbox labeled Loose NMEA $GGA <\/strong><\/em>which is found on the Caster and Clients<\/em> tab will instruct SNIP<\/strong><\/span> to allow such ill-formed $GGA sentences and placements to be used.<\/p>\n

With NEAR streams, SNIP<\/strong><\/span> will wait for 15 seconds from the time the connection is made for the user device to send in a first $GGA sentence.\u00a0 If nothing is sent by that time, the user device is disconnected.\u00a0 There is no required rate for subsequent $GGA sentence, some device send only an initial $GGA sentence by design.<\/p>\n

Is the $GGA location reasonable?<\/h3>\n

Examine the data in the NMEA-183 $GGA sentence from the user device.\u00a0 Is the location being sent reasonable for the device?\u00a0 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.\u00a0 If the distance to the closest Base Station is too far away (the Maximum Base Line Distance<\/em> which set in the NEARest MountPt Settings<\/strong> dialog), the user device will be disconnected.<\/p>\n

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.\u00a0 As there is no suitable MountPt, the user device will be disconnected.\u00a0 The device then reconnects and this pattern repeats.\u00a0 Once the GNSS of the user device starts to provide valid data, a stable connection will occur.<\/p>\n

It it too far way from a suitable mountPt?<\/h3>\n

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.\u00a0 The console will note this event if it occurs.\u00a0 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.<\/p>\n

Is it then assigned to a mountPt<\/h3>\n

Every time the $GGA sentence is received by SNIP <\/strong><\/span>an evaluation process occurs.\u00a0 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.\u00a0 This is discussed further in other articles.\u00a0 What is of value in the process of debugging that the assignment of the\u00a0 user device to a given data stream is also shown in the console.<\/p>\n

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.\u00a0 Does this assignment occur and make logical sense.\u00a0 You will see the user is then getting data from the assigned mountPt.<\/p>\n

It is getting data, but data that it cannot use?<\/h3>\n

If an NTRIP Client (user device) is getting data it cannot, it typically indicates that it expect another format (RTCM3 vs CMR for example).\u00a0 Use the normal message viewing tools in SNIP<\/strong><\/span> to confirm that the data stream content what you expect.\u00a0 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.<\/p>\n

 <\/p>\n

NTRIP Caster, SNIP<\/strong><\/span> Side issues<\/h2>\n

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).\u00a0 Therefore for RTCM3 streams (the most common), the data must be parsed. For streams SNIP<\/strong><\/span> 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.<\/p>\n

NOTE<\/strong><\/span><\/em>: Running NEAR pool requires a Basic<\/strong><\/em><\/span>, Pro<\/strong><\/em><\/span>, or Enterprise<\/strong><\/em><\/span> license for SNIP.\u00a0 A Basic<\/em><\/strong><\/span> license may run a single NEAR pool consisting of parsed RTCM3.x message content.\u00a0 A Pro<\/em><\/strong><\/span> or Enterprise<\/em><\/strong><\/span> 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 \u2018Any\u2019 (indicating any type is to be allowed)).\u00a0 For every additional ten data streams which are licensed on the node, an additional NEAR pool is also added.\u00a0 During Evaluation<\/em><\/strong><\/span>, the Basic<\/em><\/strong><\/span> license abilities are supported.<\/p>\n

To troubleshoot a problems with a NEAR pool on the Caster, confirm the following.<\/p>\n

Is the NEAR Pool Active?<\/h3>\n

Each NEAR pool requires 3 minutes to fully start.\u00a0 Each possible member of the a NEAR pool also requires three minutes before it can considered to join a pool. \u00a0 This time is used to enure that the data stream is stable, and therefore usable.\u00a0\u00a0\u00a0 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]<\/p>\n

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.<\/p>\n

Is the NEAR Pool message content correct?<\/h3>\n

If you are using NEAR streams with an Evaluation<\/em> <\/strong><\/span>or Basic<\/em> <\/strong><\/span>model, you are able to run a single RTCM3 pool.\u00a0 The Pro<\/em> <\/strong><\/span>model\u00a0 can also run pools made up of other formats including (list here), and can run five or more NEAR stream at once.<\/p>\n

The type of message content is listed in the Caster Table entry, in the same manner as any other stream.\u00a0 But is is possible that the NTRIP Client (user device) has connect to a stream it does not understand.\u00a0 Confirm the device can accept the message content found in the NEAR stream it connects to.\u00a0 Use the Require Specific Stream Content<\/strong><\/em> options in the NEARest MountPt Setting<\/a> dialog to control what content members of NEAR pool must have to join.<\/p>\n

Does the Pool contain the Expected members?<\/h3>\n

Are the Base Stations you expect to be included in the pool present (use the slots tool tip<\/a> to see a list with station details)?\u00a0 If the closest stream to a given user is offline, SNIP<\/strong><\/span> will select the next closet stream.\u00a0 But is none of the available streams is within the baseline limit, the user will be disconnected.<\/p>\n

If a Base Station is present and providing data, but not part of the expected pool – is that data parsed?\u00a0 If you have disabled parsing on an RTCM3 stream, it will not be added to the RTCM3 pool.<\/p>\n

Is the Base Station sending and RTCM 3 message type 1005 or 1006?\u00a0 Use the Show Message Types<\/em> right-click menu item to quickly see.\u00a0 These are the critical message types<\/a> that inform the rover devices where the Base Station is precisely located.\u00a0 The rover is not able to use the message stream for RTK solution without this data.\u00a0\u00a0 Some Base Stations will not immediately send these message when they have been reset, waiting for periods of 5 minutes before sending.<\/p>\n

Do the member provide a common LLH\/ECEF reference frame?<\/h3>\n

This issue occur when the data switch from one Base Station to another and causes the rover device to “jump” in its reported position.\u00a0 This is inevitably traces back to the use of by multiple reference frames between the different member so of the pool.\u00a0 This may also be due to incorrect or inconsistent base station location during its set up.\u00a0 Both effect can be removed using the PFAT<\/a> translate tools to align the report positions to a common frame.\u00a0 Here is an article<\/a> that describes how this is done<\/p>\n

Is the Region of the Pool, and the enclosing distance, for each Member correct?<\/h3>\n

When setting up a NEAR point, a regional center point<\/em> can be defined and used.\u00a0 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.\u00a0 [The RTK2go.com NEAR mountPTs\u00a0 NEAR-JPNn<\/em> and NEAR-JPNs<\/em> (Japan North and Japan South) are an example of this use.]<\/p>\n

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.\u00a0\u00a0 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<\/em> used to set the allow distance from the rover to a given Base Station.\u00a0 Setup details regarding the use of the regional center point are described further here<\/a>.<\/p>\n

 <\/p>\n

\n

The above serves to provide some advice on how to debug problems with near pool connections.\u00a0\u00a0 General information about the use of NEAR pools can be found in this section<\/a> of the knowledge base.<\/p>\n","protected":false},"excerpt":{"rendered":"

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…”\u00a0\u00a0 The resolution process needs to […]<\/p>\n","protected":false},"author":13,"comment_status":"open","ping_status":"closed","template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"ht-kb-category":[282],"ht-kb-tag":[292,102],"class_list":["post-5332","ht_kb","type-ht_kb","status-publish","format-standard","hentry","ht_kb_category-nearest-caster","ht_kb_tag-near","ht_kb_tag-troubleshooting"],"_links":{"self":[{"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb\/5332","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb"}],"about":[{"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/types\/ht_kb"}],"author":[{"embeddable":true,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/comments?post=5332"}],"version-history":[{"count":16,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb\/5332\/revisions"}],"predecessor-version":[{"id":7033,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb\/5332\/revisions\/7033"}],"wp:attachment":[{"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/media?parent=5332"}],"wp:term":[{"taxonomy":"ht_kb_category","embeddable":true,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb-category?post=5332"},{"taxonomy":"ht_kb_tag","embeddable":true,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb-tag?post=5332"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}