B: Applications Archives - Page 147 of 151 - Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design

B: Applications

GNSS Marketplace

I like the marketplace.

I really do.

I love the energy, the innovation, the diversity, the pricing mechanism of demand curves, the buyer-seller feedback loops, the promotional hoopla, the whole deal.

I like the marketplace.

I really do.

I love the energy, the innovation, the diversity, the pricing mechanism of demand curves, the buyer-seller feedback loops, the promotional hoopla, the whole deal.

In the rather remote town where I live, we have a Saturday Market that’s more than 30 years old. Every week a bunch of home-grown entrepreneurs set up their booths with pottery, tie-dyed shirts, fresh blueberries, metal sculptures, Guatemalan tamales, jewelry, everything imaginable. There’s colorful banners waving and musicians playing and aging hippies dancing.

And — just to let you know how far we are outside not merely the D.C. Beltway but outside the whole North American Free Trade Agreement zone — all the products sold in the market must be grown or made by the people selling them.

Of course, the market can’t do everything.

It apparently can’t produce enough bird flu vaccine to protect a nation or distribute enough food in the right place to prevent hunger in the midst of plenty. And one thing many people wouldn’t have expected the market to do was produce a multitude of global navigation satellite systems.

But it has, with GPS, GLONASS, Galileo, and perhaps even Beidou waiting in the wings.

And thank goodness for the marketplace, because it’s apparently going to take not merely a village, but a world to raise up a new generation of robust, modernized GNSS.

Fortunately, we have redundant programs, not merely redundant satellites. If one GNSS is delayed or changes its plan, another one is there to keep the parade moving forward. So, when Galileo sets itself hurdles, such as agreeing on not merely a concession contract but a business model as well, there’s GPS with its simple taxpayer-driven approach to keep things moving. And when GPS loses its way amid the engineering changes and chain-of-command silos of the military-industrial complex, there’s GLONASS speeding up its schedule in a race to the future.

Hopefully, by the time GLONASS encounters its next economic or technical or political challenge, Galileo and GPS will be back on track.

Yes, we definitely are in another “two-steps-forward-one-step-back” phase of GNSS development.

In an industrious and cooperative surge of activity, we have seen three sets of draft specifications reach fruition in the last few weeks: publication of a joint recommendation for design of new civil signals on GPS and Galileo, the Galileo Interface Control Document, and the GPS L1C interface specification.

Although further discussion and revisions are inevitable, these anxiously awaited items will provide guidance to GNSS product designers and encouragement to users.

Meanwhile, however, we once again have to wonder: what’s going on — or, more to the point, not going on — with the GPS program? In a short span of time, we’ve seen new delays in the first launch of a GPS Block IIF satellite (originally planned for 2005), a possible yearlong delay in GPS III, and a missed deadline for awarding an important contract on modernized user equipment for the Department of Defense (DoD) community.

Those developments underscore the need for implementing a recommendation in the Defense Science Board Task Force on GPS report: coordinate DoD responsibilities for GPS by designating a single focal point within the Office of the Secretary of Defense.

Currently, as with many other defense programs, the GPS program has three separate decision-making channels for acquisition, budget, and command. What in a well-managed organization might serve as supporting columns for a common endeavor have turned into self-contained silos sheltering processes, personnel, and purposes that become laws unto themselves. These parallel, non-convergent functions are producing asynchronous, discontinuous results.

Deputy Secretary of Defense Donald England has reportedly kicked the Positioning, Navigation, and Timing (PNT) Executive Committee meeting schedule into high gear; perhaps he’s the man to do the same for the PNT program itself.

glen@insidegnss.com

 

By

Bring Out the Galileo ICD

Here’s an idea whose time may have finally arrived: release of an Interface Control Document (ICD) for the Galileo open service (OS) — in essence, a set of specifications to which engineers can design and manufacturers can build receivers.

