SNIP can be used in a “bent pipe” mode for any desired stream. In this mode, any data sent to it is available to be relayed to any client connection (as well as being logged). This mode of operation is commonly used where the Base Station data is not industry standard RTCM3 messages (the format used for differential GNSS corrections).
Example Use cases
- You have GNSS data in a proprietary format, such as uBlox UBX, which you need to send to other devices. (see Note A)
- You have a stream of DSRC messages provided by another SCSC caster you need to send to vehicle devices. (see Note B)
- You have something unique to your own needs to send to other devices which they understand. (see Note C)
- You have older CMR or RTCM2 data to send
How to do it
- Connect to the Base Station data stream using either the remote, local serial, raw TCP/IP, or Push-In connection type in the normal way.
- Confirm that the data is present by viewing the raw data with the streams menu controls (right click on the stream’s slot menus to enable monitoring to the console for a short period of time).
- Disable parsing the data (by right clicking parse on the stream’s menus). At this point all data that appears in the slot will be relayed to any connected clients. No PFAT filtering, monitoring, or translation of any type will occur. Note: If you do not disable parsing, SNIP will process that data presuming that it is RTCM and filter any non-RTCM “clutter” it finds to prevent passing it on to clients.
- Connect an NTRIP client in the normal way and confirm that the data which you are sending is in fact what you intended.
Notes
Note A: At this time SNIP does not read and translate other GNSS data formats into RTCM3, although this is a planned long term feature. As a result, it is common to use another software module (such as RTKLIB or software provided by the Base Station GNSS vendor) to either a) use the data in its native format or b) translate the format into RTCM at the client end for local use. A more common variation of this approach is to place the translation element between the GNSS device and SNIP, thereby translating the data format into RTCM3 before it reaches SNIP or the clients.
Note B: In its enterprise configuration, SNIP provides a translation of RTCM3 messages into SAE J2735 messages for consumption by ground vehicles. This data is typically then returned to the data source (where it becomes another entry in the the caster table of that source), or is forwarded to roadside equipment nodes (RSEs) located along the roadway of the coverage areas for final transmission to the on-board equipment (OBEs) of the vehicles over a 5.9GHz radio link.
Note C: Weather station. earthquake sensors, and meteorologic data is often handled in this way in some state-wide networks. As a somewhat odd example of this use case, SCSC has also used this method to connect IMUs with very high data rates as a convenient way to let multiple developers access the data of a single device to support development needs.
Further Notes
A note on serial connections: The default read time (polling time) for serial connections is an adaptive 500 mSec rate which is generally optimal for 1Hz GNSS data. In SNIP, all streams and clients run in their own process threads so blocking and adaptive buffer sizes are not an issue. Under some conditions with faster message rates you may wish to increase or decrease the polling time to match the nominal data arrival rate. A range of 50~3000 mSec can be selected in the serial setup dialog. By contrast, TCP/IP connection data is serviced the moment the data arrives, typically within a few mSec.
A note on proprietary RTCM messages: Because these messages are well formed RTCM style messages, and approved by the RTCM standard, SNIP will pass them on to clients in either parsed or non-parsed modes. You can find a list of these assignments here.
SNIP does not decode proprietary RTCM message content beyond the basic common RTCM frame. It then displays the resulting content in a Hex format in the RTCM Viewer dialog to the user.
