{"id":9381,"date":"2026-06-05T21:06:44","date_gmt":"2026-06-05T21:06:44","guid":{"rendered":"https:\/\/www.use-snip.com\/kb\/?post_type=ht_kb&p=9381"},"modified":"2026-06-05T22:43:20","modified_gmt":"2026-06-05T22:43:20","slug":"release-3_20_00-changes","status":"publish","type":"ht_kb","link":"https:\/\/www.use-snip.com\/kb\/knowledge-base\/release-3_20_00-changes\/","title":{"rendered":"Release 3_20_00 Changes"},"content":{"rendered":"

What is new in the SNIP<\/span> 3_20_00 release<\/strong> – released June 5th, 2026
\n(updating the prior release of 3_19_00 issued on December 20th, 2025).<\/p>\n

This is the next production release of SNIP<\/strong><\/span> following the Rev 3_19 release.\u00a0 This release contains both major and <\/em>minor<\/em> improvements in response to user requests.\u00a0 This release supports both 32-bit and 64-bit installations on all Windows Platforms from Windows 7 to the current editions.<\/p>\n

This release contains 6 months of incremental improvements.
\nIt is recommended that all Windows SNIP<\/strong><\/span> installations now update to using this release.<\/p>\n

Changes in this release include<\/strong><\/h2>\n

Push-Out stream connections<\/strong><\/h3>\n

Major revisions were made to the logic that governs how Push-Out streams<\/strong><\/a>\u00a0start and restart when the connection to the remote endpoint has been dropped. Deployments will no longer have to manually restart an active connection after a loss.\u00a0 This was occurring for some deployments at odd times.<\/p>\n

Also added was additional data entry checking logic to detect and reject obvious incorrect IP or URL entries for the destination when the stream is created.<\/p>\n

Not sending Automatic eMail to selected users<\/strong><\/h3>\n

A new feature in the IP blocking<\/strong><\/a> dialog now allows adding selected entries (a User Account or email, a Base Station, or an IP)\u00a0 to a special list that will NEVER be sent any automated eMail when a problem is detected with that connection.\u00a0 Other routine email to that user (or base station owner) is not affected.<\/p>\n

\"\"<\/a><\/p>\n

This is accessed with the Never Auto-Email\u2026<\/strong>\u00a0 button in the IP Ban Setting<\/strong><\/a> dialog.<\/p>\n

Using this feature requires both a Pro <\/em><\/strong><\/span>model of SNIP <\/strong><\/span>and the Email Plug-In<\/strong><\/a>.\u00a0 A dialog with a list of the entries as well as the number of times eMail was suppressed for each entry (and the last date this was done) is displayed.<\/p>\n

\"\"<\/a><\/p>\n

In the above image there are 29 entries, shown sorted by the number of times the function has been used. You can use this to decide when\/if an entry should be removed (when abuse of your Caster has ceased) and to keep track of the worst offenders.<\/p>\n

You can disable this function by un-checking the Enable<\/strong> checkbox. \u00a0You can add new items (Base Stations, User Accounts, or IPs) \u00a0as needed. Right-click to remove an entry. Selecting one of the radio buttons will preload the combo box with entries of that type (unless there are hundreds of such entries making the list too large to display). \u00a0This is a powerful tool if you do not have full control over who your end users may be (typically a public Caster of some sort).<\/p>\n

The use case for this feature is very narrow.\u00a0 Normally you would just block a User Account, a Base Station, or an IP from\u00a0 making a successful\u00a0 connection to the Caster in the other existing ways. But if the user has provided a bad email, or the IP which is being used constantly changes (from DCHP etc.), these other ways fail to fully address the problem and result in the SNIP<\/strong><\/span>\u00a0operator getting annoying bounced emails.<\/p>\n

Raw TCP\/IP Connections<\/strong><\/h3>\n

A minor naming problem was found and resolved. During times when a raw TCP\/IP connection<\/a> has been \u201chalf disconnected\u201d (one side of the connection has dropped the connection while the other side still thinks it is connected)\u00a0 the reconnecting in-bound connection was being renamed with \u201c-\u201c appended to the name.\u00a0 In prior release the text \u201c-02\u201d was being appended, and this was a side effect of not fully resolving that. Now presumed to be completed resolved.<\/p>\n

NEAR Streams<\/strong><\/h3>\n

The allowed baseline distance for an NTRIP Rover device connecting to a NEAR stream<\/a> Base Station can now be increased from the prior limit of 300 km to 1000 km. In a similar way, the maximum span to average over can now be increased from 1000 km to be 3000 km.\u00a0 This increase was requested by a deployment with an odd use case. \u00a0As a general rule, baselines over ~60 km are rarely of any use in traditional RTK applications.<\/p>\n

The new functionality is reached (in the NEAR stream setup dialog<\/a> by clicking on one of the buttons market Km<\/strong>, the button text will change to \u201cKm expanded<\/strong>\u201d\u00a0 and the larger values can then be entered.\u00a0 This article<\/a> explains the function in more depth.<\/p>\n

\"\"<\/a><\/p>\n

These values are saved when the dialog is saved. If the Km expanded<\/strong> button is checked, and if the current values are larger than the Km<\/strong> setting will allow, they are reduced to the largest allowed value.<\/p>\n

RTCM3.x Decoding<\/strong><\/h3>\n

Support for decoding and displaying NavIC MSM messages (The Indian GNSS system) has been added.<\/p>\n

Support for decoding and displaying QZSS MSM messages (the Japanese GNSS system) has been improved.<\/p>\n

Some users are now deploying GNSS Base stations that track the NavIC MSM messages and this trend is expected to grow. However this can be a major problem for older GNSS systems that do not process these messages.<\/p>\n

In the official order in which sets of MSM messages are sent by RTCM3.x, the NavIC MSM messages is the last one to be sent.\u00a0 Hence, it asserts the \u201cwe are done\u201d flag used to signal that a complete set of MSM messages has been delivered (the prior MSM messages in the same will set this flag as \u2018more data is coming\u2019 \u2013 see DF393 in the actual std). \u00a0If\u00a0 a rover device does not decode the NavIC MSM messages it will NEVER see the we are done<\/em> flag set and will never run its navigation filter.\u00a0 And some GNSS base station developers will send an empty NavIC MSM messages just to set this flag (wasteful but allowed by the current RTCM standards). This is already proving to be a problem for some older rover devices that do not decode the NavIC messages. We may add a PFAT<\/strong> transformation to address this in the future if needed.<\/p>\n

Recording Raw NTRIP Rover user data<\/strong><\/h3>\n

The ability to record raw data streams from any connected NTRIP Client (rover) device has been added.\u00a0 See this article<\/a> for more details. \u00a0This control is found as a new tab in the User Account Restrictions<\/a> dialog.<\/p>\n

This ability allows using the rover connection to have the SNIP<\/strong><\/span> Caster capture whatever data from the field is wanted.\u00a0 You are not limited to NMEA sentences, but can send back any binary format you wish for any post processing you wish.\u00a0 Crop harvesting data or vehicle performance telemetry are typical examples of such a use.<\/p>\n

Misc. Changes<\/strong><\/h3>\n