Typically, GNSS (Global Navigation Satellite System) is used to localize an object, e.g. a car or other mobile device. STMicroelectronics (ST) is a leading manufacturer of complex GNSS receiver chips. Recently ST has introduced a tiny multi-chip module called Teseo-LIV3F, based on their 5th generation of GNSS receiver ICs in combination with some additional frontend components – offered in a standard LCC-18 package (size: 9.7 mm x 10.1 mm). With this kind of product ST is entering the marketplace for off-the-shelf GNSS receiver modules. So, let’s explore this product segment from application point of view and compare some candidates.
How GNSS works
As a starting point this video is useful for a basic understanding how GNSS works. In fact, with GNSS you can determine the actual geographic position of an object (i.e. longitude and latitude plus altitude) if it is equipped with a GNSS receiver and you are connected to it somehow (e.g. via wireless network). In addition, GNSS delivers exact time accurate to nanoseconds because GNSS satellites are equipped with atomic clocks by default. See Figure 1:
Figure 1: GNSS deliverables (© chip-info.com)
GNSS satellites are continuously broadcasting navigation messages including their identity and actual position. In addition, a GNSS receiver can determine the distance (range) to a satellite because of a common timebase. This means that transmission delay of the navigation message can be measured by the receiver. Measured delay corresponds to distance by multiplication with speed of light. Consequently, as soon as you have got three known positions and distance to each of them you can calculate the position of the the GNSS receiver. Figure 2 illustrates principle of trilateration which is used the the GNSS receiver to determine its position.
Figure 2: Trilateration principle (© chip-info.com)
Please note that in real life things are three-dimensional, i.e. intersecting circles become intersecting spheres. In theory, three satellites would be sufficient to localize the GNSS receiver. But in real life internal clocks of involved parties – used for distance calculation to the actual SV – will be slightly out-of-sync. Therefor a forth satellite is required to compensate measurement error. As soon as all clocks are perfectly synchronized, described localisation principle will work fine with only three satellites – at least for a while…
Required hardware does not cost a fortune and – thanks to off-the-shelf GNSS receiver modules reviewed here – you do not need to be an (RF-) expert to incorporate a decent GNSS service into your application. Unless you have special requirements, GNSS receiver modules allow fastest design-in because they work as independent sub-systems with own OS/firmware and API for host communication/control. In general, GNSS is aiming at…
- Vehicle navigation assistance or telematics to
- reduce transportation delays and operating costs, avoid accidents
- improve safety, track capacity and customer service (e.g. “e-call”).
- Remote control of mobile objects (e.g. machines used for agriculture, construction, industrial automation)
- increase efficiency and accuracy of movement
- Security/Surveillance: theft detection, asset tracking incl. “geo-fencing”
- Timing: deployment of a common timebase for a remote application with devices requiring precise and/or synchronized timestamps, e.g. for communication or financial networks
GNSS receiver design basics
In practice, a GNSS receiver is searching for navigation messages transmitted by satellite vehicle (SVs) at specified carrier frequencies (e.g. primary L1 frequency at 1575,42 Mhz for GPS). First the receiver tries to find a valid C/A code (course/acquisition) which is actually a binary string of 1023 bits – modulated to the carrier wave – which is unique to each SV. These patterns are called pseudo random noise (PRN), and they are carefully constructed in a way that they match in only one position if a replicated pattern is shifted against the original pattern received at GNSS antenna. This method is used to identify the SV and determine its usability as a localization channel. Then, the GNSS receiver can start extracting the navigation message of this SV.
Figure 3 outlines top-level building blocks of a GNSS receiver:
Figure 3: Generic GNSS receiver (© chip-info.com)
In short, signal received from antenna at RF frequency is cleaned by a bandpass pre-filter, then passed to a low-noise amplifier (LNA). Then, acquired signal is down-converted to intermediate frequencies (IF) by mixing frequencies provided by local oscillators (LO). PRNs and SV messages contents are preserved after the mixing process, only carrier frequency is lower (in MHz range instead of GHz).
After down-conversion the signal is digitized by an Analog-to-Digital-Converter (ADC). Then, the digital signal is reproduced into several identical copies which are fed into signal processing chains that will extract the navigation message and its propagation delay on its way from the transmitting SV. Current implementations of GNSS receiver ICs integrate up to 100 of such chains, aka channels, which are running independently in parallel. Once a certain satellite signature is found in a channel, the demodulator of that channel will decode the SV’s navigation message. The channel is then said to be locked onto that SV, each channel will try to lock on a different SV.
The localization engine will calculate the actual position of a GNSS receiver at any time – based on known positions of at least four SVs (extracted from their navigation messages) in cooperation with a synchronized timebase (RTC).
Key information for localization is so-called ephemeris data containing the orbital position of a tracked SV. Each satellite broadcasts its ephemeris data every 30 seconds, and is valid for up to four hours. In addition, a navigation message is also containing so-called almanac data. This is a set of orbit parameters that allows calculation of approximate positions and velocities of all GNSS satellites. The almanac is used by a GNSS receiver to predict satellite visibility as an aid during acquisition. Almanac data is available from any satellite and is considered valid for up to 180 days. It contains a big amount of data taking 12.5 minutes to get transmitted.
In general, for most application developers a basic understanding of GNSS fundamentals will be sufficient, but those of you who ask for more details please refer to References section.
All GNSS receiver ICs or modules offer ready-to-use firmware which allows users to configure the module according to application action needs and focus on output messages available to the application system via serial interface, I2C or other. For historical reasons NMEA data format is used as a standard for output as well as for input messages. NMEA stands for “National Marine Electronics Association”, see Ref 3. NMEA output messages are provided at a default 1Hz rate containing time stamp, satellite IDs, latitude, longitude. altitude, etc. NMEA input messages are used by the host application to control the GNSS receiver (e.g. initiate a cold re-start) or change its configuration. Same interface can also be used for proprietary functions, e.g. for firmware update.
In order to enable mass-deployment of GNSS-supported applications, manufacturers of GNSS receiver chips are ambitious to integrate useful features and extra components in an effort to shrink BOM and reduce system cost. At the same time they try to optimise some performance aspects which are beneficial for some application, but useless for other applications. So, careful consideration of available product data as selection criteria is key.
The most straight-forward method to determine the position of a GNSS receiver is the so-called Standard Positioning Service (SPS) which is using the C/A code to estimate the distance to a satellite. As mentioned before, the C/A code is being transmitted at 1023 bits per second and used primarily to identify a satellite. For this purpose the received pattern of the acquired SV is being shifted backwards bit-by-bit against the original pattern until both patterns match. In fact, the number of required shifts corresponds to the delay of transmitted signal by the SV, i.e. its range to the GNSS receiver. With SPS a receiver can achieve accuracy of 3-10 meters which is good enough for many applications.
GNSS performance can be improved by Satellite-based Augmentation Systems (SBAS) supported by many GNSS modules reviewed here. Many countries have own regional implementations which can be used wherever available. For more details please see Ref 4.
The Quasi-Zenith Satellite System (QZSS) is a Japanese regional communication service and positioning information for the mobile environment in the GPS L1C/A band. QZSS in conjunction with GPS signals provides GNSS augmentation service for the Pacific region covering Japan and Australia.
Other techniques like DGPS (Differential GPS) or RTK (Real-Time Kinematik) are supported by some GNSS modules, see our Product Overview and refer to manufacturer documentation.
Time to first fix (TTFF)
Time to first fix (TTFF) is a measure of the time required for a GNSS receiver to calculate its position (called a “fix”). A faster TTTF is possible if the receiver already knows some relevant satellite information in advance. Therefore, TTTF is commonly broken down into three more specific use case scenarios:
- Cold: A cold start is when the receiver has no knowledge about its position, velocity, time, or visibility of any other satellites. As such, the receiver must start from scratch, e.g. systematically search for satellites in order to compute first position.
- Warm: A typical warm start is when the receiver has valid almanac and time data and has not significantly moved since its last valid position calculation. This happens when the receiver has been shut down for few hours, but still has its last position, time, and almanac saved in memory, and its RTC has been running. The receiver can predict the location of the current visible satellites and its location; however, it needs to wait for an ephemeris broadcast (every 30 seconds) before it can accurately calculate its position.
- Hot: The receiver has valid time, position, almanac, and ephemeris data, enabling a rapid acquisition of satellite signals. The time required of a receiver in this state to calculate a position fix is sometimes referred to as Time to Subsequent Fix or TTSF.
TTFF is critical for many applications, esp. after cold or warm start in environments with poor satellite visibility or reception. Consequently and in order to improve startup performance most manufacturers offer support for “augmented GNSS” services. These assisted GNSS services require network access to a server. Please contact the module manufacturer for further details and which bundles are available at which cost, if any.
In addition, some manufacturers offer algorithms allowing autonomous prediction of current position without access to external sources. For example, STMicroelectronics is offering a software which is able to predict ephemeris data using past real ephemeris downloaded from the sky and stored in it’s internal database. Others have implemented algorithms to calculate the actual position from last known velocity (“dead-reckoning”).
At least for battery-powered handheld devices low power consumption is crucial. For example, you can set the module in stand-by state (i.e. GNSS core and RF part off) during time slots when no new position is required for some time. A backup battery can be used to maintain critical data and keep RTC alive in order to speed up re-acquisition after wake-up. Other low-power modes are offered to cycle receiver states (full power, CPU-only, stand-by), for example at a certain fixed rate. Such mechanism would reduce average power consumption over time.
Another approach is to reduce chip resources (e.g. number of allocated tracking channels) if not needed, e.g. in areas with good satellite visibility or strong-signal conditions.
Support for multiple GNSS constellations
In general, satellite visibility is important because the more satellites the receiver can see, the faster the fix and the more accurate the position will be when the fix is obtained. Besides GPS we have several satellite navigation systems incl. European Galileo, Russia’s GLONASS, and Chinese BeiDou. On top of this capability some GNSS receivers are able to track simultaneously signals of different satellite constellation which is beneficial in difficult environments (e.g. “urban canyons”) where satellite visibility is a challenge. If feature is offered (as indicated in Product Overview) please refer to manufacturer documentation which combinations and how many concurrent constellations are supported.
Some manufacturers are offering useful firmware-embedded functions extending standard GNSS functions – either for free or at extra cost. Usually, these functions can be used by the customer application via proprietary NMEA commands. For example:
- Geofencing determines whether the actual position is within a circular area around a predefined location point. A proprietary NMEA sentence may indicate the “inside” or “outside” status.
- Data Logging locally saves resolved GNSS positions to module flash memory in order to be retrieved on demand from the host at any time later.
- Odometer provides information on the traveled distance using positioning information.
In general, purchase prices are subject to frequent change (e.g. due to currency exchange rate), and depend on quantities and negotiation. Consequently, in below competitive overview we provide a price indication only – based on actual budgetary quotes published by manufacturer and/or distributors at publication date.
Average price range for reviewed GNSS receiver modules is around 10-14 EUR for 100 to 1000 units. Products in this range are marked “◇”. Less expensive products are marked “▽”, more expensive products are marked “△”. For a reliable quotation you will have to contact your sales partner anyway.
Our product overview covers all major manufacturers and a selection of their GNSS receiver modules. Please refer to manufacturer website for additional products not mentioned here, for technical documentation, software manuals and in-depth description of available evaluation tools.
- Linx, URL: https://linxtechnologies.com/wp/p/rf-modules/gps-gnss-modules
- STMicroelectronics, URL: https://www.st.com/en/positioning/gnss-modules.html
- Telit, URL: https://www.telit.com/m2m-iot-products/positioning-timing-modules
- GNS Electronics, URL: https://www.gns-electronics.de/product/1301
- Würth Elektronik, URL: https://www.we-online.com/catalog/en/wco/wireless-connectivity_1/gnss
- Lantronix, URL: https://www.lantronix.com/products-class/gnss-receivers
- u-blox, URL: https://www.u-blox.com/en/positioning-chips-and-modules
Chips for GNSS receiver modules are supplied only by few manufacturers. STMicroelectronics modules as well as u-blox products are based on their own GNSS chips, URLs see above list. Other chip manufacturers websites are listed here:
- Qualcomm, URL: https://www.qualcomm.com/products/sirfstar-v-5e
- MediaTek, URL: https://www.mediatek.com/products/locationIntelligence/mt3333
For better visibility and further use you can download above table as a PDF here:
Our competitive overview is focussing on off-the-shelf and ready-to-use GNSS receiver modules – to be controlled by host application via API. All of them are running a proprietary embedded OS which allows configuration of embedded GNSS functions (e.g. enable constellations, adjust thresholds, etc.) and embedded applications (e.g. Assisted GNSS or data logging). API might be based on proprietary NMEA commands. Customer modifications or extensions of the embedded software itself are not supported by manufacturers. Customers with special requirements will have to address these to the manufacturer.
Some application-specific hardware requirements are already covered by most GNSS receiver modules, e.g. support for active antennas or different LNA (to replace the internal one). RF PCB layout will be tricky anyway, so most of you will appreciate not to design from scratch. But in case you need hardware adjustments or if you have to reduce cost even further, STMicroelectronics offers used GNSS Teseo core chips separately as standard products. In fact, selling semiconductors is their core business. Also u-blox are offering their GNSS receiver chips separately.
Selection criteria depend on application requirements, and each candidate has different focus and strengths (see also green fields in Product Overview table).
Low-price-leader is u-blox MAX-8C, but it does not support concurrent GNSS constellations. Also ST’s Teseo-LIV3F and Telit SL871L are offered at prices below average. For automotive applications you will probably have to focus on STMicroelectronics chips (incl. Telit SL869-V3 module) and u-blox products. Those of you who ask for embedded antenna should look at Telit SL876Q5-A and u-blox SAM-M8Q
In general, u-blox offers the largest variety of GNSS receivers modules and chips. Flash-less u-blox modules SAM-M8Q and u-blox NEO-M8Q modules are offering lowest power consumption during full operation. Qualcomm’s SiRFstarV chip offers smart power management allowing to achieve even lower power consumption, if applicable. See Würth Erinome II and Lantronix A5100-A modules. Consequently, these four modules are good candidates for battery-powered handheld devices.
ST’s Teseo-LIV3F standard firmware offers embedded functions for data logging, geofencing and odometer.
By nature, smaller projects with limited manufacturer support will have to rely on public information and online support services available by selected manufacturer. Würth, Lantronix and GNS Elektronik allow customers to submit online support requests. In addition, STMicroelectronics and u-blox are also offering public discussion boards.