Squaring receiver for Galileo blind search

I’ve been following the drama of the two recently-launched Galileo FOC satellites. To my knowledge, nothing is yet known about the status of the transmitters, nor have the PRNs been revealed, nor does an acquisition search over all 50 codes in the Galileo ICD yield any signals when the satellites are in view (though PRNs 11, 12, and 19 show up as expected).

So if the satellites are transmitting at all, perhaps it’s with a nonstandard code. One way to check is to take a trip back in time and revisit one of the very oldest GNSS receiver techniques, that of squaring a BPSK signal to recover a tone, then driving a PLL with this tone. (The Macrometer V-1000 receiver used this scheme.)

Now Galileo E1 when viewed in a 4 MHz bandwidth is not BPSK—it is, I believe, a three-level signal, {-1,0,1}, being the sum of equal-power E1-B and E1-C with negligible contribution in quadraphase from PRS. But squaring still works on a signal of this type, though not quite as well as with BPSK.

Here is a waterfall plot with several satellites visible, and indeed Galileo PRN 11 is one of them. Its identity is confirmed by acquiring and tracking in the conventional way, then verifying that the Doppler is identical (modulo the factor of 2 from squaring).

squaring

As of September 20, though, there is still nothing from the new satellites. A predicted Doppler curve can be derived from orbital elements, but there is nothing in the spectrogram at the anticipated Doppler. So we wait.

Code for this “receiver” (all of a dozen lines) is at the GitHub repository (squaring.py). Its output can be piped to the indispensable baudline spectrum analysis tool for interactive viewing.

GNSS stamp collecting

Here’s a fun montage of the various GNSS signals-in-space. I think this accounts for all extant open-access signals that are likely to remain so (ruling out Galileo E6 for example) and that are intended for systems having global coverage (so no QZSS or IRNSS). A few comments on the signals:

  • Each waveform is 400 ms in length and is sampled at 1 ms intervals after code and carrier wipeoff
  • Secondary codes have not been removed
  • Carrier-to-noise ratios vary. The weakest signals are Galileo E5a-I and E5a-Q; by eye there is not much to see, but the acquisition metric is clearly well above threshold, and the histograms are clearly bimodal. My L1/L2 antenna receives some L5 but with about 15 dB of attenuation (!). I really need an antenna that covers down to L5. The GPS L5 signals must have been blisteringly strong to come through as well as they did.
  • The pilot signals with no secondary codes, GPS L2CL and GLONASS L2 P, are shown correctly offset from the (undrawn) centerline. I’m not sure much is known about the data modulation on GLONASS P. Apparently L1 has some data at 50 Hz (no secondary/meander code?) and L2 is unmodulated.
  • So far there are two GLONASS satellites transmitting L3OC CDMA signals. The signals shown are from PRN 30, but PRN 33 is also active and of comparable quality.

The tools for acquiring and tracking these signals are in my GitHub repository:

https://github.com/pmonta/GNSS-DSP-tools

They are command-line-ish and not very polished yet.

track-collection

Height-based multipath mitigation

Here’s a crazy idea which I might as well put on the blog.

Multipath is an important error source for GNSS reference stations. Monuments for antennas are nearly always placed close to the Earth’s surface, so the ground will act as a reflector with a grazing geometry that generates short-delay multipath. Usually other objects contribute as well (nearby buildings or fences for example).

Many solutions exist for multipath mitigation, both at the antenna and correlator levels. Another possible system technique, though, would seem to be to move the antenna upwards, far enough away from local objects that any reflected signals have delays larger than the support of the autocorrelation function for any signal of interest.

Conceptually, an antenna could simply be placed at the top of a tall tower a few hundred meters in height. The tower would ideally be transparent to RF (perhaps of lightweight dielectric construction). Of course there are many practical problems with this, but the environment around the antenna would be nearly ideal.

Another possibility is to place the GNSS antenna on a UAV, which would keep station above the reference monument and several auxiliary sensors (whose location and stability are not critical). The UAV would simultaneously maintain links with visible GNSS satellites (aided by an on-board inertial system) and with sensors on the ground using any of a variety of accurate (~0.1 mm say) short-range ranging techniques. In this way the pristine airborne GNSS signal environment is transferred to the reference monument despite the relative movement.

