This article discusses how to set up the RTKLIB tool STRSVR (aka stream server) to send data to a SNIP Caster node on the same, or on a different, machine.
Many users of OEM boards across the cost spectrum use the STRSVR tool to convert (translate) from a GNSS vendor’s proprietary data stream into industry standard RTCM 3.x messages. Many GNSS vendors charge a considerable sum for the direct ability to send RTCM 3.x messages (while RTKLIB is free to use). So this is a very cost effective solution to those users. With a modest amount of DIY effort, a very solid L1/L2 survey grade Base Station can be assembled for an investment of under $1K US using such methods.
Aside: If you plan to attempt this with a patch antenna – please read this note.
Setup for STRSVR
Here is the basic STRSVR dialog screen, showing an input data stream from a serial device and one output data stream.
In this example we have connected to a uBlox 6T board over a serial port on com port 10 (using a USB convertor) which is sending the proprietary uBlox binary format. The STRSVR tool will convert this to suitable RTCM 3.x messages (in this case the 1004 message, the L2 observational elements will be set to zeros).
We could have connected to a data stream from any Caster (such as the open one kept at ntrip.use-snip.com:2101), or any other valid data source. RTKLIB supports all the normal connection modes in this respect. But it is more typical to connect to a local serial stream. In the above image, the Cmd button allows sending setup commands to the device (typical used with a serial device) similar to what SNIP allows to setup serial devices. As a best practice, always set up your GNSS device settings each time you connect to it.
Important !
The key purpose of connecting to STRSVR (rather than directly to SNIP, see this tab to do so) is to allow it to parse and translate the data stream from one message format to another. At this time SNIP does not have a similar translation ability built into it. The STRSVR tool can be thought of as a translation step between the GNSS device and the Caster. The STRSVR tool can also be used to redirect the same data stream to as many as three parties, but it is the translate ability that is of greater value to most users.
Once you have connected to a source of data, you must connect it to an output and (optionally) translate the data for that output.
Outputting Data
The STRSVR allows up to three output streams to be created. One of these should be connected to SNIP so that SNIP can service your NTRIP Client connections.
In this context only two connection types make sense, the NTRIP Server and the TCP Client. The NTRIP Server method is to be preferred.
Aside: The TCP Server connection setting is used to instruct the STRSVR tool to be listener on a given port and to send the data stream to any connection that appears there. This is simply a brute force TCP/IP connection, and it does not use the NTRIP protocol. You can in fact connect to it with SNIP as a Remote Relay connection if you wish, but that is not needed. On the whole, leaving ports open on your machine is a security risk to be avoided.
The dialog box for the NTRIP Server connection [ Output (1) ] is shown below.
Enter the Caster URL, or the machine’s IP (enter your own IP address if the STRSVR tool and SNIP are on the same machine). Enter the port used (typically 2101). [Please do not enter serv2, as that machine is not open for public use]
Enter the mount point (mountPt) name you wish to see this data stream appear as. This needs to be a well-formed mount point name, therefore no white space and no odd symbols (!@#$%:; etc..) are allowed. Caution: STRSVR does not check for ill-formed names. Here we have used PushInAsServer as the mountPt name.
Enter the password for the SNIP Caster you will connect to. If you are using a reservation on SNIP, it will have its own password. If not, it will use the same password as other PUSH-In streams on your copy of SNIP. If the receiving Caster is not under your control, ask the operator what password is to be used.
Finally, if you are knowledgeable about NTRIP Caster table entries, enter the table entry (except for the mount point name itself) into the line called “String.” Hint: Most users simply leave this blank, letting SNIP handle it. One of the advantages of SNIP is that it understands the RTCM3 message flow (when the data stream is parsed) so it will simply fill in the correct data for you once the stream connects. If in doubt, please leave this field empty.
Translating, the Conv dialog
The Conv… button brings up a critical dialog for this setup. You can set a different set of Conv values for each output stream you create. Here we only create one.
To translate from a GNSS vendor to RTCM 3.x, set the controls as shown. The Message Types line is required to tell STRSVR exactly what message contents you want to be output. If you have a GPS L1/L2 data source a line like “1004(1)” would be typical. Some people will use “1002(1)” for L1 only systems; others will use “1004(1)” because it is more commonly understood. [When SNIP completes the Caster table entry, it will adjust for the present of L1/L2 automatically.]
You might want to added orbital messages as well. Read the RTKLIB manual for further setup details. Be sure to set a value and add an EFEF location message every few seconds, such as “1005(10)” as well, unless your end users will know it by other means.
So a full message type string for legacy GPS+GLO might look like this: “1004(1), 1005(10), 1012(1)” If you wished to use MSM messages, the string might be this: “1005(10), 1077(1), 1087(1)” etc.
You can read more about Caster String controls in RTKLIB in this article.
Aside: The STRSVR tool is adept at translating proprietary GNSS formats to the common rtcm_t data structure defined in RTKLIB, and then exporting that into RTCM 3.x messages. It is not at all adept in handling RTCM 2.x messages and it cannot even create RTCM 2.x messages. Hence, it cannot be used to “convert” from RTCM 2 to 3 or in the reverse direction. The combo box choices seem to imply this ability to some users. We note that detail here because the question seems to come up fairly often. If this is a need you have, please contact us for support.
Aside Number 2: If the STRSVR tool is told to translate a GNSS format, you must then tell it what the new message types and sending rates need to be. AND you must provide it with a suitable ECEF value to send. People often forget to set the ECEF value and then STRSVR cannot send a valid Base Station location, making the stream useless.
Once this is set up, you now have a stream of Base Station data suitable to be shared with others and the next step is to forward that to your copy of SNIP for mass distribution.
You could press Start at this point, but it is likely there are a few things to set up on the SNIP side as well.
Setup for SNIP
Sending data to SNIP as outlined above results in a new PUSH-In connection. The STRSVR tool is acting like an NTRCIP Server, while SNIP is acting like an NTRIP Caster in the normal way.
When Sending Data without a reservation
The sender simply has to follow the master password established for that Caster. See the button Set Up.. on the Pushed-In Streams tab. Here you can tell (or reset) the password to be used. Be sure to inform any other data sender when you change this value.
When Sending Data with a reservation
In this case, the sender follows the password previously established for that reservation. Other values for the reservation are then applied as well, such as parsing and logging and even limiting what the connection IP is allowed to be. This connection method is more secure. A right mouse click in the window Reserved MountPts (in the Pushed-In Streams tab) will bring up menu options to add/edit/remove reservations.
When it connects…
When the PUSH-In stream from the STRSVR tool connects to your SNIP node, you will see the new slot as an image in the tab similar to this.
The STRSVR app is shown below it in the area where the console log appears.
How can I tell if it is working?
Several ways, all practical and easy.
You can tell by:
- Look at the PUSH-In tab you can see what streams are connected and active. You will see the “UpTime” and the “Input” values increase as data arrives from the remote device. You can also see a count of how many Clients’ connections are currently present on this stream and the total amount of data that has been sent out to them.
See the image above.
- Connect to the final data stream on SNIP with a copy of RTKNAVI acting as an NTRIP Client and then navigate from your resulting stream. [You can also run simple navigation filters from within SNIP] This has the effect of doing an end-to-end check on the entire data stream.
See the RTKLIB users guide. Connect to your data stream like any other Caster Stream. Recall that the data is now in the RTCM 3.x format (and no longer in the original proprietary format).
- Look at the decoded RTCM 3.x messages in the data stream in the SNIP RTCM 3 Decoder to confirm that the data you expect is present. This is useful to confirm details like the precise ECEF location, although many of these details appear in the console log when the stream is initially evaluated.
Several examples of the RTCM decoder use can be found at the above link.
- Use the universal decoder to quickly look at the gross messages in the SNIP console as a means to quickly see that the data is flowing without decoding the content of each message. This is very handy to confirm that the message sending rates for each type as as you anticipated.
For RTCM 3.x content you will see lines like:
[PushInAsServer]: Stream analysis completed... Parsing is Enabled. [Detected RTCM3, Decoded: RTCM3]
A summary of the RTCM3 message types seen in PUSHED-In stream PushInAsServer will now be displayed.
[PushInAsServer]: MountPt PushInAsServer [I005], 1 RTCM3 messages decoded, of 21 so far.
[PushInAsServer]: RTCM3 Type 1004 (155 bytes), the 18th message of this type found so far.
[PushInAsServer]: --
[PushInAsServer]: MountPt PushInAsServer [I005], 1 RTCM3 messages decoded, of 22 so far.
[PushInAsServer]: RTCM3 Type 1004 (155 bytes), the 19th message of this type found so far.
[PushInAsServer]: --
[PushInAsServer]: MountPt PushInAsServer [I005], 1 RTCM3 messages decoded, of 23 so far.
[PushInAsServer]: RTCM3 Type 1005 (025 bytes), the 2nd message of this type found so far.
[PushInAsServer]: --
[PushInAsServer]: MountPt PushInAsServer [I005], 1 RTCM3 messages decoded, of 24 so far.
[PushInAsServer]: RTCM3 Type 1004 (155 bytes), the 20th message of this type found so far.
[PushInAsServer]: --
But if you see other content (the below used a uBlox device, the text seen will vary by vendor) it may indicate you did not translate the data stream and are in fact sending the UN-translated data:
[PushInAsServer]: On Port C007, MountPt PushInAsServer has sent 280 Bytes [#I004]. A summary decoding may follow.
[PushInAsServer]: Detected the potential presence of uBlox msg content
[PushInAsServer]: uBlox msgs, found:
NAVB562-0131-1000(24)-[D8F26C09000000000000000000000000] *81E2
NAVB562-0210-F800(256)-[D9F26C09AC070A00A54D29A622CE74C1589BB9827D1D74415E75AEC419073100C057838EB4C40DC102D634797B867841399713450D072500C2CDD86D160577C16CFF8CEAF130744114DF0A45140731003397CD24F17278C18ED62E64B5FD7341743F1FC405073300B4A5B686468D37C180766736071B7841176164C41F072900210728F10A2B75C1F481FE7EFC22744141C7AE441D073200C11A71C1493F5DC1FD7B789C09F27641E63EE34415072C0024620CF851FC10C10643735B187E7841AB8526450F0724008C220C30875663C120ADB7FC09127641AD760DC502072A00E7E3D2F004906EC139B7CB3CBD38754144B54CC50C073100] *8A65
[PushInAsServer]: On Port C007, MountPt PushInAsServer has sent 280 Bytes [#I004]. A summary decoding may follow.
[PushInAsServer]: Detected the potential presence of uBlox msg content
[PushInAsServer]: uBlox msgs, found:
NAVB562-0131-1000(24)-[C0F66C09000000000000000000000000] *6D9E
NAVB562-0210-F800(256)-[C1F66C09AC070A00A515D16ACBCD74C1F9BFFD188E1D7441B385AEC419073100C0579F597E0E0EC13AC7E1685F867841C69813450D072500C2A53044A10577C15A44A980D7307441DFD00A451407310033938449C97278C1AEC587F7BCFD734164821FC405073300B4A5756CB48937C1D68DD30D121B7841F89F64C41F0729002147E253622B75C134956BDDEB22744110C1AE441D073200C1DA002710415DC114C55B05F4F176418E33E34415072C002462072AF12511C13F942BACF87D78417A7526450F0724008C0A5A436C5563C1E5EEC2E6241276410A760DC502072A00E723A87B6B8E6EC10AD0D330E438754198BD4CC50C073100] *F708
This article deals with using the RTKLIB STRSVR tool with SNIP, providing basic setup instructions.