satellites – Page 31 – Daniel Estévez

GNU Radio decoder for AO-73

During the last few days, I have been talking with Edson PY2SDR about using GNU Radio to decode digital telemetry from AO-73 (FUNcube-1) and other FUNcube satellites. I hear that in Virginia Tech Groundstation they have a working GNU Radio decoder, but it seems they never published it.

The modulation that the FUNcube satellites use is DBPSK at 1200baud. The coding is based on a CCSDS concatenated code with a convolutional code and Reed-Solomon, but it makes extensive use of interleaving to combat the fading caused by the spin of the spacecraft. This system was originally designed by Phil Karn KA9Q for AO-40. Phil has a description of the AO-40 FEC system in his web and there is another nice description by James Miller G3RUH.

I took a glance at this documents and noted that it would be a nice and easy exercise to implement a decoder in GNU Radio, as I have most of the building blocks that are needed already working as part of gr-satellites. Today, I have implemented an out-of-tree module with a decoder for the AO-40 FEC in gr-ao40. There is another gr-ao40 project out there, but it seems incomplete. For instance, it doesn’t have any code to search for the syncword. I have also added decoders for AO-73 and UKube-1 to gr-satellites.

The signal processing in gr-ao40 is as described in the following diagram taken from G3RUH’s paper.

AO-40 FEC decoding (borrowed from G3RUH’s paper)

First, the distributed syncword is searched using a C++ custom block. It is possible to set a threshold in this block to account for several bit errors in the syncword. De-interleaving is done using another C++ custom block. For Viterbi decoding, I have used the “FEC Async Decoder” block from GNU Radio, since I like to use stock blocks when possible. Then, CCSDS descrambling is done with a hierarchical block from gr-satellites. Finally, the interleaved Reed-Solomon decoders are implemented in a C++ custom blocks that uses Phil Karn’s libfec.

The complete FEC decoder is implemented as a hierarchical block as show in the figure below.

GNU Radio AO-40 FEC decoder

Open telecommand for BY70-1

Recently, Wei BG2BHC has published instructions for the use of BY70-1’s camera by Amateurs. Essentially, there are three commands that can be used: 0x00 to take a picture and send it, 0x55 to take a picture and store it in memory, and 0xaa to send the picture stored in memory. He also gives the modulation and coding details for the commands. They use AX.25 with 1000baud FM-AFSK with tones at 1000Hz and 1833.33Hz. The AX.25 frames are UI frames containing a single byte with the command (0x00, 0x55 or 0xaa as described above). For ease of use, he also gives WAV recordings of the three commands, so they can be played back easily into an FM transmitter by any Amateur. Here I look at the contents of these WAV files and how to process and create this kind of packets.

Coding for HIT satellites (and other CCSDS satellites)

The Harbin Institute of Technology satellites LilacSat-2, BY70-1 and the upcoming LilacSat-1 all use a concatenated code with an \(r=1/2, k=7\) convolutional code and a (255,223) Reed-Solomon code according to the CCSDS TM Synchronization and Channel Coding blue book specifications. The GNU Radio decoder gr-lilacsat by Wei BG2BHC includes a custom implementation of the relevant part of the CCSDS stack, probably ported into GNU Radio from some other software.

Recently, I have been working on decoding KS-1Q and I’ve seen that it uses the same CCSDS coding as the HIT satellites. This has made me realise that most of this CCSDS coding can be processed using stock GNU Radio blocks, without the need for custom blocks. The only exception is Reed-Solomon decoding. This can be done easily with gr-libfec, which provides an easy interface from GNU Radio to Phil Karn’s libfec. Here I look at the details of the CCSDS coding and how to process it with GNU Radio. I’ve updated the decoders in gr-satellites to use this kind of processing. I’ll also talk about the small advantages of doing it in this way versus using the custom implementation in gr-lilacsat.

KS-1Q decoded