The UAV could execute certain maneuvers to continuously calibrate its antenna, similar to robot absolute antenna calibrations on the ground. The craft could spin slowly around the vertical axis, or tilt slightly, or both. The attitude from the inertial system would become part of the observation stream to close the calibration loop. By contrast, there is great reluctance to move ground-based GNSS reference antennas to carry out any sort of ongoing calibration program on them. With flyers, continuous monitoring comes for free.

Small rotations and tilts on an airborne platform are impossible to completely avoid, and high-wind situations may force some loss of observing time. But for most of the time, the environment should permit an accurate tie from UAV track to ground network. Depending on the choice of flying craft, several may be needed, spelling each other for charging or refueling. Automatic fleet management will probably have many good solutions over the next few years.

It’s hard to know whether there’s a benefit without more detailed study, but the prevailing trends in GNSS system accuracy seem to be increasing the relative importance of multipath. If we assume progressively better satellite orbit and clock estimates and ionosphere and troposphere sensing, then multipath may well loom as the last remaining large, difficult, uncertain systematic error. (Perhaps a UAV could help with estimating the wet troposphere delay as part of normal operation, to the extent that measurements on the very bottom segment of the troposphere are predictive of the full path.)

Finally, I wonder whether UAVs could help with urban canyons or tree-canopy issues. A surveyor might deal with an awkward situation by tossing a UAV into the air and replacing a bad-GNSS-signal problem with a perhaps easier-to-solve UAV-to-ground-sensor problem using vastly stronger optical or RF links.

Semicodeless P(Y)-code processing using high-rate aiding

Present schemes for semicodeless P(Y) processing assume an autonomous receiver that estimates W-code bits directly from the received signal. Given the limited C/N0 available, naturally the signals are noisy, resulting in squaring loss.

One simple way around this is to use more reliable estimates of the W bits acquired with a medium-gain antenna. These estimates can be published continuously in near-real-time by a suitable Internet-based service, then used by any client receiver, which could be a conventional real-time receiver or a recorded-waveform software receiver.

This need not be all that expensive. All that’s required is approximately one medium-gain antenna per satellite per hemisphere. A one-meter dish of 20 dB gain would reduce squaring loss to practically zero. Of course a reasonable Internet uplink is needed of 480 kbit/second for each satellite. Storage costs could be controlled by retaining the W bits for a limited time (a few weeks or months).

Another possibility, in a world where every receiver is uploading full RF waveforms to a central service, is to sum together the signals from many receivers before estimating the W bits. (If the summing is done prior to detection, this is effectively a phased-array antenna.) Quite a few signals would be needed, though, if each receiver has the usual omni antenna. Better to rely on dedicated medium-gain antennas.

The W-code bits would not be of any use to spoofers since they would be tens or hundreds of milliseconds out of date.

The same trick can be played with other unknown codes, such as the GPS M code or the PRS codes on other GNSS services. The bit rates of the published reference waveforms would be much higher than those of W-code, but perhaps the effort would be repaid by observables that could be obtained in no other way, helping with multipath and ambiguity resolution. In the limit of a totally unknown waveform, this is just VLBI.

Parallel processing of recorded GNSS signals

Most GNSS receivers process signals serially. This is natural for tracking loops based on PLLs and DLLs, as they have a feedback structure. If signals are recorded and stored, however, another viewpoint might be more flexible.

Let’s regard the recorded waveform as a series of chunks of length, say, 5 minutes. All these chunks can be processed in parallel, though at the cost of ambiguities in whole cycles of carrier phase for each chunk. (Let’s assume that acquisition or aiding has already allowed each chunk processor to start with good estimates of code phase and doppler, and that suitable guard intervals allow the tracking loops to converge somewhat in advance of the start of each chunk, so that effectively the chunks overlap a little.) Once all chunks are processed, whole cycles of carrier phase are simply cumulatively summed. This reduces the ambiguity set to the normal case of just a single ambiguity for the whole interval of the satellite pass (assuming no cycle slips or loss of lock).

