SNIP supports receiving and sending any data format or style of data you care to use.
The Basics [or: To parse or not to parse…]
When it is used in the bent pipe mode, SNIP will simply repeat the stream of data it is given to any NTRIP Client connected to that mountPt. No further processing (other than data logging, if enabled) takes place.
It is more typical to use RTCM 3.x style messages with SNIP and to parse them. In this case, SNIP performs a full decode of the messages (when the Parse switch is enabled for that stream). From this, SNIP can perform other useful functions. These include creating and correcting the Caster Table entry for that mountPt, displaying detailed message contents (useful for researchers and debugging) , or performing a basic plots or navigation filters with data itself to confirm it is working. Any ill-formed messages and other clutter (often stray NMEA contents) is also removed during this process to ensure only valid data is sent to on to the NTRIP Clients.
If one of the other common formats is used (such as RTCM 2.x or one of the CMR styles), then no message level parsing occurs. To usefully employ such streams, the sender software (the NTRIP Server) must correctly create a suitable and correct Caster Table entry for SNIP to use.
Note: A planned improvement to SNIP is to add a similar level of full message decoding to support both the older and the latest RTCM 2.x format messages (currently these are RTCM SC-104 committee working drafts). The RTCM 2.4 message standard is now being tested with improved support other constellations beside just GPS and GLONASS (message Types 41~43). Once this occurs, SNIP will be able to auto-correct similar errors in such streams as it does today for RTCM 3 streams.
The Supported Formats
SNIP supports all the common format styles; see the list below. Because there are no precise rules in the NTRIP Protocol in this regard (any string can appear or be used), SNIP takes an relaxed attitude when matching such strings. Because of these issues, some format styles that are only trivially different but unique to a vendor are grouped together (such as the Trimble R17 and R27 formats). This can also be an issue when Base Stations are being combined to create a NEAR stream. When the data sender (the NTRIP Server) provides a Caster Table entry, that entry is used as provided, unless it has obvious errors which are then corrected.
The following format keywords are used by SNIP when constructing its own Caster Table Entries. These terms also appear in various drop-down selections in the Dialogs. When sorting entries for use with NEAR pools or other operations, any entry with one of the stated format strings will be matched to a keyword and treated as belonging to the same basic group.
| Keyword | Various Format Strings Used with this keyword |
| RTCM 3.0^ | RTCM, RTCM3, RTCM 3.0 ~ RTCM3.x (and various pattern matches) |
| RTCM 2.x^ | DGPS, RTCM2, RTCM 2.0 ~ RTCM2.x (and various pattern matches) |
| CMR | CMR, CMR+, CMRP, CMRr, sCMRx |
| MBEN | MBEN (Ashtech format) |
| JPS | JPS (Javad format) |
| HEMI | HEMI (Hemisphere Eclipse format) |
| LB2 | LB2, Leica4G (various Leica formats) |
| NVS | NVS |
| SBF | SBF (Septentrio binary format) |
| R17 | R17, R28 |
| uBlox^ | UBX, uBlox, (and various pattern matches) |
| BINEX | BINEX |
(^) = Indicates a format where SNIP performs some additional content parsing
The term “RAW” is also used when a streams contents are unknown or it is still being analyzed. The NTRIP Caster table specification also allows an empty GNSS type string (“;;”) to be used when the correct data is not available. It is generally safe to use this if you are are uncertain how best to set the value.
If you feel we should add logic for a new but missing GNSS type, please contact us.
On NTRIP Clients
Many NTRIP Clients (Rovers) are particular about the formats they will accept. For example, some devices want to see “RTCM 3.0” exactly and variants like “RTCM 3.1” or “RTCM3.x” are not acceptable to them. Nor is a blank entry. Many NTRIP Clients will simply complain that a format does not precisely match what it expects, but will thereafter connect to it without further issues.
Often people will set up the format string slightly “off” as part of an ill-formed Caster Entry. SNIP will not generally correct a “near miss” presuming that the operator knows what he/she wants. For example, a string like “RTCM3” might appear when some rover devices can only cope with “RTCM 3” (note the additional space). This remains a weak area on the otherwise very successful NTRIP Protocol and the RTCM SC-104 committee is well aware of it.
The best answer when faced with these issues is simply to try it and find out. The console log in SNIP will allow you to see what is being sent in and correct things at the source as needed.