Posts – Page 43 – Daniel Estévez

Decoding AO-40 uncoded telemetry

AO-40 is an Amateur satellite that was active between 2000 and 2004. It had several transponders and beacons covering many bands from HF to microwave and its position on a HEO orbit provided several consecutive hours of coverage each day and allowed long distance contacts. Since then, many interesting things have happened with Amateur satellites, particularly the high increase of the number of cubesats that is happening over the last few years, but even so, we haven’t seen again any other satellite with the characteristics of AO-40 nor it is to be expected in the near future.

I was quite young when AO-40 was operational, so for me this is all history. However, Pieter N4IP has posted recently on Twitter some IQ recordings of AO-40 that he made back in 2003. I have been playing with these recordings to see how AO-40 was like. One of the things I’ve dong is to write my own telemetry decoder using GNU Radio.

AO-40 transmitted telemetry using 400bps BPSK. There were two modes: an uncoded mode which used no forward error correction and an experimental FEC mode proposed by Phil Karn KA9Q. The FEC mode was used later in the FUNcube satellites, and I’ve already talked about it in a previous post. The beacon in Pieter’s recordings is in uncoded mode. Here I describe this mode in detail and how my decoder works. The decoder and a small sample taken from Pieter’s recordings have already been included in gr-satellites.

Low latency decoder for LilacSat-1

LilacSat-1 is one of the QB50 project cubesats. It will be released tomorrow from the ISS. The most interesting aspect of this satellite is that it has an Amateur Radio transponder with an FM uplink on the 2m band and a Codec2 1300bps digital voice downlink on the 70cm band. It is the first time that an Amateur satellite really uses digital voice, as previous tests have only used an analog FM repeater to relay D-STAR and similar digital voice modes. LilacSat-1 however implements a Codec2 encoder in software using its ARM processor. I have talked about LilacSat-1 Codec2 downlink already in this blog. Here I present a low latency decoder for the digital voice downlink that I have recently included in gr-satellites.

gr-satellites refactored

In August last year I started my gr-satellites project as a way to make my experiments in decoding Amateur Satellite telemetry easier to use for other people. Since then, gr-satellites has become a stable project which supports 17 satellites using several different protocols. However, as time has gone by, I have been adding functionality in new GNU Radio OOT modules. Eventually, the core of gr-satellites depended on 5 OOT modules and another 7 OOT modules were used for each of the satellite families. This makes gr-satellites cumbersome to install from scratch and it also makes it difficult to track when each of the OOT modules is updated.

I have now refactored gr-satellites and included most of the OOT modules into gr-satellites, so that it is much easier to install and update. The only OOT modules I have kept separate are the following:

gr-aausat, because it doesn’t use libfec for FEC decoding, and includes its own implementation of a Viterbi and RS decoder. Eventually I would like to modify gr-aausat to make it use libfec and include it into gr-satellites.
beesat-sdr, because it is actively developed by TU Berlin and I have collaborated some code with them. Also, the implementation of the decoder is quite different from everything else in gr-satellites.
gr-lilacsat, because it is actively developed by Harbin Institute of Technology and I have collaborated some code with them. However, as I explained in a previous post, the FEC decoding for these satellites is now done very differently in gr-satellites in comparison to gr-lilacsat, as I have replaced many custom blocks by stock GNU Radio blocks. I will have to examine carefully how much code from gr-lilacsat is actually needed in gr-satellites.

The refactored version is already available in the Github repository for gr-satellites. Users updating from older versions should note that gr-satellites is now a complete GNU Radio OOT module instead of a collection of GRC flowgraphs, so it should be built and installed with cmake as usual (see the README). The GRC flowgraphs are in the apps/ folder.

The OOT modules that have been included into gr-satellites will be deprecated and no longer developed independently. I will leave their Github repositories up with a note pointing to gr-satellites.

This is not the end of the story. There are some more things I want to do with gr-satellites in the next few weeks:

Use cmake to build and install hierarchical flowgraphs, saving the user from this cumbersome step.
Use cmake to build the python scripts associated to the decoders.
Collect in a Git submodule the sample WAV files that are scattered across the different OOT modules. Add WAV samples for missing satellites. Use these WAVs to test decoders, perhaps even with some automation by a script.

