Software – Page 14 – Daniel Estévez

TY-2 decoded

In January, I took a look at TY-2 telemetry. This is a Chinese cubesat that transmits 9k6 FSK telemetry in the 70cm Amateur band. In my previous post I tried to reverse engineer the packets from TY-2 and got as far as recognizing the syncword, and noting that the syncword is the same as the one sent by the GOMspace NanoCom AX100 transceiver. However, in all AX100 transceivers I had seen, the syncword was sent scrambled with a G3RUH scrambler, and TY-2 sent it unscrambled. This left me a bit puzzled. The payload seemed to be scrambled and I was unable to descramble it, preventing any further progress.

Since then, I have tried to get in contact with the satellite team to see if they could give me any additional information about TY-2 and its companion TY-6 (which uses the same format). Finally, the satellite team have answered me, giving me some details and confirming me that they use the AX100. This has allowed me to finish the decoder. An updated decoder is now available in gr-satellites. Thanks to BI1AEM for his help. Here I look at the specific details of the format used by TY-2.

Outernet LDPC code revisited

I have been preparing the slides for my future talk about reverse-engineering Outernet at FAQin 2018. While doing this, I have been re-reading some of the material about the work done on LDPC code and FEC in Outernet by George Hopkins in January 2017. One of the things I didn’t do back then was to read carefully the LDPC decoding function implemented by George.

In my post I explained that the LDPC code used in Outernet followed RFC5170, and I wondered whether it used the staircase scheme or the triangle scheme. I also commented that erasure decoding with an LDPC code (or any other linear code, actually) was mathematically equivalent to solving a linear system where the unknowns correspond to the erased symbols. I observed that the decoding function looked very different from this mathematical procedure, but should do more or less the same thing. Now I have read the decoder implementation carefully and I have the answer to both questions.

Studying IONEX files

Many Amateur radio operators are familiar with the effects of the ionosphere at HF frequencies. However, the effects of the ionosphere are also noticeable at much higher frequencies. In particular, at L band, which is used by most satellite navigation systems. Thus, GNSS receivers can be used to measure ionospheric parameters. These measurements are usually distributed as TEC maps in IONEX files.

Here I describe some basic ionospheric physics, how a GNSS receiver can measure the ionosphere, and give some Python code to study TEC maps in IONEX files. Then I use TEC maps to study the CODAR ionospheric observations I did in December last year.

Mystery 9k6 BPSK satellite

On January 28th, Tetsu JA0CAW reported on Twitter his reception of an unknown satellite. The time of reception was 2018-01-28 12:15 UTC and the frequency was around 435.525MHz. The time and frequency coincided with a PicSat pass over JA0CAW’s station in Japan. He provided an IQ recording of the signal. So far, the satellite that originated the signal has not been identified. Several people have tried to listen to this satellite again, but I haven’t seen any other reports. Doppler identification has not been attempted and it is perhaps unfeasible with the few packets in JA0CAW’s recording.

I have looked at the recording to try to identify the satellite. The modulation is easily seen to be BPSK at 9600baud. The signal presents a lot of fading, so demodulation without bit errors is difficult. There seems to be a scrambler in use. I’ve tried descrambling with G3RUH and CCSDS without any luck. I’ve also failed to identify a preamble or frame sync marker.

To look at the packets in more detail, I’ve resorted to do demodulation as postprocessing in a Jupyter Python notebook. The resulting notebook is here. It is written with detailed comments, so it can be of interest to anyone who wants to learn these techniques.

The only interesting piece of information that I’ve been able to extract from my analysis is that the bits in the packets present strong self-correlations at lags of 1920 bits (and multiples). This is 240 bytes, but I have no clue of what to make of this.

As always, I would be grateful if anyone can provide any additional information about this unknown satellite.

A first look at TY-2

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 telemetry parser added to gr-satellites

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.

Saving and plotting bandscope data with the Hermes-Lite 2

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.

By recording and processing the bandscope data, one can produce plots similar to the full day waterfall from the University of Twente WebSDR. Here I describe my first tests using Python.

Using CODAR for ionospheric sounding

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.

Tracking an RS41-SGP radiosonde and reporting to APRS

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.

AGC for gr-satellites

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.