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.
The Amateur satellite BY70-1 launched yesterday at around 3:00UTC. The launch was a partial failure, as all the satellites from this launch have been put in a 520x220km orbit. The perigee is too low to support a long duration orbit, and the satellites will decay in a couple months. BY70-1 has a 9k6 BPSK telemetry downlink on 70cm. This downlink is also used to download JPEG images from the onboard camera. I've talked about this in a previous post.
My first impression is that the packets are not very strong. I don't know if this is something about JA0CAW's station or that the downlink of BY70-1 is not very strong. I've only managed to decode the strongest packets in the recording. In comparison, LilacSat-2 has a very strong downlink and I can decode correctly almost from horizon to horizon with a handheld 7 element yagi.
Perhaps it's possible to do some optimization of the decoder parameters such as filter width or loop bandwidths, but so far I haven't experimented much. I just wanted to write a quick post to publish all the information I've managed to decode. I'm using the decoder from gr-satellites. The decoder log from recording1 is in this gist. From recording2 I could only decode a couple of JPEG packets and no telemetry packets.
There are three distinct types of telemetry packets. It seems that BY70-1 transmits all the three types in a single burst. Another curiosity: the message in one of the telemetry packets uses the callsign ON02CN, which is the Belgian callsign that LilacSat-1 will use. Since LilacSat-1 is part of the QB50 project, it makes sense that it uses a Belgian callsign. However, it seems that it's some sort of software configuration error that BY70-1 is also using this callsign.
Update on 30/12/2016: I have found that there was a problem with the Costas loop bandwidth in the GNU Radio receiver on gr-satellites. Its value was too large. I have copied the value from the example demodulator on gr-lilacsat and now the decoder works much better. I have even been able to decode the following image from recording2.
The result looks pretty bad, but the keen eye will notice that in fact there are few packets lost in this JPEG image. Compare with the image posted by BG2BHC, which has no errors and is presumably the same image.
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 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.
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.
I have updated the gist with the GNU Radio flowgraph and python script used to produce the images.
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.
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.
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.
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.
GOMX-1 is a 2U cubesat from GomSpace that was launched in November 2013 into a sun-synchronous orbit. As far as I know, it was the first satellite with an ADS-B receiver payload. It transmits telemetry on the 70cm Amateur band, including some data from the ADS-B receiver, as GOMX-3 does. Some Amateurs, including me, had tried to decode its telemetry on several occasions, without success. GOMX-3 will decay in about 4 weeks, as it was launched from the ISS on October 2015. Therefore, it now becomes more interesting to decode GOMX-1, which is in a longer term orbit. After one more serious try, I've been able to decode the telemetry. This is the first time that an Amateur decodes telemetry from GOMX-1 completely. The decoder code can be found in gr-satellites and gr-ax100, including an example wav file in
In the previous post I've talked about HORYU-4 CW telemetry. Here I report my findings when trying to decode 1200baud AFSK telemetry. Since the satellite transmits digital telemetry only over Japan, the recordings I've analysed have being kindly provided by Tetsurou JA0CAW. There is a telemetry format document from Kyutech, but as it is the case with the CW document, it is rather incomplete and lacks several important details.
In a previous post, I looked at the telemetry packets transmitted by the satellite 3CAT-2. This satellite transmits 9600bps AX.25 BPSK packets in the Amateur 2m band. As far as I know, it is the only satellite that transmits fast BPSK without any form of forward error correction. LilacSat-2 uses a concatenated code with a (7, 1/2) convolutional inner code and a (255, 223) Reed-Solomon outer code. The remaining BPSK satellites transmit at 1200bps, either using AX.25 without FEC (the QB50p satellites, for instance), or with strong FEC (Funcube, for example). Therefore, I remark that 3CAT-2's packets will be a bit difficult to decode without errors. But how difficult? Here I look at how to use the theory to calculate this, without resorting to simulations.