And of course, there are many QB50 project satellites being launched starting next week. I’ll try to keep up and add decoders for them, especially for the ones using not so standard modes. I already have a working decoder for Duchifat-2, since I have been collaborating with their team at Herzliya Space Laboratory. I will also adapt the LilacSat-1 decoder from gr-lilacsat. This decoder has already been featured in this blog.

Quick fixes for some bugs in LimeSDR drivers

These days I have been experimenting with my LimeSDR board. This is an SDR board based on the LMS7002M transceiver chip. The drivers for the LimeSDR are called LimeSuite. This bundle contains a SoapySDR driver called SoapyLMS7, which makes the LimeSDR accessible through SoapySDR and also in GNU Radio through gr-osmosdr; some lower level drivers for the LMS7002M chip; and a GUI called LimeSuiteGUI that allows one to play with all the settings and parameters of the LMS7002M by hand.

In my tests I have come across a couple of driver-related bugs which I find quite annoying. This is not surprising, as the LMS7002M is a very complex piece of hardware and the LimeSDR drivers must control a huge number of settings and parameters and provide different interfaces to access the SDR hardware. I have reported them in the GitHub issues page of LimeSuite, but there are many other bugs open and LimeSuite is still seeing heavy development, so it doesn’t look likely that they will be fixed very soon.

To overcome this bugs, I have done some workarounds. Rather than trying to find the root cause of the problem, these disable the part of the software that is not working as it should. These workarounds are in the dirtyfixes branch of my LimeSuite fork.

The first bug I found was related to the baseband filter. This filter has a selectable bandwidth. Some bandwidths didn’t work properly, because the passband was far from flat or the cut-off frequency was way off. Moreover, just changing the bandwidth slightly sometimes produced a very different filter shape. I have been tweeting some pictures showing this effect (see also my replies to this tweet). I’ve found that the reason for this is that the parameters to tune the filter are usually cached by the drivers in order to save computations, but this cache system doesn’t work properly. My workaround is to disable the cache and always compute the filter parameters.

The second bug is related to DC spur hardware removal. We are used to the fact that many IQ SDR hardware have a (sometimes huge) DC spur in the centre of the passband, due to several hardware imperfections. This is also the case for the LimeSDR, but the LMS7002M has a hardware system (called RX DC correction) which is quite effective at removing the DC spur. I noted that DC spur removal was much better in LimeSuiteGUI than in GNU Radio or SoapySDR based applications. You can see the difference here. At first, I thought that this was an issue with the IQ calibration. However, it turns out that the RX DC correction was always being disabled by the SoapyLMS7 driver, even though it was supposed to be enabled by default. The reason for this is that a lower-level function from the LMS7002M seems to lie and says that the RX DC correction is disabled, even though it is not. I have bypassed this lower-level function in my workaround. You can see the effects of RX DC correction here.

Update: The second bug has just been fixed. It seems that the DC_BY_RXTSP bit that controls the RX DC correction was being overwritten somewhere else in the TX setup code because of a typo. I have reverted the workaround in my “dirtyfixes” branch and merged the proper fix. This branch still contains the workaround for the lowpass filter calibration.

Calibrating the Hermes-Lite 2.0 beta2 in Linrad

Lately, I have been trying to make an amplitude and phase calibration of my Hermes-Lite 2 beta2 in order to use Linrad’s smart noise blanker. This is quite a task because Linrad doesn’t support the Hermes-Lite 2 directly. Today I’ve finally managed to do it. Here I describe all my setup and calibration results.

Waterfalls from the EAPSK63 contest

Last weekend, I recorded the full EAPSK63 contest in the 40m band with the goal of monitoring IMD levels. I made a 48kHz IQ recording spanning the full 24 contest hours (from 16:00 UTC on Saturday to 16:00 UTC on Sunday). This week I’ve been playing with making waterfall plots from the recording. These are very interesting, showing patterns in propagation and contest activity. Here I show some of the waterfalls I’ve obtained, together with the Python code used to compute them.

Monitoring IMD levels in the EAPSK63 contest

