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.

The pass was not particularly good, with a maximum elevation of a bit more than 30º, as the figure below shows. The downlink signal was not very strong, ranging between 5dB and 12dB (S+N)/N during the pass. The satellite seemed to respond well to my 5W uplink signal whenever I keyed the radio, but hearing the downlink properly was a bit tricky and I was only partially successful. The WAV recording of the downlink can be downloaded from my Google drive. It is a 48kHz WAV file with the signal centred at around 12kHz, so it can be processed directly with gr-satellites.

The Codec2 data recovered from the downlink is in lilacsat1.c2. This file can be processed with c2dec as show in this post. It produces roughly 3 minutes of audio that you can play below. Most of the time the audio is garbage, since my decoder always sends Codec2 frames whenever it receives a packet from LilacSat-1, even if the Codec2 frames in the packet are marked as invalid by the satellite. My voice is audible in several occasions.

Below you can find the best excerpt of the audio. I’m pretty satisfied with the quality. Note that this experiment has been done after Wei BG2BHC reduced the audio gain of the satellite according to David Rowe VK5DGR tests and analysis.

I have also decoded lots of telemetry (around 150 packets, some of them invalid) during this pass. I have put the decoded packets in this gist. One interesting thing about the telemetry from LilacSat-1 is that some of the packets include the GPS position of the satellite. I have added a block to gr-satellites to dump this information to a file in KML format. Currently I’m only looking at the ADCS parameters packet from the OBC, which contains the latitude, longitude and altitude already processed. However, the GPS data could probably be derived from other telemetry packets as well.

I have put the GPS data from the pass in lilacsat1.kml. The decoder stores the GPS data in /tmp/lilacsat1.kml by default. However, this is not a complete KML file. To convert it in a well-formatted KML file you need to add a header such as

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <Document>
    <name>LilacSat-1</name>
    <Style id="path">
      <LineStyle>
        <color>ff0000ff</color>
        <width>1</width>
      </LineStyle>
    </Style>
    <Placemark>
      <name>LilacSat-1</name>
      <styleUrl>#path</styleUrl>
      <LineString>
        <altitudeMode>absolute</altitudeMode>
        <coordinates>

and a matching footer such as

        </coordinates>
      </LineString>
    </Placemark>
  </Document>
</kml>

The GPS track can be seen in the map below. It seems that for some reason I didn’t receive any GPS packets during the first half of the pass.

You can compare the GPS track with the groundtrack below as computed by Gpredict from the following TLE:

1 42725U 98067ME  17155.74805754  .00008333  00000-0  12961-3 0  9998
2 42725  51.6397 100.2730 0005963 265.3626  94.6684 15.54835296  1544