Space – Page 31 – Daniel Estévez

WSJT-X and linear satellites: part II

This is a follow-up to the part I post about using WSJT-X modes through a linear transponder on a LEO satellite. In part I, we considered the tolerance of several WSJT-X modes to the residual Doppler produced by a temporal offset in the Doppler computation used for computer Doppler correction. There, we introduced a parameter \(\delta\) which represents the time shift between the real Doppler curve and the computed Doppler curve. The main idea was that a decoder could try to correct the residual Doppler by trying several values of \(\delta\) until a decode is produced.

Here we examine the effect of TLE age on the accuracy of the Doppler computation. The problem is that, when a satellite pass occurs, TLEs have been calculated at an epoch in the past, so there is an error between the actual Doppler curve and the Doppler curve predicted by the TLEs. We show that the actual Doppler curve is very well approximated by applying a time shift to the Doppler curve predicted by the TLEs, justifying the study in part I.

Charlas en IberRadio

English summary: Slides and recordings for the two talks I gave yesterday in IberRadio. One of the is about gr-satellites and the other one is about Linrad. All the material are in Spanish.

Ayer estuve en la feria IberRadio, en Ávila, dando dos charlas: una sobre gr-satellites y la otra sobre Linrad. Las diapositivas en PDF de las charlas se pueden descargar aquí:

He grabado las charlas usando mi cámara. El enfoque y la exposición no son muy buenos, pero he editado el vídeo incluyendo encima las imágenes de las diapositivas, lo que facilita seguir el vídeo de la charla. Por contra, las demostraciones en directo en la charla de Linrad se ven un poco mal.

Actualización: David EA1FAQ también hizo grabaciones de las charlas. En sus grabaciones se ve mejor el proyector, por lo que las demostraciones en directo durante la charla de Linrad se siguen mejor. Incluyo links más abajo.

Grabaciones con diapositivas por EA4GPZ

Grabaciones por EA1FAQ

Polarization in Voyager signal from Green Bank Telescope

A few days ago I read the paper about the Breakthrough Listen experiment. This experiment consists in doing many wideband recordings of different stars using the Green Bank Telescope, and (in the future) Parkes Observatory and then trying to find signals from extraterrestrial intelligent life in the recordings. The Breakthrough Listen project has a nice Github repository with some documentation and an analysis of a recording they did of Voyager 1 to test their setup.

I have also been thinking about how to study the polarization of signals in a dual polarization recording (two coherent channels with orthogonal polarizations). My main goal for this is to study the polarization of the signals of Amateur satellites in low Earth orbit. It seems that there are many myths regarding polarization and the rotation of cubesats, and these myths eventually pop up whenever anyone tries to discuss whether linearly polarized or circularly polarized Yagis are any good for receiving cubesats.

Through the Breakthrough Listen paper I’ve learned of the Stokes parameters. These are a set of parameters to describe polarization which are very popular in optics, since they are easy to measure physically. I have immediately noticed that they are also easy to compute from a dual polarization recording. In comparison with Jones vectors, Stokes parameters disregard all the information about phase, but instead they are computed from the averaged power in different polarizations. This makes their computation less affected by noise and other factors.

As I also wanted to get my hands on the Breakthrough Listen raw recordings, I have been computing the Stokes parameters of the Voyager 1 signal in their recording. Since the Voyager 1 signal is left hand circularly polarized, the results are not particularly interesting. It would be better to use a signal with changing polarization or some form of elliptical polarization.

I have started to use Jupyter notebook. This is something I had been wanting to try since a while ago, and I’ve realised that a Jupyter notebook serves better to document my experiments in Python than a Python script in a gist, which is what I was doing before. I have started a Github repo for my experiments using Jupyter notebooks. The experiment about polarization in the Voyager 1 signal is the first of them. Incidentally, this experiment has been done near Voyager 1’s 40th anniversary.

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.

ÑuSat finally decoded

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.

D-SAT image downlink

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.

D-SAT support added to gr-satellites

D-SAT is an Italian cubesat that will demonstrate a new deorbit hardware. Apparently this system uses dedicated propulsion to make the satellite re-enter from a 500km orbit in 30 minutes. It also carries three more experiments and it was launched in June 23 together with several other small satellites. According to the information from the team, it transmits 4k8 telemetry in the 70cm band. It is not stated explicitly, but we read attentively, we see that it uses a NanoCom U482C transceiver from GOMspace.

