destevez – Page 46 – Daniel Estévez

Improving signal processing in my OTH radar receiver

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.

Dolph-Chebyshev window with 100dB attenuation

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.

Dolph-Chebyshev window with 55dB attenuation

I have updated the gist with the GNU Radio flowgraph and python script used to produce the images.

Looking at an HF OTH radar

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.

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.

Some measurements of CAS-2T on orbit 25

Last Thursday, a CZ-11 Chinese rocket launched from Jiuquan. Alan Kung BA1DU posted in amsat-bb some minutes after launch saying that this launch contains an Amateur payload: CAS-2T. As it is usual with Chinese Amateur satellites, little information is available publicly and we hadn’t heard about CAS-2T before.

According to BA1DU, CAS-2T is a 2U Cubesat with a CW beacon on 70cm and a V/U FM transponder. The satellite will not separate from the upper stage of the rocket, so it will decay between 10 and 30 days before launch. However, this is not correct. After launch, CAS-2T was identified as object 2016-066E by Mike Rupprecht DK3WN using Doppler measurements. This object is on a 1030km x 500km elliptical orbit, so it will not decay soon. Apparently, due to a problem in the launch, the upper stage of the rocket has being put in this 10 year+ orbit. Indeed, there are radar TLEs for 6 objects from this launch. Four of them are on circular orbits of roughly 500km height, while the other two are on elliptical orbits of 1030km x 500km radius. All of these orbits will last for many years.

Reports of CAS-2T from Amateurs worldwide agree that the CW signal has good strength, but it suffers much fading. Unfortunately, the FM transponder does not function properly. It seems to respond well to an uplink signal, but it doesn’t modulate properly, as if it lacked power or suffered some other problem. On Friday afternoon, I took an SDR recording of the CW and FM signals of CAS-2T during its orbit 25. Here I show some measurements of these signals. The recording was done with a 7 element yagi and a FUNcube Dongle Pro+, and it has been Doppler corrected using the TLE for object 2016-066E, which gives a very good match.

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.

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.