SAM-M10Q-Integration manual
If a sanity check against a limit of the dynamic platform model fails, then the position solution
becomes invalid. Table 4 shows the types of sanity checks which are applied for a particular dynamic
platform model.
2.1.2.2 Navigation input filters
The navigation input filters in the CFG-NAVSPG-* configuration group control how the navigation
engine handles the input data that comes from the satellite signal.
Configuration item Description
CFG-NAVSPG-FIXMODE By default, the receiver calculates a 3D position fix if possible but reverts to 2D
position if necessary (auto 2D/3D). The receiver can be forced to only calculate 2D
(2D only) or 3D (3D only) positions.
CFG-NAVSPG-CONSTR_ALT, CFG-
NAVSPG-CONSTR_ALTVAR
The fixed altitude is used if fixMode is set to 2D only. A variance greater than zero
must also be supplied.
CFG-NAVSPG-INFIL_MINELEV Minimum elevation of a satellite above the horizon to be used in the navigation
solution. Low-elevation satellites may provide degraded accuracy, due to the long
signal path through the atmosphere.
CFG-NAVSPG-INFIL_MINSVS, CFG-
NAVSPG-INFIL_MAXSVS
Minimum and maximum number of satellites to use in the navigation solution.
There is an absolute maximum limit of 32 satellites that can be used for navigation.
CFG-NAVSPG-INFIL_NCNOTHRS,
CFG-NAVSPG-INFIL_CNOTHRS
A navigation solution will only be attempted if there is at least the given number of
satellites with signals at least as strong as the given threshold.
Table 5: Navigation input filter parameters
If the receiver only has three satellites for calculating a position, the navigation algorithm uses a
constant altitude to compensate for the missing fourth satellite. When a satellite is lost after a
successful 3D fix (min four satellites available), the altitude is kept constant at the last known value.
This is called a 2D fix.
u-blox receivers do not calculate any navigation solution with less than three satellites.
2.1.2.3 Navigation output filters
The result of a navigation solution is initially classified by the fix type (as detailed in the fixType
field of UBX-NAV-PVT message). This distinguishes between failures to obtain a fix at all ("No Fix")
and cases where a fix has been achieved, which are further subdivided into specific types of fixes
(for example, 2D, 3D ).
Where a fix has been achieved, the fix is checked to determine whether it is valid or not. A fix is only
valid if it passes the navigation output filters as defined in CFG-NAVSPG-OUTFIL. In particular, both
PDOP and accuracy values must be below the respective limits.
Important: Users are recommended to check the gnssFixOK flag in the UBX-NAV-PVT or
the NMEA valid flag. Fixes not marked as valid should not be used.
UBX-NAV-STATUS message also reports whether a fix is valid in the gpsFixOK flag. These
messages have only been retained for backwards compatibility and it is recommended to use the
UBX-NAV-PVT message.
2.1.2.4 Odometer filters
2.1.2.4.1 Speed (3D) low-pass filter
The CFG-ODO-OUTLPVEL configuration item activates a speed (3D) low-pass filter. The output of
the speed low-pass filter is available in the UBX-NAV-VELNED message (speed field). The filtering
level can be set via the CFG-ODO-VELLPGAIN configuration item and must be between 0 (heavy low-
pass filtering) and 255 (weak low-pass filtering).
UBX-22020019 - R01
2 Receiver functionality Page 12 of 72
C1-Public
To Next Page
Loading...
