gnuradio – Page 10 – Daniel Estévez

D-SAT image downlink

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.

Image of Spain and Portugal taken by D-SAT

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 352×288 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.

D-SAT support added to gr-satellites

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.

BER simulation in GNU Radio

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.

Degradation bug in GNU Radio “Decode CCSDS 27”

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 \(r=1/2\), \(k=7\) (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.

Viterbi decoding for NanoCom U482C

The NanoCom U482C is a a transceiver made by GOMspace intended for cubesats and other small satellites. Currently, it seems to be out of production, since it has been superseded by the newer NanoCom AX100, but nevertheless the U482C is being flown in new satellites, such as the QB50 AU03 INSPIRE-2. The U482C is also used in GOMspace’s cubesat GOMX-1, so we may say that GOMX-1 is the reference satellite for U482C.

My gr-satellites project includes a partially reverse-engineered U482C decoder which is able to decode GOMX-1 and several other satellites. It does CCSDS descrambling and Reed-Solomon decoding. Recently, Jan PE0SAT made a recording of INSPIRE-2. I tried to decode it with gr-satellites and although the signal was very good, the Reed-Solomon decoder failed. The history behind this recording is interesting. After being released from the ISS near the end of May, INSPIRE-2 wasn’t transmitting as it should. The satellite team got in contact with Amateurs having powerful stations to try to telecommand the satellite and get it transmitting. Eventually, the CAMRAS 25m dish was used to telecommand and activate INSPIRE-2. Later, Jan made a recording from his groundstation.

After exchanging some emails with the satellite team, I learnt that the U482C also supports an \(r=1/2\), \(k=7\) convolutional code, which is used by INSPIRE-2 but not by other satellite I’ve seen. I have added Viterbi decoding support for the U482C decoder in gr-satellites, so that INSPIRE-2 can now be decoded. Here I describe some details of the implementation.

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.

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.

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.