Recently, I have seen Mike DK3WN decode very nice images from D-SAT and I have investigated a bit to see what software he is using.

The satellite team provides some decoding software through their forum, which requires registration. Version 2 of their software can be downloaded directly here using the password dsatmission. Its software is based on GNU Radio and it uses a few components from gr-satellites, namely the U482C decoder and some KISS and CSP blocks. These have been incorporated into their decoder from before gr-satellites was restructured. They include a note thanking me in the README, but I didn’t ever hear from them that they were using gr-satellites. It would have been nice if they had contacted me, since this opens up many possibilities for collaboration.

Apart from that, they include a groundstation software which performs telemetry decoding and so on. Unfortunately, the groundstation software is closed-source, distributed only as an x86_64 Linux executable. This is not good for Amateur Radio. We should strive for open source software and open specifications for everything that transmits in our bands. The groundstation software is also distributed in a quite ugly manner as the remains of an Eclipse project (source code stripped, of course). However, it is interesting because it seems that this software is the same they use in their groundstation, and it supports sending commands to the satellite. Naturally, the command transmission is not implemented in the software they distribute, but it is still very interesting to have a peek and see what kinds of commands the satellite supports.

I have added a D-SAT decoder to gr-satellites. The decoder supports sending frames to their groundstation software. Here I describe how to set everything up.

WSJT-X and linear satellites: part I

Several weeks ago, in an AMSAT EA informal meeting, Eduardo EA3GHS wondered about the possibility of using WSJT-X modes through linear transponder satellites in low Earth orbit. Of course, computer Doppler correction is a must, but even under the best circumstances we cannot assume a perfect Doppler correction. First, there are errors in the Doppler computation because the TLEs used are always measured at an earlier time and do not reflect exactly the current state of the satellite. This was the aspect that Eduardo was studying. Second, there are also errors because the computer clock is not perfect. Even a 10ms error in the computer clock can produce a noticeable error in the Doppler computation. Also, usually there is a delay between the time that the RF signal reaches the antenna and the time that the Doppler correction is computed for and applied to the signal, especially if using SDR hardware, which can have large buffers for the signal. This delay can be measured and compensated in the Doppler calculation, but this is usually not done.

Here we look at errors of the second kind. We denote by \(D(t)\) the function describing the Doppler frequency, where \(t\) is the time when the signal arrives at the antenna. We assume that the correction is not done using \(D(t)\), but rather \(D(t – \delta)\), where \(\delta\) is a small constant. Thus, a residual Doppler \(D(t)-D(t-\delta)\) is still present in the received signal. We will study this residual Doppler and how tolerant to it are several WSJT-X modes, depending on the value of \(\delta\).

The dependence of Doppler on the age of the TLEs will be studied in a later post, but it is worthy to note that the largest error made by using old TLEs is in the along-track position of the satellite, and that this effect is well modelled by offsetting the Doppler curve in time. This justifies the study of the residual Doppler \(D(t)-D(t-\delta)\).

A first look at DSLWP SSDV downlink

The Chang’e 4 is a Chinese lunar mission that will land a rover on the far side of the Moon by the end of 2018. To support this mission, the Chang’e 4 relay satellite will be launched six months before and put into a halo orbit around the Earth-Moon Lagrange L2 point. The relay will provide four 256Kbps links with the rover and lander on X-band and a 2Mbps link with Earth on S-band using a 4.2m dish. Two CE-4 microsatellites will be launched together with the relay satellite. They will be put in a 200km x 9000km lunar elliptical orbit. The main mission of the CE-4 microsatellites is to perform HF interferometry of celestial bodies, using the Moon as a shield from the radiation of the Sun and Earth. The satellites also carry an Amateur radio system called DSLWP, which will provide telecommand, telemetry and image downlink.

A team at Harbin Institute of Technology is currently designing the Amateur radio payload. As it is the case with previous HIT satellites such as BY70-1 and LilacSat-1, the payload will have a camera which can be telecommanded by radio Amateurs, which can use it to take and download pictures. Yesterday, Wei BG2BHC has released some work in progress of the image downlink. Many important parts of the downlink will still change, but releasing the work in progress at this early stage is a very good idea. Probably it is not too late in the development process so that the Amateur community can contribute with ideas and improvements.

