Position tracking, using the Global Navigation Satellite System (GNSS), including Global Positioning System (GPS) and/or Galileo, is driving many consumer electronics applications. GNSS is no longer limited to automotive applications, surveying equipment, marine guidance, or expensive handheld tracking systems, but is now finding its way into many new cost-sensitive applications, including cellular handsets and Personal Navigation Devices (PNDs). Driving down cost is still a key for widespread GNSS acceptance in consumer electronics, however,
For high-end devices with a more flexible price point, GNSS is usually implemented using a stand-alone, hardware- based module. While simplifying GNSS design-in, hardware-based modules provide fully evaluated positionfix data to the host processor; however, these modules introduce a relatively high cost item into the bill of materials (BOM). Since GNSS is intended as a value-added feature rather than the primary purpose in these types of consumer devices, it has not always been feasible to implement GNSS in a consumer electronics product without significantly impacting product cost, with the attendant risk that the product must be sold at a price that doesn't attract sufficient market interest.
The availability of software-based GNSS has dramatically dropped the cost of adding GNSS to a system. Effectively, the investment of the integrated circuits (ICs) traditionally used for a GNSS baseband microcontroller and memory is not needed in software-based GNSS, thereby providing savings as much as 80 percent compared to the cost of a stand-alone GNSS receiver. Consequently, it has become possible to bring GNSS functionality cost-effectively to a wide range of applications, including portable media players and handsets. Notably, these devices already have a color liquid-crystal display (LCD) available that can be leveraged to display position information, as well as sufficient processing resources for baseband processing without requiring the addition of any new processing resources or capabilities.
Developing a GNSS subsystem for consumer electronic devices can, however, appear daunting to developers with little or no expertise in Radio Frequency (RF) design. The difficulty is not so much in optimizing the RF performance of the receiver, since many available GNSS receivers feature a high level of integration, low BOM, and comprehensive support collateral with good results obtained by following the recommendations for the reference design. Rather, when implementing the GNSS baseband processing in pure software there are numerous architectural and detail decisions that have a huge impact (positive or negative) on sensitivity, performance, accuracy, and power consumption.
If software engineers understand certain key RF principles and how these can be optimized in a system, they become much better able to maximize signal integrity and positioning accuracy to build successful GNSS systems for the highly competitive consumer electronics market. It is possible to take advantage of the inherent flexibility of software architectures to achieve a higher level of system capability (e.g., improved positioning accuracy with fewer satellites) at a lower cost than hardware-based modules.
Baseband GNSS processing is far from trivial. For performance and cost reasons, the GNSS baseband has traditionally implemented a GNSS Correlator function in hardware, either using real correlator fingers or employing a digital-signal-processing (DSP) core to emulate the function of a massively parallel correlator . The drive to bring GNSS to consumer electronics devices such as handsets has changed the returnon- investment (ROI) equation for determining the most efficient method for implementing GNSS. Specifically, what matters is the incremental cost to introduce GNSS to an already existing architecture. For example, if GNSS is implemented using a hardware-based module costing $6, this adds $6 to the system BOM.Figure 1 shows a traditional standalone GPS module architecture, with RF radio and hardware-based baseband. Figure 2 shows how the same stand-alone GPS module is connected to an applications processor in a product such as a PND. In a softwarebased architecture, baseband processing is implemented on a host processor (Figure 3) in a way that resembles the software modems ubiquitous in modern personal computers (PCs).
Baseband processing of GNSS signals has not traditionally been implemented on a host processor in GNSSonly applications because the cost of processor cycles has been significantly more than the cost of the equivalent number of gates using an applicationspecific integrated circuit (ASIC) for the GNSS processing. In a handset, however, a powerful applications host processor is already a necessary part of the overall architecture since, in order to meet the recent increase in demand for multimedia services, this processor must have enough capacity to decode streaming music and video files. Furthermore, when these services are not in use, the application processor may be underutilized and sitting idle, making it available to perform other tasks.
Until recently, the processing capability of this applications host processor could not deliver the processing power to implement software-based GNSS. However, it is now possible to have this processor perform GNSS baseband processing, substantially reducing the incremental expense and barriers to entry of introducing GNSS into a wide range of consumer electronics devices. From a price perspective, software-based GNSS will add approximately $3 (or about one-half that of a hardware-based module) to the system BOM while extending full GNSS capabilities.
It is important to note that this is only the starting cost for a softwarebased GNSS subsystem and therefore its peak price. Software has a very different pricing model than hardware based on the widespread perception that there is no manufacturing cost to software once it has been developed. The market traditionally has viewed software as a means for selling hardware and, as a consequence, software is often bundled with hardware. As market pressures drive down GNSS radio cost and adoption into higher volume applications takes off, this price is anticipated to quickly reach $1. At this cost, GNSS becomes a function that can be implemented in almost any consumer electronics application. In time, it will also facilitate the convergence of diverse wireless technologies, including GNSS, Bluetooth, and wireless local area networks (WLANs), onto a single, software-defined radio (SDR) platform.
Since the cost savings behind software-based GNSS come from making use of otherwise unutilized processor cycles on an applications host processor that is already part of the architecture, this transfers some of the responsibility of optimizing RF processing to software developers, whereas this used to be the domain of RF designers. Note that optimization by software developers does not involve development and refinement of RF baseband processing algorithms; there are already several RF market leaders developing off-the-shelf GNSS baseband processing software. Rather, optimization is achieved by how well developers integrate software-based GNSS technology into existing designs. Primarily, optimization is focused on maintaining performance and accuracy under worst-case operating conditions, minimizing power consumption, and preserving architectural flexibility.
Continued on page 2
Page Title
One consideration that should be addressed is worst-case processing load. Since the economies of software- based processing are partially based upon unutilized host processor resources, software-based GNSS processing needs to be dynamically adjustable based upon available resources. In effect, GNSS processing must not adversely affect other system functions, such as multimedia processing. Certainly, if accuracy can be maintained during worst-case processing, then by default it can be maintained when more processing resources are available. For example, in a handset that supports video and audio playback, if video playback is the most processorintensive function in the handset, then any mode not using video, including audio-only playback, will have more than sufficient resources available for GNSS baseband processing.
In the case of video playback, which uses most of the host processor resources, GNSS baseband processing may need to scale back. However, given the visual nature of video, users will be watching the video rather than following their current position. Therefore, highly accurate positioning data is only required when the user pauses the video and switches to the positiontracking application.
Developers can take advantage of this by adjusting the accuracy of tracking during video playback. Since the user isn't using position data at that moment, developers have the option of loosening accuracy tolerances. For example, using various dead-reckoning techniques that require less information to estimate location, the system can maintain approximate position within a reasonable accuracy. When position data is again required, the GNSS subsystem can quickly recover high accuracy using the processing resources that have been released from video processing.
Note that the signal must be maintained with some accuracy at all times to avoid signal loss; otherwise re-acquisition will need to be done. Because of the time it could take to reacquire the signal, and the fact that initial position-acquisition requires substantially more computational resources than tracking and holding position, it is undesirable to ever completely lose position lock.
Rather than continuously maintaining high accuracy at a fixed rate that gives continuous navigation, the system can take a number of steps to reduce the overall baseband processing load:
- Limit the number of satellites being tracked. Since processing load is directly proportional to the number of satellites being tracked, this will reduce the number of cycles required to maintain position.
- Reduce how much of the signal the system processes. Processing only one out of every three samples, for example, reduces how much data must be processed while sufficiently maintaining position. This will impact system sensitivity, but this can be readily sacrificed if the system is already tracking strong signals.
- Reduce the position-fix rate. The standard position-fix rate is 1-position- fix/second. Not all applications need this rate, and there may be some applications where 1-positionfix every 10 seconds, for example, may be sufficient.
- Average and filter data. While averaging reduces accuracy, it also reduces the magnitude of errors. Depending upon the application, averaging can either be conservative or ambitious.
- Take advantage of idle cycles to regain accuracy. There are times when the baseband processing will not be heavily utilized. Rather than let these cycles go idle, the GNSS subsystem can dynamically claim these cycles to process more of the acquired signals in order to regain accuracy, which could otherwise degrade.
- Select a radio that delivers data in an in-phase (I)/quadrature (Q) format rather than as a raw signal. By performing the I/Q baseband conversion step in hardware, some processing is offloaded from the host processor. The primary disadvantage of this approach is that it creates twice as much data to download over the interface between the radio and processor, requiring a higher-speed interface than is supported by the processor.
- Employ dead reckoning and interpolation. By just running the clock, the system can estimate the probable location of a user based on last known position, direction, and velocity. Dead reckoning can be quite accurate over long periods of time. For example, cars on a freeway don't tend to suddenly turn around. Dead reckoning is one of the same techniques used to maintain position when satellite signals are lost, such as when a car passes through a tunnel. The difference is that the "poor" signal conditions are intentionally imposed rather than caused by environmental factors.
- Choose a higher-performance processor. If there are not enough underutilized cycles available, depending upon the application, it may actually be the case that upgrading the application processor to the next available speed may be less expensive than using a hardware baseband processor. Handset application processors, for example, tend to be high-volume, designed using the latest and most cost-effective process technology, thus lowering their cost. Baseband processors, given their relatively lower volumes, tend to have a longer optimization cycle. As a result, it could cost less and consume less power to use a software baseband running on the smaller geometry of a host processor than a hardware-based baseband processor.
- Mask latency. In those cases where it takes time to restore enough accuracy, it is important to mask the latency from users. Highly visible latency, such as taking too long to first acquire a signal, can have an extreme negative impact on user perception. For example, when determining the quality of GNSS-enabled devices, many users will focus on a single characteristic, such as initial position-acquisition, to evaluate overall GNSS quality. If it takes too long to first acquire a position, many users will not bother to compare how accurate overall accuracy is. Thus, it is important to acquire first position as quickly as possible while masking what the system is doing. For example, requiring the user to pause video, go back to a menu, and then select the GNSS position-mapping screen provides a few extra moments for the GNSS subsystem to restore accuracy and reduce perceived waiting time.
Many of the above techniques that reduce processing load can also be used to balance power consumption and sensitivity. Even though the system may have ample processing resources underutilized and available, developers may want to implement worst-case operating condition techniques in any event to limit power consumption.
Implementing baseband processing in software also enables more flexible power management than hardwarebased approaches, since different parts of the system can be individually controlled. Additionally, as new innovative algorithms and power-saving techniques are developed, they can be implemented in existing designs without a costly silicon redesign. Other power-saving techniques include:
- System-level awareness. The GNSS subsystem should have access to system- level states so it can act on them accordingly. If the PND determines that the user is not actively viewing the screen, when it turns off the display backlight it could also notify the GNSS subsystem to reduce position- processing load as well. When the user returns to use the device, the position can be refreshed.
- Maintain the GNSS clock. When powering down the GNSS receiver system or putting it into a standby (sleep) mode, power-down the radio section but maintain the GNSS clock. This technique actually requires more power since the clock consumes current, but it enables faster signal acquisition when the system wakes up since it won't have to reacquire the time. This technique can be tied directly to any powersaving functions already implemented in the device.
- Save enough information about the last known position. Any time the device has an idea of its approximate location, time, or references, signal acquisition is accelerated since the system knows the approximate answer.
- Save satellite orbital data. The GNSS receiver needs to know the orbital parameters (almanac and ephemeris) for all the satellites it is tracking while navigating. By storing the orbital data, there will be situations where the receiver is off for only a brief time, and the same satellites as used previously are still available. In this instance, the receiver can hot-start, reducing the time required for a first-fix from potentially more than 30 s to less than 3 s.
- Program the radio to output less data. When trying to maintain accuracy under worst-case operating conditions, it can be advantageous to send the complete GNSS signal to the host processor so it can use it if there are suddenly resources available or discard samples if there are not. However, this approach drives the radio/processor interface at full rate. By reducing the signal rate from the radio, the processor loses the ability to process more samples if more resources are available, but rather saves power instead.
- Employ intelligent dead reckoning. Use dead reckoning and other techniques that reduce processing load at the expense of accuracy when position is more easily estimated, such as when driving on a freeway with no exits within a half-mile. By effectively interleaving positioning calculations with dead-reckoning techniques or lowering the signal rate, signal processing load can be reduced while maintaining sufficient accuracy. The flexibility of a software- based approach makes implementing a power-saving feature like this simple and feasible.
Continued on page 3
Page Title
While the GNSS radio requirements are similar across different applications, baseband processing does vary, given the differing performance and sensitivity requirements in each case. Software-based baseband processing provides developers with the flexibility to adjust processing to meet the cost, power, and performance needs of each specific application. For example, one common benchmark is the maximum number of channels a GNSS receiver can support. With a hardware baseband, this decision must be determined before releasing the silicon production tooling needed to manufacture integrated circuits. With a software baseband, this number can be adjusted dynamically to match a particular application or set of operating conditions.
Software-based GNSS also offers the advantage of enabling developers to quickly make use of continuing innovation in GNSS algorithm development. For example, algorithms may be developed to compensate for particular signal or environmental conditions. As these algorithms become available, they can be introduced into the library of processing algorithms that a software-based GNSS device has, potentially improving its accuracy, tracking-sensitivity, and so on.
Working with software also simplifies GNSS deployment across multiple product lines. For example, different handset models impose different worst-case operating constraints. While it would be difficult to optimize a hardware module across a diverse range of handsets, software gives developers the flexibility to configure processing in a straightforward fashion. Thus, OEMs can design a single radio platform rather than a distinct radio for each product line.
Some host processors are limited in the GNSS data bandwidth they can handle. For example, some processors only have enough input/output (I/O) ports to allow a single GNSS signal input (e.g., 1-b SIGN), along with a clock-out signal at 5.456 MHz. To achieve this data rate, two out of three samples are typically discarded (or decimated) before being sent over the interface. Developers have the option of introducing glue logic' between the radio and processor that discards the appropriate samples, specifying a radio that can be configured to discard the samples, utilizing a faster interface, or utilizing multiple interfaces. Degrading the signal does degrade both acquisition and trackingsensitivity. However, software can be adjusted in some situations to compensate for lower sensitivity levels.
Because of its flexible nature, it is possible for software-based GNSS to achieve higher accuracy than hardware- based implementations. Figure 4 shows a plot of navigation points using Microsoft Autoroute from a navigation trial conducted around the Canary Wharf district in London, England. The green points show location as tracked by a hardware-based receiver with external active antenna while the red points come from a software- based receiver (the SE4110LEK3 running CSR-NordNav E5000 SW GNSS on a laptop with an external active antenna).
The table shows the top-level differences for the Canary Wharf road trial. What is interesting to note is that while the hardware-based receiver tracked more satellites on average (6.9 versus 5.1), the Horizontal Dilution of Precision (HDOPa number that shows worse positional accuracy the larger the number is) is actually better for the software-based GNSS receiver. This is in large part due to the higher average SNR of the software-based GNSS receiver, as the 3 dB difference in sensitivity between the units results in the ability to track fewer satellites while achieving more reliable navigation.
Another important factor to consider when evaluating and developing a software-based GNSS subsystem is the flexibility of the software and radio to support the Galileo system, which is expected to become operational later in the decade. Galileo is a network of satellites being developed in Europe designed not to compete with GPS, but rather coordinated to work with it. Galileo satellites will transmit signals in a number of bands, and as the L1 band uses the same frequency as GPS and will be spaced between GPS satellites with complementary orbits, this will increase the number of signals that can be acquired from any particular location. Galileo will also provide greater position accuracy than GPS (4 m compared to 10 m for commercial applications) and will not be controlled by a single government agency that can black out services or change satellite accuracy without warning. Systems able to track both Galileo and GPS satellites will be able to achieve a significant improvement in accuracy in the urban canyons of major cities, enabling PNDs to determine which side of the street pedestrians are on, thus increasing the PNDs' usefulness, reliability, and desirability.
While the same radio can be used to acquire both Galileo and GPS signals, substantially different baseband processing is required. This will require significant extensions to the baseband hardware. Devices that wish to support Galileo before it is activated will need to absorb the cost of the additional hardware without gaining any immediate functional benefit.
Using a software approach, both the GPS and Galileo basebands can be implemented in software. This means that the Galileo baseband can be implemented as a software upgrade, enabling existing devices in the field to acquire Galileo signals without increasing device cost in the meantime. Even if OEMs do not plan on upgrading devices already deployed, designing architectures capable of supporting both systems avoids costly time-to-market delays and lost opportunity when Galileo becomes available.
GNSS promises to become an important differentiating feature among many consumer electronics applications. By implementing GNSS baseband processing in software, developers can leverage existing processing resources. While this transfers some burden of optimizing the RF system onto the software team, developers can arm themselves by becoming aware of the impact of certain architectural decisions on baseband processing performance. In this way, software developers can maintain positioning service under even worst-case operating conditions, with optimum performance.