In my previous post I showed a GNU Radio demodulator for the QO-100 multimedia beacon, which AMSAT-DL has recently started to broadcast through the QO-100 NB transponder, using a downlink frequency of 10489.995 MHz. This demodulator flowgraph could receive and save to disk the files transmitted by the beacon using the file receiver from gr-satellites. However, the performance was not so good, because it had a couple of ad-hoc Python blocks. Also, the real-time streaming data (which uses WebSockets) was not handled.
I have continued working in the decoder and solved these problems. Now we have a decoder with good performance that uses new C++ blocks that I have added to gr-satellites, and the streaming data is supported. I think that the only feature that isn’t supported yet is displaying the AMSAT bulletins in the qo100info.html web page (but the bulletins are received and saved to disk).
I have added the decoder and related tools to the examples folder of gr-satellites, so that other people can set this up more easily. In this post I summarise this work.
Last weekend, AMSAT-DL started some test transmissions of a high-speed multimedia beacon through the QO-100 NB transponder. The beacon uses the high-speed modem by Kurt Moraw DJ0ABR. It is called “high-speed” because the idea is to fit several kbps of data within the typical 2.7 kHz bandwidth of an SSB channel. The modem waveform is 2.4 kbaud 8APSK with Reed-Solomon (255, 223) frames. The net data rate (taking into account FEC and syncword overhead) is about 6.2 kbps.
I had never worked with this modem before, even though it served me as motivation for my 32APSK modem (still a work in progress). With a 24/7 continuous transmission on QO-100, now it was the perfect time to play with the modem, so I quickly put something together in GNU Radio. In this post I explain how my prototype decoder works and what remains to be improved.
A couple months ago I presented my work-in-progress design for a data modem intended to be used through the QO-100 NB transponder. The main design goal for this modem is to give the maximum data rate possible in a 2.7 kHz channel at 50 dB·Hz CN0. For the physical layer I settled on an RRC-filtered single-carrier modulation with 32APSK data symbols and an interleaved BPSK pilot sequence for synchronization. Simulation and over-the-air tests of this modulation showed good performance. The next step was designing an appropriate FEC.
Owing to the properties of the synchronization sequence, a natural size for the FEC codewords of this modem is 7595 bits (transmitted in 1519 data symbols). The modem uses a baudrate of 2570 baud, so at 50 dB·Hz CN0 the Es/N0 is 15.90 dB. In my previous post I considered using an LDPC code with a rate of 8/9 or 9/10 for FEC, taking as a reference the target Es/N0 performance of the DVB-S2 MODCODs. After some performing some simulations, it turns out that 9/10 is a bit too high with 7595 bit codewords (the DVB-S2 normal FECFRAMEs are 64800 bits long, giving a lower LDPC decoding threshold). Therefore, I’ve settled on trying to design a good rate 8/9 FEC. At this rate, the Eb/N0 is 9.42 dB.
Some time ago I did a few experiments about pushing 2kbaud 8PSK and differential 8PSK through the QO-100 NB transponder. I didn’t develop these experiments further into a complete modem, but in part they served as inspiration to Kurt Moraw DJ0ABR, who has now made a QO-100 Highspeed Multimedia Modem application that uses up to 2.4 kbaud 8PSK to send image, files and digital voice. Motivated by this, I have decided to pick up these experiments again and try to up the game by cramming as much bits per second as possible into a 2.7 kHz SSB channel.
Now I have a definition for the modem waveform, and an implementation in GNU Radio of the modulation, synchronization and demodulation that is working quite well both on simulation and in over-the-air tests on the QO-100 NB transponder. The next step would be to choose or design an appropriate FEC for error-free copy.
In this post I give an overview of the design choices for the modem, and present the GNU Radio implementation, which is available in gr-qo100_modem.
Presumably this satellite uses “AX25, 9k6, GMSK”, as listed at the bottom of this page from Taiwan’s National Space Organization, and also in this research paper. However, this is not true. It’s simple to check that the usual 9k6 FSK AX.25 decoders aren’t able to decode this signal, and a look at the FSK symbols shows that there is no scrambler (9k6 AX.25 uses the G3RUH scrambler) and that the symbol sequence doesn’t have much to do with AX.25.
After some reverse-enginnering, yesterday I figured out how the coding used by IDEASSat worked, and today I added a decoder to gr-satellites to help Mike investigate what kind of telemetry the packets contain. The protocol is not very good, so I think it’s interesting to document it in detail, as some sort of lessons learned. In this post I’ll do so. As it turns out, the protocol has some elements that loosely resemble AX.25, so I’m left wondering whether this is some unsuccessful attempt at implementing standard AX.25 (we’ve already seen very weird attempts, such as ESEO).
NEXUS, also called FO-99, is a Japanese Amateur satellite built by Nihon University and JAMSAT. It was launched on January 2019, and one of its interesting features is a π/4-DQPSK high-speed transmitter for the 435 MHz Amateur satellite band.
I was always interested in implementing a decoder for this satellite, due to its unusual modulation, but the technical information that is publicly available is scarce, so I never set to do it. A few days ago, Andrei Kopanchuk UZ7HO asked me a question about the Reed-Solomon code used in this satellite. He was working on a decoder for this satellite, and had some extra documentation. This renewed my interest in building a decoder for this satellite.
AMICal Sat was finally launched on 2020-09-03, and since them the satellite team has been busy trying to downlink some images, both using the UHF transmitter (which uses the same protocol as Światowid) and the S-band transmitter. This has proven a bit difficult because the ADCS of the satellite is not working, and the downlink protocols are not very robust.
Julien has been sending me recordings done by their groundstation in Russia with the hope that we could be able to decode some of the data. Before several failed attempts where we were hardly able to decode a few packets, we got a particularly good S-band recording done on 2020-10-05. Using that recording, I have been able to decode a full image.
On 2020-09-04, China launched a “reusable experimental spacecraft” of which very little is publicly known. The most popular hypothesis is that this is a robotic spaceplane similar to the X-37B. The spacecraft spent two days in orbit and landed back at Earth, most likely near Lop Nur nuclear test site. Marco Langbroek has a nice post detailing all we know about the mission.
This is a post I had announced since I first described Tianwen-1’s modulation. Since we have very high SNR recordings of the Tianwen-1 low rate rate telemetry signal made with the 20m dish in Bochum observatory, it is interesting to make detailed measurements of the modulation parameters. In fact, there is something curious about the way the modulation is implemented in the spacecraft’s transmitter. This analysis will show it clearly, but I will reserve the details for later in the post.
Here I will be using a recording that already appeared in a previous post. It was made on 2020-07-26 07:47:20 UTC in Bochum shortly after the switch to the high gain antenna, so the SNR is fantastic. The recording was done at 2.5Msps, and the spectrum can be seen below. The asymmetry (especially around +1MHz) might be due to the receive chain.
The signal is residual carrier phase modulation, with 16348 baud BPSK data on a 65536Hz square wave subcarrier. There is also a 500kHz ranging tone.