Introducing PFAT

With release 1.12 and onward, the the P.F.A.T. control system present in the Enterprise editions of SNIP is being moved to the Pro, Basic, and Lite editions.  Lite copies of SNIP share the same code base, but many of these innovative features are disabled in the freely available Lite edition.

What is P.F.A.T.  (or PFAT)

PFAT™ is a control system used to operate on each data stream present in your SNIP Caster.  The acronym is made of four letters which reflect the processing stages of all data in SNIP as follows:

Parse — Parse and Decode the messages in the data stream for further processing.

Filter  — Remove any unwanted message content in the data stream.

Add  — Add wanted but missing data content to the data stream.

Translate  — Translate the contents of messages to align them to common needs (often a common datum translation) and express the messages themselves into alternative formats and packaging (including MSM, J2735, RTCM 2.4, RTCM 3.x private messages, etc.).

Until the 2.x release, the “FAT” part of this process has been unavailable to most SNIP users.  In the new release each stream is associated with its own “recipe” that describes the PFAT operations to be performed on it.

Why you should care

Many users today depend on the default Parse and Filter ability of SNIP to remove non-RTCM3 data (such as NMEA-183) from the data stream they send.  PFAT significantly further expands this ability.

Here are a few illustrative use cases where PFAT is of value to SNIP operators.

  • Parsing (which has been present in SNIP from the beginning) allows the detection of non-valid message content and its removal.  It’s a fact of life that this occurs more often than any of us would like.  Hence, SNIP was built to simply deal with it.
  • Filtering with PFAT allows removing unwanted message types, such as older style RTK RTCM 2.x 18 and 19 messages when only types 1 and 3 are wanted for classic DGPS used in marine and automotive safety application.
  • Filtering with PFAT allows removing unwanted and entire GNSS types from a stream, such as all GLONASS, typical when transmission bandwidth must be conserved.
  • Filtering with PFAT allows removing entire message types, such as 1019 and 1020 when orbital data is not wanted in the final stream.
  • Adding with PFAT allows the converse to occur.  One could, as an example, add selected orbital data for specific GNSS system to a data stream.
  • Adding with PFAT also allows adding private messages (RTCM 3.x messages in the range of 4000+) to an existing message stream.
  • Translating with PFAT provides a simple means to cope with a network of Base Stations all using different data in their report locations. One can replace the ECEF values sent by the base stations with those taken from a common datum, resolving the issue.
  • Translating with PFAT is how DSRC J2735 conformant data streams are created from RTCM for automotive users.

The PFAT process can be used on almost any stream type to create derivative data streams for further use.

Further Details

Here are few articles with additional details about each step in the process.

Use of Parse

Use of Filter

Use of Add

Uses of Translate

To be provided at rev 2 release
(After all, we need to keep the other Caster makers on their toes).

How to Set up PFAT

The PFAT settings and controls are all reached by use of the new expanded right-click stream menu system.

Until the formal release in 2.x, only the Parse on/off checkbox is enabled.

The other setting are further described in the links above.

The use of PFAT on any specific stream is optional.

With the improved auto-parse logic it is also safe to enable Parse on any stream you are unsure about and let SNIP work it out for you. If it is unable to determine the content type, it will revert to a bent pipe mode of operation.

Was this article helpful?

Related Articles

Leave A Comment?

You must be logged in to post a comment.