This Wednesday, a DSLWP-B test was done between 04:00 and 06:00 UTC. During this test, a few stations reported on Twitter that they were able to receive the JT4G signal correctly (they saw the tones on the waterfall) but decoding failed.
It turns out that the cause of the decoding failures is that the DSLWP-B clock is running a few seconds late. Thus, the JT4G transmission starts several seconds after the start of the UTC minute and so the decoding fails, since WSJT-X only searchs for a time offset of a few seconds.
Yesterday I tried to detect DSLWP-B using my 7 element Arrow satellite yagi. The test schedule for DSLWP-B was as follows: active between 21:00 and 23:00 UTC on 2018-06-22. GMSK telemetry transmitted both on 435.4MHz and 436.4MHz. JT4G only on 435.4MHz every 10 minutes starting at 21:10. The idea was to record the tests with my equipment and the run my JT4G detector, which should be able to detect very weak signals. Today I have processed the recorded data and I have obtained a clear detection of one of the JT4G transmissions (albeit with a small SNR margin). This shows that it is possible to detect DSLWP-B with very modest equipment.
Last week I presented a JT4G detection algorithm intended to detect very weak signals from DSLWP-B, down to -25dB SNR in 2500Hz. I have now processed the recordings of yesterday’s transmissions with this algorithm and here I look at the results. I have also made a Python script with the algorithm so that people can process their recordings easily. Instructions are included in this post.
Now that DSLWP-B has already been for 17 days in lunar orbit, there have been several tests of the 70cm Amateur Radio payload, using 250bps GMSK with an r=1/2 turbo code. Several stations have received and decoded these transmissions successfully, ranging from the 25m radiotelescope at PI9CAM in Dwingeloo, the Netherlands (see recordings here) and the old 12m Inmarsat C-band dish in Shahe, Beijing, to much more modest stations such as DK3WN‘s, with a 15.4dBic 20-element crossed yagi in RHCP. The notices for future tests are published in Wei Mingchuan BG2BHC’s twitter account.
As far as I know, there have been no tests using JT4G yet. According to the documentation of WSJT-X 1.9.0, JT4G can be decoded down to -17dB SNR measured in 2.5kHz bandwidth. However, if we don’t insist on decoding the data, but only detecting the signal, much weaker signals can be detected. The algorithm presented here achieves reliable detections down to about -25dB SNR, or 9dB C/N0.
This possibility is very interesting, because it enables very modest stations to detect signals from DSLWP-B. In comparison, the r=1/2 turbo code can achieve decodes down to 1dB Eb/N0, or 25dB C/N0. In theory, this makes detection of JT4G signals 16dB easier than decoding the GMSK telemetry. Thus, very small stations should be able to detect JT4G signals from DSLWP-B.
Continuing with my research on using WSJT-X modes through linear transponder satellites in low Earth orbit (see part I and part II), a few days ago I transmitted and recorded an FT8 signal through the V/U linear transponder on FO-29 during a complete pass. The recording started at 2017/10/23 20:26:00 UTC and ended at 20:42:30 UTC. It was made with a FUNcube Dongle Pro+ set to a centre frequency of 435.850MHz and connected to a handheld Arrow satellite yagi through a duplexer. Here the duplexer was used to avoid desense on transmit.
An FT8 signal was transmitted on every even period during the recording, at a fixed frequency of 145.990MHz, using a Yaesu FT-817ND and the Arrow antenna. The signal was transmitted using lower sideband (i.e., inverted in the frequency domain) to get a correct FT8 signal through the inverting transponder. The transmit power was adjusted often to get a reasonable signal through the transponder and avoid using excessive power. There have been reports and complaints of people using too much power with digital modes through linear satellites. In this post, a study of the power is included to show that it is possible to use digital modes effectively without putting any pressure on the satellite’s transponder.
Out of the 33 even periods, a total of 24 can be decoded by WSJT-X using the best TLEs from Space-Track. No measures were taken to correct for the time offset \(\delta\) that has been studied in the previous posts, as the TLEs already provided a good Doppler correction. Regarding the choice of TLEs, there are still some remarks to make. First, the epoch of the TLEs used was 2017/10/23 21:39:16 UTC, so these TLEs were actually taken after the pass. The previous TLEs were taken a few hours before the pass, and it is likely that they also provided a good correction, perhaps by using a time offset \(\delta\) if necessary. However, I do not know if these previous TLEs were also available from CelesTrak before the start of the pass, as it seems that TLEs take a while to propagate from Space-Track to Celestrack. To explain why the TLEs with no time offset correction are enough, it will be interesting to study the rate of change of TLE parameters for FO-29. This will be done in a future post.
The results of this test look very promising. Even though this wasn’t an overhead pass (the maximum elevation was 40º), the maximum rate of change of the Doppler was over 20Hz/s for the self-Doppler seen on the FT8 signal and 35Hz/s for the downlink Doppler seen on the CW beacon. Most of the periods which couldn’t be decoded were near the start or end of the pass. This is the only test that I know of that has decoded FT8 signals in the presence of high rates of change of Doppler. The previous tests by other people were made at low elevations, where the rate of change of Doppler is small. This test has shown that it is possible to get many decodes with high rates of change of Doppler, even using no corrections to the TLEs. Here I continue with a detailed analysis of the recording.
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.
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.
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)\).
