ZED-F9P-Integration Manual
UBX-18010802 - R02
4 Receiver description Page 53 of 114
Advance Information
during the expected lifetime of the system (the first ambiguous date will be in 2124). Therefore,
u-blox 9 receivers using Protocol Version 24 and above regard the date information transmitted
by GLONASS, BeiDou and Galileo to be unambiguous and, where necessary, use this to resolve any
ambiguity in the GPS date.
Customers attaching u-blox receivers to simulators should be aware that GPS time is
referenced to 6th January 1980, GLONASS to 1st January 1996, Galileo to 22nd August 1999
and BeiDou to 1st January 2006; the receiver cannot be expected to work reliably with signals
that appear to come from before these dates.
4.8.9.1 GPS-only date resolution
In circumstances where only GPS L1C/A signals are available and for receivers with earlier firmware
versions, the receiver establishes the date by assuming that all week numbers must be at least as
large as a reference rollover week number. This reference rollover week number is hard-coded into
the firmware at compile time and is normally set a few weeks before the s/w is completed, but it can
be overridden by CFG-NAVSPG-WKNROLLOVER configuration item to any value the user wishes.
The following example illustrates how this works: Assume that the reference rollover week number
set in the firmware at compile time is 1524 (which corresponds to a week in calendar year 2009,
but would be transmitted by the satellites as 500). In this case, if the receiver sees transmissions
containing week numbers in the range 500 ... 1023, these will be interpreted as week numbers
1524 ... 2047 (CY 2009 ... 2019), whereas transmissions with week numbers from 0 to 499 are
interpreted as week numbers 2048 ... 2547 (CY 2019 ... 2028).
It is important to set the reference rollover week number appropriately when supplying u-blox
receivers with simulated signals, especially when the scenarios are in the past.
4.9 Navigation configuration settings description
This section relates to the configuration group CFG-NAVSPG-*.
4.9.1 Platform settings
u-blox receivers support different dynamic platform models (see table below) to adjust the
navigation engine to the expected application environment. These platform settings can be
changed dynamically without performing a power cycle or reset. The settings improve the receiver's
interpretation of the measurements and thus provide a more accurate position output. Setting the
receiver to an unsuitable platform model for the given application environment is likely to result in
a loss of receiver performance and position accuracy.
CFG-NAVSPG-DYNMODEL is the configuration item used to select the dynamic model.
Platform Description
Portable Applications with low acceleration, e.g. portable devices. Suitable for most situations.
Stationary Used in timing applications (antenna must be stationary) or other stationary applications.
Velocity restricted to 0 m/s. Zero dynamics assumed.
Pedestrian Applications with low acceleration and speed, e.g. how a pedestrian would move. Low
acceleration assumed.
Automotive Used for applications with equivalent dynamics to those of a passenger car. Low vertical
acceleration assumed.
At sea Recommended for applications at sea, with zero vertical velocity. Zero vertical velocity
assumed. Sea level assumed.
Airborne <1g Used for applications with a higher dynamic range and greater vertical acceleration than a
passenger car. No 2D position fixes supported.
Airborne <2g Recommended for typical airborne environments. No 2D position fixes supported.
Airborne <4g Only recommended for extremely dynamic environments. No 2D position fixes supported.
To Next Page
Loading...
Need help?
General
