A GNSS receiver, in general, is an electronic device that receives and digitally processes the signals from a navigation satellite constellation in order to provide position, velocity and time (of the receiver).
GNSS receivers have been traditionally implemented in hardware: a hardware GNSS receiver is conceived as a dedicated chip that have been designed and built (from the very beginning) with the only purpose of being a GNSS receiver.
In a software GNSS receiver, all digital processing is performed by a general purpose microprocessor. In this approach, a small amount of inexpensive hardware is still needed, known as the frontend, that digitizes the signal from the satellites. The microprocessor can then work on this raw digital stream to implement the GNSS functionality.
When comparing hardwarevssoftware GNSS receivers, a number of pros and cons can be found for each approach:
Hardware GNSS receivers are in general more efficient from the point of view of both computational load and power consumption since they have been designed in a highly specialized way with the only purpose of implementing the GNSS processing.
Software GNSS receivers allow a huge flexibility: many features of the receiver can be modified just through software. This provides the receiver with adaptive capabilities, depending on the user's needs and working conditions. In addition, the receiver can be easily upgraded via software.[1]
Under some assumptions, Software GNSS receivers can be more profitable for some applications, as long as sufficient computational power is available (and can be shared among multiple applications). For example, the microprocessor of a smartphone can be used to provide GNSS navigation with the only need of including a frontend (instead of a full, more expensive, hardware receiver).
Currently, most of the GNSS receiver market is still hardware. However, there already exist operational solutions based on the software approach able to run on low-cost microprocessors. Software GNSS receivers are expected to increase their market share or even take over in the near future, following the development of the computational capabilities of the microprocessors (Moore's law).
This comparison is strictly about GNSS SDR; please do not include general GNSS positioning and mapping software.
This article should be written as a table. Please improve this article to meet Wikipedia's quality standards, or discuss this issue on the talk page. Editing help is available.
Under active development (as-of date): public version - no, non-public versions - yes (2013-Sep-30)
Hardware support:
Front-ends: SiGe GN3S Sampler v1 (in the original SDR and driver release). Signal records originating from other Sampler versions or other front-ends require configuration changes and in some cases also minor code changes.
Host computer special hardware supported: no
Multicore supported?: no
GNSS/SBAS signals support (separate version for each band of each GNSS):
Real-time Kinematic: yes, GRID can function as an RTK-base station or rover with integrated network support, RTK estimation when integrated with PpEngine (available through separate license)
Differential corrections: yes, CNAV and SBAS
Maximum number of real-time channels: Hardware-dependent, 30 on a Raspberry Pi 1, >100 on most desktop computers.
Borre, K; Akos, D; Bertelsen, N; Rinder, P; Jensen, S H (2007). A software-defined GPS and Galileo receiver: a single-frequency approach. Birkhauser. ISBN978-0-8176-4390-4.
Petrovski, Ivan; Tsujii, Toshiaki (2012). Digital satellite navigation and geophysics a practical guide with GNSS signal simulator and receiver laboratory. Cambridge University Press. ISBN9780521760546.