So an attractive GNSS processing scenario might be:

  • deposit all waveforms in a central place, such as one of the cloud computation environments like Amazon’s S3 and EC2
  • do all processing of interest in parallel, by allocating as many processors as needed; place intermediate results as annotations on a common scoreboard
  • coalesce the results, obtain observables, and post-process

By having the entire waveform accessible at once to a common pool of processors, a kind of annotation-based processing becomes possible. First, acquisition might be performed at fixed intervals, possibly aided by a location estimate and orbit estimates from IGS. Once the file has been annotated with acquisition results, each chunk can be tracked as outlined above. Vector tracking, differencing at the correlator level, quality monitoring, etc. can all be included as additional workflow options.

GPS P code exploration

As a first step towards obtaining GPS P-code observables, it seems prudent to verify that the P code is detectable in a test recording with high C/N0.

Here’s the result with an L1 recording containing a strong signal from PRN 30 (about 50 dBHz). The peak is smeared over an extent somewhat larger than two chips, the result of some residual code doppler. Also the peak is offset by about 1 chip, again the result of residual error from the C/A acquisition (about 0.1 C/A chip). It was great to see it at all though. Certainly it proves out the P code generator.

p_code

The recording is about 1.4 seconds long and contains these data bits:

000100010110111101111011110010001011000011000001100010101110010100100100101

It turns out I was a bit lucky and got a complete TOW word at the end:

0001000101101111011110111100
10001011                        # Preamble
00001100000110                  # TLM Message
0                               # Integrity Status Flag
0                               # Reserved
101011                          # Parity
10010100100100101               # TOW Count (inverted: 01101011011011010)

This TOW count corresponds to Wednesday 19:40:12 in the GPS week, so the first bit of the preamble is at 19:40:06. Adding up the C/A code phase and the previous bits gives the time of the first RF sample of the file as 19:40:05.450822469 or 3375955761914 P code chips. That was the offset given to the script that produced the above plot.

I’ve put the code generators and some preliminary acquisition and tracking software in a new GitHub repository:

http://github.com/pmonta/GNSS-DSP-tools/

I’m sure it’s not as efficient as low-level code in C, but it’s nice to have concise scripts for prototyping, with everything in the Matlab-like python / numpy environment.

New “GNSS Firehose” board

I’ve finally gotten around to updating the GNSS front-end digitizer. Along with a new Ethernet PHY chip (the old one from Vitesse seems to be no longer available), there is an external clock option, an expanded auxiliary header, and a number of small improvements in signal integrity. The external-clock header can accept an external OCXO or rubidium signal, for example; and multiple boards can be driven with a common clock.

new-board

Here’s a spectrum at L1. Despite the poor antenna placement (almost surrounded by tall trees), the GPS C/A signal shows up quite well as a broad peak of 2 MHz bandwidth. There is substantial ripple in the antenna’s ~35 MHz passband, and unfortunately the antenna filtering cuts off around 1595 MHz, so GLONASS signals are suppressed. The signals near 1557 MHz are probably satellite downlinks, and the peak near 1584 MHz is the receiver’s DC spur.

spectrum

The usable alias-free bandwidth of the system is about 50 MHz per channel. At L1 this is enough to cover all the services, from BeiDou B1 starting at 1559 MHz to GLONASS extending to 1610 MHz.

Here’s a C/A correlation peak from this recording (PRN 13). The nice sharp corners are a result of using all of the C/A bandwidth:

peak

Next steps are to clean up the software and HDL and to test the other two channels. See previous blog posts for a pointer to the GitHub repository containing the newly-updated design files.

SMT stencil cutting

I’ve been making some SMT stencils using a Silhouette Cameo craft cutter (vinyl cutter). It’s great for fast turnaround time and low materials cost, though the quality is not as high as a laser-cut stainless-steel stencil. Still, they’re useful down to 0.5 mm pitch and 0201, and possibly a little better, and that’s good enough for many applications.

Here’s a stencil cut by the Cameo. The partial QFP footprint is 0.5 mm pitch and the smallest discretes are 0402.

gerber2graphtec examples/test_0.5mm_0402.gbr >/dev/usb/lp0

