System-on-Chip GNSS Solution

Global Navigation Satellite System (GNSS) is the general term for satellite tracking systems and covers GPS, Galileo, GLONASS, QZSS and Compass constellations. Systems for urban canyon applications need to incorporate a range of functions including GNSS tracking, inertial measurement, telemetry, and telematics processing. Given the volumes emerging telematics solutions are manufactured in, these functions often have to be spread across a number of discreet chipsets. With the advent of new low power, single-die, System-on-Chip GNSS solutions and MEMS inertial sensors, these functions can now be consolidated into one chipset, reducing the power-consumption, complexity, and cost of the overall system. The Urban Canyon Problem GNSS signals are primarily "Line of Sight" and work by "Time of Arrival" (ToA) ranging methods that measure and calculate the position and velocity of a receiver based on the signal path delay from the GNSS satellites. As a result, the accuracy and stability of the solution can be severely affected in urban canyon environments where the signals are degraded by multipath or obscured by tall structures. Even with the use of highly sensitive receivers and alternative startup measures (such as providing ephemeris assistance data), the positional accuracy can be still be degraded to the point of not being useful for certain functions like navigation, emergency-call, road-tolling, congestion-surcharge monitors, or pay-as-you go insurance modules. False positions in these scenarios will result in lost-drivers, incorrect charges and possible loss of life in emergency call situations. Dead Reckoning Solutions In many of these applications, the only current solution is a Dead-Reckoning (DR) system that uses the GNSS data coupled with the vehicle's speed sensors to provide additional accuracy when needed. This approach, while expensive to develop, works well for large volume telematics providers (such as OnStar), but is inadequate when the unit needs to be installed as an after-market device due to problematic access to the vehicle data bus. Some units get around the vehicle bus problem by using a CAN -based On-Board-Diagnostic interface (OBD-II or EOBD in the case or Europe) for speed information and then an on-board gyro to provide for heading data. This solution, while easier to develop and integrate, results in high production costs due to the need to integrate a GNSS module, inertial sensors (gyros and accelerometers), a general purpose microprocessor, a vehicle interface, and a network communications module (usually a cellular modem module). To be cost-effective in the emerging telematics markets, a method to provide more accuracy and lower-cost is required. A Multi-Constellation GNSS Receiver In urban-canyon environments, accuracy and availability are directly related to the number of satellites the receiver can find and track, and since there are a fixed number of satellites in a given GNSS constellation, there is a fixed limit to the accuracy and availability that can be achieved in any particular environment. To achieve better accuracy and availability beyond this point requires the use of dead-reckoning (using the vehicle sensors to augment the GNSS solution) or adding more satellites to the tracking solution. ST's new Teseo-II line of multi-constellation, System-on-Chip (SoC), single-die with integrated RF, GNSS receivers support additional accuracy and availability by tracking GPS, GLONASS, and Galileo satellites at the same time, with the net result of nearly doubling the number of available satellites in most signal environments. In the future, there will be the prospect of tripling the number of available satellites when the Galileo and QZSS GNSS systems become active in the 2016 to 2018 time-frame. Additionally, dead-reckoning algorithms can be integrated alongside the GNSS receiver functions to provide for additional accuracy where needed. In urban-canyon testing over a 24-hour period, the Teseo-II's GPS + GLONASS tracking engine achieved 2.5 times better accuracy and 3.8 times more availability than a GPS-only solution. In this 24-hour test run there were 380-minutes of outage (no position fix) when using a GPS-only solution, while Teseo-II's GPS + GLONASS solution had no loss of position (see Table 1 below). In some application areas, the additional accuracy and availability of the Teseo-II's GPS + GLONASS solution may also make it possible to completely replace a current GPS + Dead-Reckoning solution resulting in reduced complexity and system costs.

A System-on-Chip Approach to Low-Cost Telematics While there are volume, certification, and regulatory road-blocks to "super-integrating" the cellular modem module into mid to low-volume telematics architectures, ST's Teseo-II telematics processors and MEMS sensor solutions allow for integration of the GNSS receiver, the dead-reckoning sub-system, the inertial measurement sub-system and the network communications protocol stacks into a 2-chip solution that significantly reduces production costs (see Figure 1 - A Teseo-II based Telematics Solution). Figure 1 details a simplified, low-cost "Pay As You Go" Insurance module that incorporates the Teseo-II STA8088SAL GNSS System-on-Chip, a LSM320DL inertial sensor module, a cellular modem module, and a CAN interface (the Teseo-II architecture includes up to two 2.0B Active CAN controllers built in). The "Stand-Alone" version of the Teseo-II includes a 4M-Byte System Flash for program use, 256K of Static RAM, two UART ports, an I2C and SPI port, a USB 2.0 Full-Speed interface, and a 3-channel 10-bit analog to digital converter. While not all of the System Flash or SRAM is available for user applications, there is plenty of space to host simplified communications stacks to communicate (via cellular modem) road usage data. In this application, the Teseo-II architecture achieves the best overall low-cost solution. For more complex telematics solutions, there is also a "System-on-Chip" variant (the STA8088EX) that includes, in addition to the above, an external memory interface, two SD/MMC memory card interfaces, an extended function timer, and an audio codec interface.

Software Architectures and APIs The standard GNSS tracking software library implemented within the Teseo-II SoC is the GNSS-API-Library. It allows for integration of custom application code and driver sets to fully implement a telematics system. In addition to the GNSS-Library, there are also libraries available for dead-reckoning, SD-MMC Card file I/O, graphics-libraries and various low-level device-driver libraries for audio, UART and CAN interfaces (see Figure 2 -Application Software API Diagram). The communication libraries used will depend on the modem module in use and the server component/system it communicates with. Some possible implementations include TCP/IP and HTTP protocol stacks to communication with corporate databases and web-engines for transferring of customer data, or Short-Message-Service (SMS) data transfers of user data to database servers. The file-storage library also comes in handy when embedding map content which may be required for certain applications such as road-tolling, congestion-tax usage, or Advanced Driver Assistance Data (ADAS) applications for in-vehicle road-content information such as NAVTEQ's "Map and Positioning Engine". Conclusion Urban canyon telematics applications can greatly benefit from the reduced cost and complexity, and improved performance of the new multi-constellation GNSS SoC solutions now available. www.st.com