Wanted adaptable chip: performance requirements converge

GPS World,  July, 2007  by Jacqueline Bickerstaff,  Robert Frayling-Cork,  Tony Haddrell

• E-mail
• Print
• Link

As the consumer market develops, users become increasingly aware of leading-edge performance, and therefore unwilling to accept restricted performance envelopes for different devices. Different software fits for specific environments are becoming unacceptable. The user of a converged device, a smart phone, simply wants top performance anywhere, anytime, regardless--and right now. This may require a GPS engine able to adapt to its environment and mode of operation without operator input.

**********

A buzzword in the consumer electronics arena, convergence affects GPS receiver performance requirements as a consequence of the one-gadget-fits-all approach that will likely soon dominate the consumer sector. In the past, industry has provided GPS solutions for handheld navigators, automotive navigators, PDAs, mobile phones, cameras, and even music players. Whilst the platform makers wrestle with the compromises in their products (for instance, how small a screen will support sensible mapping display), the GPS fallout is being left to chip providers to address.

At the marketing end, a blurred product development approach quickly becomes apparent as we move along the convergence road. Mobile phones have camera, PDAs have automotive navigation software and sometimes phones, cameras have music players, and so on. We will call this new converged device a smart phone, for want of a better term, and understand this to mean a device with all of these applications--and often even more--built in.

Whilst all of our separate GPS solutions were perfectly fit for their respective purpose, the requirement for a single solution to operate in all of the expected user environments or applications does not present a trivial problem. We are up against the suitability of tried and tested algorithms (for urban canyon multipath, for instance) in other or new environments, such as indoors. Even testing new algorithms becomes a problem, as they must now work in multiple scenarios, not always synthesizable using laboratory simulators.

We can take another approach here: let the device (usually just the GPS, but any help from other applications is welcome) determine which of the signal environments and applications it is currently expected to support. Assuming we get this right, then we no longer have to use the same algorithms throughout, but can pick and choose the approach to best suit the user's expectations. Of course, this is easier to describe than implement, and the whole thing has a fine-tuning aspect required to provide the best service possible in any environment--even if the GPS cannot recognize it from the parameters it can measure.

However, in a modern consumer GPS solution, we can measure many things. User dynamics, for instance, and signal strength are readily available. Digging deeper, we can assess the multipath environment, the satellite visibility (all high, or all low, or mixed) and the power expectations for the host (is the smart phone in a cradle, for example). From all of this, we can take a shot at the user's current environment. Some environments are obscure and designed to throw us off. Our classic example is a train, which appears to the GPS to be an indoor environment, but is in fact capable of speeds greater than 100 miles per hour. So these we have to cope with as they arise, and must keep some flexibility in hand for that.

On top of these considerations come the connectivity issues. Assisted GPS has an ever increasing number of possibilities, including asking the phone network for data, or using stored ephemeris predicted from the past and downloaded at a previous time. Assistance in time, frequency, and starting location can be sometimes inferred from previous calibration, rather than asking a network server. So the GPS, or some intelligent middleware in the smart phone, has to determine what to use as the starting criteria, and know where to get it. Part of this is based on the type of fix the user or his location service is asking for (that is, a one shot push-to-fix, periodic, or continuous requirement), and also how much power he is prepared to use, and how much money he can spend (for a call to an assistance server, for instance). All of these issues add to the required flexibility of the GPS and provide us with even more variables.

In this article, we look at some example work underway to implement the let-the-device-determine-the-environment approach, and to provide some evidence of the performance gains we can see. This work is far from complete, but can be viewed as the next layer in the ever-improving performance of consumer GPS. After all, less than a decade has passed since we even thought about getting a fix indoors. But consumers will not be interested in how it works, or how near the edge the technology is--neither should they be--but only in the functionality and reliability that their do-it-all smart phone affords them.

Chip Development

The way an adaptable GPS may address this convergence requirement can be illustrated by looking at the issues raised during the development of a high-sensitivity GPS chip at our company.