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.
- Decodificación de satélites digitales
- Linrad: qué es, estructura, funcionamiento y ajuste de filtros
He grabado las charlas usando mi cámara. El enfoque y la exposición no son muy buenos, pero he editado el vídeo incluyendo encima las imágenes de las diapositivas, lo que facilita seguir el vídeo de la charla. Por contra, las demostraciones en directo en la charla de Linrad se ven un poco mal.
Actualización: David EA1FAQ también hizo grabaciones de las charlas. En sus grabaciones se ve mejor el proyector, por lo que las demostraciones en directo durante la charla de Linrad se siguen mejor. Incluyo links más abajo.
Grabaciones con diapositivas por EA4GPZ
Grabaciones por EA1FAQ
Having to deal with DSP texts written by engineers, I have sometimes to work a bit to get a good grasp the concepts, which many times are not explained clearly from their mathematical bases. Often, a formula is just used without much motivation. Lately, I've been trying to understand critically damped systems, in the context of PLL loop filters.
The issue is as follows. In a second order filter there is a damping parameter . The impulse response of the filter is an exponentially decaying sinusoid if (underdamped system), a decaying exponential if (overdamped system) and something of the form if (critically damped system). Critical damping is desirable in many cases because it maximizes the exponential decay rate of the impulse response. However, many engineering texts just go and choose without any justification and even call this critical damping. Here I give some motivation starting with the basics and explain what is special about and why one may want to choose this value in applications.
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.
Last Monday I did a recording for the HamSci eclipse 2017 HF wideband recording experiment. I used my Hermes-Lite 2.0beta2 to record three 384kHz slices: the 40m band, the 30m band and the 20m band, from 14:00 to 22:00UTC. The 3 band recording in Digital RF format has a size of 248GB, so I'm still compressing the data to upload it to Zenodo.
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.
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.
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.
Update 29/08/2017: I have finished uploading the IQ recordings to Zenodo. These are found at:
More than a year ago, I spoke about my efforts to decode ÑuSat-1 and -2. I got as far as reverse-engineering the syncword and packet length, and I conjectured that the last 4 bytes of the packet were a CRC, but without the scrambler algorithm I couldn't do much. Recently I've been exchanging some emails with Gerardo Richarte from Satellogic, which is the company behind the ÑuSat satellites. He has been able to provide me the details of the protocol that I wasn't able to reverse engineer. The result of this exchange is that a complete decoder for ÑuSat-1 and -2 is now included in gr-satellites, together with an example recording. The beacon format is still unknown, but there is some ASCII data in the beacon. Here I summarise the technical details of the protocol used by ÑuSat. Thanks to Gerardo for his help and to Mike DK3WN for insisting into getting this job eventually done.
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.
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.