Following a discussion on Twitter about how to use satellite signals to check that distributed receivers are properly synchronized, I have decided to write a post about how to use GPS signals to timestamp an SDR recording. The idea is simple: we do a short IQ recording of GPS signals, and then process those signals to find the GPS time corresponding to the start of the recording. This can be applied in many contexts, such as:
- Checking if the 1PPS synchronization in an SDR receiver is working correctly.
- Timestamping an SDR recording without the need of a GPS receiver or 1PPS input, by first recording GPS signals for some seconds and then moving to the signals of interest (this only works if you’re able to change frequency without stopping the sample stream).
- Measuring hardware delays between the 1PPS input and the ADC of an SDR (for this you need to know the hardware delay between the antenna connector and 1PPS output of your GPSDO).
- Checking if synchronization is repetitive across restarts or power cycles.
We will do things in a fairly manual way, using a couple of open source tools and a Jupyter notebook. The procedure could certainly be automated more (but if you do so, at some point you might end up building a full fledged GPS receiver!). The post is written with a walk-through approach in mind, and besides the usefulness of timestamping recordings, it is also interesting to see hands-on how GPS works.
Galileo OSNMA (Open Service Navigation Message Authentication) is a protocol that will allow Galileo GNSS receivers to authenticate cryptographically the navigation data that is broadcast by Galileo satellites. The system is currently in a public test phase and according to the roadmap it will begin the initial service in 2023.
This month I have spent some time working in a new Rust library that implements the receiver-side processing of OSNMA. The library is called galileo-osnma. Although there are still some features that are not implemented, and some other future ideas that I have for this library, it has already reached a point where I feel it can be released and used by others. In its present state it is already able to perform all the steps that are needed to check all the OSNMA authentication data that is currently being transmitted by the satellites during the test phase. The library is licensed under a permissive open source license (Apache + MIT, which is common in the Rust ecosystem).
For the European GNU Radio Days 2021, Jean-Michel Friedt, as part of the organizing team set up a signal decoding challenge based on GPS signals. The price to the two best solutions was two USRP B205mini‘s kindly provided by NI Ettus, who sponsored the conference.
I managed to solve this challenge shortly after it was published, and sent Jean-Michel a Jupyter notebook explaining my solution. Jean-Michel liked this approach and invited me to present my solution today at the conference. This presentation can be watched in the recording of the conference livestream.
I have now published a repository with all the material of my solution. Thanks to Jean-Michel for putting together this interesting and enjoyable challenge and to NI for providing a prize to make the challenge more attractive.
Over the last few weeks I have been helping the Allen Telescope Array by calibrating the pointing of some of the recently upgraded antennas using the GNU Radio backend, which consists of two USRP N32x devices that are connected to the IF output of the RFCB downconverter. For this calibration, GPS satellites are used, since they are very bright, cover most of the sky, and have precise ephemerides.
The calibration procedure is described in this memo. Essentially, it involves pointing at a few points that describe a cross in elevation and cross-elevation coordinates and which is centred at the position of the GPS satellite. Power measurements are taken at each of these points and a Gaussian is fitted to compute the pointing error.
The script I am using is based on this script for the CASPER SNAP boards, with a few modifications to use my GNU Radio polarimetric correlator, which uses the USRPs and a software FX correlator that computes the crosscorrelations and autocorrelations of the two polarizations of two antennas. For the pointing calibration, only the autocorrelations are used to measure Stokes I, but all the correlations are saved to disk, which allows later analysis.
In this post I analyse the single-dish polarimetric spectra of the GPS satellites we have observed during some of these calibrations.
This post belongs to a series about the activities of the GNU Radio community at Allen Telescope Array. For more information about these activities, see my first post.
The feeds in the ATA dishes are dual polarization linear feeds, giving two orthogonal linear polarizations that are called X and Y and (corresponding to the horizontal and vertical polarizations). In the setup we currently have, the two RF signals from a single dish are downconverted to an IF around 512 MHz using common LOs and then sampled by the two channels of a USRP N32x. Since we have two USRPs, we are able to receive dual polarization signals from two dishes simultaneously.
The two USRPs are synchronized with the 10MHz and PPS signals from the observatory, but even in these conditions there will be random phase offsets between the different channels. These offsets are caused by fractional-N PLL states and other factors, and change with every device reset. To solve this problem, it is possible to distribute the LO from the first channel of a USRP N321 into its second channel and both channels of a second USRP N320. In fact, it is possible to daisy chain several USRPs to achieve a massive MIMO configuration. By sharing the LO between all the channels, we achieve repeatable phase offsets in every run.
During the first weekends of experiments at ATA we didn’t use LO sharing, and we finally set it up and tested it last weekend. After verifying that phase offsets were in fact repeatable between all the channels, I did some polarimetric observations of GNSS satellites to calibrate the phase offsets. The results are summarised in this post. The data has been published in Zenodo as “Allen Telescope Array polarimetric observation of GNSS satellites“.
Back in July, I wrote about how the Galileo E24 differential code biases were abnormally large in comparison to other satellites from the constellation. This was initially noticed by Bert Hubert from galmon.eu in the large size of the BGDs of this satellite. In that post I did a study of the DCB products from the Chinese Academy of Science and the broadcast ephemeris BGDs, and explained the relation between them.
At the end of September, Bert tweeted that after some maintenance the BGDs of E24 had stopped being so large. That is not so surprising, since the payload on-board the satellite can adjust the relative delays between each of the navigation signals, in order to correct these kinds of problems.
After letting a few weeks go by so that the MGEX products get uploaded, I have now redone some of the plots in that study with the data surrounding the change.
Since the beginning of October, together with a group of people from the GNU Radio community, we are doing some experiments and tests remotely at Allen Telescope Array (ATA). This amazing opportunity forms part of the recent collaboration agreement between SETI Institute and GNU Radio. We are taking advantage of the fact that the ATA hardware is relatively unused on weekends, and putting it to good use for our experiments. One of the goal of these activities is to put in contact GNU Radio people and radio astronomy people, to learn from each other and discover what features of GNU Radio could benefit radio astronomy and SETI, particularly at the ATA.
I’m very grateful to Wael Farah, Alex Pollak, Steve Croft and Ellie White from ATA and SETI Institute for their support of this project and the very interesting conversations we’ve had, to Derek Kozel, who is Principal Investigator for GNU Radio at SETI, for organizing and supporting all this, and to the rest of my GNU Radio teammates for what’s being an excellent collaboration of ideas and sharing of resources.
From the work I’ve been doing at ATA, I already have several recordings and data, and also some studies and material that I’ll be publishing in the near future. Hopefully this post will be the first in a series of many.
Here I will speak about one of the first experiments I did at ATA, which is a recording of one Galileo GNSS satellite using two of the dishes from the array. This kind of recording can be used to perform interferometry. GNSS satellites are good test targets because they have strong wideband signals and their location is known precisely. The IQ recording described in this post is published as the dataset “Allen Telescope Array Galileo E31 RF recording with 2 antennas and 2 polarizations” in Zenodo.
Back on January, I did a post with a simulation about the DOP distribution for the Galileo and GPS constellations. In there, I computed the DOP for a grid of points on the surface of the Earth and then plotted maps with the average and worst DOP. I used three different kinds of constellation definitions, both for Galileo and for GPS: the base constellation, which has 24 satellites in both cases; an expanded constellation, which in the case of Galileo adds 6 spares and in the case of GPS has 27 satellites as defined in the 2008 SPS performance standard; and a real life constellation taken from the almanac at the beginning of January.
Since I wrote that post, the 2020 SPS performance standard came out in April. This defines a new expandable reference constellation of 30 satellites. Besides the three expandable slots on planes B, D and F, three new expandable slots are added on planes A, C and E, so that now there is one expandable slot per plane. All the RAANs and mean anomalies corresponding to the slots have also been updated, since the constellation is now referenced to an epoch on 2016 (the previous one had an epoch on 1993).
I have now run again my simulations using the 30 satellite expandable constellation, which provides a closer model to the real life constellation. Here I show briefly the results.
In my previous post I looked at the BGDs and related topics for the Galileo satellites. We saw that satellite E24 has atypically large BGDs, but everything else seems fine and consistent with that satellite. However, Bert Hubert from galmon.eu shows that several RTCM sources broadcast a clock correction of around -5ns for E24. Here we look at the possible causes for that correction, and discuss whether it might be problematic.
A few days ago, Bert Hubert, from galmon.eu noticed that Galileo satellite E24 was somewhat special because it had unusually large BGDs. This raised a number of questions, such as what is the physical interpretation of BGDs, what they have to do with broadcast clock models, and so on.
In this post I will explain a few basic facts about BGDs and related topics, following an approach that is perhaps different to that of the usual GNSS literature, and also study the current values for the Galileo constellation. People who know all the details about the BGDs or who just want to see a few pretty plots can skip all the first section of the post.