TY-2 is a 6U Chinese cubesat that was launched on January 19th in a CZ-11 rocket from Jiuquan, together with several other small satellites, including TY-6. According to the IARU Satcoord, TY-2 and TY-6 transmit 9k6 GMSK telemetry in the 70cm Amateur satellite band (435.350MHz for TY-2 and 436.100MHz for TY-6).
Several Amateurs such as K4KDR and PD0OXW have tried to decode the packets from TY-2 and TY-6 without success. I have taken a look to an IQ recording of TY-2 that Scott K4KDR has sent me and at least I’ve managed to do something (though not much) with it. Here I describe my findings.
PicSat is a recently launched cubesat from the Observatoire de Paris. It is designed to observe the Beta Pictoris star system, using a telescope based on an optical fibre. It transmits telemetry in the 70cm Amateur satellite band and it also carries a V/U FM Amateur transponder as a secondary payload. In my previous post, I decoded the 1k2 BPSK + G3RUH AX.25 packets from PicSat, and added a decoder to gr-satellites. Now I have added a telemetry parser to the gr-satellites decoder.
The Hermes-Lite 2 and other SDR transceivers based on the openHPSDR protocol support sending bandscope data from the SDR to the PC. The bandscope data consists in fixed-length chunks of samples taken directly from the ADC. Since the ADC in a DDC receiver runs at a high sampling rate, by taking the Fourier transform of these chunks, the bandscope data can be used to display a spectrum or waterfall of a huge frequency range, covering all the HF bands. In the case of the Hermes-Lite 2, the ADC samples at 76.8MHz, so the bandscope data gives us a spectrum from 0 to 38.4MHz.
Note that the the chunks of the bandscope data are not contiguous. Streaming samples at 76.8MHz from the ADC into the PC continuously would be a lot of data. Thus, a chunk is taken and stored in the FPGA and then sent to the PC slowly. Therefore, bandscope data is only intended for wideband spectral analysis and probably has very little use outside of that.
CODAR is an HF radar used to measure surface ocean currents in coastal areas. Usually, it consists of a chirp which repeats every second. The chirp rate is usually on the order of 10kHz/s, and the signal is gated in small pulses so that the CODAR receiver can listen between pulses. The gating frequency can be on the order of 1kHz.
CODAR can be received by skywave many kilometers inland. Being a chirped signal, it is easy to extract the multipath information from the received signal. In this way, one can see the signal bouncing off the different layers of the ionosphere, and magnificent pictures showing the changes in the ionosphere (especially at dawn and dusk) can be obtained. For instance, see these images by Pieter Ibelings N4IP, or the image at the top of this post, which contains 48 hours worth of CODAR data.
Here I describe my approach to receiving CODAR. It uses GNU Radio for most of the signal processing, and Python with NumPy, SciPy and Matplotlib for plotting.
In the past, I’ve talked about the RS92-SGP radiosonde launched from Madrid-Barajas. Recently, Barajas has replaced the RS92-SGP with the newer Vaisala RS41-SGP (except for ozone sounding, which is is still done with the RS92). The new radiosondes transmit at 401MHz and are released daily at 11:15 and 23:15 UTC.
In that post, I described about how to receive the position data from the RS92 and plot it in Viking in real time. Since then, a few features such as FEC decoding have been added to the RS decoder software, so I have decided to give this a go again with the newer RS41. This will be a complete walk through, since some people are interested in setting up unattended decoders, perhaps running on a Raspberry Pi.
In a previous post I discussed my BER simulations with the LilacSat-1 receiver in gr-satellites. I found out that the “Feed Forward AGC” block was not performing well and causing a considerable loss in performance. David Rowe remarked that an AGC should not be necessary in a PSK modem, since PSK is not sensitive to amplitude. While this is true, several of the GNU Radio blocks that I’m using in my BPSK receiver are indeed sensitive to amplitude, so an AGC must be used with them. Here I look at these blocks and I explain the new AGC that I’m now using in gr-satellites.
More than a year ago, I spoke about my efforts to decode ÑuSat-1 and -2. I got as far as reverse-engineering the syncword and packet length, and I conjectured that the last 4 bytes of the packet were a CRC, but without the scrambler algorithm I couldn’t do much. Recently I’ve been exchanging some emails with Gerardo Richarte from Satellogic, which is the company behind the ÑuSat satellites. He has been able to provide me the details of the protocol that I wasn’t able to reverse engineer. The result of this exchange is that a complete decoder for ÑuSat-1 and -2 is now included in gr-satellites, together with an example recording. The beacon format is still unknown, but there is some ASCII data in the beacon. Here I summarise the technical details of the protocol used by ÑuSat. Thanks to Gerardo for his help and to Mike DK3WN for insisting into getting this job eventually done.
Lately, I have been playing around with the concept of doing acquisition and wipeoff of JT9A signals, using a locally generated replica when the transmitted message is known. These are concepts and terminologies that come from GNSS signal processing, but they can applied to many other cases.
In GNSS, most of the systems transmit a known spreading sequence using BPSK. When the signal arrives to the receiver, the frequency offset (given by Doppler and clock error) and delay are unknown. The receiver runs a search correlating against a locally generated replica signal which uses the same spreading sequence. The correlation will peak for the correct values of frequency offset and delay. The receiver then mixes the incoming signal with the replica to remove the DSSS modulation, so that only the data bits that carry the navigation message remain. This process can be understood as a matched filter that removes a lot of noise bandwidth. The procedure is called code wipeoff.
The same ideas can be applied to almost any kind of signal. A JT9A signal is a 9-FSK signal, so when trying to do an FFT to visually detect the signal in a spectrum display, the energy of the signal spreads over several bins and we lose SNR. We can generate a replica JT9A signal carrying the same message and at the same temporal delay than the signal we want to detect. Then we mix the signal with the complex conjugate of the replica. The result is a CW tone at the difference of frequencies of both signals, which we call wiped signal. This is much easier to detect in an FFT, because all the energy is concentrated in a single bin. Here I look at the procedure in detail and show an application with real world signals. Recordings and a Python script are included.
In a previous post, I spoke about the cubesat D-SAT. The thing that first caught my attention about this satellite is its image downlink and the quality of some of the images that Mike DK3WN has managed to receive. Yesterday, Mike sent me an IQ recording of D-SAT downlinking a couple of images. After using the Groundstation software by the D-SAT team to verify that the images in the recording can be decoded, I have reverse engineered the protocol used to transmit images and added an image decoder to the D-SAT decoder in gr-satellites.
The image decoder can be tested with the dsat-image.wav recording in satellite-recordings. This WAV file contains the image below, which shows the Southwestern part of Spain and Portugal. The image was taken by D-SAT on 2017-08-17 10:09:54 UTC and received by Mike during the 19:10 UTC pass that evening.
Image of Spain and Portugal taken by D-SAT
According to the TLEs, at the time this image was taken, D-SAT was just above Rincón de la Victoria, in Málaga, passing on a North to South orbit. This means that D-SAT’s camera was pointing more or less in a direction normal to the orbit.
This image is a 352×288 pixels JPEG image with a size of 13057 bytes. It took 43 seconds to transfer using D-SAT’s 4k8 AF GMSK downlink (yes, the overhead is around 100%, more on that later). In the rest of this post, I detail the protocol used to transmit the images.
Back in September 26 2016, I posted an email in Spanish to the Hamnet.es mailing list detailing my proposal for an IPv6 Amateur radio network, and trying to engage people into some preliminary tests. In October 1 2016, I posted a summary (in English) of my message to the 44net mailing list. There was some discussion afterwards in the list, but no real actions were taken. Since then, no much interest in IPv6 for Amateur radio seems to have sprung. Still, I think that the time for IPv6 will come. I have collected my IPv6 for Amateur radio proposal in a page here for future reference. At least I hope that this pops up on Google searches for IPv6 and Amateur radio, since there is not much material about this on the Internet, and most of what one can find is quite dated.