This weekend I have recorded the full EAPSK63 Spanish PSK63 contest in the 40m band with the goal of playing back the recording later and reporting the stations showing excessively high IMD levels. In PSK contests, it is usual to see terribly distorted signals, which are the result of reckless operating techniques and stations which are setup inadequately. Contest rules don’t help much, as they are usually too weak to prevent distorted signals from interfering other participants. Amateurs should take care and strive to produce a signal as clean as possible. For instance, in the US, Part 97 101 a) states that “each amateur station must be operated in accordance with good engineering and good amateur practice”. Here I describe the signal processing done in this study and list a “hall of shame” of the worst stations I have spotted in my recording. I will notify by email the contest manager and all the stations in this list with the hope that the situation improves in the future.

Sending data from GNU Radio into Linrad using the network

During the last few days I’ve been experimenting with feeding signals from GNU Radio into Linrad using Linrad’s network protocol. Linrad has several network protocols designed to share data between different instances of Linrad, but generally these protocols are only supported by Linrad itself. The only other example I know of is MAP65, which can receive noise-blanked data from Linrad using the timf2 format.

The result of these experiments is a GNU Radio out-of-tree module called gr-linrad which allows to send data from GNU Radio and receive the data in Linrad. Currently, gr-linrad only supports sending a one-channel complex IQ signal using the raw 24 bit format, but I’ll probably add more options in the future. The intended application of gr-linrad is to easily add support for SDR hardware to Linrad. Usually GNU Radio has support for most SDR hardware in the market, perhaps through osmocom or other libraries. Linrad has support for a good amount of SDR hardware, but there are some notable exceptions of unsupported hardware, such as the HackRF One. I also want to use my Hermes-Lite 2.0 beta2 in Linrad, and this seems the easiest way to do it.

Another possible use of gr-linrad is as an instrumentation for any kind of GNU Radio flowgraph. It is very easy to stream data into Linrad, so it can be used as a very nice waterfall display or to do any sort of signal processing, such as noise blanking or adaptive polarization. Here I describe how to get the test flowgraph in gr-linrad working and some aspects of the network protocol.

GNU Radio decoder for AO-73

During the last few days, I have been talking with Edson PY2SDR about using GNU Radio to decode digital telemetry from AO-73 (FUNcube-1) and other FUNcube satellites. I hear that in Virginia Tech Groundstation they have a working GNU Radio decoder, but it seems they never published it.

The modulation that the FUNcube satellites use is DBPSK at 1200baud. The coding is based on a CCSDS concatenated code with a convolutional code and Reed-Solomon, but it makes extensive use of interleaving to combat the fading caused by the spin of the spacecraft. This system was originally designed by Phil Karn KA9Q for AO-40. Phil has a description of the AO-40 FEC system in his web and there is another nice description by James Miller G3RUH.

I took a glance at this documents and noted that it would be a nice and easy exercise to implement a decoder in GNU Radio, as I have most of the building blocks that are needed already working as part of gr-satellites. Today, I have implemented an out-of-tree module with a decoder for the AO-40 FEC in gr-ao40. There is another gr-ao40 project out there, but it seems incomplete. For instance, it doesn’t have any code to search for the syncword. I have also added decoders for AO-73 and UKube-1 to gr-satellites.

The signal processing in gr-ao40 is as described in the following diagram taken from G3RUH’s paper.

AO-40 FEC decoding (borrowed from G3RUH’s paper)

First, the distributed syncword is searched using a C++ custom block. It is possible to set a threshold in this block to account for several bit errors in the syncword. De-interleaving is done using another C++ custom block. For Viterbi decoding, I have used the “FEC Async Decoder” block from GNU Radio, since I like to use stock blocks when possible. Then, CCSDS descrambling is done with a hierarchical block from gr-satellites. Finally, the interleaved Reed-Solomon decoders are implemented in a C++ custom blocks that uses Phil Karn’s libfec.

The complete FEC decoder is implemented as a hierarchical block as show in the figure below.

GNU Radio AO-40 FEC decoder

An erasure code based on Vandermonde matrices

I’ve been looking at an erasure code by Luigi Rizzo which is based on Vandermonde matrices, since this code is used in Outernet. In fact, it is the code implemented by the zfec library. Luigi Rizzo describes his code in a paper from 1997, but the paper can be very confusing and misleading because it describes the mathematics in very little detail. I needed to go to the source code to understand how it works. Actually, the idea behind this code is very simple. Here I do a mathematical description of the code and show that it is the same as a Reed-Solomon code. This is rather weird, because Luigi Rizzo makes no mention of Reed-Solomon codes, which were first described in 1960.