With the advent of release 1.10 and onward, SNIP now uses intelligent auto-parse logic to determine the format of the messages in the data stream and reacts accordingly.
As a best practice, enable the Parse checkbox on all streams. Do this unless you specifically want the stream to be treated in the bent-pipe mode (where all inbound content is sent to all corrected users with no PFAT operations applied to it).
Default Parse behavior for new in-bound data streams is set on the major tab (Push-In) and on the individual setup dialog for each of the other stream types. Every active data stream has its own Parse menu item in the right-click stream menu system. When SNIP stores the settings data for a stream, the current Parse setting is also kept.
Side Note: Because of this improvement, the RTK2go.com site has also been switched to a default parse enabled mode. In the past, a few users with CMR and CMR+ type data streams requested that we leave default Parsing off. A prior reservation was required to enable parsing for RTCM3 users. Getting your own reservation is still the best way to use RTK2go as your own Caster. In the current release, SNIP will correctly deal both RTCM 3 and other message types without user intervention. This setup better serves those L1-only users of RTK2go who often need SNIP‘s help creating a suitable Caster Table Entry.
By enabling Parse on a data stream, SNIP will detect if the stream contains RTCM3 message (as well as other well know formats) and set suitable content in the Caster Table Entry for that stream to complete it. If the stream provides a field or an entry, that data will be used.
If the data is in the RTCM 3.x format, SNIP will analyze the data and extract details about it. This includes the RTCM 3.x message types present, details about the Base Station, and various counts and statics about the data itself. RTCM 3.x messages can decoded and shown in a view, or used to feed basic graphical navigation filters.
If the data is in the RTCM 2.x format, SNIP will also analyze the data and extract more limited details about the data stream and the RTCM 2.x message types present.
Other formats (such as uBlox binary) are also detected, and set in the Caster Table Entry. The universal decoder provides some content details, but further processing such a navigation filtering is not provided.
How It Works…
When a stream first starts, an analysis process occurs for the first 3KB of data or the first 30 seconds of its lifetime (whichever occurs first).
During that time the data is not sent to end users, this ensures that gross corrupted data is not sent onward. Hence no PFAT content filtering is occurring either. The data stream is not yet published for use by NTRIP Clients.
During this period of time, if the data stream comes from another NTRIP Caster, a copy of the remote Caster Table entries are obtained and compared with the data present. Certain conflicts are reported when found, otherwise the remote data is used in the local Caster Table.
When analysis completes, the message format is determined and used to create the local Caster Table Entry (if needed). A few other tasks then occur.
- The types of different messages present are recorded
- Various message counts over the measurement periods are used determine average message rates
- A task is scheduled for 15 minutes later to recompute the message rates once more data has been obtained
- The Base Station details are added to a tooltip for that stream, and periodically updated thereafter.
- The new stream is added to the Caster Table and NTRIP Clients can then connect to it in the normal way.
When ECEF messages arrive in the stream, these are used to update the gross position in the Caster Table Entry, and also for use in navigation and other places. If a PFAT datum transformation is active, it is applied to the value to align them.
After the stream has operated for >180 seconds, it is considered further for inclusion in any NEARest data stream operating within its coverage area.