Release 3_04_00 Changes

What is new in the SNIP 3_04_00 release – released December 30th, 2021
(updating the prior release of 3_03 issued on November 16th, 2021)

This is the next production release of SNIP following the Rev 3_03 release.  This release contains several minor corrections and minor improvements in response to user requests.  It also contains a number of revisions to support a Web API to allow integrating SNIP with your hosting site (to be released on 3.05).  It is recommended that all deployments upgrade to this edition.

This release supports both 32-bit and 64-bit installations on all Windows Platforms from Windows 7 to the current editions.  It is recommended that all Windows 32/64 SNIP installations now update to using this release.

Changes in this release include

Misc Improvements in this release

In this release we have a number of minor improvements to report, and one key bug fix. We provide a short list below.

  • A fatal bug in the Backup processing logic for some models of SNIP has been corrected.  In Rev 3.03, any user initiated system backup made on Lite or Basic models of SNIP caused a crash due to a dangling pointer.
  • Reverse Geo-location functions and IP tracking features in all models of SNIP have been extended another 12 months to end of year 2022. Once this release is installed you will again see various links to small Goggle maps showing the locations of NTRIP Clients (users), Base Stations, and IP values.
  • Minor English typographical errors were corrected and additional tool-tip text was added to some of the older parts of SNIP.
    [General Tip: When in doubt about a GUI control, hover your mouse over it.]
  • In the “no Observational Data seen” message, additional logic has been added to report the precise time when when the last data of any kind was received.  This message is displayed when a given data stream has not sent any new OBS messages in the past 5 seconds.  This addition will aid in debugging to determine if the loss of observation messages was in conjunction with a general loss of message flow or simply the GNSS device not sending such messages.
  • Additional logic has been added to report whenever any RTCM 3.x message with encoding errors are found.  In practice this is rarely ever observed, and the CRC of the RTCM message itself (as well as the TCP/IP checksum process) function to prevent undetected corruption during transfer.  This feature is of value to detect encoding errors occurring at the GNSS devices itself, typically indicative of bad software at the Base Station.   Reporting can be enabled / disabled from a new checkbox added to the Preferences dialog.
  • Minor additional details were added to the weekly logs to support post analysis.  Major increases and decreases in memory use are also now noted.  Some additional time stamps and memory usage reports were also added.
  • A problems with logging raw Base Station data files every 15 minutes for some users was corrected.  The various other log periods (30min, 1hr,2hr,… 24hours) were not affected.
  • A new control “Show API Details” has been added to the Caster and Clients tab. This is used to enable the display of a detailed summary of any Web API commands/requests.  It is similar to the way “Show Protocol Details” is enabled to see the actual NTRIP Client requests on the console.  We would recommend leaving both of these controls checked.
  • The pop-up menu displayed in the Connected Users dialog has been modified to add three new items. Besides the existing commands to disconnect the selected user, or to see various reports in the document viewer, the operator can now select a menu item to copy the user name, the IP, and last NMEA $GGA sentence received (when one is present) to the clipboard for further use.
  • The displayed tool-tips and reports used for data streams containing RTCM 2.x message content have been improved to provide additional details decoded from the message content.  These are displayed for the Base Station in a fashion similar to the style used with RTCM 3.x message content.

The AVL Tab

The AVL server (see this article for more details)  now supports three new output formats beyond sending the $GGA sentence format which has been supported for some time.  These are:

    • A tab separated lat-long format
    • A KML style format
    • A GeoJSON style format

A simple password support system has also now been added.  If you have been using the “Open Access” connection model in the past, you should consider switching to this model.  The required password is the value you set (as shown in the image at right) which the connection must send at the start of the TCP/IP connection.

And, some additional logic has been added to deal with users who connect to the AVL server using common browsers (not advised).  This which will return and disconnect any requests for favicon.ico and other common web clutter.  As an AVL server, such requests are not meaningful.

Secure Caster Operations

Considerable new work has been completed in this release but deployment with a fully TLS/SSL secure Caster not yet ready.  The new Secure Caster system (which is a Plug-In) will allowing running your SNIP Caster with two modes at once; a ‘normal’ un-secure Caster (typically using port 2101) and a secure Caster (typically using port 443) with each serving identical data streams.  The secure Caster port will also service Web API requests (described further below) when the SNIP operator has enabled this.

Aside: From the prior release onward (Rev 3.03) all models of the SNIP Caster fully support making secure NTRIP Client connections to other secure Casters (see this article for more details).  At this point in time, very few Casters support secure client connections and even fewer NTRIP Clients do so.

[Further Aside: We expect the year 2022 to see increased adoption of this ability. If you manufacturer NTRIP Client software, please feel free to contact us for any support you may need to add this ability.]

Multi-Caster use

In this release there are several behind-the-scenes changes to support operating multiple separate Casters from a single host machine.  This feature allows an operator to present different Casters on different IP and port combinations (as well as different DNS names) to support different user communities. The operator can allocate which Base Stations appear on each Caster and which customer accounts and user accounts (NTRIP Clients) can access and/or manage them.  And, any of these Casters can be operated in a secure mode when required.  This feature has been requested by deployments that operate multiple copies of SNIP on which they resell services.

When operating in a Multi-Caster mode, the Caster and Clients tab show similar controls for the additional Casters which are present

Now in Alpha testing, an early release of this be found at (see this article: ). Wider testing will begin soon.  Please contact us if you are a Pro user and wish be a Beta tester for this new feature.


In this release there are also several behind-the-scenes changes to support the remote administration of the SNIP Caster by means of a web interface.  This will be part of the Rev 3.05 release.  Nearly every operation associated with creating and managing user accounts, as well as obtaining current status about users and base stations, will be available with a web based interface.   Many of the reports have been expanded and cross-linked in anticipation of this.  Support for the routine administration tasks of the caster using secure POST submission is being added.

If the requestor has been granted sufficient privileges (the Web API uses a secure session token methodology over a secure TLS/SSL link described above) then specific user connection details and base station usage detail are provided back as html pages. This use case is intended for designated administrators of the Caster and overcomes the need for direct windows desktop access.  The revised reports show (for example) details about the user connected to a Base, which in turn link to current and historical details about each NTRIP Client user (along with current and prior NMEA $GGA locations), which in turn link to details about the IPs used to connect, etc.

When a report is requested without sufficient privileges, much less information is provided to protect the security of the system and the users.  Of course the SNIP operator can control who has access to these reports or fully disable various reports as they see fit.


How to Update…

Updates to SNIP are always free and easy.  Your Caster will be offline about 3 minutes.  From within SNIP, simply use the menu item HelpCheck for Updates…   Your update will be downloaded from our secure servers and then you will be asked to allow SNIP to restart and update itself.  On some Windows 10 systems you must also manually exit the current copy of SNIP to update.  That’s all there is to it!

Was this article helpful?

Related Articles