Stencil 1

And a test coupon with QFP pitch from 0.65 mm to 0.3 mm, discretes from 0603 to 01005, and BGA pitch from 1.0 mm to 0.5 mm:

Background

The web page that got me looking at craft cutters was this one:

http://www.idleloop.com/robotics/cutter/index.php#stencil

These results are very nice, but on the software side I wanted something that fits into a normal PCB workflow with no hassle, by working directly from the solderpaste Gerber file as exported by a PCB CAM tool.

In addition, I wanted the best quality possible. Using the cutter in its default mode rounds off corners considerably due to the drag-knife mechanics, so instead I dice all features into individual line segments and draw them separately in multiple passes. Also, machine backlash is an issue, so the software works around that, at the expense of speed.

Fortunately, the low-level protocol for these machines has been documented, and the rest is mere geometry conversion that’s considerably helped by existing tools like gerbv and pstoedit. The software can be found here:

http://github.com/pmonta/gerber2graphtec

Also included are some example Gerber files. A test coupon with QFP/QFN and BGA pitches from 0.65 mm down to 0.3 mm and two-pad footprints from 0603 to 01005 is included, as well as a few larger examples.

The generated files run well on my Silhouette Cameo and probably on other similar Graphtec cutters as well.

Materials

Polyester film is a natural choice. It’s inexpensive, dimensionally stable, and very available in the form of laser-printer or copier transparency sheets. Thickness of these sheets is usually around 4 mils, close to the IPC-recommended values for fine-pitch work. Other thicknesses can be obtained easily enough from sources like McMaster-Carr.

I’m using Highland 901 sheets (a 3M brand apparently) together with full-sheet Avery labels, number 5353, as an adhesive backing sheet. The adhesive is a little too aggressive and can be difficult to remove cleanly once the stencil is finished. One can use Goo-Gone or similar citrus-oil cleaner to remove all the adhesive, and this results in a squeaky-clean stencil, but it takes a few minutes of extra time. Perhaps it would be better to use the cutter’s cutting mat, though cleaning off the small plastic chads is a bother too. Another option might be to use a separate full-sheet double-sided low-tack adhesive to laminate a plastic sheet to a plain paper backing.

Calibration

Two aspects of the machine should be calibrated for best performance: cutting force and the spatial coordinate system.

For force, the software includes an example script that produces 30 small squares, each cut with a different force. Just have a look at the result to see which force settings result in good performance with your material stackup (mylar plus adhesive backing): first, a reasonable initial cut, to score the material, and second, a final pass that aims to cleanly separate the unwanted material from the stencil background.

For axis calibration, a script is provided to cut a calibration artifact. Measure the distance between marks along each direction (x, y, 45 degrees, and -45 degrees), then calculate a matrix to take out the distortion. (Rub in a bit of felt-tip-pen ink to make the marks more visible when comparing against a good ruler. The provided script produces a 17-step vernier against a 1/16-inch ruler; modify this for 11 steps against a 1 mm ruler if you’re using a metric ruler.) My machine is pretty reasonable in x, has a rather large 0.6% error in y, and has a skew of about 1 milliradian. After compensation I think the error is down to less than 0.1%. Even this is uncomfortably high: it is still a 50-micron positioning error across half the dimension of a 100 mm board.

Platform notes

So far I’ve run this only under Linux (Fedora), which provides a device node at /dev/usb/lp0 when the device is plugged in. Other platforms may need different device-driver arrangments. One can always send the output of gerber2graphtec to a file and deal with getting it to the cutter separately. Fortunately no feedback from the cutter seems to be necessary.

Application notes

Perhaps these stencils are best suited to prototyping that needs very fast turnaround. For example, it’s sometimes convenient to populate and test only parts of a board, and for this separate stencils can be cut for each region.

I plan to evaluate at some point this source of laser-cut Kapton stencils:

http://ohararp.com/Stencils.html

as well as the various lower-end laser-cut stainless vendors.

GNSS Firehose

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:

http://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.

GNSS_Firehose_L1L2.tcpdump

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:

http://www.rtklib.com/
http://www.gpstk.org/
http://gnss-sdr.org/

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.