Whenever a SNIP Caster is communicating with another SNIP Caster, some additional helpful message traffic can be exchanged. This process uses a concept called SNIP-2-SNIP messages.
The general purpose of these messages is to allow the SNIP Caster to provide useful hints and advice to the human party making the remote connections. These messages are displayed on the console of the remote system with a light red gradient style to ensure attention to them. This feature can be disabled, and it is only used with SNIP agents as it ‘extends’ the official RTCM NTRIP Caster protocol in small ways. These messages are designed to assist the party controlling the remote connections to overcome basic connection issues without the need to contact the SNIP Caster operator, hence saving time. At the same time, few additional data details are provided in order to thwart parties seeking to exploit the SNIP Caster.
Typical Message Content
The SNIP-2-SNIP assistance occurs when several common connection issues are detected including:
- Requests for missing MountPts
- Missing/Incorrect User/Pw credentials on a closed Caster
- MountPt issues differing only from capitalization
- PUSH-In Reservations with incorrect User/Pw credentials
- PUSH-In Connections that connect but then send no actual data
- PUSH-In Connections that becomes data starved and cease sending
- ECEF message types 1005/1006 are set to zero/zero or to North/South Pole locations
- Requests made when the subject IP is currently Banned
Examples of reply messages:
Missing MountPts
Here is a typical report generated when the user requests a mountPt that is no longer present in the Caster Tables. The reply report differentiates between mountPt it has never seen and those that are simply offline when requested (and were present in the recent past). Most SNIP-2-SNIP reports follow a similar pattern with text advising the remote party regarding what to check for and correct.
Data Starvation
When a remove device is acting as an NTRIP Server and forwarding data to the SNIP Caster, it may on occasion stop sending. This is normally caused by issues with the GNSS Base Station. A simple SNIP-2-SNIP message is issued to alert the remote operator this is occurring:
Nonsensical ECEF Values
In order to use a data stream for RTK, one must know the precise location of the Base Station. And this can be expressed with different datum (which can then be corrected to a common reference using PFAT Transformations when needed). It has been observed that some users send in a stream without setting this value, and SNIP can detect and report this event. The message received by the remote connection denotes this issue and urges the other party to correct it.
On the SNIP Caster side the notice appears after the ECEF decoding completes and is fairly terse:
These two examples are representative of the SNIP-2-SNIP message contents.
Enabling SNIP-2-SNIP Messages
The SNIP-2-SNIP assistance feature is controlled from a checkbox in the Preferences Dialog box.
(Menu: Edit -> Preferences…)
When checked, and when the other connecting part is a SNIP agent, the additional message content will be sent.