The article came about when both a SNIP Caster deployment and an end user on RTK2go.com (a popular free public Caster) both had trouble using the BKG Ntrip Client (BNC) tool to connect and to send in NMEA-183 $GPGGA and $GNGGA sentences. Here is how to resolve it.

Hint:  The full manual for the BNC tool can be downloaded from here.

Background

Investigation (just looking at the details of the connections content, or lack of it, in the SNIP console logs) showed that the BNC tool was never connecting at all!  And the reason for this was that the Caster table had set all the table entries to state that a NMEA $GGA string should be sent in with the connection.  But the BNC tool had no such value, and hence never in fact connected.   In this article we cover how to set the BNC tool to send out a suitable $GGA string to overcome this issue.  [Here we use $GGA to mean either a $GPGGA or $GNGGA sentence, SNIP accepts both]

Why would the send NMEA flag be set for every Caster Entry?

This is a popular way for the NTRIP Caster operator to ask all the rover devices to send in their current locations (useful for AVL tracking).  When this flag is set (see the Preferences dialog), most Rover devices will just send the current data along.  Some will not (or cannot) send such data.  Many SNIP Caster operators (as well as other NTRIP Caster operators) will set this flag true for all entries, even when it is not used to determine what data to deliver to the rover devices.  Read more about how NMEA $GGA is used in NTRIP in this article.

Originally this flag meant that the rover device MUST send that data, and in the case of NEAR streams  or VRS streams this is still the case.  In the SNIP single baseline NEAR approach, the provided location is then used to determine which Base Station the Rover device will be connected to.  In a NEAR stream, the absence of the rover providing such a location results in a disconnect after a period of time, or when the location is beyond the service area.  See this article  for setup details.    The rate at which this data is sent, and the actual accuracy, can vary widely (and is up to the rover device).  Most devices send a new update very 5 or 10 seconds.

Note: The values sent from the Rover are typically NOT with RTK fixed accuracy. Often a simple autonomous filter solution is used (~2meters), and in any event the vertical data is corrupted by whatever local geoid model was used to create the NMEA string.  It is a good way to track devices, but that is about it.

How to Set it Up, Part One

First, add the subject stream in the normal BNC way.

Press the “Add Stream” button followed by “Caster” and then entering the Caster URL address and port and pressing the “Get Table” button.

At this point, pause a moment and widen the display table window so you can see the column marked “nmea” and note its value.  Any item with “yes” is asking for a NMEA $GGA string to be sent to it.  [Whether this value is in fact required to have data returned depends on the specific design.  For a NEAR stream this data is in fact needed.  See above remarks.]

If the entry is marked “yes” then BNC will simply not connect to it unless it also has a NMEA $GGA to use.   You must complete part two below.

If the entry is marked “no” then BNC does not need a NMEA $GGA sentence to connect, you can skip part two below.

Note also that NTRIP Rev1 and Rev 2 message styles are supported by the BNC tool (and also by SNIP).  The deployment of Rev2 devices (both Rovers and Casters) remains very limited at this point in time.  Rev 1 is recommended as it is universally supported.

How to Set it Up, Part Two

This is the area where there is a ‘trick’ to the BNC tools.   And as far as we are aware, you can only use this trick for one stream at a time.

The BNC tool uses the NMEA $GGA sentence which the end device provides.  Typically this is a GNSS device connected to a serial port that is being fed the RTCM data stream coming from the SNIP Caster.  Without the NMEA data, BNC cannot determine what the GGA sentence needs to be.  Because the Caster table says it must send one, it sends nothing at all.  This can confuse folks and often makes them think something is broken.

So, regardless of whether we use it or not, we need to open the “Serial Output” tab and setup a serial port with the same mountPt name.  Thankfully this works even if your machine does not have any serial ports.  Below is an example of the complete dialog tab for the mountPt AZU1_RTCM3. (AZU1 is a common mountPt near SNIPs development offices that is used as one the defaults when you first download and run SNIP in evaluation mode).

The only two settings that matter here are the “Mountpoint”   (we use the term mountPt) and the “NMEA” combo box selection.

The “Mountpoint” is set to be the name of the stream you wish to get.

The “NMEA” combo box is set to “Manual GPGGA”  (or to Manual GNGGA) and not to “no” or to “Auto”

The height value here provides a NMEA ht (not an ellipsoidal height) and the value does not matter in this application.

The Sampling value appears to have no effect on the rate at which the $GGA sentence is sent. It is presumed to be a threshold for how often data from the serial port would be forwarded.

This will then connect and work.

Remarks

Now that there is a source that BNC can associate with the NMEA $GGA sentence, it will try and connect in the normal way. You will then see data flowing and being counted in the main window for this stream.  A typical connection looks like this on the console:

A couple of additional issues may also prevent data from flowing and result in your NTRIP Client being disconnected:

1. If the Caster entry is a NEAR or VRS stream, the provided Lat-Lon must also be within the region area that is serviced by that stream, see the NEAR region controls for more details
2. The resulting NMEA $GGA sentence must be correctly formed. If a users NTRIP Client creates ill-formed NMEA sentences, the SNIP caster checkbox “Loose NMEA $GGA” can be enabled (if the operator chooses) to overcome many common NMEA sentence issues.
3. If a user has many numerous failed attempts to connect with this NTRIP Client in the recent past (a few hours), that IP many be temporarily banned. Use the xxxx:2101/SNIP::STATUS command to check for your IP on the temp ban list (see Note A). This will not occur with the BNC due to missing a NMEA $GGA sentence, as it simply never tries to connect.

Note A:

Use a different IP to check this, if you get no html reply, the requesting IP is probably being banned.  On most SNIP Casters the operator sets the ban period to be hour or so.  Inquire with the operator for details.  More information on using the Ban functions in SNIP can be found here and here.