CODAR is an HF radar used to measure surface ocean currents in coastal areas. Usually, it consists of a chirp which repeats every second. The chirp rate is usually on the order of 10kHz/s, and the signal is gated in small pulses so that the CODAR receiver can listen between pulses. The gating frequency can be on the order of 1kHz.
CODAR can be received by skywave many kilometers inland. Being a chirped signal, it is easy to extract the multipath information from the received signal. In this way, one can see the signal bouncing off the different layers of the ionosphere, and magnificent pictures showing the changes in the ionosphere (especially at dawn and dusk) can be obtained. For instance, see these images by Pieter Ibelings N4IP, or the image at the top of this post, which contains 48 hours worth of CODAR data.
Here I describe my approach to receiving CODAR. It uses GNU Radio for most of the signal processing, and Python with NumPy, SciPy and Matplotlib for plotting.
In that post, I described about how to receive the position data from the RS92 and plot it in Viking in real time. Since then, a few features such as FEC decoding have been added to the RS decoder software, so I have decided to give this a go again with the newer RS41. This will be a complete walk through, since some people are interested in setting up unattended decoders, perhaps running on a Raspberry Pi.
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.
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.
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.
In a previous post, I spoke about the cubesat D-SAT. The thing that first caught my attention about this satellite is its image downlink and the quality of some of the images that Mike DK3WN has managed to receive. Yesterday, Mike sent me an IQ recording of D-SAT downlinking a couple of images. After using the Groundstation software by the D-SAT team to verify that the images in the recording can be decoded, I have reverse engineered the protocol used to transmit images and added an image decoder to the D-SAT decoder in gr-satellites.
The image decoder can be tested with the dsat-image.wav recording in satellite-recordings. This WAV file contains the image below, which shows the Southwestern part of Spain and Portugal. The image was taken by D-SAT on 2017-08-17 10:09:54 UTC and received by Mike during the 19:10 UTC pass that evening.
According to the TLEs, at the time this image was taken, D-SAT was just above Rincón de la Victoria, in Málaga, passing on a North to South orbit. This means that D-SAT's camera was pointing more or less in a direction normal to the orbit.
This image is a 352x288 pixels JPEG image with a size of 13057 bytes. It took 43 seconds to transfer using D-SAT's 4k8 AF GMSK downlink (yes, the overhead is around 100%, more on that later). In the rest of this post, I detail the protocol used to transmit the images.
Back in September 26 2016, I posted an email in Spanish to the Hamnet.es mailing list detailing my proposal for an IPv6 Amateur radio network, and trying to engage people into some preliminary tests. In October 1 2016, I posted a summary (in English) of my message to the 44net mailing list. There was some discussion afterwards in the list, but no real actions were taken. Since then, no much interest in IPv6 for Amateur radio seems to have sprung. Still, I think that the time for IPv6 will come. I have collected my IPv6 for Amateur radio proposal in a page here for future reference. At least I hope that this pops up on Google searches for IPv6 and Amateur radio, since there is not much material about this on the Internet, and most of what one can find is quite dated.
D-SAT is an Italian cubesat that will demonstrate a new deorbit hardware. Apparently this system uses dedicated propulsion to make the satellite re-enter from a 500km orbit in 30 minutes. It also carries three more experiments and it was launched in June 23 together with several other small satellites. According to the information from the team, it transmits 4k8 telemetry in the 70cm band. It is not stated explicitly, but we read attentively, we see that it uses a NanoCom U482C transceiver from GOMspace.
Recently, I have seen Mike DK3WN decode very nice images from D-SAT and I have investigated a bit to see what software he is using.
The satellite team provides some decoding software through their forum, which requires registration. Version 2 of their software can be downloaded directly here using the password dsatmission. Its software is based on GNU Radio and it uses a few components from gr-satellites, namely the U482C decoder and some KISS and CSP blocks. These have been incorporated into their decoder from before gr-satellites was restructured. They include a note thanking me in the README, but I didn't ever hear from them that they were using gr-satellites. It would have been nice if they had contacted me, since this opens up many possibilities for collaboration.
Apart from that, they include a groundstation software which performs telemetry decoding and so on. Unfortunately, the groundstation software is closed-source, distributed only as an x86_64 Linux executable. This is not good for Amateur Radio. We should strive for open source software and open specifications for everything that transmits in our bands. The groundstation software is also distributed in a quite ugly manner as the remains of an Eclipse project (source code stripped, of course). However, it is interesting because it seems that this software is the same they use in their groundstation, and it supports sending commands to the satellite. Naturally, the command transmission is not implemented in the software they distribute, but it is still very interesting to have a peek and see what kinds of commands the satellite supports.
I have added a D-SAT decoder to gr-satellites. The decoder supports sending frames to their groundstation software. Here I describe how to set everything up.
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.
I am doing some BER simulations with GNU Radio (stay tuned for the next post), and during my experiments I have stumbled upon a bug in the "Decode CCSDS 27" block. This block is a Viterbi decoder for the CCSDS convolutional code with , (note that the convention used by this block is first POLYA then POLYB so it doesn't match the NASA-DSN convention nor the CCSDS/NASA-GSFC conventions, as I have mentioned in another post).
The bug consists in the block entering a "degraded" state after it has processed many symbols (on the order of several millions). In this degraded state, it doesn't decode properly, producing lots of bit errors even if no input symbols are in error. Fortunately, there is another block in GNU Radio which can decode the CCSDS convolutional code, the "CC Decoder" included in FECAPI. This block doesn't seem to suffer this issue. Here I describe how to replicate the bug, how to replace "Decode CCSDS 27" by "CC Decoder" and some other miscellaneous things related to this bug.