Recently I have added a telemetry parser to the S-NET decoder in gr-satellites. Recall that I have talked about S-NET and its decoder in a previous post. To implement this telemetry parser I have used the information in Mike Rupprecht DK3WN's web, some additional information shared by the S-NET team, as well as some recordings done by Mike. Many thanks to Mike and the S-NET team for all their help. Here I describe a few details about the telemetry.
A year ago, I made a decoder for the AO-40 FEC. While AO-40 has been dead for many years, the same FEC system is used in AO-73 and the rest of the FUNcube satellites. This decoder was later included in gr-satellites and it is currently used in the decoders for AO-73, UKube-1 and Nayif-1.
When I implemented this FEC decoder, for simplicity I used a hard decision Viterbi decoder, since my main concern was to get all the system working. I always intended to replace this by a soft decision Viterbi decoder, but it seems that I forgot completely about it.
Now, while thinking about integrating gr-aausat (my AAUSAT-4 decoder OOT module) into gr-satellites and adding a soft Viterbi decoder for AAUSAT-4, I have remembered about this. While the decoder for AAUSAT-4 will have to wait, since I have found a bug in the GNU Radio Viterbi decoder that makes it segfault, I have already added a soft Viterbi AO-40 FEC decoder to the FUNcube decoders in gr-satellites.
PolyITAN-2-SAU, or QB50 UA01, is a cubesat from National Technical University of Ukraine, that was launched on May 2017 as part of the QB50 proyect. When it was launched, I made a recording of several QB50 satellites, including PolyITAN-2-SAU. Presumably, the modulation and coding used by this satellite is 9k6 BPSK AX.25, with G3RUH scrambling. Back then, I commented that although the signal was strong and I could get a clean constellation plot, I was unable to get valid AX.25 packets.
I had completely forgotten this satellite, but the other day I saw that Andy UZ7HO had added support for PolyITAN-2-SAU to his SoundModem. I asked Andy for some help, since I suspected that the coding wasn't exactly standard G3RUH AX.25.
The trick is that this satellite uses two "layers" of NRZI encoding. The relevant part of the decoder is shown below. The BPSK symbols come in from the left of the figure and the AX.25 packets exit by the right. A standard G3RUH AX.25 decoder wouldn't have the extra NRZI decoder on the right.
Note that NRZI decoding and G3RUH descrambling commute, since the G3RUH polynomial has an odd number of terms. Therefore, the decoder can also be organized in a different way, with both NRZI decoders at one side (either the input or output) of the descrambler.
Having two NRZI decoders in chain is a really funny concept, so it almost seems as some kind of mistake from the satellite team (most QB50 satellites use standard BPSK or FSK AX.25 packet radio for compatibility). In fact, if we write an NRZI decoder as , where is the input sequence, is the output sequence and the operations are performed on the finite field , then the effect of two NRZI decoders in chain can be written as
which is a rather strange form of differential decoder.
Thanks to Andy for giving me the clue about the extra NRZI decoder, as I would have had a hard time in finding it by myself (although, in retrospective, it is not that difficult to guess it by looking at the descrambled stream and seeing how HDLC 0x7e flags can be obtained from it). I have now added a decoder for PolyITAN-2-SAU to gr-satellites.
In my previous post, I talked about the coding used by the S-NET cubesats and the implementation of my decoder included in gr-satellites. The decoder was still missing a BCH decoder. I have now implemented a BCH decoder and included it in gr-satellites. Here I describe the details of this decoder.
S-NET is a swarm of 4 cubesats from TU-Berlin. Their mission is to test SLink, an S-band transceiver for inter-satellite communications. They were launched on February 1 this year and they use use Amateur frequencies for their telemetry downlink on the 70cm band. Several weeks ago, Mike Rupprecht DK3WN raised my attention towards these satellites. Since they use a rather particular coding, custom software would be needed to decode the telemetry. Then, I set to add support for S-NET to gr-satellites
After some really helpful communication with the S-NET team, in particular with Walter Frese, and some exchanges of ideas with Andrei Kopanchuk UZ7HO, who was also working to add an S-NET decoder to his soundmodem, I have finally added a basic S-NET decoder to gr-satellites.
Last week I published my results about the LilacSat-2 VLBI experiment. There, I mentioned that there were some things I still wanted to do, such as studying the biases in the calculations or trying to improve the signal processing. Since then, I have continued working on this and I have tried out some ideas I had. These have given good results. For instance, I have been able to reduce the delta-range measurement noise from around 700m to 300m. Here I present the improvements I have made. Reading the previous post before this one is highly recommended. The calculations of this post were performed in this Jupyter notebook.
In January, I took a look at TY-2 telemetry. This is a Chinese cubesat that transmits 9k6 FSK telemetry in the 70cm Amateur band. In my previous post I tried to reverse engineer the packets from TY-2 and got as far as recognizing the syncword, and noting that the syncword is the same as the one sent by the GOMspace NanoCom AX100 transceiver. However, in all AX100 transceivers I had seen, the syncword was sent scrambled with a G3RUH scrambler, and TY-2 sent it unscrambled. This left me a bit puzzled. The payload seemed to be scrambled and I was unable to descramble it, preventing any further progress.
Since then, I have tried to get in contact with the satellite team to see if they could give me any additional information about TY-2 and its companion TY-6 (which uses the same format). Finally, the satellite team have answered me, giving me some details and confirming me that they use the AX100. This has allowed me to finish the decoder. An updated decoder is now available in gr-satellites. Thanks to BI1AEM for his help. Here I look at the specific details of the format used by TY-2.
On 23 February, Wei Mingchuan BG2BHC published on Twitter the first Amateur VLBI experiment. This consisted of a GPS-synchronized recording of signals from LilacSat-2 using USRPs in groundstations at Harbin and Chongqing, which are about 2500km apart. Wei has made a Github repository containing the recording (in MATLAB file format) and some signal processing in MATLAB. I have done some signal processing of my own with the recording and published my results in a Jupyter notebook. Here I describe some general aspects about VLBI and its use in Amateur radio, and some specific details of the signal processing I have done.
In my previous post I talked about the RFC5170 LDPC codes used in Outernet. There I explained in some detail the pseudorandom construction of the LDPC codes and the simple erasure decoding algorithm used both in free-outernet and in the official closed-source receiver.
The Outernet LDPC codes follow what I call the "identity scheme". This is different from the staircase and triangle schemes introduced in the RFC. The identity scheme already appeared in the literature, but it did not make it into the RFC. See, for instance, the report by Roca and Neumann Design, Evaluation and Comparison of Four Large Block FEC Codecs, LDPC, LDGM, LDGM Staircase and LDGM Triangle, plus a Reed-Solomon Small Block FEC Codec, especially Section 2, where it is called "LDGM".
I also commented that erasure decoding for an LDPC code (or any other linear code) amounts to solving a linear system. This can be done using any algebraic method, such as Gaussian elimination. However, the simple decoding algorithm used in Outernet is as follows: try to find an equation with only one unknown, solve for that unknown, and repeat until the system is solved. Clearly this algorithm can fail even if the system can be solved (see my previous post for some examples and formal results). I will refer to this algorithm as iterative decoding, as it is done in the RFC.
With these two things in mind, I wondered about the performance of the LDPC codes used in Outernet and the iterative decoding algorithm. I've done some simulations and here I present my results.
I have been preparing the slides for my future talk about reverse-engineering Outernet at FAQin 2018. While doing this, I have been re-reading some of the material about the work done on LDPC code and FEC in Outernet by George Hopkins in January 2017. One of the things I didn't do back then was to read carefully the LDPC decoding function implemented by George.
In my post I explained that the LDPC code used in Outernet followed RFC5170, and I wondered whether it used the staircase scheme or the triangle scheme. I also commented that erasure decoding with an LDPC code (or any other linear code, actually) was mathematically equivalent to solving a linear system where the unknowns correspond to the erased symbols. I observed that the decoding function looked very different from this mathematical procedure, but should do more or less the same thing. Now I have read the decoder implementation carefully and I have the answer to both questions.