Here’s an idea whose time may have finally arrived: release of an Interface Control Document (ICD) for the Galileo open service (OS) — in essence, a set of specifications to which engineers can design and manufacturers can build receivers.

European sources suggest that publication of the ICD could take place around April 20 and would fill in some key missing details. This development follows on the heels of a late-March decision by a bilateral U.S./European technical working group that the future GPS civil signal (L1C) and the Galileo OS will use an optimized version of the BOC (1,1) format tentatively accepted under the 2004 agreement on GPS/Galileo cooperation.

If realized in action, this would be doubly welcome news for manufacturers, design engineers, and system developers eager to exploit the promise of expanded, modernized GNSS signals. It would also help sustain the surge of interest in Galileo that has taken place since launch of the program’s first experimental spacecraft last December.

Over the last couple of years, a series of papers coauthored by members of the European Commission (EC) Galileo Signal Task Force have laid out elements of the frequency plan and signal structure: RF bands, lengths and types of codes, data rates, and so forth. What had remained missing were the Galileo codes and the navigation message structure.

Some manufacturers have tried to overcome this problem by designing GNSS receivers with reconfigurable chips, using field programmable gate arrays (FPGAs) that could be updated when the final spec became available. But such work-arounds are inherently messy, complicating sales and marketing efforts and building in a need for early upgrades and extra customer support.

Moreover, the absence of technical guidelines and standards inhibits engineering managers and companies in adapting new technologies, particularly those in sectors such as aviation and automotive engineering with lengthy design and certification cycles.

Galileo, of course, is a work in progress, and most people in the GNSS community understand that technical details will change as the project evolves. That was the situation with the Global Positioning System, in which smudged and much-photocopied documents circulated in the engineering community and helped with the design of GPS products that appeared long before the final official ICD in the early 1990s. What made the ad hoc process work and kept this GPS “living document” alive was the willingness of the GPS Joint Program Office and its contractors to communicate openly with the manufacturing community.

However, it was becoming unclear as to who was really in charge of the Galileo ICD process: the European Space Agency (ESA), the EC through its signal task force, the Galileo Joint Undertaking (GJU) negotiating the concession contract, the Galileo Supervisory Authority that will oversee the program, or even the concessionaire who would understandably want to claim every possible piece of Galileo-related intellectual property. And, finally, GARMIS, a consortium of 30 companies led by France Developpement Conseil holds a €4 million GJU contract to provide “engineering support for optimizing the Galileo documentation,” including the Galileo ICD.

In addition to this divided responsibility for the ICD, a divergence was occurring, not only between European and non-European companies, but even among European companies. That created the peculiar situation of one manufacturer announcing a GPS/Galileo-capable receiver with the caveat that the Galileo functionality was available only to customers authorized by ESA. Or a well-positioned European company offering a GNSS signal generator with Galileo functionality that the vendor claimed would always be a step ahead due to the company’s involvement in writing the Galileo ICD.

So, the prospect of an initial Galileo ICD appearing in the near future will dispel doubts, sustain enthusiasm for the project, and provide a crucial resource for the real work of engineering a better GNSS future.

glen@insidegnss.com

 

By
October 18, 2007

STM Launches 32-Channel GPS Processor

STMicroelectronics has introduced Cartesio, its new automotive-grade application processor with embedded GPS for navigation and telematics. The processor couples with ST’s GPS RF chip (STA5620) to provide a core receiver unit.

Cartesio (STA2062) integrates a 32-bit ARM CPU core with a high-sensitivity 32-channel GPS subsystem and a large set of connectivity peripherals, including CAN, USB, UARTs, and SPI. It also provides on-chip high-speed RAM and real-time clock functionality, according to the company.

Read More >

By Glen Gibbons
[uam_ad id="183541"]
October 17, 2007

Spirent GNSS Simulator User Conference

