Navigation Data Filtering

Detailed Description

The NavFilter classes provide a framework for applying filters to navigation data. The primary purpose is to perform validity checks on raw navigation data and remove suspect data from a data stream.

The filter is implemented using a cascading filter approach, meaning that the data output by one filter becomes the input for the next. The order and choice of filters is entirely up to the developer.

To use the filter, the developer will instantiate a NavFilterMgr object, one per navigation structure type (e.g. one for GPS LNAV, one for GPS CNAV, and so on). Filters for that particular navigation message structure are instantiated and added to the manager using NavFilterMgr::addFilter(). Data is processed and returned using NavFilterMgr::validate().

Data is added to the NavFilterMgr using child classes of NavFilterKey. These child classes will have data members pointing to pre-existing storage of the navigation messages themselves. Using pointers to pre-existing storage allows the algorithm to operate quickly where it would otherwise have to make copies of blocks of memory. Most filters will not change the contents of the navigation message data, but that is not guaranteed and in fact some filters are intended to do just that (e.g. LNavCookFilter).

See also

NavFilterMgr for a list of examples.

Storing NavFilterKey Data

For performance reasons, the filter data is passed around using pointers rather than copying the messages themselves. The down side to this approach is that the user is subsequently required to manage the memory used to store the data being filtered. There are a number of ways to do this, including:

1. Keeping the data in a container of the application's data structure of choice, then discarding the data when appropriate. This approach is most appropriate when using filters of depth 1.
2. Creating new NavFilterKey classes that inherit from the filter data classes appropriate to the nav messages being process (e.g. LNavFilterData). The data in the application's data structure of choice could be stored as a new field in this child class or inheriting from both the NavFilter and data structure. This has the additional advantage that the application's data can be created dynamically on the heap and freed as the data is either rejected or accepted. This approach is most useful when using filters of depth 2 and larger.

See also

NavFilterMgr for a list of examples.

GPS Legacy Nav Filters

Filters in this group use the data class LNavFilterData, which contains a pointer to an array of 10 uint32_t values in host byte order. Each of the 10 values contains one subframe word each, with the 30 bits of the word in the 30 LSBs of the 32-bit value.

Class	Filter Depth	Modifies Msg
LNavFilterData	n/a	no
LNavAlmValFilter	1	no
LNavCookFilter	1	yes
LNavCrossSourceFilter	2	no
LNavEmptyFilter	1	no
LNavParityFilter	1	no
LNavTLMHOWFilter	1	no

GPS Civil Nav Filters

Filters in this group use the data class CNavFilterData, which contains a pointer to gnsstk::PackedNavBits object that contains the message data.

Class	Filter Depth	Modifies Msg
CNavFilterData	n/a	no
CNavCookFilter	1	yes
CNavCrossSourceFilter	2	no
CNavEmptyFilter	1	no
CNavParityFilter	1	no
LNavTWFilter	1	no

Classes
class	gnsstk::CNav2SanityFilter
class	gnsstk::CNavCookFilter
class	gnsstk::CNavCrossSourceFilter
class	gnsstk::CNavEmptyFilter
class	gnsstk::CNavParityFilter
class	gnsstk::CNavTOWFilter
class	gnsstk::GenericNavFilterData
class	gnsstk::LNavAlmValFilter
class	gnsstk::LNavCookFilter
class	gnsstk::LNavCrossSourceFilter
class	gnsstk::LNavEmptyFilter
struct	gnsstk::LNavEphMakerSort
class	gnsstk::LNavFilterData
class	gnsstk::LNavParityFilter
struct	gnsstk::LNavTimeSort
class	gnsstk::LNavTLMHOWFilter
class	gnsstk::NavFilter
class	gnsstk::NavFilterKey
class	gnsstk::NavMsgData
class	gnsstk::NavMsgDataBits
class	gnsstk::NavMsgDataPNB
class	gnsstk::NavMsgDataWords< WordSize >
struct	gnsstk::NavTimeSort