Page | 1 March 15, 2016
APN-038 Rev 5C
APN-038:
Pseudorange/Delta-Phase (PDP) and
GLIDE™ Filters
Page | 2 March 15, 2016
Pseudorange/Delta-Phase (PDP) and GLIDE Filters
Contents
Introduction .................................................................................................................................................. 4
PDP (Normal Mode PDP)............................................................................................................................... 4
About PDP ................................................................................................................................................. 4
History ....................................................................................................................................................... 4
Test Results ............................................................................................................................................... 5
Data from a Residential Neighborhood with Mature Trees ................................................................. 5
Data from an Urban Canyon ................................................................................................................. 6
Test Conclusions ....................................................................................................................................... 9
GLIDE (Relative Mode PDP) ......................................................................................................................... 10
About GLIDE ............................................................................................................................................ 10
Dual Frequency GLIDE ............................................................................................................................. 14
GLIDE Initialization .................................................................................................................................. 15
Using PDP/GLIDE ......................................................................................................................................... 16
Hardware Requirements ......................................................................................................................... 16
Firmware Requirements ......................................................................................................................... 16
OEM6 .................................................................................................................................................. 16
OEMStar .............................................................................................................................................. 18
Configuring a Receiver ............................................................................................................................ 19
Enable the PDP Filter .......................................................................................................................... 19
Specify the PDP Mode ......................................................................................................................... 19
Verify the PDP/GLIDE Position ............................................................................................................ 20
Using GLIDE with STEADYLINE™.......................................................................................................... 20
Commands .................................................................................................................................................. 22
BESTVELTYPE ........................................................................................................................................... 22
GLIDEINITIALIZATIONPERIOD .................................................................................................................. 22
PDPFILTER ............................................................................................................................................... 22
Page | 3 March 15, 2016
PDPMODE ............................................................................................................................................... 23
Logs ............................................................................................................................................................. 24
PDPPOS ................................................................................................................................................... 24
PDPSATS .................................................................................................................................................. 25
PDPVEL .................................................................................................................................................... 25
PDPXYZ .................................................................................................................................................... 25
Additional Information and Recommendations ......................................................................................... 26
Where to go for Support ............................................................................................................................. 27
Page | 4 March 15, 2016
Introduction
This application note contains NovAtel Pseudorange/Delta-Phase (PDP) filter details and general
guidance on how to use it. Revision 4 of this document also introduces GLIDE (relative PDP) to the
PDPFILTER command and the PDPMODE command. In addition, Revision 5B of this document
introduces dual-frequency GLIDE and additional information surrounding its use.
PDP (Normal Mode PDP)
About PDP
The PDP filter provides a filtered position and velocity solution based on assumed vehicle dynamics. The
advantage of this approach is smoother solution output and greater solution availability. The PDP
solution optimizes the absolute positioning accuracy of the GPS code observation and leverages the
excellent relative stability of the GPS carrier phase and Doppler observations. By optimally combining
these satellite signal observations, the solution stability improves over a traditional code-only
positioning algorithm.
PDP differs from a standard instantaneous positioning algorithm, which will only give a solution when
more than 3 satellites are visible. The PDP allows a solution to be generated for short periods when
fewer than 4 satellites are visible using what observations are available and assumptions about vehicle
dynamics. Having more observations available allows better observation error detection so that poor
observations are rejected before making it into the solution.
In conditions where GPS signal tracking is hampered by obstructions such as trees or buildings, the PDP
filter will bridge through brief partial or even complete GPS outages while providing a continuous
position/velocity solution. In conditions where satellites are coming in and out of the solution, the PDP
helps minimize position solution jumps often associated with satellite geometry changes.
The PDP is not intended to provide a solution in all conditions. In conditions where satellite signals are
completely blocked for extended periods, such as in a tunnel or severe urban settings, the PDP will have
the same problems as all satellite based navigation systems and a solution will not be possible.
History
The motivation for the PDP filter approach came from Sportvision, a customer of NovAtel Inc.
Sportvision brought NovAtel a set of racing environment requirements. They wanted to have meter-
level positioning accuracy on NASCAR racecars so they could provide real-time computer graphics that
followed the cars as they went across the television screen. The difficulty in this problem was that
better-than-normal pseudorange positioning was required, but the duration of the satellite constellation
was too short for either fixed ambiguity positioning or accurate floating ambiguity positioning. PDP
satisfied the requirements to the extent that Sportvision uses the technology and the results can be
seen during televised NASCAR races on either FOX or NBC.
Page | 5 March 15, 2016
Test Results
The plots in Figure 1 and Figure 2 show data from a residential Calgary neighborhood known for its
mature trees. The plots in Figure 5 and Figure 6 on pages 7 and 8 respectively show data position
improvement through downtown Calgary, with its associated urban canyon geography.
Data from a Residential Neighborhood with Mature Trees
Compare the least-squares trajectory with the inertial control trajectory in Figure 1 and the PDP
trajectory in Figure 2. NovAtel’s inertial system generated the inertial control and consisted of the
integration of an OEM4 receiver operating in differential carrier mode and a Honeywell HG1700-AG11
inertial measurement unit. The PDP trajectory shows the output of the PDP Kalman filter.
Figure 1: Residential Neighbourhood Least Square Plot of Inertial Trajectory
Figure 2: Residential Neighbourhood PDP Plot of Inertial Trajectory
Page | 6 March 15, 2016
The result is a much smoother and more accurate trajectory. The filter also bridges through the portions
of the test when fewer than four satellites are in view. The maximum horizontal position error for this
test has been reduced by half—from over 40 m to approximately 20 m. The position availability
percentage has increased from 87 to 100 percent (see Table 1 below and Table 2 on page 6).
Table 1: Residential Neighbourhood Solution Availability
Parameter
Least
Squares
PDP Filter, All
Solutions
Computed Solution Epochs
1,270
1,459
Total Possible
1,459
1,459
% Achieved
87
100
Table 2: Residential Neighbourhood Position Accuracy
Parameter
Least
Squares
PDP Filter, All
Solutions
Latitude Error RMS
3.814
2.788
Longitude Error RMS
1.784
0.786
Height Error RMS
13.721
12.508
2D Position Error RMS
4.210
2.896
Data from an Urban Canyon
In the urban canyon setting, improvements are even more evident. Figure 3 and the satellite visibility
plot in Figure 4, below, shows the tracking environment in the urban core. Not only is the constellation
masked, but the receiver must also occasionally track a reflected signal rather than the direct signal.
Figure 4 shows that there are fewer than four satellites available for a significant portion of the time.
Figure 3: Urban Canyon (4th Avenue, Calgary, facing west)
Page | 7 March 15, 2016
Figure 4: Urban Canyon Satellite Visibility
Figure 5 shows least-squares-derived horizontal positions in the downtown corridors. The least squares
trajectory for the first downtown dataset shows very noisy data and clearly demonstrates the effect of
unchecked multipath errors. Maximum horizontal position error is approaching 600 m during portions of
this dataset.
Figure 5: Urban Canyon Least-Squares Plot of Inertial Trajectory
Page | 8 March 15, 2016
The PDP trajectory in Figure 6 below shows the results of filtering the GPS observations and the solution
availability when fewer than four satellites are in view. The solution availability improves to 99 percent
(see Table 3 below). The maximum horizontal position error reduces from 600 m to 95 m. The position
error in the north/south direction (latitude) is significantly higher than that in the east/west direction
(longitude), as shown in Table 4 below. Since this test is performed primarily driving in east/west
directions with high buildings on the north and south of the vehicle, the satellite geometry is such that
the along-track direction (east/west) will be better constrained than the across-track (north/south).
Figure 6: Urban Canyon PDP Plot of Inertial Trajectory
Table 3: Urban Canyon Solution Availability
Parameter
Least
Squares
PDP Filter, All
Solutions
Computed Solution Epochs
5,021
7,103
Total Possible
7,180
7,180
% Achieved
70
99
Table 4: Urban Canyon Position Accuracy
Parameter
Least
Squares
PDP Filter, All
Solutions (m)
Latitude Error RMS
58.359
19.632
Longitude Error RMS
26.443
4.454
Height Error RMS
42.038
26.218
2D Position Error RMS
64.070
20.130
Page | 9 March 15, 2016
Test Conclusions
There are improvements in solution availability with the PDP filter. This is evident in the reduction of
both the amount of time a solution is not available and the position spikes from multipath. With PDP,
satellites that lose lock can be reacquired without significant loss in performance provided that at least
four satellites (the same or various) are maintained across the delta time between epochs.
The test results show that PDP improves positioning availability in established residential neighborhoods
by over 10 percent and in urban canyon settings by 40 percent. PDP has also improved single-point
horizontal accuracy from 4 m (2 dRMS) to 3 m (2 dRMS) in residential neighborhoods. In urban canyon
settings, with PDP, accuracy has improved significantly, from 64 m (2 dRMS) to 20 m (2 dRMS) in one
test and from 7.6 m (2 dRMS) to 6.0 m (2 dRMS) in another.
Page | 10 March 15, 2016
GLIDE (Relative Mode PDP)
About GLIDE
GLIDE is a PDP mode that is tuned and optimized for error consistency rather than absolute accuracy. It
is therefore intended for users who prefer precision over accuracy, and for applications that do not
require long-term repeatability.
Figure 7: Precision versus Accuracy
GLIDE combines code, phase, and Doppler measurements from each satellite.
Code: accurate but not precise
Phase: precise but not accurate
While normal mode PDP optimizes a solution in multiple conditions, GLIDE is designed for one major
purpose – position smoothing to provide accurate “pass-to-pass”
1
performance. This is ideally in clear
sky conditions where the user needs a tight, smooth, and consistent output. An example of an
application for which GLIDE is optimized is shown in Figure 8 below.
1
The term “pass-to-pass” is used to describe a standard 15 minute time frame for evaluating relative accuracy.
The idea is that in 15 minutes, in an agricultural application, the user will have completed one pass of a field, or a
portion thereof, and be separated from the starting location by a fixed path width plus a position error. The
purpose of GLIDE is to minimize the change in error over time (ie: 15 minutes).
Page | 11 March 15, 2016
Figure 8: Broad Acre Farming and Pass-to-Pass Example
Normal mode PDP is smoother than a least squares fit but is still noisy in places. GLIDE produces a very
smooth solution with consistent rather than absolute position accuracy. See Figure 9 on page 12 for a
comparison of a least squares, PDP, and GLIDE solution. Using GLIDE significantly reduces the variation
in position errors to less than 1 cm from one epoch to the next. GLIDE works with single point, DGNSS
and SBAS modes and can use signals from GPS, GLONASS and BeiDou constellations when available.
Page | 12 March 15, 2016
Figure 9: Position Error with WAAS for Least Squares (PSR) vs. PDP vs. GLIDE
1.05 1.06 1.07 1.08 1.09 1.1 1.11 1.12
x 10
5
-1.5
-1
-0.5
0
0.5
1
1.5
GPS Time (s)
metres
FLEX V1 with WAAS - PSR
Easting
Northing
1.05 1.06 1.07 1.08 1.09 1.1 1.11 1.12
x 10
5
-1.5
-1
-0.5
0
0.5
1
1.5
GPS Time (s)
metres
FLEX V1 with WAAS - PDP
Easting
Northing
1.05 1.06 1.07 1.08 1.09 1.1 1.11 1.12
x 10
5
-1.5
-1
-0.5
0
0.5
1
1.5
GPS Time (s)
metres
FLEX V1 with WAAS - GLIDE
Easting
Northing
Page | 13 March 15, 2016
For the comparisons above, we used a FlexPak-V1 receiver with a GPS-702-GGL antenna mounted on a
vehicle traveling east to west at speeds of 5 to 12 km/hour. We collected approximately 2 hours of data.
Notice how the PDP solution is much less noisy than the least-squares pseudorange (PSR) solution. Then,
the GLIDE solution is even smoother.
The GLIDE effect is most noticeable when using a SMART-V1 antenna, which has a lower quality antenna
than the 700-series antenna we used in the above comparison. Its PSR solution is much noisier and the
GLIDE solution smoothes it exceptionally well. Please refer to our GLIDE white paper, available on our
website at http://www.novatel.com/products/whitepapers.htm, for more results and comparisons using
different products.
Consider the case of an agricultural user plowing rows in a field. This user, with clear skies, prefers to
have minimal differences in position between now and 15 minutes ago rather than knowing the exact
position to within millimeters. See Figure 10 below.
Figure 10: Agricultural User and GLIDE
Page | 14 March 15, 2016
Dual-Frequency GLIDE
Introduced in firmware version 6.200 (OEM060200RN0000) for OEM6® receivers is dual-frequency
GLIDE. This new functionality, available with dual-frequency receiver models, uses both code and phase
measurements from L1 and L2 signals to compensate for delays due to the signals passing through the
ionosphere. Ionospheric delay is typically the largest error source in GNSS positioning.
Single-frequency (L1) GLIDE uses models to estimate the ionospheric delay.
Dual-frequency (L1+L2) GLIDE uses measurements to compute the delay.
Dual-frequency GLIDE improves the absolute and relative (pass-to-pass) accuracy of the GLIDE position
and creates a robust solution, resistant to the effects of high ionospheric activity. Figure 11 below
illustrates the evolution of GLIDE using data collected in a high-ionospheric environment. The plots
specifically highlight the benefits of dual-frequency GLIDE for pass-to-pass performance.
Figure 11: GLIDE Pass-to-Pass Performance Comparison in High Ionospheric Activity
Page | 15 March 15, 2016
In challenging ionospheric environments, the dual-frequency GLIDE solution maintains solid pass-to-pass
performance compared to other solutions. It is important to note that the key objective achieved with
GLIDE is a smooth solution with good time-relative accuracy which can sometimes be at the expense of
absolute accuracy. The GLIDE solution can have a bias which can be compensated for with steering and
guidance systems.
GLIDE Initialization
When the receiver is first configured for GLIDE, it will operate in normal mode PDP for a period of time
until GLIDE has initialized. The initialization period allows the receiver to improve the absolute accuracy
and gather SBAS corrections if SBAS has been enabled
2
.
It is important to have open sky conditions during initialization although the antenna can be moving or
stationary. When using the automatic dynamics setting, it can be beneficial to remain stationary during
initialization to take advantage of the auto-detection of dynamics for improved absolute accuracy. The
default GLIDE initialization time is 300 seconds, but it can be adjusted using the
GLIDEINITIALIZATIONPERIOD command (page 22) in special cases. At the same time, the startup time
for an SBAS solution is 3-5 minutes to allow for a full set of SBAS ionospheric grid corrections to be
received.
2
To enable SBAS tracking, use the SBASCONTROL command. See
www.novatel.com/assets/Documents/Manuals/om-20000129.pdf for more details.
Page | 16 March 15, 2016
Using PDP/GLIDE
Hardware Requirements
Normal mode PDP is available on all OEMStar and OEM6 receivers. GLIDE is also available on both
platforms but a specific model option is required.
Firmware Requirements
All OEMStar and OEM6 firmware versions support single-frequency GLIDE and PDP mode. To take
advantage of dual-frequency GLIDE on OEM6 receivers, version 6.200 (OEM060200RN0000) or later is
required along with dual-frequency receiver and antenna hardware.
For best performance and solution availability on either platform, a model enabled for both GPS and
GLONASS is required. In regions where SBAS corrections are available, PDP and GLIDE are able to
continue using GLONASS satellites in the solution even though current SBAS systems do not provide
corrections for those satellites. For users operating in mature SBAS regions, such as WAAS or EGNOS, it
is recommended to always enable SBAS along with PDP or GLIDE for best overall accuracy.
OEM6
Based on the OEM6 model structure, firmware model option 6 must be enabled (“G” or “R”) to use
GLIDE on OEM6 receivers. For example:
OEM615-G1S-00G-0T0
SM6L-D2L-0PG-0T0
PP6-D2J-RPR-TTN
Figure 12: OEM6 Model Structure & Firmware Model Options Required for GLIDE
Channel configuration options for dual-frequency (L1 & L2) tracking must be included in the model to
use dual-frequency GLIDE, as well as GPS+GLONASS tracking to take advantage of both constellations.
To allow for this, the first two firmware options must be “D” and “2” as shown in the examples and in
Figure 12.
Page | 17 March 15, 2016
There are many other OEM6 firmware model options available, such as those that enable NovAtel’s
ALIGN®, RTK, API, SPAN, etc., but the options mentioned above are the minimum requirements to use
GLIDE.
To verify the model currently loaded and being used on a receiver, use the command “LOG VERSION” to
output the version information. For example:
<VERSION COM1 0 83.0 FINESTEERING 1786 421494.851 00000020 3681 13498
< 1
< GPSCARD "D2LRPGTT0" "BFN11210275" "OEM628-1.01" "OEM060620RN0000"
"OEM060200RB0000" "2015/Jul/08" "16:47:41"
In this example, the model options indicate the following:
Channel configuration options allow tracking of:
o D: GPS+GLONASS
o 2: L1/L2/E1/B1 signals
o L: SBAS/L-Band
Positioning options available:
o R: RTK Fixed, RTK Float, RTK Tx (transmit), DGPS Tx/Rx (transmit/receive)
o P: PPP
o G: GLIDE
Page | 18 March 15, 2016
OEMStar
For OEMStar and Ag-Star receivers, the model structure is simpler but the model must include the “S”
option to allow the use of GLIDE.
Table 5: Position Types by Log
Designator
Description
G
L1 GLONASS channels, frequencies to match GPS configuration
D
Transmit DGPS corrections
M
Measurements
T
10 Hz logging
S
GLIDE
A
API
I
Raim
Some examples are provided in Table 6.
Table 6: Example Models with Corresponding Marketing Name
Marketing Name
Receiver Software Model
OEMSTAR-10HZ
LXMTS
OEMSTAR-10HZ-G
LXGMTS
AG-STAR-10HZ-G
LXGMTSA
OEMStar models with “PVT” in the marketing name, such as “OEMSTAR-PVT-1HZ” (M6XV1G or LX as
reported by the receiver), support normal mode PDP only and not GLIDE.
The VERSION log can be requested from an OEMStar receiver to verify the model currently loaded.
Example:
<VERSION COM1 0 65.5 FINESTEERING 1878 234092.513 00000000 3681 12778
< 1
< GPSCARD "LXGMTS" "BHD10040038" "M6XV1G-1.01-TT" "L6X010201RN0000" "1.001"
"2014/Feb/27" "16:49:20"
Page | 19 March 15, 2016
Configuring a Receiver
Enable the PDP Filter
By default, the PDP filter is disabled on OEM6 receivers. To enable the filter, the “PDPFILTER” command
is used. On OEMStar and AG-STAR, the filter is enabled in normal mode by default.
To enable the PDP filter:
PDPFILTER ENABLE
The command above is required for both normal mode PDP and GLIDE. The mode used depends on the
“PDPMODE” command setting which is described in the next section. The PDPFILTER command must be
used first.
Specify the PDP Mode
Once enabled, the “PDPMODE” command is used to specify the operating mode and dynamics of the
PDP filter. By default, the filter mode is “normal” and the dynamics is “auto”.
The “PDPFILTER” command must be sent first, before modifying “PDPMODE” settings.
NORMAL Mode
To select normal mode PDP with automatic dynamics, this is the required command:
PDPMODE NORMAL AUTO
The above command is also the default setting for PDPMODE.
GLIDE/RELATIVE Mode
For GLIDE (also known as “relative” mode), the PDPMODE command supports two options:
PDPMODE RELATIVE [dynamics mode] or PDPMODE GLIDE [dynamics mode]
There is no difference between “GLIDE” and “RELATIVE” in terms of the PDPMODE command. However,
some users may prefer to use “GLIDE” as it is most intuitive and direct in its name.
Dynamics Mode
In most cases “auto” is the recommended setting and will provide optimum PDP performance for both
normal and GLIDE modes. However, the dynamics mode can also be explicitly set to “static” or
“dynamic” for applications that require it. For example, these are some exceptions where the mode
should explicitly be set to “dynamic” or “static”:
In applications with extremely slow motion (movement at less than a 2 cm/s for a number of
seconds) it is best to use the “dynamic” setting.
In extremely noisy environments with high logging rates (10 or 20 Hz) “static” mode can be
selected when the user knows they are stationary.
Page | 20 March 15, 2016
Verify the PDP/GLIDE Position
To verify the availability of a PDP position solution, either normal mode or GLIDE, the following position
logs can be output using the “LOG” command:
PDPPOS
PDPXYZ
BESTPOS
GPGGA
For example, the following command will request the PDPPOS log in binary format on the Com1 port
with a rate of 2 Hz:
LOG COM1 PDPPOSB ONTIME 0.5
The PDPPOS log will always output the PDP solution when available, whereas the BESTPOS and GPGGA
logs will output the “best available” solution. When using BESTPOS or GPGGA logs, another solution can
be output in some cases. The receiver uses the estimated standard deviations, based on the
“SETBESTPOSCRITERIA” command setting
3
, to determine the “best” solution available. By default, the
receiver will use the three dimensional standard deviation.
For BESTPOS and PDPPOS logs, the “extended solution status” can be used to determine when GLIDE
has initialized. See PDPPOS (page 24) for more details.
Using GLIDE with STEADYLINE™
The stability and pass-to-pass performance of GLIDE make it an optimal fallback when using higher
accuracy solutions such as RTK. However, for GLIDE to be available when necessary, it must be enabled
in the background even if the GLIDE solution is not the best available.
NovAtel receivers have multiple positioning filters or “engines” that can run simultaneously and the
“BEST” filter will select and provide the best solution based on variance and availability. Offsets or
“biases” between the solutions can cause position “shifts” when directly switching between solutions
from different filters. STEADYLINE
4
is a feature that handles such position shifts and operates as the last
step before populating the BESTPOS log.
3
See www.novatel.com/assets/Documents/Manuals/om-20000129.pdf for the SETBESTPOSCRITERIA definition.
4
See OM-20000129 (previous link) for details on STEADYLINE.
Page | 21 March 15, 2016
Figure 13: Position Engines and STEADYLINE
In cases where a receiver is configured for RTK and there is an outage in the radio link, STEADYLINE will
use the next available solution to either maintain the RTK path until the corrections come back or
provide the smoothest transition possible between the RTK and GLIDE trajectories. The receiver must
be initially configured with GLIDE and STEADYLINE enabled to take advantage of this functionality when
necessary.
The effects of STEADYLINE can be especially evident in cases where the RTK solution is biased due to an
offset in the base station coordinate or the use of different reference datums. In those cases, using
STEADYLINE and GLIDE with RTK can prevent large position jumps in the BESTPOS solution in the event
that RTK is lost.
Page | 22 March 15, 2016
Commands
All of the commands and logs mentioned in this document are described in full detail in the OEM6
Firmware Reference Manual (www.novatel.com/assets/Documents/Manuals/om-20000129.pdf).
BESTVELTYPE
The BESTVELTYPE can be used to configure the source of the velocity that is output in the BESTVEL and
GPVTG logs. With the default setting of “BESTPOS”, the BESTVEL and GPVTG logs will contain the
velocity associated with best solution available. If the PDP solution is currently the best available, the
velocity will come from a delta-position calculation and is typically more latent than other solutions due
to additional filtering.
Some applications require a low-latency velocity and in those cases it can be beneficial to always output
a Doppler velocity since it is the lowest latency velocity available from the receiver. To always output
the Doppler velocity, regardless of the source of the position solution in BESTPOS, use the following
command:
BESTVELTYPE DOPPLER
Otherwise, this is the default setting:
BESTVELTYPE BESTPOS
GLIDEINITIALIZATIONPERIOD
The GLIDEINITIALIZATIONPERIOD command is an advanced setting that can be used in special cases to
adjust the length of time GLIDE takes to initialize. The setting can be increased to as much as 20
minutes in environments with very high multipath. The default setting is 300 seconds.
GLIDEINITIALIZATIONPERIOD 300
When using the automatic dynamics setting, GLIDE will perform a static initialization for as long as the
user remains static. If the user begins to move before the initialization period is up, GLIDE will continue
with a dynamic initialization until the initialization time is complete.
Increasing the initialization period will delay the transition of the PDP filter from normal mode to GLIDE.
The added delay can help improve the absolute error as much as possible before changing to GLIDE
where pass-to-pass accuracy is preferred. Decreasing the initialization period will shorten the time
before the PDP filter will transition to GLIDE mode. However, doing so can result in degraded absolute
accuracy of the GLIDE solution when initialized. It is recommended to only increase or decrease the
initialization period in special cases, or for testing, and only if the application can tolerate the resulting
behaviour.
Page | 23 March 15, 2016
PDPFILTER
The PDPFILTER command is used to enable the PDP filter and must be used before modifying PDP mode
settings. PDPFILTER is disabled by default on OEM6 receivers but is enabled by default on OEMStar and
AG-STAR products. The command to enable the PDP filter is:
PDPFILTER ENABLE
In special cases the PDPFILTER command can also be used to reset GLIDE to remove any accumulated
biases, but doing so will cause a re-initialization of the filter. The command to reset the PDP filter is:
PDPFILTER RESET
PDPMODE
Once the PDP filter has been enabled with the PDPFILTER command, the PDPMODE command is used to
specify the PDP mode (normal or GLIDE) and the dynamics setting. The default setting is normal mode
with automatic dynamics.
PDPMODE NORMAL AUTO
For GLIDE, the mode can be specified as “RELATIVE” or “GLIDE”. For example:
PDPMODE GLIDE DYNAMIC
In most cases “auto” is the recommended dynamics setting and will provide optimum PDP performance
for both normal and GLIDE modes. However, the dynamics mode can also be specifically set to “static”
or “dynamic” for applications that require it. For example, these are some exceptions where the mode
should explicitly be set to “dynamic” or “static”:
In applications with extremely slow motion (movement at less than a 2 cm/s for a number of
seconds) it is best to use the “dynamic” setting.
In extremely noisy environments with high logging rates (10 or 20 Hz) “static” mode can be
selected when the user knows they are stationary.
Page | 24 March 15, 2016
Logs
Any of the logs described below can be output using the LOG command. Appending an “A” or a “B” to
the log name when sending the LOG command will output the message in full ASCII (examples below are
‘abbreviated’ ASCII) or binary respectively. For example, the command “LOG PDPPOSB” will log the
PDPPOS log in binary format.
For complete details about the LOG command, including how to specify the data rate/interval and
trigger, see the LOG command definition in the OEM6 Firmware Reference Manual
(www.novatel.com/assets/Documents/Manuals/om-20000129.pdf).
PDPPOS
The PDPPOS log contains the position solution computed specifically by the PDP filter. For example:
<PDPPOS COM1 0 67.0 FINESTEERING 1878 235100.000 00000000 21dc 12778
< SOL_COMPUTED SINGLE 51.11680432844 -114.03886985769 1063.5435 -16.9000 WGS84
0.2878 0.2126 0.4029 "" 0.000 0.000 14 14 0 0 0 12 00 11
The 19
th
field after the header in the PDPPOS log (also included in BESTPOS) is the “Extended Solution
Status”. Bit 0 of this field indicates when the solution is a GLIDE solution. When that bit is not set, the
solution will be a normal mode PDP solution. In the above example, the extended solution status is
“12”, which means that the receiver is in normal mode PDP. Here is another example with a GLIDE
solution:
<PDPPOS COM1 0 58.5 FINESTEERING 1878 247099.000 00000000 21dc 12778
< SOL_COMPUTED WAAS 51.11679370493 -114.03886763918 1064.4956 -16.9000 WGS84
0.3994 0.2571 0.5246 "138" 4.000 0.000 14 12 0 0 0 1b 00 11
The possible position types associated with a PDP solution (GLIDE or normal mode) are outlined in Table
7 below. Note that the BESTPOS log will report the same position types when the PDP solution is the
best available.
Table 7: PDPPOS Position Types with Equivalent GPGGA Quality Indicator Values
PDPPOS Type
GPGGA Quality
Description
NONE
0
No solution
SINGLE
1
Autonomous or “single point”
WAAS
9
5
SBAS solution (EGNOS, WAAS, etc.)
PSRDIFF
2
Differential (DGPS) solution
PROPAGATED
6
Propagated solution using previous velocity
When there are significant signal blockages, such as those caused by trees, the previous velocity can be
used by the PDP filter to provide a propagated solution for a brief period of time.
5
NovAtel labels SBAS solutions with a value of 9 by default, but the GGAQUALITY command can be used to remap
the GPGGA quality indicator. See www.novatel.com/assets/Documents/Manuals/om-20000129.pdf for more
details.
Page | 25 March 15, 2016
PDPSATS
This log provides a list of the used and unused satellites for the corresponding PDPPOS solution. The
signals of the used satellites are also described, along with the reasons for exclusions.
For example:
<PDPSATS COM1 0 63.5 FINESTEERING 1878 234901.000 00000000 be33 12778
< 14
< GPS 21 GOOD 00000001
< GPS 20 GOOD 00000001
< GPS 22 GOOD 00000001
< GPS 15 GOOD 00000001
< GPS 10 GOOD 00000001
< GPS 27 GOOD 00000001
< GPS 14 GOOD 00000001
< GPS 24 GOOD 00000001
< GPS 8 GOOD 00000001
< GPS 18 GOOD 00000001
< GLONASS 21+4 GOOD 00000001
< GLONASS 7+5 GOOD 00000001
< GLONASS 22-3 GOOD 00000001
< GLONASS 6-4 GOOD 00000001
PDPVEL
This PDPVEL log contains the velocity computed by the PDP filter when it is enabled. For example:
<PDPVEL COM1 0 69.5 FINESTEERING 1878 411638.000 00000000 2208 12778
< SOL_COMPUTED SINGLE 0.250 0.000 1.5208e-08 348.658906 4.4341e-10 0.0
PDPXYZ
The PDPXYZ log contains the Cartesian position and velocity in X, Y and Z coordinates as computed by
the PDP filter when it is enabled. For example:
<PDPXYZ COM1 0 70.5 FINESTEERING 1878 411641.000 00000000 6750 12778
< SOL_COMPUTED SINGLE -1634550.4061 -3664567.9584 4942526.7319 0.2971 0.4434
0.3632 SOL_COMPUTED SINGLE 0.0000 0.0000 0.0000 0.0011 0.0011 0.0011 "" 0.250 0.000
0.000 12 12 0 0 0 1b 00 11
This log also contains corresponding standard deviations (X, Y and Z components) for the position and
velocity.
Page | 26 March 15, 2016
Additional Information and Recommendations
In general, with any NovAtel product, it is recommended to use normal mode PDP as a minimum when
operating in autonomous or SBAS modes.
While GLIDE is optimized for agriculture, specifically open-sky conditions, “normal mode” PDP can
provide good performance in cases where a constant clear view of the sky is not possible. For example,
small fields that are lined with tall trees can cause frequent or extended (and significant) signal
blockages for a GNSS receiver. Such blockages can result in extra biases in GLIDE that can be
undesirable for some applications. This can be especially evident when turns at tree lines (headland
turns) are combined with a change in dynamics. As well, headland turns can be multi-point which can
increase signal blockages due to extended time spent in close proximity of trees. In some cases, normal
mode PDP can provide better performance in those conditions. However, GLIDE is still recommended if
pass-to-pass accuracy is crucial for the application.
To provide the best performance with GLIDE:
Ensure the antenna is located in an area that has a clear view of the sky with no obstructions,
especially during initial startup and initialization.
If the vehicle and antenna can and will be stationary during convergence, use the “AUTO”
setting for PDPMODE (page 23) to take advantage of automatic dynamics detection and
filtering.
Use SBAS or DGNSS corrections when available.
Select a high quality antenna with good multipath rejection capabilities, such as NovAtel’s
Pinwheel™ antennas.
o An agricultural environment can often have multiple sources of multipath, including
surfaces of surrounding machinery, trees, buildings, etc.
Page | 27 March 15, 2016
Where to go for Support
To help answer questions and/or diagnose any technical issues that may occur, the NovAtel Support
website is a first resource: www.novatel.com/support/.
Remaining questions or issues can be directed to NovAtel Support by visiting
www.novatel.com/support/contact/. To enable the online form and submit a ticket, first select a
"Product Line" and then an associated "Product" from the list.
However, before contacting Support, it is helpful to collect data from the receiver to help investigate
and diagnose any performance-related issues. In those cases, if possible, collect the following list of logs
(the LOG command with the recommended trigger and data rate is included):
LOG VERSIONA ONCE
LOG RXSTATUSA ONCHANGED
LOG RAWEPHEMB ONCHANGED
LOG ALMANACB ONCHANGED
LOG IONUTCB ONCHANGED
LOG GLORAWEPHEMB ONCHANGED
LOG GLORAWALMB ONCHANGED
LOG GLOCLOCKB ONCHANGED
LOG RANGEB ONTIME 1
LOG BESTPOSB ONTIME 1
LOG PDPPOSB ONTIME 1
LOG PDPSATSB ONTIME 1
The data described above can be collected using a terminal program that supports binary data logging,
or NovAtel’s CONNECT utility can be downloaded and installed from the NovAtel website:
www.novatel.com/support/info/documents/809
Page | 28 March 15, 2016