Spirent engineers and other GNSS professionals present papers on new developments in GNSS. Customers will present real-life case studies and Spirent Positioning Technology Business Unit engineers will discuss them, analyze problems, offer technical product demonstrations, and show new products. Participants include end-users of Spirent simulators from avionics, automotive, military, space and academia.

The conference hotel is Hotel Catalonia Ramblas.

Read More >

By Inside GNSS
October 14, 2007

Precise Point Positioning and Its Challenges, Aided-GNSS and Signal Tracking

Q: What is precise point positioning (PPP), and what are its requirements, advantages and challenges?

A: Precise point positioning (PPP) is a method that performs precise position determination using a single GPS receiver.

This positioning approach arose from the advent of widely available precise GPS orbit and clock data products with centimeter accuracy. These data can be applied to substantially reduce the errors in GPS satellite orbits and clocks, two of the most significant error sources in GPS positioning.

Q: What is precise point positioning (PPP), and what are its requirements, advantages and challenges?

A: Precise point positioning (PPP) is a method that performs precise position determination using a single GPS receiver.

This positioning approach arose from the advent of widely available precise GPS orbit and clock data products with centimeter accuracy. These data can be applied to substantially reduce the errors in GPS satellite orbits and clocks, two of the most significant error sources in GPS positioning.

Combining precise satellite positions and clocks with a dual-frequency GPS receiver (to remove the first order effect of the ionosphere), PPP is able to provide position solutions at centimeter to decimeter level, which is appealing to many applications such as airborne mapping. PPP is different from double-difference RTK (real-time kinematic) positioning that requires access to observations from one or more base stations with known coordinates. The word “precise” is also used to distinguish it from the conventional point positioning techniques that use only code or phase-smoothed code as the principal observable for position determination.

(For the rest of Yang Gao’s answer to this question, please download the complete article using the PDF link above.)

Q: Does Aided-GNSS improve signal acquisition, tracking, or both?

A: A-GPS (Aided/Assisted-GPS) and more recently its extensions, A-GNSS, have been introduced to substitute for missing satellite broadcast data when access is intermittent, difficult, or impossible due to signal obstruction. It has expanded the capabilities of the traditional receiver in reducing the time to first fix (TTFF), enabling “high sensitivity” modes, improving the performance in urban canyons and indoors, and incidentally, boosting the receiver’s efficient use of power.

Multiple ways have been developed to deploy an A-GPS server, and to distribute the process flow between the server and the mobile. The mobile station–based method places the position determination in the receiver, while the network-based method relegates it back to the server.

Other notable factors influence the architecture. The assistance can be one-way, where information accessible at the server flows down to the receiver, or in closed loop, where the information is uploaded to the server, processed remotely applying far larger computational resources and extra knowledge not available to the receiver, and then pushed back to the receiver in its final form.

We will now introduce two simple rules that will illustrate the rest of the explanations:

Rule 1: For A-GPS to be practical, the assistance information should not be stale when ready to be used at the mobile. In more technical terms, the assistance information persistence needs to be longer than the sum of network latency plus server and mobile processing times,

Rule 2: In a closed loop architecture, the information collected at the mobile, and processed at the server should be returned fast enough before the internal state of the mobile changes too much. We can reformulate it as the sum of the round trip network delay plus server and mobile processing times have to be shorter than the process time constant to control the mobile.

(For the rest of Lionel J. Garin’s answer to this question, please download the complete article using the PDF link above.)

By

A New Version of the RTCM SC-106 Standard, the Probability of Solving Integer Ambiguities

Q: The RTCM has announced a new version of its widely used differential GPS (DGPS) standard. Why did the group decide a new standard — Version 3 — was needed, and what are the benefits compared to Version 2?

Q: The RTCM has announced a new version of its widely used differential GPS (DGPS) standard. Why did the group decide a new standard — Version 3 — was needed, and what are the benefits compared to Version 2?

