B: Applications

October 20, 2007

Public Private Perplexity

High up in one corner of a trophy hall in the castle of the Bavarian royal dynasty in Berchtesgaden, Germany, hangs a poignant scene of inextricable conflict and death: the heads of two mighty stags, their antlers locked in combat.

Our tour guide translated the story behind this tableau. On October 14, 1735, a hunting party from the castle discovered the pair of struggling animals. Unable to separate the entangled antlers and with one deer’s neck already broken, the hunters had to shoot the other stag.

High up in one corner of a trophy hall in the castle of the Bavarian royal dynasty in Berchtesgaden, Germany, hangs a poignant scene of inextricable conflict and death: the heads of two mighty stags, their antlers locked in combat.

Our tour guide translated the story behind this tableau. On October 14, 1735, a hunting party from the castle discovered the pair of struggling animals. Unable to separate the entangled antlers and with one deer’s neck already broken, the hunters had to shoot the other stag.

A quiet murmur fell over the tour group, a post-conference excursion of delegates from the Munich Satellite Navigation Conference, as we reflected on the brute intransigence of nature. Then a voice spoke up from the back of the crowd: “That’s what happens when you have a PPP.”

Public Private Partnership or PPP, the now-notorious solution to a temporary impasse in Europe’s Galileo program. How quickly shibboleth can turn into epithet.

The laughter that followed the delegate’s wry comparison of death throes and thwarted politics drew strength from the discussions we had heard in the three previous days.

Prolonged negotiations have broken down between public patrons of Galileo and the private consortium seeking to complete and operate the European GNSS. The two sides have not come to terms over several major elements of risk-sharing associated with the program. The consortium has failed to incorporate a Galileo Operating Company (GOC), which would manage the system infrastructure as a profit-seeking venture under the oversight of the European GNSS Supervisory Authority (GSA).

“The negotiations are far more difficult than anyone anticipated,” Matthias Ruete, director general of energy and transport for the European Commission (EC), told his Munich summit audience.

Added Pedro Pedreira, executive director of the GSA, an EC entity that took over public sector responsibilities for Galileo at the beginning of the year, “The consortium is not able to present its own [unified] terms, let alone negotiate those terms.”

For their part representatives of the private consortium, while complaining that engineering changes and an elusive business model derived from the Galileo infrastructure were complicating the situation, acknowledged the new stalemate and their own internal disunity.

As this issue of Inside GNSS went to press, the problem was on its way to the council of European transport ministers meeting on March 22.

In its nearly 14 years of evolution, Europe’s GNSS program has met many such obstacles and, ultimately, always found a way through or around them. But never, as Ruete commented to me, have the challenges needed to be dealt with at such a high level.

And perhaps never with such urgency in the context of a global surge in GNSS expansion and modernization. China’s proposed new Compass system, the U.S. GPS III initiative, and restoration of Russia’s GLONASS are all scheduled (perhaps wishfully) to take place before or about the same time as Galileo is now expected to reach full operational capability around 2010–12.

PPP, a solution in the political environment of 1999, has now created a larger problem than the one it solved. Consequently, the public sector has a large responsibility for ensuring that it brings sufficient resources to resolve the current situation.

For years many in Europe have started referring to PPP as meaning, “Public Pays Private,” referring to the practical necessity for public subsidy — overt or covert — of an infrastructure that will ultimately pay for itself in the tax revenues generated by user equipment, services, and applications and not solely from revenues derived directly from the system itself.

For their part, the individual companies comprising the consortium need to resist the temptation of short-term competitive maneuvers or opportunistic national interests and reach an accord with the GSA.

Otherwise, without a two-sided exercise of self-discipline, it won’t matter which of these entangled entities gets its neck broken and which gets shot.

gl**@********ss.com

 

By

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.

gl**@********ss.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.

gl**@********ss.com

 

By
[uam_ad id="183541"]
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
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
[uam_ad id="183541"]
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
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
IGM_e-news_subscribe