When a Caster table entry is incomplete

There are several possible reasons a given Caster Table entry may appear to be empty or missing key data.  This article covers the process of setting up Caster Table entries in greater detail.  As a broad rule, you only need to provide these details for your serial port connections and any Raw TCP/IP type connections. For other stream types, SNIP will reuse the connection details provided by other data sources when they are available.  SNIP also provides a number of basic auto-set functions for caster entries when RTCM3 message streams are used.

When SNIP itself or a new data stream is starting, this process takes place and it may require up to 180 seconds for SNIP to complete an analysis of the data stream.

When a Caster entry seems incomplete, it is best to examine the type of data stream involved and proceed from there.  While correct and well-formed Caster entries are not required to operate SNIP or an RTK network, (all the table data is informative only), your NTRIP Clients will need this data to determine which streams will suit their needs.

If this is a UART Serial port connection…

You (the SNIP operator) need to fill these details out using the “Edit Caster Entry” menu (right click on the stream and select the menu item).  These values are kept and reused for that stream each time SNIP is restarted until changed.    Before editing the entry, you must first disconnect the stream if it is active.

[Keep in mind the ‘auto setup’ features described in the above article only work for RTCM3 messages. For example, they will not work with uBlox raw data]

Aside: If this stream is set  as “parsed” ( the Parse menu is checked) and the stream contains RTCM3 message contents, SNIP will fill out the caster table details of what message are present and its precise location for you after observing the message traffic for about 120 seconds.  You can press the “Table” button on the Caster/Clients tab as the stream first starts up to see this process occurring.

If this is a Relay stream or a PUSH-In stream…

Then the Caster Table entry provided by the other source is used by SNIP.  Depending on settings, SNIP may update/correct the message types if message parsing is active for RTCM3 message streams.  The Base Station transmits an ECEF value provided as part of the stream, and this will be used to precisely locate the stream (for streams with RTCM3 messages) both intneraly and for use in the Caster Table entry.  This value is used in Base Station mapping and also in NEAREST neighbor distance calculations.

Aside:  Acquiring the remote Caster Table for a relay type stream is recovered in a separate thread (so the new stream can start as quickly as possible), and as a result the local SNIP Caster Table may be incomplete for a several seconds while this process completes.  Because SNIP is now the encoder device sending the stream, its name is added to the caster table details.  You may also notice that the styles in such entries will vary in small ways (“GPS+GLO” vs “GPS & GLONASS” for example) due to the style conventions used by the different sources.

Aside: If you are sending PUSH-In data to SNIP from RTKLIB, or its various component tools, this article provides some advice on how to setup a suitable Caster Entry using those tools.

If this is a NEAREST stream…

Then the Caster Table entry is provided by SNIP based on a summary of the streams in each pool at any given time.  For NEAREST streams, the pool of suitable streams is examined to determine a central LL location. Hence, message details are often not provided if they vary with each selected stream.  If SNIP is not able to provide a realistic average LL location of the coverage area (typically because the coverage areas span hundreds of km), then the caster location entry will be set to zero, zero.

Aside: Note that the reported center of the coverage location will change as new caster streams enter and leave the pools.  Also, many State agencies running VRS Caster networks use zero, zero as the caster entry location, when in fact the coverage location is often the boundary of their region

If this is a Raw TCP/IP connection…

The setup process is similar to the UART Serial case described above.  You (the SNIP operator) need to fill the Caster Table entry details out using the normal dialog, which will appear after you press the Add New Port button and assign the Port and IP details to be used.  These values are kept and reused for that stream each time SNIP is restarted until changed.    Before editing the entry, you must first disconnect the stream if it is active.

If SNIP is sending data to another caster (PUSH-Out streams)…

[ Such as RTK2go.com, another SNIP node, and any standards conformant NTRIP Caster ]

In this case, the Caster Table entry which SNIP has for that stream will be sent along to the remote Caster for its use.  Make sure that the Caster Table entry is correct on SNIP, as most other Caster designs do not check the stream details they are given.

Aside:  If the Show Connection check box in the Pushed-Out Streams tab is enabled, the console log will show the connection details to the remote caster.  The caster table entry (the line stating with “STR:” can then be observed.  Here is the connection in a typical PUSH-Out setup call:

[ANNARBOR_RTCM3-GG]:  Sending PUSH-Out Connection [O00-ANNARBOR_RTCM3-GG] to rtk2go.com:2101 with: 
 User-Agent: NTRIP sNTRIP/1.1.4
 SNIP-Account: OPEN
 STR: ANNARBOR_RTCM3-GG;RTCM 3;1004(1), 1006(5), 1008(5), 1012(1), 1013(5), 1033(5);2;GPS & GLONASS;SNIP;;42.30;-83.84;0;0;sNTRIP;none;B;Y;9600;wwwMDOTCORSorg
 Accept: */*
 Connection: close


This article has served to review the way in which individual Caster Table entries are created and used by SNIP.

Hint: You can always see the current Caster Table in the console log by pressing the Table button on the Caster and Clients  tab.


Was this article helpful?

Related Articles