This is a follow-up to the part I post about using WSJT-X modes through a linear transponder on a LEO satellite. In part I, we considered the tolerance of several WSJT-X modes to the residual Doppler produced by a temporal offset in the Doppler computation used for computer Doppler correction. There, we introduced a parameter \(\delta\) which represents the time shift between the real Doppler curve and the computed Doppler curve. The main idea was that a decoder could try to correct the residual Doppler by trying several values of \(\delta\) until a decode is produced.
Here we examine the effect of TLE age on the accuracy of the Doppler computation. The problem is that, when a satellite pass occurs, TLEs have been calculated at an epoch in the past, so there is an error between the actual Doppler curve and the Doppler curve predicted by the TLEs. We show that the actual Doppler curve is very well approximated by applying a time shift to the Doppler curve predicted by the TLEs, justifying the study in part I.
I have made a mains choke for my HF station, following Ian GM3SEK’s design, which involves twisting the three mains wires together and passing as many turns as possible through a Fair-Rite 0431177081 snap-on ferrite core. I wanted to measure the choke’s impedance to get an idea of its performance, so I’ve used my Hermes-Lite 2.0 beta2 in VNA mode.
A few days ago I read the paper about the Breakthrough Listen experiment. This experiment consists in doing many wideband recordings of different stars using the Green Bank Telescope, and (in the future) Parkes Observatory and then trying to find signals from extraterrestrial intelligent life in the recordings. The Breakthrough Listen project has a nice Github repository with some documentation and an analysis of a recording they did of Voyager 1 to test their setup.
I have also been thinking about how to study the polarization of signals in a dual polarization recording (two coherent channels with orthogonal polarizations). My main goal for this is to study the polarization of the signals of Amateur satellites in low Earth orbit. It seems that there are many myths regarding polarization and the rotation of cubesats, and these myths eventually pop up whenever anyone tries to discuss whether linearly polarized or circularly polarized Yagis are any good for receiving cubesats.
Through the Breakthrough Listen paper I’ve learned of the Stokes parameters. These are a set of parameters to describe polarization which are very popular in optics, since they are easy to measure physically. I have immediately noticed that they are also easy to compute from a dual polarization recording. In comparison with Jones vectors, Stokes parameters disregard all the information about phase, but instead they are computed from the averaged power in different polarizations. This makes their computation less affected by noise and other factors.
As I also wanted to get my hands on the Breakthrough Listen raw recordings, I have been computing the Stokes parameters of the Voyager 1 signal in their recording. Since the Voyager 1 signal is left hand circularly polarized, the results are not particularly interesting. It would be better to use a signal with changing polarization or some form of elliptical polarization.
I have started to use Jupyter notebook. This is something I had been wanting to try since a while ago, and I’ve realised that a Jupyter notebook serves better to document my experiments in Python than a Python script in a gist, which is what I was doing before. I have started a Github repo for my experiments using Jupyter notebooks. The experiment about polarization in the Voyager 1 signal is the first of them. Incidentally, this experiment has been done near Voyager 1’s 40th anniversary.
Last week I did an experiment where I transmitted WSPR on a fixed frequency for several days and studied the distribution of the frequency reports I got in the WSPR Database. This can be used to study the frequency accuracy of the reporters’ receivers.
I was surprised to find that the distribution of reports was skewed. It was more likely for the reference of a reporter to be low in frequency than to be high in frequency. The experiment was done in the 40m band. Now I have repeated the same experiment in the 20m band, obtaining similar results.
In a previous post I discussed my BER simulations with the LilacSat-1 receiver in gr-satellites. I found out that the “Feed Forward AGC” block was not performing well and causing a considerable loss in performance. David Rowe remarked that an AGC should not be necessary in a PSK modem, since PSK is not sensitive to amplitude. While this is true, several of the GNU Radio blocks that I’m using in my BPSK receiver are indeed sensitive to amplitude, so an AGC must be used with them. Here I look at these blocks and I explain the new AGC that I’m now using in gr-satellites.
Meanwhile, I have used a variation of my usual Python script to plot waterfalls of the recording. Below you can see waterfalls for the 3 bands. They use the same scaling, with a dynamic range of 50dB, so it is easy to see how the noise floor changes per band. The carriers of the strongest broadcast AM stations are clipped. The resolution in these waterfalls is 187.5Hz or 15s per pixel.
40m waterfall (centre frequency 7180kHz)30m waterfall (centre frequency 9970kHz)20m waterfall (centre frequency 14175kHz)
I have also taken a high resolution waterfall around the WWV carrier at 10MHz. The resolution is 22.9mHz or 65.5s per pixel, and the frequency span is 19.95Hz.
Centre frequency: 10MHz. Span 19.95Hz.
Near the centre of this waterfall, two signal can be seen. The signal which is concentrated in frequency is leakage from my 10MHz GPSDO. The signal which is spread out in frequency is the carrier of WWV, probably mixed with BPM. I’m not sure about the identity of the signal below them, which is about 5Hz below 10MHz. I suspect that it is JN53DV.
This waterfall shows that the 500ppb TCXO of my Hermes-Lite 2.0beta2 is stable to a few tens of parts per billion, as I remarked in my WSPR study.
Over the last few days I’ve been transmitting WSPR on 40m with 20dBm of power using my Hermes-Lite 2.0beta2. For this, I’m using the instrument output of the Hermes-Lite, which is driven by an OPA2677 200MHz dual opamp that produces a maximum output of 20dBm. I’ve been transmitting always on the frequency 7040100Hz. I have been collecting the reports from the WSPR database for a total of 2518 reports over 5 days of activity.
There are many statistics that can be done with this data, but since I have always been transmitting on the same frequency, it is quite interesting to look at the frequency in the reports. My Hermes-Lite is quite stable in frequency, as it uses a 0.5ppm 38.4MHz TCXO from Abracon. In fact, in the shack its stability is usually much better than 0.5ppm. During these tests I have verified the accuracy of the Hermes-Lite frequency by receiving my DF9NP 27MHz PLL, which is driven with a DF9NP 10MHz GPSDO. The 27MHz signal is usually reported around 3Hz high by the Hermes-Lite, with a drift of roughly 0.3Hz. This accounts for an error of 0.1ppm, and the drift is around 10ppb.
It seems that this performance is much better than the usual performance of the Amateur radio transceivers that report on the WSPR network, so the frequency reports can be used to measure the error of the frequency references in these Amateur radio transceivers. Noting that at 27MHz my Hermes-Lite is 3Hz low in frequency, I have determined a correction of -0.782Hz for my WSPR frequency, so I have chosen to take my transmission frequency as 7040099.218Hz when doing the calculations. This is probably accurate to a few tens of ppb.
I wanted to do a statistic of the distribution of the error in the frequency references of the WSPR receivers. To do this, I’ve decided that it’s better to first do, for each reporter, an average of the frequency of its reports, and then take this average as the frequency measured by that reporter. Then I do a histogram of the errors in the frequency reported by each reporter. The first average is done because there are some reporters which have a great number of reports with a very similar frequency (because their receiver might have an error, but it doesn’t drift much), and so the histogram would be biased with these reports if I just plotted the histogram of all the frequency reports. The histogram is shown below.
Frequency error of WSPR reporters
I find this histogram rather surprising. I expected to get a normal distribution or something similar, or at least a symmetric histogram centred on an error of 0ppm. However, the histogram is clearly skewed to the left. We conclude from this that a good number of WSPR receivers are quite accurate in frequency, and have an error of 0.5ppm or less. However, from those that are not accurate, it is much more probable that they are low in frequency (so they report me at a higher frequency).
I still have to find a good explanation for this effect. However, I have suspicions that this has something to do with the way that the frequency of a quartz crystal depends on the temperature (and this depends on the way that the crystal is cut). I have found in this document the image below.
Note that non-AT-cut crystals are low in frequency over most of the temperature range, so I can’t help but think that this is too much of a coincidence with the skew in my histogram above. Other people have pointed out that this is not so simple, as for instance the adjustment of the tuning capacitors of the crystal oscillator also plays an important role. It would be good to repeat this test in other bands and by other stations, perhaps in other parts of the world (my reporters come from Europe) and see if they also obtain a skewed histogram.
As an indication of the statistical significance of this test, I can say that a total of 2518 reports coming from 104 different reporters have been used. Just looking at these numbers is very far from doing a proper hypothesis contrast, but it is indicative that I have used a good amount of data. It is also interesting to look at the distribution of the number of reports given by each reporter. This is shown in the two histograms below (first for all numbers of reports and then for 30 reports and less).
The Python script and data used in this post are in this gist.
Lately, I have been playing around with the concept of doing acquisition and wipeoff of JT9A signals, using a locally generated replica when the transmitted message is known. These are concepts and terminologies that come from GNSS signal processing, but they can applied to many other cases.
In GNSS, most of the systems transmit a known spreading sequence using BPSK. When the signal arrives to the receiver, the frequency offset (given by Doppler and clock error) and delay are unknown. The receiver runs a search correlating against a locally generated replica signal which uses the same spreading sequence. The correlation will peak for the correct values of frequency offset and delay. The receiver then mixes the incoming signal with the replica to remove the DSSS modulation, so that only the data bits that carry the navigation message remain. This process can be understood as a matched filter that removes a lot of noise bandwidth. The procedure is called code wipeoff.
The same ideas can be applied to almost any kind of signal. A JT9A signal is a 9-FSK signal, so when trying to do an FFT to visually detect the signal in a spectrum display, the energy of the signal spreads over several bins and we lose SNR. We can generate a replica JT9A signal carrying the same message and at the same temporal delay than the signal we want to detect. Then we mix the signal with the complex conjugate of the replica. The result is a CW tone at the difference of frequencies of both signals, which we call wiped signal. This is much easier to detect in an FFT, because all the energy is concentrated in a single bin. Here I look at the procedure in detail and show an application with real world signals. Recordings and a Python script are included.
Several weeks ago, in an AMSAT EA informal meeting, Eduardo EA3GHS wondered about the possibility of using WSJT-X modes through linear transponder satellites in low Earth orbit. Of course, computer Doppler correction is a must, but even under the best circumstances we cannot assume a perfect Doppler correction. First, there are errors in the Doppler computation because the TLEs used are always measured at an earlier time and do not reflect exactly the current state of the satellite. This was the aspect that Eduardo was studying. Second, there are also errors because the computer clock is not perfect. Even a 10ms error in the computer clock can produce a noticeable error in the Doppler computation. Also, usually there is a delay between the time that the RF signal reaches the antenna and the time that the Doppler correction is computed for and applied to the signal, especially if using SDR hardware, which can have large buffers for the signal. This delay can be measured and compensated in the Doppler calculation, but this is usually not done.
Here we look at errors of the second kind. We denote by \(D(t)\) the function describing the Doppler frequency, where \(t\) is the time when the signal arrives at the antenna. We assume that the correction is not done using \(D(t)\), but rather \(D(t – \delta)\), where \(\delta\) is a small constant. Thus, a residual Doppler \(D(t)-D(t-\delta)\) is still present in the received signal. We will study this residual Doppler and how tolerant to it are several WSJT-X modes, depending on the value of \(\delta\).
The dependence of Doppler on the age of the TLEs will be studied in a later post, but it is worthy to note that the largest error made by using old TLEs is in the along-track position of the satellite, and that this effect is well modelled by offsetting the Doppler curve in time. This justifies the study of the residual Doppler \(D(t)-D(t-\delta)\).
David Rowe always insists that you should simulate the bit error rate for any modem you build. I’ve been intending to do some simulations of the decoders in gr-satellites since a while ago, and I’ve finally had some time to do so. I have simulated the performance of the LilacSat-1 decoder, both for uncoded BPSK and for the Viterbi decoder. This is just the beginning of the story, as the code can be adapted to simulate other modems. Here I describe some generalities about BER simulation in GNU Radio, the simulations I have done for LilacSat-1, and the results.
