Wideband front end for GPS, Glonass, Galileo, Compass
I've long wanted a fully flexible GPS receiver. Starting from the raw RF samples gives complete visibility into the signal processing and estimation algorithms for the observables. Unfortunately, existing commercial products, either in the test-equipment class (e.g. vector signal analyzer, USRP), the L1-only USB dongle class, or the "front-end box driving expensive closed-source GNSS software receiver" class, are either narrowband, expensive, bulky, power hungry, or perhaps all of these attributes together.
Especially after reading this paper I wanted a small, cheap front end that gives access to everything a software receiver could want. From there it's a small matter of programming to derive useful measurements from the sample stream.
Pictured above is a prototype board with two of the three RF channels populated. (Once I have an antenna that reaches down to L5, perhaps a homemade helibowl, I'll solder down the third channel.)
Goals for the project:
- high-quality signals from all current and near-future GNSS systems (GPS, Glonass, Galileo, Compass)
- wide bandwidth---provides three 50 MHz channels, nominally at L1, L2, and L5
- low cost---currently about $170 parts cost in single quantity, ~$110 in qty 100
- simplicity of use---emits streams of 2-bit samples to gigabit Ethernet, feeding a downstream software-receiver farm
- two baseband clock inputs for use by timing receivers---any combination of 10 MHz, 100 MHz, 1 PPS
- tunability typically from 0.7 to 2.2 GHz on each channel independently, for non-GPS applications such as radio astronomy
- easy to fabricate and procure parts---4-layer PCB, everything available from friendly distributors such as Digikey and Mouser
- free and open-source licensing: TAPR Open Hardware License version 1.0 for hardware, GPLv2 for HDL, firmware, and software
Design files, including schematic, PCB artwork, HDL, and software, are available at my github repository:
https://github.com/pmonta/GNSS_Firehose
Here is a sky recording of L1 and L2 with 2-bit samples at 64 MHz in libpcap/tcpdump format. The github software has a tool to extract samples, but briefly, this file has 20000 packets, each with 1024 byte payload; each byte is {I_L1, Q_L1, I_L2, Q_L2} where each field is 2 bits; samples are encoded as 00, 01, 10, 11 from most negative to most positive; and the center frequencies are 65*fref for L1 and 51*fref for L2 where fref is 24.380952 MHz. (In any given byte the L1 and L2 samples are simultaneous, modulo any small yet-to-be-characterized interchannel biases (of order ~100 ps perhaps).) Thus GPS L1 is offset by -9.341880 MHz plus any particular satellite's doppler, and L2 is offset by -15.828552 MHz plus doppler. Length of capture is 0.32 seconds.
There are some strong L1 and L2C signals in this recording, though my antenna location could be better (trees). Use your favorite software receiver (e.g. fastgps) to acquire and track. For the next spin I may change the TCXO from 40 MHz to 38.88 MHz, since that frequency seems to be more available from the distributors.
I'm still in the process of characterizing the prototype; also some HDL for ancillary functions like AGC needs to be written---this and a few other configuration tasks are currently driven from an external PC, so the board is not quite autonomous yet.
Design considerations
While I considered direct sampling, the overall design ended up as a classical direct-conversion quadrature receiver much like the USRP's DBSRX2 board: LNAs, followed by MAX2112 downconverters with pretty reasonable integrated synthesizers (running in integer-N mode for repeatable interchannel phase), followed by 8-bit ADCs. For clocks I went with a TCXO (or, optionally in a future revision, the external 10 MHz or 100 MHz reference) driving National's LMK03806 low-jitter clock synthesizer.
For output format, Ethernet is attractive. USB might be a little cheaper and a little more convenient for small deployments, but the low data rate of USB 2.0 is a showstopper, ubiquitous and easily-embeddable USB 3.0 is not quite here yet, and the clear trend in radio astronomy at least is flexible commodity networking feeding general-purpose receiver farms. I wanted something that could fit into that mold. An emerging radio-astronomy packet format, VDIF, might be a good way to go; are there GNU Radio sources and sinks for VDIF yet? Currently I'm just using raw broadcast Ethernet packets and tcpdump (though perhaps gulp would be better) for capturing the ~800 Mbit/s stream on a Linux box.
Applications
It would be nice to have a software-receiver chain that gives very high quality GNSS code and phase observables for every open or semi-open signal available. These could be dumped to a RINEX file for postprocessing or used in real time for navigation or timing. Timing, in particular, could benefit from dual- or triple-frequency observables, multi-GNSS processing (especially with the Galileo clocks as they are launched), and the availability of real-time clock information from IGS in the NTRIP format. The usual single-frequency autonomous GPSDO seems a bit limited. I'd like a multi-frequency, multi-system GNSSDO that is getting up-to-the-second clock and orbit data from the net. While I have no direct experience with systems of this type yet, from what I can tell, reliable real-time timing at the few-ns level might be possible (relative to some notional UTC(GPS+IGS/NTRIP+other_metadata) timescale), along with frequency comparisons at the ~5e-15/day level with suitable postprocessing.
Increasingly, open-source software is filling in these areas. Interesting projects include RTKLIB, GPSTk, and GNSS-SDR:
The only thing missing seems to be inexpensive wideband front-end hardware, including, by the way, inexpensive antennas with full frequency coverage and stable phase center---still thinking about that. Certainly for L5/E5, wide bandwidth is required, and for L1 and L2 as well when going the semicodeless route with the P(Y) signals.
I'll put descriptions of any project updates in future posts.