The release consists of an IQ recording of the signal containing a full image and a decoder in gr-lilacsat. The IQ recording is at 2ksamp/s, since the signal is FSK at 250baud. Note that the recording is almost 32 minutes long. It takes a while to transmit an image at such a low rate. However, a low baudrate and a good amount of FEC are needed for an effective downlink from the Moon, given the huge path loss of around 197dB in the 70cm band.

The good news about this work in progress is that SSDV is now used to transmit the image. SSDV is a packetised protocol based on JPEG, but which is tolerant to packet loss. In contrast, BY70-1 and LilacSat-1 send JPEG images in 64byte chunks, and a single lost chunk can destroy the image completely. SSDV was originally developed to transmit images from Amateur high altitude ballons, so it is a good idea to use it also for DSLWP.

The bad news is that the way that SSDV has been included into the downlink protocol is not very optimal. In the rest of this post I do an in-depth look at the protocol, point out the main problems and suggest some solutions. Hopefully the protocol can still be modified and improved.

LilacSat-1 downlink usage

In my previous post, I examined a recording of LilacSat-1 transmitting an image. I did some calculations regarding the time it would take to transmit that image and the time that it actually took to transmit, given that the image was interleaved with telemetry packets. I wondered if the downlink KISS stream capacity was being used completely.

You can find more information about the downlink protocol of LilacSat-1 in this post. The important information to know here is that it consists of two interleaved channels: a channel that contains Codec2 frames for the FM/Codec2 repeater and a channel that contains a KISS stream. The KISS stream is sent at 3400bps. At any moment in time, the KISS stream can be either idling, by sending c0 bytes, or transmitting a CSP packet. The CSP packets can be camera packets (which are sent to CSP destination 6) or telemetry packets (and perhaps also other kinds of packets).

I have extracted the KISS stream from the recording and examined its usage to determine if it is being used at its full capacity or if it spends time idling. The image below represents the usage of each byte in the KISS stream, as time progresses. Bytes belonging to image packets are shown in blue, bytes belonging to other packets are shown in red and idle bytes are shown in white. (Remember that you can click the images to view them in full size).

The first 3 or 4 seconds of the graph are garbage, since the signal wasn’t strong enough. Then we see some telemetry packets and the image transmission starts. We observe that most image packets are transmitted leaving an idle gap between them. The size of the gap is similar to the size of the image packet. Every 10 seconds, a bunch of telemetry packets are transmitted, in a somewhat different order each time. Some telemetry packets are sent back to back, and others are interleaved with image packets. Image packets are only sent back to back just after a telemetry transmission.

The next graph shows the usage of the KISS stream averaged over periods of 5 secons. The y-axis means fraction of capacity of the link, so a 1 means that the full 3400bps are used. The capacity spent for image packets is shown in blue and the capacity used for telemetry is shown in red. The green curve is the sum of the blue and red, so it means the fraction of time that the link is not idle. We see that the link is never used completely. The total usage ranges between 60% and 90%, but never reaches 100%.

As expected, the capacity used for telemetry spikes up every 10 seconds. The blue curve is more interesting. It is roughly around 55%, but whenever telemetry is sent, it decreases a little. Just after each telemetry burst, the blue curve increases a little. This matches the behaviour we have seen in the previous graph. Every 10 seconds a telemetry burst is sent, using up some capacity that would normally be spent for image. After the telemetry burst, some image packets are sent back to back in a burst, peaking up to 60% capacity, but soon the packets continue being sent with idle gaps between them, and the capacity goes down to 55%.

It is a bit strange that the link is not fully utilised. One would expect that image packets are sent as fast as possible, stopping only to send telemetry. However, we have seen that there are many idle gaps. It seems that the image can’t be read very fast or that there is some other throttling mechanism. This would explain why a burst of image packets is sent after each telemetry burst: the image packets buffer up, because the link is sending telemetry. When the link is no longer busy with telemetry, it sends all the buffered image packets in a row, but soon enough image packets can’t be produced as fast as the link sends them, so idle gaps appear. This seems quite an important performance issue, as it appears that image transmission speed is capped at about 1870bps.

The Python code that generated these graphs can be seen below. The KISS file is also in the same gist.