{"id":2481,"date":"2016-11-07T18:10:16","date_gmt":"2016-11-07T18:10:16","guid":{"rendered":"\/?post_type=ht_kb&p=2481"},"modified":"2020-08-29T21:59:43","modified_gmt":"2020-08-29T21:59:43","slug":"subtle-issues-with-using-ntrip-client-nmea-183-strings","status":"publish","type":"ht_kb","link":"https:\/\/www.use-snip.com\/kb\/knowledge-base\/subtle-issues-with-using-ntrip-client-nmea-183-strings\/","title":{"rendered":"Subtle issues with using NTRIP Client NMEA-183 strings"},"content":{"rendered":"

Recently a few SNIP<\/strong> <\/span>users have asked about using the NMEA-183 $GPGGA sentence from connected rovers to track their community of users.\u00a0\u00a0 The rationale for wanting this varies. Some just want to know who is using their network, others want to provide field support, and still others want to use this data for simple GIS\/AVL tracking.\u00a0 We been adding new reporting and mapping feature to SNIP<\/strong><\/span> to further support this need.<\/p>\n

This article discusses some of the finer points regarding how<\/em> these sentences are used (or abused) inside any NTRIP Caster system.\u00a0 You can set your copy of SNIP<\/strong> <\/span>in this regard any way you wish; none of the discussed features will affect your user’s ability (more correctly their NTRIP Client’s ability) to log in and get data.\u00a0 But, having NTRIP Clients sending extra\u00a0 NMEA-183 $GPGGA<\/a> sentences may cost end users in terms of cellular connection bandwidth.<\/p>\n

Why does an NTRIP Client send an NMEA-183 $GPGGA sentence to the caster?<\/h4>\n

When a rover (an NTRIP Client<\/a>) connects to an NTRIP Caster<\/a> such as SNIP<\/strong><\/span>, particularly a caster offering either a NEAR<\/a> or a V<\/span>irtual R<\/span>eference S<\/span>tation (VRS) connections, the rover device provides a basic NMEA-183 $GPGGA sentence to the NTRIP Caster so it can decide what would be the best data stream (typically the closest) to send back to it<\/span>.\u00a0\u00a0 That is really all there is to it.\u00a0 Any NTRIP Caster offering single baseline connections (such as SNIP<\/strong><\/span>) does not typically need this information; the NTRIP Client is simply connected to the stream asked for (if it exists).<\/p>\n

Some (in fact many) “VRS” systems are not “Virtual” at all, they simply connect to the closest operational Reference Station in their network.\u00a0 Mount Points with terms like “iMax” or “near” in them are typical of this type.\u00a0 You can use SNIPS<\/strong><\/span>s NEAR tab<\/a> to create this sort of network.\u00a0 Here is a quick comparison article<\/a> of some VRS mountPt differences taken from a typical Leica system operating in Lombardy.<\/p>\n

A note to RTKLIB users:<\/strong><\/span>\u00a0 Rovers<\/em> send NMEA-183 $GPGGA sentences to Casters<\/em>, while Base stations do not.\u00a0 You can manually enter in a fake LLH data for your testing needs with tools like RTKNAVI.\u00a0 But many\u00a0 NTRIP Casters will look at the provided data and, if it is out of their overall service area, will not reply with any data.\u00a0 If you will be doing that routinely, then consider setting up a SNIP<\/strong><\/span> node with your favorite connection points renamed using the vanity name<\/strong> feature in such as way that makes sense for your needs.\u00a0 And you can rename you NEAR streams in the same ways, NEAR3<\/em> might be better named NEAR3-MyOffice<\/em>, as an example.<\/p>\n

How does the Caster use this information<\/h4>\n

As mentioned above, the NTRIP Caster uses this data to decide what data stream the user will receive.\u00a0 In the case of a system offering “real” virtual connections, a process unique to that user connection must be started to systematically create the requested data products from the network sources.\u00a0 This is why some VRS mountPt connections can take many tens of seconds to reply with the initial data.\u00a0\u00a0 In casters which do not create unique data products, the process is simply to select which existing data feed to connect the user to.<\/p>\n

Aside<\/strong><\/span>: Many US statewide network deployments have moved to no longer providing a large list of mount points, preferring to use various means like this to allow users to connect to the nearest physical site.\u00a0 When in doubt, look on their web pages and then verify what you see using the MAP display<\/a> dialog in SNIP<\/strong><\/span>.\u00a0 SNIP<\/strong> <\/span>will show the actual ECEF data recovered from the stream, so you can determine if it is a physical site or not.<\/p>\n

Both of these variations will also monitor the subsequent stream of NMEA-183 $GPGGA sentences from each rover to periodically re-evaluate the data that the end user is being sent.\u00a0 This is why the $GPGGA sentence is re-sent periodically (and why the client may be suddenly disconnected by the Caster if it does not send a new sentence every few seconds).\u00a0 As the rover moves, it can transparently be switched to a new (closer) base station. This data is also used for recovery when a GNSS base station suddenly goes offline, typically switching each connected user to the next closest station.<\/p>\n

Note that SNIP<\/strong> <\/span>does not in fact need any NTRIP Client data for single baselines (except for those clients connected to a NEAR<\/a> mountPt).\u00a0 When you set up the single baseline streams you will offer on SNIP<\/strong><\/span>, you have already “localized” any VRS data stream to the LLH location when the connection was established.<\/p>\n

How does SNIP report this information<\/h4>\n

When SNIP<\/strong><\/span> is not using the client\/rover’s GGA data to control the corrections which the user receives, it simply reports it to the operator on the console log (the first few times) and then updates a record which is then used in connected user reports.\u00a0 [From release 1.5.0 onwards, the moving positions of rovers are plotted on the map.]<\/p>\n

When SNIP<\/strong><\/span> has a client\/rover connecting to a NEAR<\/a> stream, then the rover’s GGA data is also used to evaluate which base station in the NEAR pool to connect the rover to.\u00a0 When the connection is made to a new, different, base station, this is noted in the console log.<\/p>\n

Hint<\/strong><\/span>:\u00a0 Current details about any connect client (what base station it is connected to, the distance to that base station, and the number of NMEA-183 $GPGGA sentences received (and the last sentence) can be shown for all current users with the\u00a0 List Current Users…<\/strong> button found on the Caster and Clients tab<\/a>.<\/p>\n

SNIP<\/strong> <\/span>also creates and uses its own $GPGGA sentences when connecting to remote Casters using the remote-relay method.\u00a0 This is provided to support sending that Caster coordinates it can use.\u00a0 See this article<\/a> for further details on use.<\/p>\n

Different NTRIP Clients behave in various\u00a0 ways<\/h4>\n

The behavior seen in different NTRIP Clients can vary considerably.\u00a0 Most clients are fairly simple and the least featured do not offer the ability to send the $GPGGA sentence at all.\u00a0 Some clients never even look at the Caster table details where the sending of NMEA is defined.\u00a0 NTRIP Clients can be broadly classified as follows.<\/p>\n

There are NTRIP Clients that:<\/p>\n