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.

The GNUradio decoder is included in the gr-lilacsat out-of-tree module. The IQ recording of the downlink is linked in the Readme file. In case you want to process this recording using other tools, you should know that it is raw IQ data with 2 channels of little-endian 32bit floats at 250kHz sampling rate.

The modulation used for the downlink is 9k6 BPSK, the same as LilacSat-2. An \(r=1/2\), \(k=7\) convolutional code is used as FEC (the same code as LilacSat-2). However, Reed-Solomon is not used. This leaves us a useful bitrate of 4800bps. Not using Reed-Solomon is a good idea, because a 255 byte Reed-Solomon block would take 425ms to transmit, which would introduce too much latency for digital voice use.

The variant of Codec2 used is Codec2 1300. This is a 1300bps codec, and it is the same variant that is used in the FreeDV 1600 mode, which is the “higher quality” mode for FreeDV in the HF bands. This codec is also being used in the modes FreeDV 2400A and 2400B, which are currently in an advanced stage of development and are intended for the VHF and UHF bands. Although Codec2 1300 is far from sounding natural (as it is the case for the AMBE codecs), the common opinion is that Codec2 1300 sounds OK and it is easy to copy without effort. In fact, the developers of FreeDV could have aimed for a higher bitrate variant when designing the modes for VHF, but they decided to keep the same bitrate as in HF and aim for much better performance in terms of SNR than FM and the other digital voice modes.

Below you can see the recording being played in Linrad. There are two bursts of data and the BPSK signal is about 13kHz wide.

To decode the recording, you have to start examples/demod_lilacsat-1.grc and then open examples/replay_lilacsat1_rx.grc, point it to the correct recording path and run it. The recording will be processed in real time and the digital voice audio should start when the first data burst is played back. Below you can hear a recording of the digital voice audio. The first 19 seconds are valid voice data and the rest is garbage. It seems that the first burst, which is 20 seconds long contains the valid Codec2 data and the second is either garbage or contains some other kind of data that for some reason gets sent to the Codec2 decoder.

It’s interesting to compare this audio with the recordings I made almost year ago during the European FreeDV net (actually that was the first post of this blog, so this blog will soon turn 1 year).

Note that only 1300bps are spent in the digital voice codec. Taking into account any reasonable amount of framing, there are still many spare bits until reaching the 4800bps of data that the 9k6 BPSK signal with \(r=1/2\) FEC offers. I think that these spare bits will probably be used for telemetry. However, this seems quite a high rate for telemetry. I’m not sure why they have chosen to use Codec2 1300. They could have opted for Codec2 2400 or even 3200, which sound much better and still leave room for telemetry.

Another design choice which is curious is the FM uplink. I think it would be much more desirable to have a Codec2 uplink as well. Codec2 1300 performs very well with a good microphone in a quite environment. However, as any low bitrate voice codec, it starts to fail miserably if there is background noise. I’m afraid that you’ll need to put a strong FM signal into LilacSat-1, or else the Codec2 downlink will be very difficult to copy, as Codec2 will have to struggle to encode in the best possible way the noisy analog audio signal that the satellite hears. Time will tell how well this works.

I get that the advantage of this configuration is that you can use any inexpensive handheld or mobile FM radio for the uplink and an RTLSDR or other SDR receiver for the downlink, so it’s not technically that difficult to work this transponder. However, this transponder isn’t very friendly for portable operations. You need a computer or tablet running GNUradio to decode the downlink. The SM1000 (even with modified software) and a conventional SSB receiver can’t be used because the BPSK signal is too wide.

A Codec2 uplink also has the advantage that the satellite doesn’t need to do any Codec2 work, it only needs to move bits around. With the FM uplink, the Codec2 encoding has to be done at the satellite. This is impressive: they’ve managed to fit a Codec2 encoder into a 2U cubesat that already has to carry the QB50 science payloads. I think that it’s also the first time that an Amateur radio satellite will carry a digital voice codec. The previous satellites that I know that have been used for digital voice only did repeating of the signal at the analog level in the case of AO-27 and D-STAR, and as far as I know the D-STAR satellite OUFTI-1 was only supposed to move bits around, although it never got to work.

I think that the transponder of LilacSat-1 is good as a first step for getting Codec2 and FreeDV into space, but there is many room for interesting ideas that could be implemented. I have already said that, with the 9k6 BPSK downlink using in LilacSat-1 a higher Codec2 bitrate could be used for better voice quality. A more interesting alternative is to pack two (or even three) Codec2 1300 streams into the downlink. These open up many new possibilities. One of the streams could be used for a store and forward system that loops over the last N seconds that where uploaded to the system. If you keep the FM uplink, you can use a special CTCSS tone to mark that the voice should be recorded into the store and forward system. If you change to a Codec2 uplink, you can use some of the free bits in the protocol to signal this. This can’t be used to make QSOs but it will surely be fun to use, especially in areas where the activity in this satellite is low (I expect that not that many people will try to work this satellite, as it is usually the case with satellites using non-conventional modes).

Apart from the store and forward system, the obvious application for several Codec2 streams in the downlink is to support several concurrent QSOs. The uplink could do frequency division multiplexing and have a different frequency for each of the streams (I think that two streams are probably more than enough). Also, each of the uplink frequencies could support different modes (preferably with automatic mode selection). You can support FM uplink to allow for the possibility of using inexpensive uplink radios.

Both FreeDV 2400A and 2400B could also be used for the uplink. FreeDV 2400B can be used with conventional FM radios, so given that you already need a computer to decode the downlink, it doesn’t complicate the station setup much. FreeDV 2400A only works with SDR transmitters, but it gives much better performance. Also, since the uplink is in the 144MHz band, the SM2000, which is still in development, could be used for the uplink. It would be very interesting to test how well does FreeDV 2400A perform, especially with only the 1W of power that the SM2000 gives. FreeDV 2400A and B are FSK modes, so I expect that they will work well regarding Doppler. The FreeDV 1600 mode is an FDM modem using QPSK subcarriers, so it is quite sensible to tuning and it will probably give problems with Doppler (and this is specially bad in the uplink, since you don’t have good feedback to compensate for the Doppler shift).

There is also the possibility of using another modulation. For instance, the 1600bps that the FreeDV 1600 mode uses could be transmitted as a 1k6 BPSK signal. This signal is narrow enough to be transmitted with a conventional SSB transmitter.

And I haven’t talked about FEC yet. Perhaps you want some strong FEC in the uplink, similar to the downlink FEC (note that the FreeDV 1600 mode already includes some Golay FEC). You can use the spare bits in the FreeDV 2400A and B modes for FEC. You could drop the codec bitrate and use Codec2 700B, which is the codec used in FreeDV 700B, the lower quality but higher SNR performance mode for FreeDV on HF. The Codec2 700B stream can be protected by a convolutional code. With a \(r=1/2\) code you would have 1400bps, which is comparable to Codec2 1300. Moreover, there is no need for the satellite to decode the convolutional code. It can repeat the convolutional coded Codec2 stream and leave decoding to the groundstations. You could also keep Codec2 1300 and use a higher bitrate: some sort of FreeDV 4800 mode, and use the extra bits for convolutional coding. The possibilities are endless.

A good thing about all these ideas is that you don’t even need a satellite to have fun with them. You can fit the appropriate software in a single board computer and use an SDR such as the HackRF or LimeSDR to set up a cross band Codec2 repeater supporting many different modes. Bring this up to a repeater site and it will surely be an interesting experiment for the local users.