Software – Page 16 – Daniel Estévez

A first look at DSLWP SSDV downlink

The Chang’e 4 is a Chinese lunar mission that will land a rover on the far side of the Moon by the end of 2018. To support this mission, the Chang’e 4 relay satellite will be launched six months before and put into a halo orbit around the Earth-Moon Lagrange L2 point. The relay will provide four 256Kbps links with the rover and lander on X-band and a 2Mbps link with Earth on S-band using a 4.2m dish. Two CE-4 microsatellites will be launched together with the relay satellite. They will be put in a 200km x 9000km lunar elliptical orbit. The main mission of the CE-4 microsatellites is to perform HF interferometry of celestial bodies, using the Moon as a shield from the radiation of the Sun and Earth. The satellites also carry an Amateur radio system called DSLWP, which will provide telecommand, telemetry and image downlink.

A team at Harbin Institute of Technology is currently designing the Amateur radio payload. As it is the case with previous HIT satellites such as BY70-1 and LilacSat-1, the payload will have a camera which can be telecommanded by radio Amateurs, which can use it to take and download pictures. Yesterday, Wei BG2BHC has released some work in progress of the image downlink. Many important parts of the downlink will still change, but releasing the work in progress at this early stage is a very good idea. Probably it is not too late in the development process so that the Amateur community can contribute with ideas and improvements.

The release consists of an IQ recording of the signal containing a full image and a decoder in gr-lilacsat. The IQ recording is at 2ksamp/s, since the signal is FSK at 250baud. Note that the recording is almost 32 minutes long. It takes a while to transmit an image at such a low rate. However, a low baudrate and a good amount of FEC are needed for an effective downlink from the Moon, given the huge path loss of around 197dB in the 70cm band.

The good news about this work in progress is that SSDV is now used to transmit the image. SSDV is a packetised protocol based on JPEG, but which is tolerant to packet loss. In contrast, BY70-1 and LilacSat-1 send JPEG images in 64byte chunks, and a single lost chunk can destroy the image completely. SSDV was originally developed to transmit images from Amateur high altitude ballons, so it is a good idea to use it also for DSLWP.

The bad news is that the way that SSDV has been included into the downlink protocol is not very optimal. In the rest of this post I do an in-depth look at the protocol, point out the main problems and suggest some solutions. Hopefully the protocol can still be modified and improved.

LilacSat-1 image downlink

Yesterday, Wei BG2BHC posted on Twitter an IQ recording of LilacSat-1 sending an image. LilacSat-1 has an onboard camera and it can send images using the same format as BY70-1. However, one has to keep in mind that in LilacSat-1 the Codec2 frames and the KISS stream with telemetry and image packets are multiplexed as described here, whereas BY70-1 only transmitted the KISS stream with telemetry and image packets. As in the case of BY70-1, the camera is potentially open to telecommand by all Amateurs, although it seems that system is not enabled yet.

The signal in Wei’s recording is very strong and stable, about 20dB SNR in its natural bandwidth of 13kHz. Therefore, it is no surprise that the image can be decoded without errors.

When BY70-1 was in orbit, it was quite difficult for an Amateur station to get a perfect decode of the image, since a single fade in the signal would completely corrupt the JPEG file. LilacSat-1 doesn’t seem particularly stronger than BY70-1, so the same degree of difficulty can be expected. Of course, a well equipped groundstation such as the one in Harbin Institute of Technollogy will have no problems to get a good decode, as shown by this IQ recording. Amateurs with more modest stations should resort to a collaborative effort to try to combine the different packets that form the image, as received by several stations. Currently this procedure can only be partially automated by software, because the CRC algorithm used in LilacSat-1 is not publicly known, so it is not possible to check the packets for bit errors.

The image transmitted by LilacSat-1 can be seen above. Its size is 13861 bytes and it took 217 camera packets and 1 minute and 26 seconds to transmit. This is pretty good, as it means that several images can be taken and transmitted during a pass.

Recall that the downlink of LilacSat-1 transmits at 4800bps, but 1400bps are taken for Codec2, leaving 3400bps for the KISS stream containing image packets (and telemetry packets). Each camera packet contains a 64 byte JPEG chunk, but taking into account headers it is 87 bytes long. We also need to take into account the overhead of the KISS stream. Assuming that no bytes have to be escaped, we just need to include 2 extra bytes for the frame delimiters, so a camera packet takes 89 bytes from the KISS stream and so it takes 197ms to transmit. This means that the image above could have been sent in only 43 seconds. All the extra time is probably due to the fact that the image was sent interleaved with many telemetry packets, although it would be interesting to examine if the KISS stream was in fact completely busy all the time during the image download.

The complete telemetry log decoded from this recording is in this gist. I have also taken the GPS data from the telemetry and plotted it in the map below. The position of the Harbin Institute of Technology, where the recording was made, is also shown.

A 48kHz WAV file extracted from the recording has been included in satellite-recordings. It can be fed directly to the gr-satellites LilacSat-1 decoder.

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.

Testing LilacSat-1 Codec2 downlink and GPS telemetry

Today I’ve finally had some time to test the LilacSat-1 Codec2 downlink on the air. I’ve been transmitting and listening to myself on the downlink during the 17:16 UTC pass over Europe from locator IN80do. The equipment used is a Yaesu FT-2D for the FM uplink, a FUNcube Dongle Pro+ and my decoder from gr-satellites for the downlink, and a handheld Arrow satellite yagi (3 elements on VHF and 7 elements on UHF). Here I describe the results of my test.

A tour of QB50

The QB50 project consists in a constellation of cubesats with the goal of studying the thermosphere. The cubesats are built by different universities around the world and each of them carries one of three different scientific instruments. A total of 36 cubesats have been built for the QB50 project. All of them transmit on the 70cm Amateur satellite band. A total of 28 were launched to the ISS on April 18th on the Cygnus CRS-7 resupply ship. Over the last two weeks, they have been released from the ISS. The complete launch schedule and radio information can be found here (note that the launches on May 23rd were delayed due to an unforeseen EVA). Several other non-QB50 cubesats, some of them transmitting in the Amateur bands, have also been released together with the QB50 satellites. This is probably the time that more Amateur satellite have been released at the same time. The satellites have not separated much yet, giving a great opportunity to record a single pass and analyse the telemetry of all the satellites.

A few days after the release of all the 28 QB50 cubesats, on May 29th at 18:25:29 UTC, I made an SDR recording of the complete pass of all the cubesats. The recording spans the 3MHz of the 70cm Amateur satellite band (435-438MHz) and lasts 23 minutes and 08 seconds. It was made from locator IN80do using a 7 element handheld yagi (the Arrow satellite yagi) held in the vertical polarization and a LimeSDR. The gain of the LimeSDR was set to maximum, but no external LNA was used. Here I look at the recording, list the satellites heard, and decode their telemetry.

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.