In a previous post, I talked about my attempts to decode KS-1Q. Lately, WarMonkey, who is part of the satellite team, has been giving me some extra information and finally I have been able to decode the packets from the satellite. The decoder is in gr-ks1q, together with a sample recording contributed by Scott K4KDR. I’ve also added support for KS-1Q in gr-satellites. Here I look at the coding of the packets in more detail.

First data from BY70-1

The Amateur satellite BY70-1 launched yesterday at around 3:00UTC. The launch was a partial failure, as all the satellites from this launch have been put in a 520x220km orbit. The perigee is too low to support a long duration orbit, and the satellites will decay in a couple months. BY70-1 has a 9k6 BPSK telemetry downlink on 70cm. This downlink is also used to download JPEG images from the onboard camera. I’ve talked about this in a previous post.

Since I’m at 33C3, I haven’t been able to receive this satellite with my own equipment yet. However, Tetsu JA0CAW already has posted some IQ recordings. Here I look at recording1 and recording2.

My first impression is that the packets are not very strong. I don’t know if this is something about JA0CAW’s station or that the downlink of BY70-1 is not very strong. I’ve only managed to decode the strongest packets in the recording. In comparison, LilacSat-2 has a very strong downlink and I can decode correctly almost from horizon to horizon with a handheld 7 element yagi.

Perhaps it’s possible to do some optimization of the decoder parameters such as filter width or loop bandwidths, but so far I haven’t experimented much. I just wanted to write a quick post to publish all the information I’ve managed to decode. I’m using the decoder from gr-satellites. The decoder log from recording1 is in this gist. From recording2 I could only decode a couple of JPEG packets and no telemetry packets.

There are three distinct types of telemetry packets. It seems that BY70-1 transmits all the three types in a single burst. Another curiosity: the message in one of the telemetry packets uses the callsign ON02CN, which is the Belgian callsign that LilacSat-1 will use. Since LilacSat-1 is part of the QB50 project, it makes sense that it uses a Belgian callsign. However, it seems that it’s some sort of software configuration error that BY70-1 is also using this callsign.

Update on 30/12/2016: I have found that there was a problem with the Costas loop bandwidth in the GNU Radio receiver on gr-satellites. Its value was too large. I have copied the value from the example demodulator on gr-lilacsat and now the decoder works much better. I have even been able to decode the following image from recording2.

The result looks pretty bad, but the keen eye will notice that in fact there are few packets lost in this JPEG image. Compare with the image posted by BG2BHC, which has no errors and is presumably the same image.

Looking at BY70-1 image downlink

BY70-1 is a Chinese Amateur satellite that will launch on Monday 26 December. It has a V/U FM repeater, a camera and a 9k6 BPSK downlink on 70cm that transmits telemetry and the JPEG images taken by the camera. The BPSK downlink uses the same modulation and coding as LilacSat-2, of which I have spoken several times. Recently, Wei MingChuan BG2BHC has added support for the image downlink of BY70-1 to gr-lilacsat and a bit stream recording to test the image receiver.

Unfortunately, the image decoder is closed-source, as it contains some certification methods used to avoid fake packets over the internet. However, Wei gave me a brief description of how the image downlink protocol works. After seeing the closed-source decoder running, I had enough to figure out how the protocol works. I have implemented an open-source image decoder as a python GNU Radio block. It is in my gr-lilacsat fork, and it will soon be included in the upstream gr-lilacsat repository. Here I look at the protocol used for the image downlink.

About KS-1Q

In a previous post, I talked about the satellite CAS-2T on a recent Chinese launch. CAS-2T was designed to remain attached to the upper stage of the rocket and decay in a few days. However, due to an error in the launch, the upper stage of the rocket and CAS-2T where put on a long-term 1000km x 500km elliptical orbit. A few days after launch we learned that another satellite, called KS-1Q was also attached to the same upper stage of the rocket. This satellite transmits telemetry on the 70cm Amateur Satellite band.

