Adding Pushed In Data from NTRIP Servers

Controlling Push-In data access

Unlike relay-remote data or serial stream data, you cannot start a connection from the Caster with a button click. Rather, you must wait for the other party to connect to you.  Pushed-In data [PUSH-In] is managed under the Pushed Streams tab. Pushed-Out data [PUSH-Out] is managed under the Output Data tab.

SNIPwPUSHinFlowPushed-In data, that is, data which is sent to SNIP from an NTRIP Server, creates a connection to SNIP when it presents a suitable password followed by a mountPt name.  If the password provided is correct (and you have not reached the number of streams for which your copy of SNIP is allowed), the connection is made.  Like the other stream types, you can control starting the entire process with a master on/off check box marked Allow Connections.

This process is managed under the Setup dialog, shown below.

PushSetUPDialog

Here you establish the master password, and whether the log will have an entry when a failed connection event occurs.  You can also select whether details of the connection will be displayed in the console log.  This can be of value when debugging a connection.

On Passwords

Use the Generate button to create a unique password string, rather than the default value.

The password value is checked only at connection time, so changing the value will not affect any currently connected users until their next connection event.  CAUTION: It is your responsibility to inform other parties when you change the password on your site.

The other party’s GNSS device must know your system’s password in order to connect.  Provide this only to trusted partners. The connecting party will suggest / provide a mountPt to be used in the connection string.  Generally this is the published mountPt that your users will then see in your own caster table, but SNIP contains some logic to rename mountPt to always avoid duplication. So if two remote NTRIP Servers both connected at the same time and used the mountPt “test,” the 2nd one would be renamed “test_02” in your caster table. If the connection device provided a Caster table string, this value would be used in your table.  If not, then a minimal entry will be created for you.

As remote data sources connect, the events are shown in the console and current connection status is reflected on the tab in the normal way.

Disconnection Events

When a remote push source disconnects, it is removed from the tab tables (and the mountPt entries) in a few seconds. If a remote push source ceases to send any data, this is also noted.  After a ~10 second lapse, the source is marked as “down” and will be marked as active once data resumes.  If a full 3 minutes passes (180 seconds) with no further data received, the socket will be disconnected and can be used by others. Well-behaved NTRIP Server devices disconnect when they end a service.  Some NTRIP Server devices will attempt to reconnect when a service is disconnected, while others will not; consult your vendor.

Remote PUSH-In sources can be manually disconnected (by using the right-click popup menu for the slot) but there is no way to directly encourage a given remote source to connect to the Caster.

Aside: If you have this need, consider using the Remote-Relay stream type.  In this type of stream, SNIP will aggressively attempt to reconnect to the remote Caster should a connection ever be lost.  The algorithm used is an adaptive aggressive one.  A retry rate of  every few seconds for the first few minutes then backs off to progressively  slower re-connection times (15 seconds, 1min, 5 minutes, etc.), reaching a rate of a single attempt once per hour for remote Caster mountPts deemed to be ‘dead.’  The button Restart Pending Streams on the Relay Stream Tab can be used for forcing any inactive Remote-Relay stream to attempt a reconnect.

 

See also:  Sending Pushed Out Data from a SNIP Caster

Was this article helpful?

Related Articles