A: Initially, the RTCM (Radio Technical Commission for Maritime Services) Subcommittee (SC104) Version 2 standard was developed with marine DGPS as the target application. One of the design goals for the RTCM SC 104 standard was to have correctional information readily available for user equipment. The outlines of the messages were specifically tailored for low bit rate data links.

Not until the beginning of the 1990s did RTK (real-time kinematic) surveying applications come into focus for RTCM. The committee drafted new RTK messages based on the proven DGPS messages. Although the DGPS messages only contain corrections, the RTK messages also allow transmission of raw observables from the satellite signals. RTCM tentatively published redundant means of disseminating precise RTK information with the aim of gaining practical experience during their implementation.

The first implementations by different manufacturers had diverse interoperability issues. For instance, various manufacturers have different sign conventions for representing the carrier phase observations, which resulted in incompatibilities when mixing receivers of different manufacturers.

(For the rest of Dr. Hans-Jürgen Euler’s answer to this question, please download the complete article using the PDF link above.)

Q: What is the probability of correctly resolving integer ambiguities and how can it be evaluated?

A: Resolving, or “fixing”, carrier phase ambiguities to integer values is ultimately based on statistical assumptions and testing. As such, a probability is associated with resolving any particular ambiguity correctly. Evaluating the probability of correct fix (PCF), that is, the probability that the ambiguities are fixed to the correct integer values, is particularly important for safety-critical applications where an incorrect ambiguity fix would produce hazardously misleading information (HMI).

In fixed-ambiguity carrier phase processing, the usual procedure is to begin by estimating the carrier phase ambiguities as real-valued (“float”) parameters and then to determine their integer values. A difficulty with this method is that, although the least-squares adjustment or Kalman filter used to estimate the real-valued ambiguities provides an estimate of their quality (a covariance matrix), it is not obvious how to obtain an estimate of the quality of the integer ambiguities.

In most carrier phase ambiguity estimation methods, integer quality is validated using some sort of statistical test. These generally involve testing the least-squares sum-squared residuals of the best fitting integer solution against the second best fitting solution. The test statistic is then compared against a threshold value, the idea being that if the best solution is sufficiently better than the second-best solution, then it must be correct.

(For the rest of Kyle O’Keefe and Mark Petovello’s answer to this question, please download the complete article using the PDF link above.)

By
October 9, 2007

Xsens Integrated GPS-IMU Unit

Xsens Technologies has launched a GPS-enhanced IMU, the MTi-G. The device incorporates an integrated 16-channel GPS and MEMS inertial measurement unit with an internal ultra low-power attitude and heading reference system (AHRS) processor running a real-time Kalman filter, the unit provides accurate positioning (2.5 meters CEP, autonomous), velocity, acceleration, and orientation estimates, with a high update rate (4 Hz GPS, 512 Hz inertial).

Read More >

By Glen Gibbons
[uam_ad id="183541"]
October 6, 2007

Cornering the Market on Navigable Maps? Nokia/NAVTEQ, TomTom/Tele Atlas Deals

The stunning sequence of multi-billion-dollar buyout offers for the two leading navigable map data providers TeleAtlas and NAVTEQ — by TomTom and Nokia, respectively — raises issues not only of access to critical intellectual property (IP) and a long-delayed explosion of location-based services (LBS) but may also determine the outcome of the long-debated platform of choice for GNSS-enriched consumer applications.

Read More >

By Glen Gibbons
September 19, 2007

NavCom Tech L1 GPS RTK Receiver

NavCom Technology offers its new SF-2110M and SF-2110R modular L1 StarFire GPS receivers. The SF-2110M has an integrated, compact dual-band antenna capable of receiving GPS and StarFire signals from NavCom’s global satellite-based augmentation system. The SF-2110R includes a separate L-Band antenna for enhanced StarFire signal reception in challenging environments and at high latitudes, according to the company. NavCom Technology Inc., Torrance, California USA.

Read More >

By Glen Gibbons
IGM_e-news_subscribe