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.
This is a follow up post to my experiments studying OTH radar. I have found that the signal processing I did there to obtain the cross-correlation was far from optimal. This produced the strange side-bands below the main reflection. The keen reader might have noticed that I was doing the cross-correlation with a template pulse that lasted the whole pulse repetition cycle. However, the pulses from the radar are shorter. Therefore, it is a better idea to use a shorter template pulse. Ideally, the template pulse should have the same length as the transmitted pulse. However, I don’t know this length precisely, because multipath propagation makes the received pulses a bit longer. However, I think that 6.5ms is a good estimate.
I have also changed the window for the pulse. I’m now using a Dolph-Chebyshev window. I use scipy to compute this window, because it is not included in GNU Radio. This window has the property that the side-bands have constant attenuation. Indeed, it minimizes the \(L^\infty\) norm of the side-bands. There is a parameter that tunes the side-bands attenuation. For higher attenuations, you have a wider main lobe, while if you want a narrower main love you get less side-band attenuation. These properties make this window useful in radar applications.
Below I’m doing the cross-correlation in GNU Radio with a shorter template pulse shaped with a Dolph-Chebyshev window set for 55dB attenuation.
The good thing about the settable attenuation of the Dolph-Chebyshev window is that it can be used to trade-off performance between different features. First, we use an attenuation of 100dB. The side-bands are below the noise floor in this case, so we have no “false responses” in our cross-correlation. The drawback is that the main lobe is wide so the resolution of the features of the ionosphere in the image below is not very good.
Next we try with 55dB attenuation. This narrows the main lobe, improving the resolution and crispness of the features of the ionosphere in the image below. However, side-bands start being visible above the noise floor, producing “false responses”. However, comparing with the image above, we now know where the false responses are.
I have updated the gist with the GNU Radio flowgraph and python script used to produce the images.
Most amateur operators are familiar with over-the-horizon radars in the HF bands. They sometimes pop up in the Amateur bands, rendering several tens of kilohertzs unusable. Inspired by Balint Seeber’s talk in GRCon16, I’ve decided to learn more about radars. Here I look at a typical OTH radar, presumably of Russian origin. It was recorded at my station around 20:00UTC on 8 December at a frequency around 6860kHz. This radar sometimes appears inside the 40m Amateur band as well.
Some fellow Spanish Amateur Operators were talking about the use of the Opera mode as a weak signal mode for the VHF and higher bands. I have little experience with this mode, but I asked them what is the advantage of this mode and how it compares in sensitivity with the JT modes available in WSJT-X. I haven’t found many serious tests of what is the sensitivity of Opera over AWGN, so I’ve done some tests using GNU Radio to generate signals with a known SNR. Here I’ll talk about how to use GNU Radio for this purpose and the results I’ve obtained with Opera. Probably the most interesting part of the post is how to use GNU Radio, because it turns out that Opera is much less sensitive than comparable JT modes.
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.
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.
This post is to present my gr-satellites project. The goal of this project is to make a collection of GNUradio decoders for the telemetry of different satellites. The decoders support submitting telemetry in real time to the PE0SAT telemetry server. Another goal is that the decoders are as easy to use as possible, to try to make more people interested in receiving digital telemetry from satellites and collaborating in online telemetry submission.
The decoders can be used with the Gqrx SDR software, using its UDP audio streaming capabilities. This is the easiest way to use the decoders. It is also possible to use the GNUradio frontends in the companion project gr-frontends. These support several different SDR hardware, WAV and IQ recordings, and conventional receivers connected through a soundcard. They are design to be flexible and to allow its use in headless and automated receiving configurations.
The long-term goal of this project is to provide an alternative software chain to the UZ7HO soundmodem, AGW packet engine and DK3WN telemetry forwarder. The use of GNUradio makes these decoders more configurable and flexible and eases programming decoders for non-AX.25 satellites, which usually employ strong forward error correction.
Currently, the satellites supported by gr-satellites are 3CAT-2, AAUSAT-4 and GOMX-3. I plan to continue adding support for more satellites in the future.
On 15th August, a Chinese CZ-2D rocket launched three satellites from Juiuquan (Mongolia). The main payload was the Chinese satellite QSS, designed to do some experiments in quantum communications and entanglement. As anything that has the word quantum on it, this satellite even made it to the mainstream news in Spain. The rocket also launched Lixing 1, another Chinese satellite which will research the upper atmosphere, and 3CAT2, from the Universidad Politècnica de Catalunya (Spain).
3CAT2’s main payload is a GNSS reflectrometer designed to measure the altitude of the Earth and map the oceans. This means that it uses reflections of satellite navigation signals off the surface of the earth and sea to perform mapping. It will mainly use the L1 and L2 signals from GPS, but it can also work with Galileo, GLONASS and BeiDou signals. It also carries a prototype of a magnetometer designed for the eLISA project. This project consists in setting up a laser interferometer in space to observe gravity waves. It is roughly the same as the Earth-based LIGO, that recently confirmed the first detections of gravity waves. However, since eLISA will be in space, its laser arms will much longer than LIGO’s. This permits to study much lower frequencies than it’s possible Earth-based interferometers.
3CAT2 has a downlink in the Amateur 2m band, at 145.970MHz, and transmits 9600bps BPSK. It also has a faster BPSK downlink in the S-band, presumably at 2401MHz (inside the Amateur 13cm band). The days following 3CAT2’s launch I tried to receive its VHF signal, without any luck. I have been in contact with other Amateurs who also listened and didn’t hear anything.
This morning, I’ve received email from Scott K4KDR telling me that he has heard the satellite for the first time and he has managed to do a recording, but he is unable to decode the data.
We where unsure about which encoding that 3CAT2 is using. It could be AX.25, or some custom protocol using FEC. As far as I know, the only other satellite that transmits 9k6 BPSK in the Amateur bands is LilacSat-2, which uses strong FEC. Nevertheless, I’ve taken a good look at Scott’s recording and I’ve been able to decode one packet. This is, as far as I’m aware, the first decoding of 3CAT2 by an Amateur operator.
A while ago, I uploaded my gr-kiss out-of-tree GNUradio module to Github. This is a set of blocks to handle KISS, HDLC and AX.25, which are the protocols used in amateur packet radio. There are several other OOT modules that do similar things, but I didn’t like the functionality of them very much. While programming this module, I’ve also noted that the documentation for these protocols is not so good sometimes. Here I’ll give a brief description of the protocols and explain how everything works together.