gnuradio – Page 12 – Daniel Estévez

LilacSat-1 Codec 2 downlink

LilacSat-1 is one of the satellites that will form part of the QB50 constellation, a network of 50 cubesats built by different universities around the world that will conduct studies of the thermosphere. LilacSat-1 is Harbin Institute of Technology’s satellite in the QB50 constellation, and is expected to launch late this year. Incidentally, his “brother” LilacSat-2 launched in September 2015, and it has become a popular satellite because of its Amateur Radio FM repeater.

Apparently, LilacSat-1 will feature a very novel transponder configuration: FM uplink and Codec2 digital voice downlink. I have discovered this yesterday while browsing the last updates to the Harbin Institute of Technology gr-lilacsat github repository. In fact, there is no mention of digital voice in the IARU coordination page for LilacSat-1. According to the coordination, the transponder will be mode V/U (uplink in the 144MHz band and downlink in the 435MHz band). However, it seems that only downlink frequencies have been coordinated with IARU. Hopefully the uplink frequency will lie in the satellite subband this time. LilacSat-2 is infamous because of its uplink at 144.350MHz, which lies in the SSB subband in the Region 1.

Codec2 is the open source digital voice codec that is used in FreeDV. This makes LilacSat-1 very exciting, because Codec2 is the only codec for digital voice radio that is not riddled with patents. Moreover, it performs much better than its main competitor: the AMBE/IMBE family of codecs, which are used in D-STAR, DMR and Yaesu System Fusion. Codec2 can achieve the same voice quality as AMBE using roughly half the bitrate.

Harbin Institute of Technology has recently published a GNUradio decoder for the Codec2 downlink and an IQ recording to test the decoder. Here I take a quick look at this code and I talk a bit about the possibilities of using Codec2/FreeDV in satellites.

Introducing gr-satellites

This post is to present my gr-satellites project. The goal of this project is to make a collection of GNUradio decoders for the telemetry of different satellites. The decoders support submitting telemetry in real time to the PE0SAT telemetry server. Another goal is that the decoders are as easy to use as possible, to try to make more people interested in receiving digital telemetry from satellites and collaborating in online telemetry submission.

The decoders can be used with the Gqrx SDR software, using its UDP audio streaming capabilities. This is the easiest way to use the decoders. It is also possible to use the GNUradio frontends in the companion project gr-frontends. These support several different SDR hardware, WAV and IQ recordings, and conventional receivers connected through a soundcard. They are design to be flexible and to allow its use in headless and automated receiving configurations.

The long-term goal of this project is to provide an alternative software chain to the UZ7HO soundmodem, AGW packet engine and DK3WN telemetry forwarder. The use of GNUradio makes these decoders more configurable and flexible and eases programming decoders for non-AX.25 satellites, which usually employ strong forward error correction.

Currently, the satellites supported by gr-satellites are 3CAT-2, AAUSAT-4 and GOMX-3. I plan to continue adding support for more satellites in the future.

Decoding packets from 3CAT2

On 15th August, a Chinese CZ-2D rocket launched three satellites from Juiuquan (Mongolia). The main payload was the Chinese satellite QSS, designed to do some experiments in quantum communications and entanglement. As anything that has the word quantum on it, this satellite even made it to the mainstream news in Spain. The rocket also launched Lixing 1, another Chinese satellite which will research the upper atmosphere, and 3CAT2, from the Universidad Politècnica de Catalunya (Spain).

3CAT2’s main payload is a GNSS reflectrometer designed to measure the altitude of the Earth and map the oceans. This means that it uses reflections of satellite navigation signals off the surface of the earth and sea to perform mapping. It will mainly use the L1 and L2 signals from GPS, but it can also work with Galileo, GLONASS and BeiDou signals. It also carries a prototype of a magnetometer designed for the eLISA project. This project consists in setting up a laser interferometer in space to observe gravity waves. It is roughly the same as the Earth-based LIGO, that recently confirmed the first detections of gravity waves. However, since eLISA will be in space, its laser arms will much longer than LIGO’s. This permits to study much lower frequencies than it’s possible Earth-based interferometers.

3CAT2 has a downlink in the Amateur 2m band, at 145.970MHz, and transmits 9600bps BPSK. It also has a faster BPSK downlink in the S-band, presumably at 2401MHz (inside the Amateur 13cm band). The days following 3CAT2’s launch I tried to receive its VHF signal, without any luck. I have been in contact with other Amateurs who also listened and didn’t hear anything.

This morning, I’ve received email from Scott K4KDR telling me that he has heard the satellite for the first time and he has managed to do a recording, but he is unable to decode the data.

We where unsure about which encoding that 3CAT2 is using. It could be AX.25, or some custom protocol using FEC. As far as I know, the only other satellite that transmits 9k6 BPSK in the Amateur bands is LilacSat-2, which uses strong FEC. Nevertheless, I’ve taken a good look at Scott’s recording and I’ve been able to decode one packet. This is, as far as I’m aware, the first decoding of 3CAT2 by an Amateur operator.

