In my previous post I talked about some small updates made by George Hopkins to my free-outernet project. In fact, George has been reverse engineering the ondd binary quite in depth and he has been able to reverse engineer the LDPC code which is used for file FEC. This solves a long-standing issue of free-outernet. Formerly, LDPC decoding was not implemented, so to recover a file successfully all the file blocks had to be received correctly. Now, with LDPC decoding the file can be recovered even if some of the file blocks are lost. Thus, the performance of free-outernet in this aspect should now be the same as the performance of the closed source ondd binary included in the official Outernet receiver. Many thanks to George, as this is a substantial improvement of free-outernet. Here I describe the latest changes made by George in free-outernet.
Category: Software
Using, configuring and programming amateur radio related software.
Updated format for Outernet LDP protocol
After my talk in 33C3, George Hopkins has been doing some further reverse engineering of the Outernet protocols. By looking at the ondd binary, he has discovered that the length of the LDP header is not 6 bytes, but rather 4 bytes. He has sent a pull request with these changes. I have already merged it into free-outernet.
Thus, the last field of the LDP header as described in my previous post, which was formerly known as “B field”, gets now included in the payload of the package. The former “A field” is now the only field that identifies the port or service, and therefore it is now known as “type”. For file and FEC blocks, this change is small, because the former “B field” was always 0, so it gets incorporated into the “file id” field of the payload, which is now 24 bits long instead of 16 bits. For time packets it provides a nice way to interpret the packet as a variable record field structure. This interpretation now explains all the contents of the time packet.
After reviewing and merging George’s changes and while I still have these details fresh in my mind, I have updated the slides I used in my 33C3 talk to reflect these changes. These are the updated slides.
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.
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.
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: time and file services
In my last two posts, I’ve being talking about my reverse engineering efforts with the Outernet signal and I’ve described the modulation, coding and framing and the L3 and L4 network protocols used in Outernet. This post is the last in this series. Here I talk about how the time and file services work. Recall that a Free Software implementation of an Outernet receiver based on these descriptions is now available at gr-outernet and free-outernet.
Reverse engineering Outernet: L3 and L4 protocols
This is a follow-up to my last post, where I talked about my efforts to reverse engineer the protocols used in the Outernet L-band signal. Here I will describe the L3 and L4 protocols that are used in Outernet.
This description is solely based upon my reverse engineering efforts. As there is no documentation available for this protocols, I get to name them as I like. Also, I’ll describe the protocols just from how they appear to work. Probably the developers at Outernet had something a bit different in mind. In any case, my understanding of how the protocols work seems quite good, as I have now a functional file receiver called free-outernet. In my next post I’ll talk about how the Outernet time service and file service work.