One of the more complicated details when using the RTKLIB tools to push data to SNIP is how to set up the Caster table “string” entry in the dialog box shown below. This article deals with how to correctly enter this data.
Aside: RTKLIB provides an NTRIP Server function only; that is, it can PUSH data out. It requires SNIP to be the NTRIP Caster in order to serve multiple users. RTKLIB also provides an NTRIP Client function which is how most users obtain their base station raw data, from SNIP or from any other NTRIP Caster.
Aside: Here is an excellent article on the RTCM-NTRIP.org site that provides a handy summary of what each element in the Caster table means and how to set them.
Best Practice: SNIP will automatically analyze the stream during the first ~120 seconds of operation and will deduce (from the message traffic it decodes) the correct lat-long location and the type of messages which the stream is sending. This information will then be used to populate the caster string for you. This feature only works when RTCM3 messages types are being used.
Background
We use a stream called TEST and a default password of “foobar” for these examples. You are advised to select other terms on your own copy of SNIP. There are default example, so please do not use this password on your own copy of SNIP. While this article pertains to the popular RTKLIB tool suite, most other NTRIP Server tools have similar settings and similar issues. [And from release 0.9.6 onward, SNIP can also send data in a PUSH-Out mode (as an NTRIP Server), but this is mostly used connect to other networks such as RTK2go.com when the the sender does not have a static IP of their own.]
Hint: We make use of the console set in the “minor” mode so additional event details are presented. If you are only seeing a portion of the log entries shown here on your own machine, please be sure that the Log Threshold combo menu item is set to: “Minor (Show All)”.
Article Format
We consider the four examples of how to fill in the caster string line (“String” in the above dialog):
- No caster string is provided.
- A fully formed (fake) string is provided.
- A reasonable example string for uBloxT6 use.
- A gibberish example string.
In each case we will consider three items:
- What you type in the “String” line from the NTRIP Sever tool (RTKLIB in this case).
- The raw messages you see in the console from the connecting device and what SNIP replies.
- How the result appears in your Caster Table.
Providing no string at all
This is the simplest case. Just leave the RTKLIB dialog entry blank. Keep in mind that the caster table details are fact optional in NTRIP.
When the RTKLIB NTRIP Server connects to SNIP it will look like the below. Note that the like “STR:” is simply blank. SNIP will process this request and create the new PUSH stream called TEST.
[C52]: A remote NTRIP Server (was a Client) sent: ======================
[C52]: SOURCE foobar TEST
Source-Agent: NTRIP RTKLIB/2.4.2
STR:
[C52]: ====================== (an inbound PUSH data connection attempt)
[TEST]: NTRIP PUSH Server [#P00, TEST] established at 01:00:40 PM (local)
[TEST]: New PUSH Stream is now [#P00] connected, at Thu 01:00:40 PM (Local)
[TEST]: NTRIP Client [#C52] becomes an NTRIP Server PUSH stream [#P00, TEST]
[TEST]: And now is awaiting data from [69.75.31.227 : 53367]
[TEST]: Re-Opening log file: TEST_160623.rtcm, is 31.650 MB
Note that in this example it was the 52nd client connection (“C52”) that became PUSH stream slot “P00” – with the mountPt “TEST.” The index values displayed will vary depending on how many prior connections the SNIP Caster has seen when they occur, so your connection numbers will not match.
When this action has completed, the Caster table will have a new entry (shown below in bold) reflecting the TEST mountPt. Below is a fragment (a few lines) of the new table. The keyword RAW is used because nothing further is known about the stream’s contents. The default descriptive name (which on this machine defaults to “Glendora, CA” if it is left as a blank) is left empty, as are the local default lat-long values. This is because (unlike a serial port) we have no idea if the source of the PUSH data connection to us is nearby or not. Similar logic follows for the country, which is set to XXX.
STR;SCSC;Glendora, CA;RTCM 3.1;;;GPS+GLO;SNIP;USA;34.00;-117.00;1;;sNTRIP;;;;;; STR;TEST;;Raw;Unknown;;;SNIP;XXX;;;0;0;sNTRIP;None;B;N;0; STR;TLSE0;Toulouse;RTCM 3.1;1004(1),1006(10),1008(10),1012(1),1013(10),1019(30),1020(30),1033(10);2;GPS+GLO;IGS;FRA;43.56;1.48;0;1;sNTRIP;none;B;N;2400;rgp-ip.ign.fr:2101/TLSE1(1)
We also note in passing that the above caster table fragment serves to illustrate the wide range of caster table entry lengths that are commonly found. Many NTRIP Client tools will display this information in a well formed table making it more readable.
Given that SNIP will detect and will fill in much of the missing data (the message types and the lat-long location of the base station), the user need only provide the mountPt and the city name to achieve a well formed caster entry.
Providing a huge (fake) placeholder string
Providing a full caster string is somewhat laborious. Here is a starting point with human readable names for all the key data items. You can take this string and edit it to make a string suitable for your own needs. In the case of any item you do not wish to provide, that item can be made into a blank (a blank is just no text between the “;” delimiters, as “;;”).
City-Description;RTCMformat;MsgList;SigCnt;GNSStypes;SNIP;country;lat;long;0;0;sNTRIP;Compression;Basic;NoFee;0;
Some of these items have std abbreviations, so a better starting point for a human readers’ wanting to edit this is to change only the items listed in blue in the below. Also note that lat-long values are expected to only have 2 digits past the decimal point and that North America resides in a negative region of longitude.
City-Description;RTCMformat;MsgList;SigCnt;GNSStypes;SNIP;country;lat;long;0;0;sNTRIP;None;B;N;0;
Remember that the mountPt (which will be added to the string) is not part of the string. The RTKLIB tool provides that on another line in the protocol request. When this connects to SNIP it will look like the below exchange. Note that the additional content after the line starting with “STR:” follows in the first figure above. SNIP will process this request and create the new PUSH stream called TEST.
[C56]: A remote NTRIP Server (was a Client) sent: ======================
[C56]: SOURCE foobar TEST
Source-Agent: NTRIP RTKLIB/2.4.2
STR: City-Description;RTCMformat;MsgList;SigCnt;GNSStypes;SNIP;country;lat;long;0;0;sNTRIP;Compression;Basic;NoFee;0;
[C56]: ====================== (an inbound PUSH data connection attempt)
[TEST]: NTRIP PUSH Server [#P00, TEST] established at 01:03:02 PM (local)
[TEST]: New PUSH Stream is now [#P00] connected, at Thu 01:03:02 PM (Local)
[TEST]: NTRIP Client [#C56] becomes an NTRIP Server PUSH stream [#P00, TEST]
[TEST]: And now is awaiting data from [69.75.31.227 : 53494]
[TEST]: Re-Opening log file: TEST_160623.rtcm, is 31.668 MB
When this action has completed, the Caster table will have a new entry (shown below in bold) reflecting the TEST mountPt. Below is a fragment of the new table. Because the PUSH source provides all the details, these are used in the resulting Caster table.
STR;SCSC;Glendora, CA;RTCM 3.1;;;GPS+GLO;SNIP;USA;34.00;-117.00;1;;sNTRIP;;;;;; STR;TEST;City-Description;RTCMformat;MsgList;SigCnt;GNSStypes;SNIP;country;lat;long;0;0;sNTRIP;Compression;Basic;NoFee;0; STR;TLSE0;Toulouse;RTCM 3.1;1004(1),1006(10),1008(10),1012(1),1013(10),1019(30),1020(30),1033(10);2;GPS+GLO;IGS;FRA;43.56;1.48;0;1;sNTRIP;none;B;N;2400;rgp-ip.ign.fr:2101/TLSE1(1)
While this caster line is pretty much meaningless, it is completely valid from an NTRIP protocol perspective. Regrettably, NTRIP is not strict on the precise capitalization of the list of suitable keywords to be used.
Providing a typical uBlox 6T example
Here is a starting point for use with a common uBlox6T device. As you will be aware, this is an L1 only GPS device so we adjust the SigCnt and RTCMFormat entries to reflect this. Here we presume that the raw uBlox messages have been converted to RTCM3.x by RTKLIB’s tools and that we will be sending one 1004 type message at 1Hz. If you plan to send raw uBlox messages use the “raw” keyword or the “uBlox raw” keyword in place of the “RTCM 3.1” keyword. Also, quite a few deployments leave the message list empty rather than try to enumerate each item.
Collocated Testing;RTCM 3.1;1004(1);1;GPS;SNIP;USA;34.00;-117.00;0;0;sNTRIP;;None;B;N;0;
Lacking a suitable name, we used “Collocated Testing” and our office for the Lat-Lon values. You can leave this entry blank if you desire. Some people repeat the mountPt as an alternative. Note also the “1” (not a 2 for L1/L2) and the the “GPS” (not GPS+GLO) in the above line.
When this connects to SNIP it will look like the below exchange. Note that the additional content after the line starting with “STR:” follows the above. SNIP will process this request and create the new PUSH stream called TEST.
[C60]: A remote NTRIP Server (was a Client) sent: ======================
[C60]: SOURCE foobar uBlox6T
Source-Agent: NTRIP RTKLIB/2.4.2
STR: Collocated Testing;RTCM 3.1;1004(1);1;GPS;SNIP;USA;34.00;-117.00;0;0;sNTRIP;;None;B;N;0;
[C60]: ====================== (an inbound PUSH data connection attempt)
[uBlox6T]: NTRIP PUSH Server [#P00, uBlox6T_02] established at 01:10:47 PM (local)
[uBlox6T]: New PUSH Stream is now [#P00] connected, at Thu 01:10:47 PM (Local)
[uBlox6T]: NTRIP Client [#C60] becomes an NTRIP Server PUSH stream [#P00, uBlox6T_02]
[uBlox6T]: And now is awaiting data from [69.75.31.227 : 53886]
[uBlox6T]: Log file: …/simpleNTRIP/data/uBlox6T_02_160623.rtcm opened.
When this action has completed, the Caster table will have a new entry (shown below in bold) reflecting the TEST mountPt. Below is a fragment (a few lines) of the new table.
STR;SCSC;Glendora, CA;RTCM 3.1;;;GPS+GLO;SNIP;USA;34.00;-117.00;1;;sNTRIP;;;;;; STR;TLSE0;Toulouse;RTCM 3.1;1004(1),1006(10),1008(10),1012(1),1013(10),1019(30),1020(30),1033(10);2;GPS+GLO;IGS;FRA;43.56;1.48;0;1;sNTRIP;none;B;N;2400;rgp-ip.ign.fr:2101/TLSE1(1) STR;uBlox6T_02;Colocated Testing;RTCM 3.1;1004(1);1;GPS;SNIP;USA;34.00;-117.00;0;0;sNTRIP;;None;B;N;0;
If you will be using a uBlox device translated by RTKLIB as base station, a setting similar to this will be what you need.
A Gibberish ill-formed example
Here is an example where the provided caster table lines is not correctly formatted and cannot be used.
[C48]: A remote NTRIP Server (was a Client) sent: ======================
[C48]: SOURCE foobar TEST
Source-Agent: NTRIP RTKLIB/2.4.2
STR: ee;0;
[C48]: ====================== (an inbound PUSH data connection attempt)
[TEST]: NTRIP PUSH Server [#P00, TEST] established at 12:58:36 PM (local)
[TEST]: New PUSH Stream is now [#P00] connected, at Thu 12:58:36 PM (Local)
[TEST]: NTRIP Client [#C48] becomes an NTRIP Server PUSH stream [#P00, TEST]
[TEST]: And now is awaiting data from [69.75.31.227 : 53252]
[TEST]: Re-Opening log file: TEST_160623.rtcm, is 31.607 MB
When this action has completed, the Caster table will have a blank style default entry (shown below in bold) reflecting the TEST mountPt. Because the stream really exists (and is public – not hidden), an entry is required. But because the submitted line was unable to pass the internal SNIP quality process rules, that line could not be used. A default entry is used instead. The most common user cause of this is too few or too many “;” characters, leading to ill formed content.
STR;SCSC;Glendora, CA;RTCM 3.1;;;GPS+GLO;SNIP;USA;34.00;-117.00;1;;sNTRIP;;;;;; STR;TEST;;Raw;Unknown;;;SNIP;XXX;;;0;0;sNTRIP;None;B;N;0; STR;TLSE0;Toulouse;RTCM 3.1;1004(1),1006(10),1008(10),1012(1),1013(10),1019(30),1020(30),1033(10);2;GPS+GLO;IGS;FRA;43.56;1.48;0;1;sNTRIP;none;B;N;2400;rgp-ip.ign.fr:2101/TLSE1(1)
This article has presented some core concepts on how to enter a suitable caster string when sending PUSH data to SNIP. In general this data is not required for small networks when the number of caster choices is limited. But in larger networks and environments where others will seek to find which of your data streams suits their needs, it becomes essential.
This article has some related concepts when creating caster table entries for serial data sources on SNIP.