{"id":2316,"date":"2016-09-30T22:57:22","date_gmt":"2016-09-30T22:57:22","guid":{"rendered":"\/?post_type=ht_kb&p=2316"},"modified":"2018-04-29T15:25:35","modified_gmt":"2018-04-29T15:25:35","slug":"federating-data-streams","status":"publish","type":"ht_kb","link":"https:\/\/www.use-snip.com\/kb\/knowledge-base\/federating-data-streams\/","title":{"rendered":"Federating Data Streams"},"content":{"rendered":"

As a general rule, SNIP<\/strong><\/span> can federate data from other Casters (including other SNIP<\/span><\/strong> installations) in any way you could care to connect such things.\u00a0 Use this ability to create the network you need, gather the set of data you need and to ensure that key data streams are distributed to others. Subject the license limit your copy of SNIP<\/strong><\/span> has for streams, there are no limits.<\/p>\n

You can think of each copy of SNIP<\/strong><\/span> as something like a single Lego building block.\u00a0 It is up to you what will connect to what.\u00a0 A few common variations of this are further described in this article.<\/p>\n

Single GNSS User<\/strong><\/h4>\n

The typical “single node” use of SNIP<\/strong><\/span> involves connecting a GNSS source (often from a local serial port) to SNI<\/span>P<\/strong> and letting others (NTRIP Clients) then connect to SNIP<\/strong><\/span> to share the data stream.\u00a0 Any party that can reach the SNIP<\/strong><\/span> node can connect to it (if allowed).\u00a0 This is perhaps the simplest use case.\u00a0 Variations of this involve\u00a0 connecting to other streams run by others (relay-remote streams) or having other devices send your SNIP<\/strong><\/span> node data (PUSH-In streams).<\/p>\n

\"typical_snip_wserialport\"<\/a><\/p>\n

Many users who are new to using NTRIP start with such a configuration and then add additional data streams such as broadcasting improved orbital data or clock data, as their need grow.\u00a0 The low cost base station deployment referred to as\u00a0 “L1 only” or “uBlox + RTKLIB = base station” are also well served by SNIP<\/strong><\/span> in its Lite<\/strong><\/em> form.<\/p>\n

Variations of the above basic approach include a great many configurations where the local GNSS device must by connected by intermediate cables, adapter boxes, Bluetooth, and other means to create a basic serial port.\u00a0\u00a0 The rational for the use of these is often due to cost (many GNSS device makers charge an additional fee for the ability to send NTRIP Server data directly to a Caster).<\/p>\n

Single GNSS User, no static IP available<\/strong><\/h4>\n

The above use case works well if all your users can access the SNIP<\/strong><\/span> node.\u00a0 This typically means that they all exist on the same sub-net, or that the SNIP<\/strong><\/span> node has a static IP on the internet that other parties can reach.\u00a0 Variations of this also include using a commercial Dynamic DNS service (DDNS) to tell others where they can reach the SNIP<\/strong><\/span> node.\u00a0 These are all variations of network connectivity issues which must be overcome to allow others to reach your SNIP<\/span><\/strong> Caster.<\/p>\n

However, in the absence of one of these solutions, SNIP<\/strong><\/span> can be used to easily forward the data streams it has (one or more) to another NTCIP Caster (provided by another<\/em> copy of SNIP<\/strong><\/span> or any other standards conformant Caster).\u00a0 This 2nd caster is then used as the public location where the NTRIP Clients can connect.\u00a0 This is most useful when firewalls are involved or when no static IP is available.<\/p>\n

\"singlegnss_noip\"<\/a><\/p>\n

In this image the SNIP<\/strong><\/span> Caster on the left is using a PUSH-out mode stream to cross the firewall and\/or overcome the dynamic IP to reach the SNIP<\/strong><\/span> Caster on the right.\u00a0\u00a0 The SNIP<\/strong><\/span> Caster on the right is accepting this data as a simple PUSH-In data stream.\u00a0 The SNIP<\/strong><\/span> Caster on the right can then provide this data (along with any other streams it has) to the NTRIP Clients.<\/p>\n

Note that the sending caster must also know the correct log-in credentials provided by the receiving caster.\u00a0 [Technically speaking, in this case the sending caster is connecting to the receiving caster as an NTRIP Server.]<\/p>\n

A final variation on this is to have the SNIP<\/strong><\/span> NTRIP Caster on the left connect using a relay-remote stream to the receiving caster and recover its own stream which is can then monitor for end to end<\/em> quality assurance.\u00a0 This creates a “back haul” link to the original data source.\u00a0 This allows detecting issues such as message latency and drops out along the complete distribution route.\u00a0 [Technically speaking, in this case the final remote-relay connection to the right side NTRIP Caster as as an NTRIP Client device.]<\/p>\n

Hint:\u00a0<\/strong><\/span> If you need a public IP to send your corrections stream out to, consider using the RTK2go.com<\/a> system.<\/p>\n

Federating Data Streams<\/strong><\/h4>\n

The easy ability to make these connections lends itself to creating ad hoc<\/em> networks of data.\u00a0 Within reason such networks are to be encouraged.\u00a0 Here is an example where three SNIP<\/strong><\/span> Casters have been used to pass the data originally provided by the GNSS device shown on the bottom to each local user community.\u00a0 Note that each new layer adds (or drops) whatever content is needed.<\/p>\n

\"federated\"<\/a><\/p>\n

Keep in mind that users often do this without you (the Caster operator) being aware of it. Please keep in mind you may need to first obtain data rights to do this with private sector data streams.\u00a0 Many of the mountPt streams found on larger sites such as rtgpsout.unavco.org<\/strong> or rtcm-ntrip.org<\/strong> are also rebroadcast over different networks with slightly different names.\u00a0 The mountPt AZ01_RTCM3<\/strong>\u00a0found on our open Caster<\/a> site at ntrip.use-snip.com\u00a0(on port 2101) <\/a>is a good example of this.\u00a0 This stream, which is located in the city of AZUSA, is a simple GPS only station located at one of our local high schools, yet it is rebroadcast in multiple international networks.<\/p>\n

A common problem to keep in mind when federating data streams from multiple other network is that they may be using different datums for the ECEF data they send.<\/p>\n

 <\/p>\n

Simple Data Logging<\/strong><\/h4>\n

Many users record corrections data from SNIP<\/strong><\/span> for possible longer term use.\u00a0 SNIP<\/strong><\/span> has several simple FTP abilities to gather, compress, and save files in support of this.\u00a0 And of course raw data from any stream can be logged for long term storage. So field servery team use a copy of SNIP<\/strong><\/span> operating at the office to gather duplicate corrections data from what will be needed in the field. This is a simple way to ensure an uninterrupted data stream for post processing use or as a recovery mechanism should field losses occur.\u00a0 In this use case SNIP<\/strong><\/span> is being used simply as digital tape recorder.<\/p>\n

\"datalogger\"<\/a><\/p>\n

A variation on this is to take one copy of SNIP<\/strong><\/span> out to the field site, connect it to a stationary cellular link back to the desired corrections source (using a remote-rely stream connection), and then distribute this stream using local RF and WiFi \/ WiMax to all the local survey teams members during the campaign.\u00a0 This can be considerably cheaper then using dedicated radio links.<\/p>\n

 <\/p>\n

Self Connections<\/strong><\/h4>\n

It is also possible to send data from a SNIP<\/strong><\/span> node back to itself.\u00a0 This has little practical value other then consuming your machine’s MIPS and bandwidth, but is not prevented by the SNIP<\/strong><\/span> control logic. The normal logic found in SNIP<\/strong><\/span> to prevent duplicate mountPt names will be used when needed to ensure that every mountPt is unique (adding terms like “_02”, “_03” the the mountPt name as needed).<\/p>\n

 <\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

As a general rule, SNIP can federate data from other Casters (including other SNIP installations) in any way you could care to connect such things.\u00a0 Use this ability to create the network you need, gather the set of data you need and to ensure that key data streams are distributed […]<\/p>\n","protected":false},"author":13,"comment_status":"open","ping_status":"closed","template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"ht-kb-category":[115],"ht-kb-tag":[361],"class_list":["post-2316","ht_kb","type-ht_kb","status-publish","format-standard","hentry","ht_kb_category-getting-started","ht_kb_tag-data-stream"],"_links":{"self":[{"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb\/2316","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb"}],"about":[{"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/types\/ht_kb"}],"author":[{"embeddable":true,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/comments?post=2316"}],"version-history":[{"count":19,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb\/2316\/revisions"}],"predecessor-version":[{"id":3900,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb\/2316\/revisions\/3900"}],"wp:attachment":[{"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/media?parent=2316"}],"wp:term":[{"taxonomy":"ht_kb_category","embeddable":true,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb-category?post=2316"},{"taxonomy":"ht_kb_tag","embeddable":true,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb-tag?post=2316"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}