KISS, HDLC, AX.25 and friends

A while ago, I uploaded my gr-kiss out-of-tree GNUradio module to Github. This is a set of blocks to handle KISS, HDLC and AX.25, which are the protocols used in amateur packet radio. There are several other OOT modules that do similar things, but I didn’t like the functionality of them very much. While programming this module, I’ve also noted that the documentation for these protocols is not so good sometimes. Here I’ll give a brief description of the protocols and explain how everything works together.

Trying to decode data from ÑuSat

Last Monday, a Chinese CZ-4B rocket launched the Chinese Earth observation satellite ZY-3 and the Argentinian satellites ÑuSat-1 and 2. These two satellites are the first of the Aleph-1 constellation of Earth observation satellites. ÑuSat-1 carries LUSEX, an Amateur payload which consists of a U/V linear transponder. Also, the two ÑuSat satellites transmit backup telemetry in the 70cm Amateur band, as one can see in the IARU frequency coordination application. In fact, the latest news is that ÑuSat-1 transmits telemetry on 436.445MHz and ÑuSat-2 uses 437.445MHz. According to the public announcements, the telemetry was supposed to be 9200 baud or 19200 baud. However, some people have noticed that, on the contrary, it is 40 kbaud. Although the modulation and coding specifications are not public, I’ve taken a look at an IQ recording of ÑuSat-2 by Mike DK3WN to see if I can decode anything. Here are my findings.

LilacSat-2 subaudio telemetry

Yesterday, the FM repeater on the Amateur satellite LilacSat-2 was active. I’ve talked about LilacSat-2 before, but so far I hadn’t made any recordings containing subaudio telemetry. While contacting several Spanish stations (EA5TT, EA1JM and EA1IW) throughout the pass, I made an IQ recording to analyse the telemetry later. Here I take a look at the telemetry format and the decoded data.

Scramblers and their implementation in GNU Radio

A scrambler is a function that is applied to a sequence of data before transmitting with the goal of making this data more “random-like”. For instance, scrambling avoids long runs of the bits 0 or 1 only, which may make the receiver loose synchronization or cause spectral concentration of the signal. The receiver applies the inverse function, which is called descrambler, to recover the original data. The documentation for the scrambler blocks in GNU Radio is not very good and one may need to take a look at the implementation of these blocks to get their parameters right. Here, I’ll try to explain a bit of the mathematics behind scramblers and the peculiarities of their implementation in GNU Radio.

Decoding packets from GOMX-3: modulation and coding

Recently, Mike DK3WN pointed me to some decoder software for the satellite GOMX-3. This satellite is a 3U cubesat from GomSpace and transmits in the 70cm Amateur band. It has an ADS-B receiver on board, as well as an L-band SDR. As far as I know, no Amateur has decoded packets from this satellite previously, and Mike had some problems running the decoder software. I have taken a look at the software and tried my best to decode some packets from GOMX-3. So far, I have been able to do Reed-Solomon decoding and get CSP packets. However, I don’t have the precise details for the beacon format yet. Here, I describe all of my findings.

A bunch of data from AAUSAT-4

Recently, I have published a Gnuradio AAUSAT-4 decoder in Github. It is based on software from the university team, but several parts have been rewritten completely.

The current features of this decoder are as follows:

FEC decoding of both long frames and short frames using the code from bbctl (this code is included in the Gnuradio decoder)
CSP header parsing according to the specifications in Wikipedia
Parsing of the COM and EPS fields in telemetry beacons, using the code from the university team

In the future, I would like to be able to parse more data from the satellite, but I don’t have the format specifications. I’m trying to get the university team to send me some information.

Doppler correction with GNURadio

When receiving signals from a satellite, it can be important to correct for the Doppler shift in the signal. Normally, I use Gpredict to track satellites and compute the Doppler shift. Gpredict can control the frequency of a receiver using Hamlib to track the Doppler shift. When using an SDR receiver, there are several possible ways of using Gpredict’s frequency control.

Normally, the SDR software doesn’t support Hamlib control in a way that it’s useful and easy to use for this purpose. This is the case with Linrad, which is the software I use, and probably with many other popular SDR softwares. An easy solution is to let Gpredict completely control the frequency of the SDR receiver through Hamlib and prevent the SDR software from controlling the frequency. With the FUNCube Dongle Pro+, which is the receiver I normally use, this is easy to do. It can be controlled without problem with recent versions of Hamlib, and if you set the dongle in Linrad as an “Undefined” card instead of a FUNCube Dongle, then Linrad will not try to control its frequency.

The problem with this solution is that each time that the frequency gets updated, it does so in a non phase continuous manner, because the PLL of the receiver has to lock on to the new frequency, effectively losing reception for just a tiny amount of time. This supposes no problem for SSB, CW or FM reception, because your ears just don’t notice. However, if you want to receive any digital signal or SSTV, the frequency change usually messes with the decoder software, which loses sync and suffers decoding problems. An alternative solution is to leave the receiver frequency fixed and correct for Doppler shift in software.