Recently a few SNIP users have asked about using the NMEA-183 $GPGGA sentence from connected rovers to track their community of users. 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. We been adding new reporting and mapping feature to SNIP to further support this need.
This article discusses some of the finer points regarding how these sentences are used (or abused) inside any NTRIP Caster system. You can set your copy of SNIP 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. But, having NTRIP Clients sending extra NMEA-183 $GPGGA sentences may cost end users in terms of cellular connection bandwidth.
Why does an NTRIP Client send an NMEA-183 $GPGGA sentence to the caster?
When a rover (an NTRIP Client) connects to an NTRIP Caster such as SNIP, particularly a caster offering either a NEAR or a Virtual Reference Station (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. That is really all there is to it. Any NTRIP Caster offering single baseline connections (such as SNIP) does not typically need this information; the NTRIP Client is simply connected to the stream asked for (if it exists).
Some (in fact many) “VRS” systems are not “Virtual” at all, they simply connect to the closest operational Reference Station in their network. Mount Points with terms like “iMax” or “near” in them are typical of this type. You can use SNIPSs NEAR tab to create this sort of network. Here is a quick comparison article of some VRS mountPt differences taken from a typical Leica system operating in Lombardy.
A note to RTKLIB users: Rovers send NMEA-183 $GPGGA sentences to Casters, while Base stations do not. You can manually enter in a fake LLH data for your testing needs with tools like RTKNAVI. But many NTRIP Casters will look at the provided data and, if it is out of their overall service area, will not reply with any data. If you will be doing that routinely, then consider setting up a SNIP node with your favorite connection points renamed using the vanity name feature in such as way that makes sense for your needs. And you can rename you NEAR streams in the same ways, NEAR3 might be better named NEAR3-MyOffice, as an example.
How does the Caster use this information
As mentioned above, the NTRIP Caster uses this data to decide what data stream the user will receive. 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. This is why some VRS mountPt connections can take many tens of seconds to reply with the initial data. In casters which do not create unique data products, the process is simply to select which existing data feed to connect the user to.
Aside: 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. When in doubt, look on their web pages and then verify what you see using the MAP display dialog in SNIP. SNIP will show the actual ECEF data recovered from the stream, so you can determine if it is a physical site or not.
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. 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). 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.
Note that SNIP does not in fact need any NTRIP Client data for single baselines (except for those clients connected to a NEAR mountPt). When you set up the single baseline streams you will offer on SNIP, you have already “localized” any VRS data stream to the LLH location when the connection was established.
How does SNIP report this information
When SNIP 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. [From release 1.5.0 onwards, the moving positions of rovers are plotted on the map.]
When SNIP has a client/rover connecting to a NEAR stream, then the rover’s GGA data is also used to evaluate which base station in the NEAR pool to connect the rover to. When the connection is made to a new, different, base station, this is noted in the console log.
Hint: 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 List Current Users… button found on the Caster and Clients tab.
SNIP also creates and uses its own $GPGGA sentences when connecting to remote Casters using the remote-relay method. This is provided to support sending that Caster coordinates it can use. See this article for further details on use.
Different NTRIP Clients behave in various ways
The behavior seen in different NTRIP Clients can vary considerably. Most clients are fairly simple and the least featured do not offer the ability to send the $GPGGA sentence at all. Some clients never even look at the Caster table details where the sending of NMEA is defined. NTRIP Clients can be broadly classified as follows.
There are NTRIP Clients that:
- Do not support sending NMEA sentences at all
- Send one NMEA-183 $GPGGA sentence once at initial connection,
but one that is ill-formed or has incorrect time - Send NMEA-183 $GPGGA sentences all the time (even when not wanted)
- Send other forms of unwanted NMEA-183 sentences (bandwidth pigs)
- Send NMEA-183 $GPGGA sentences once and only once at connection start
- Send NMEA-183 $GPGGA periodically and according to the end user settings
(this is the most common type) - Send NMEA-183 $GPGGA according the Caster Table flags
(and the user settings to be periodic if allowed) - Send NMEA-183 $GPGGA according the Caster Table flags, but incorrectly
(and the user settings to be periodic if allowed)
In broad protocol terms, the NTRIP client must first connect (get an HTTP “OK” reply) and only then should it send the sentence. NTRIP protocol revision 2 (which does not have very broad industry acceptance at this time) does allow sending the sentence in the original header. SNIP supports both protocol formats. And SNIP correctly copes with all of the above real world examples.
After the initial sending event, most NTRIP Clients will then send a sentence every X seconds thereafter; where X is the number of seconds set by the end user (and is typically 5, 10, 15, 30, 60 seconds or so). A few NTRIP Clients will align the sending time with the rover’s GNSS clock (Hemisphere is one). The precise delay between sending times is not overly critical to either party.
Some NTRIP Clients will time out and reconnect if no data stream is forthcoming (this can be a common issue with any initial VRS setup that takes time). Others will reconnect, or even resend the setup data on the same connection very quickly. Most of these details are transparent to the SNIP owner/operator, but can be helpful to understand what is occurring when a user cannot connect. The knowledge base has some articles on debugging client connections in this regard.
What does the official RTCM SC-104 standard say?
Well, you will need to buy it (see here) to read it in context but the key concern is the <nmea> flag, the use of which is described in a table as follows. From RTCM STANDARD 10410.1 NETWORKED TRANSPORT OF RTCM via INTERNET PROTOCOL (Ntrip) – Version 2.0:
Capability of Caster to receive NMEA message with approximate position from Client
0 = Caster is not able to handle incoming NMEA message with approximate position from Client
1 = Caster is able to handle incoming NMEA GGA message with approximate position from Client
Terms such as “is able to handle” are not defined and elsewhere in the document it points out that a caster must be ready to consume other NMEA messages coming from clients.
A widely available unofficial pre-standard draft states provides some slightly outdated text:
5.4 NMEA REQUEST MESSAGES
For some network-dependent applications it is necessary to send the position of the NtripClient to the NtripCaster. That position could be used by the NtripCaster to provide a data stream for a Virtual Reference Station (VRS) or to determine the best data stream to broadcast. Ntrip allows clients to send NMEA strings after the HTTP request for a data stream. If the <nmea> parameter is set to “1” (see Source-table section), the NtripCaster must receive at least one NMEA GGA string to prepare the data and start sending. The NtripClient is allowed to send more than one NMEA GGA string or NMEA strings of other type than GGA at any time. The following is an example of a request to a source-table named “vrs_bayern” to get a data stream generated for a virtual reference station with the coordinates of the NMEA string:….. [no example is given]
(See official RTCM documentation available from http://www.rtcm.org/orderinfo.php for further details.)
You can see here the original design intent was more to keep an NTRIP Client from sending the NMEA-183 $GPGGA sentences to the Caster. Today it more often is taken to mean: “if you do not send it, then I (the Caster) will not send you any data in return” or “I can handle that sort of data” which has become the more common meaning today.
What does all this mean for SNIP
It means that if you want those few NTRIP Client user devices who DO pay close attention to the key caster <nmea> flag in the caster table to send you any periodic $GPGGA data – you will need to tell them to do so. [Otherwise you will probably get one and only one sentence.]
Other than keeping tabs on the NTRIP Clients, there is no technical reason to do this. SNIP is generally a single baseline NTRIP Caster, in that you can connect to many VRS devices, but your users get the single point which you connected to. That is true UNLESS, you are running a NEAR stream. If you attach a serial port to a GNSS device with SNIP, or use PUSH-In data, these are also single baseline connections. Within SNIP the only time you as an operator need to send $GPGGA data is for a Remote-Relay connection to a VRS, and this is easily handled with the relay stream connection dialog.
In order to expressly instruct your NTRIP Client users to send you periodic $GPGGA data, you need to change it in the caster table entries. To support the need to be able to have NTRIP Clients send $GPGGA sentence a global preference has been added to the SNIP code base and is called “Request User Positions” (it is found in the Preferences… dialog, available under the Edit menu).
When set to be active, SNIP will modify all caster table entries to ensure it tells other parties connecting to that stream that a periodic $GPGGA data is desired and can be handled. It is up to the NTRIP Client how often this data is sent, but values from 5~60 seconds are common. Many NTRIP Clients also allow setting the data rate. If a client device sends this data, SNIP will report it. If a client does not, SNIP will not record or report anything. Unlike most VRS connections, the client will never be disconnected if they do not send the $GPGGA sentence. (again except in the case of NEAR connections where the location is needed to select which base station is to be used).
Aside: Please keep in mind that many NTRIP Clients are going to send your SNIP node periodic $GPGGA data regardless of whether you ask for it or not. SNIP has a normal filter method that will alert you to this sort of content the first five times it occurs for each user connection and then filter it from the log to prevent clutter. If you wish to see the last $GPGGA sentence for a user (as well as a count of the number received), it is shown when you press List Current Users on the Caster and Clients tab.
How to do it, explained more tersely
If you want to instruct every NTRIP Client user to to send SNIP periodic $GPGGA data do this: Select the menu item Edit, submenu Preferences. The Preferences… dialog will appear; select the check box marked Always Accept NMEA-183 $GPGGA data and click okay. The <nema> value in each new Caster table entry will now be set to “1” indicating to those rovers which follow this flag that periodic $GPGGA data should be sent.
There are a few NTRIP Clients that also need to see the Caster Table “Solution” flag set to “network” (not “single”) in order to send periodic $GPGGA data. Some devices appear to send the data more often if this is set as a network solution. Sending the rover position every second or so can be of value with rapidly moving vehicles. It also produces nice AVL (automatic vehicle location) plots of your connected rovers, but SNIP does need prior locations in order to operate.