Last weekend, I recorded the full EAPSK63 contest in the 40m band with the goal of monitoring IMD levels. I made a 48kHz IQ recording spanning the full 24 contest hours (from 16:00 UTC on Saturday to 16:00 UTC on Sunday). This week I’ve been playing with making waterfall plots from the recording. These are very interesting, showing patterns in propagation and contest activity. Here I show some of the waterfalls I’ve obtained, together with the Python code used to compute them.
Tag: digital modes
Monitoring IMD levels in the EAPSK63 contest
This weekend I have recorded the full EAPSK63 Spanish PSK63 contest in the 40m band with the goal of playing back the recording later and reporting the stations showing excessively high IMD levels. In PSK contests, it is usual to see terribly distorted signals, which are the result of reckless operating techniques and stations which are setup inadequately. Contest rules don’t help much, as they are usually too weak to prevent distorted signals from interfering other participants. Amateurs should take care and strive to produce a signal as clean as possible. For instance, in the US, Part 97 101 a) states that “each amateur station must be operated in accordance with good engineering and good amateur practice”. Here I describe the signal processing done in this study and list a “hall of shame” of the worst stations I have spotted in my recording. I will notify by email the contest manager and all the stations in this list with the hope that the situation improves in the future.
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.
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.
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.
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.
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.
Testing Opera sensitivity with GNU Radio
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.
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.
Simulating JT modes: how low can they get?
In this post I’ll show how one can use the signal generation tools in WSJT-X to do decoding simulations. This is nothing new, since the performance of the modes that WSJT-X offers has being thoroughly studied both with simulations and real off-air signals. However, these tools seem not very widely known amongst WSJT-X operators. Here I’ll give some examples of simulations for several JT modes. These can give the operators a hands-on experience of what the different modes can and cannot achieve.
Please note that when doing any sort of experiments, you should be careful before jumping to conclusions hastily. You should make sure that the tools you’re using are working as they should and also as you intend to (did you enter correctly all the parameters and settings?). Also, you should check that your results are reproducible and agree with the theory and other experiments.
Another warning: some of the software that I’ll be showing here, in particular the Franke-Taylor soft decoder for JT65 and the QRA64 mode, is still under development. The results that I show here may not reflect the optimal performance that the WSJT-X team aims to achieve in the final release version.
After all these warnings, let’s jump to study the modes. We’ll be considering the following modes: WSPR, JT9A, JT65A, JT65B and QRA64B. To give our tests some purpose, we want to find the decoding threshold for these different modes. This is the signal to noise ratio (SNR) below which the probability of a successful decode is too small to be useful (say, lower than 20%). For each mode, we will generate 100 test files containing a single signal with a fixed SNR. We will then see how many files can be successfully decoded for each SNR.