I haven’t been able to completely decode telemetry from KS-1Q yet, mostly because the satellite team hasn’t given many technical details about the telemetry format. There is a technical brochure in Chinese, but it is not publicly available. I have asked the team if they could send me a copy, but they haven’t replied. Here I report my findings so far in case someone finds them useful.

Some measurements of CAS-2T on orbit 25

Last Thursday, a CZ-11 Chinese rocket launched from Jiuquan. Alan Kung BA1DU posted in amsat-bb some minutes after launch saying that this launch contains an Amateur payload: CAS-2T. As it is usual with Chinese Amateur satellites, little information is available publicly and we hadn’t heard about CAS-2T before.

According to BA1DU, CAS-2T is a 2U Cubesat with a CW beacon on 70cm and a V/U FM transponder. The satellite will not separate from the upper stage of the rocket, so it will decay between 10 and 30 days before launch. However, this is not correct. After launch, CAS-2T was identified as object 2016-066E by Mike Rupprecht DK3WN using Doppler measurements. This object is on a 1030km x 500km elliptical orbit, so it will not decay soon. Apparently, due to a problem in the launch, the upper stage of the rocket has being put in this 10 year+ orbit. Indeed, there are radar TLEs for 6 objects from this launch. Four of them are on circular orbits of roughly 500km height, while the other two are on elliptical orbits of 1030km x 500km radius. All of these orbits will last for many years.

Reports of CAS-2T from Amateurs worldwide agree that the CW signal has good strength, but it suffers much fading. Unfortunately, the FM transponder does not function properly. It seems to respond well to an uplink signal, but it doesn’t modulate properly, as if it lacked power or suffered some other problem. On Friday afternoon, I took an SDR recording of the CW and FM signals of CAS-2T during its orbit 25. Here I show some measurements of these signals. The recording was done with a 7 element yagi and a FUNcube Dongle Pro+, and it has been Doppler corrected using the TLE for object 2016-066E, which gives a very good match.

Reverse-engineering Outernet in GNU Radio blog

I have published a post in the GNU Radio blog about my reverse engineered GNU Radio Outernet receiver gr-outernet. I cover more or less the same information as in a previous post in this blog, but I include lots of screenshots. Many thanks to Ben Hilburn and Johnathan Corgan for contacting me to write this post in the GNU Radio blog and for their useful suggestions.

Head over to the GNU Radio blog and read the post: Reverse-engineering Outernet.

Reverse engineering Outernet: modulation, coding and framing

Outernet is a company whose goal is to ease worldwide access to internet content. They aim to provide a downlink of selected internet content via geostationary satellites. Currently, they provide data streams from three Inmarsat satellites on the L-band (roughly around 1.5GHz). This gives them almost worldwide coverage. The downlink bitrate is about 2kbps or 20MB of content per day.

The downlink is used to stream files, mostly of educational or informational content, and recently it also streams some APRS data. As this is a new radio technology to play with, it is starting to get the attention of some Amateur Radio operators and other tech-savvy people.

Most of the Outernet software is open-source, except for some key parts of the receiver, which are closed-source and distributed as freeware binaries only. The details of the format of the signal are not publicly known, so the only way to receive the content is to use the Outernet closed-source binaries. Why Outernet has decided to do this escapes me. I find that this is contrary to the principles of broadcasting internet content. The protocol specifications should be public. Also, as an Amateur Radio operator, I find that it is not acceptable to work with a black box receiver of which I can’t know what kind of signal receives and how it does it. Indeed, the Amateur Radio spirit is quite related in some aspects to the Free Software movement philosophy.

For this reason, I have decided to reverse engineer the Outernet signal and protocol with the goal of publishing the details and building an open-source receiver. During the last few days, I’ve managed to reverse engineer all the specifications of the modulation, coding and framing. I’ve being posting all the development updates to my Twitter account. I’ve built a GNUradio Outernet receiver that is able to get Outernet frames from the L-band signal. The protocols used in these frames is still unknown, so there is still much reverse engineering work to do.