Space – Page 17 – Daniel Estévez

DOP geographical distribution for the Galileo and GPS constellations

I have been wondering about how the DOP for the different GNSS constellation varies geographically, owing to the different number of satellites and constellation geometries. There are many DOP maps, such as this Galileo HDOP map by the Galileo System Simulation facility, but after a quick search in the literature I couldn’t find any survey paper that made a comprehensive comparison. The closest thing I found to what I was looking for was Consellation design optimization with a DOP based criterion, by Dufour etl. This was published in 1995, so it compares the GPS and GLONASS constellations with prototypical constellations such as the Walker delta using different parameters, but it doesn’t mention Galileo, which wasn’t even planned back then.

Therefore, I have decided to do my own simulations and compare the DOP for the Galileo and GPS constellations. Since the actual distribution of the satellites can differ substantially from the slots designated in the constellation, I am considering both the theoretical reference constellations and the real world constellations, as taken from the almanacs at the beginning of 2020. This post is a detailed account of my methodology and results.

Fourth alpha for gr-satellites 3

Shortly after releasing the third alpha, I have released today gr-satellites v3-alpha3, which is the fourth in the series of alphas of the future gr-satellites v3. This release focuses on a new file and image receiver framework that tries to give a general way of reassembling files transmitted in chunks using different protocols.

Extracting AX.25 satellites from SatNOGS DB

In my last post about gr-satellites 3, I announced that gr-satellites would start to support all the AX.25 satellites transmitting in Amateur bands. Historically, gr-satellites didn’t support packet radio (AFSK and FSK AX.25) satellites since there were too many of them and there were already other good decoders such as Direwolf. At one point Rocco Valenzano W2RTV convinced me to add “generic” packet radio decoders to gr-satellites and since then these have been seeing quite some use.

In gr-satellites 3 it is very easy to add new satellites, since this is done with a SatYAML file, which is a brief YAML file describing basic information about the satellite and its transmitters. Therefore, I decided to make a script to get this data from SatNOGS DB and write the SatYAMLs automatically for all the AFSK and FSK AX.25 satellites.

Third alpha for gr-satellites 3

gr-satellites v3 is a large refactor of the gr-satellites codebase that I introduced in September. Since then, I have been working and releasing alphas to showcase the new features and get feedback from the community. Today I have released the third alpha in the series: v3-alpha2.

Each of the alphas has focused on a different topic or feature, and v3-alpha2 focuses on extending the number of satellites supported and bringing back most of the satellites supported in gr-satellites v2. Whereas previous alphas supported only a few different satellites, this alpha supports a large number. Therefore, I think that this is the first gr-satellites v3 release that is really useful. I expect that interested people will be able to use v3-alpha2 as a replacement of gr-satellites v2 in their usual activities.

In this post, I explain the main features that this alpha brings. For the basic usage of gr-satellites v3, please refer to the post about the second alpha.

DSLWP-B whole mission telemetry

Recently, together with people from Harbin Institute of Technology and CAMRAS, we have published in Zenodo the data collected during the DSLWP-B mission. This data release includes all the raw telemetry frames uploaded to the DSLWP telemetry server.

I have made a Jupyter notebook that loads up and parses the telemetry, with the idea of providing a simple way to study the data.

First tests of a narrowband data modem for QO-100

Since a while ago, I have had the idea to design a data modem for the NB transponder of QO-100 (Es’hail 2). The main design criteria of this modem is that it should fit in a bandwidth of 2.7kHz and be able to work at a signal power equal to that of the transponder BPSK beacon, since these are the bandwidth and power constraints when using the NB transponder.

Currently, the following modes are used for medium speed data (understood as a few kbps) on the NB transponder. First, there are the FreeDV modes, whose use has been covered in this Lime microsystems community post. Most of these modes use OFDM or multi-carrier modems and are designed having HF fading channels in mind. These don’t give good performance over the QO-100 transponder, since the frequency instabilities of the transmitters and receivers give problems with OFDM modems. A single carrier modem is much better. David Rowe VK5DGR has made some modifications to the FreeDV 2020 modem to improve performance over QO-100, and it certainly works quite well, but better results can be obtained with a single carrier modem.

There are some people using DRM for DSSTV. This is also an OFDM modem intended for HF, and the symbol time is quite long, so the frequency instabilities can give problems. Finally, there is KG-STV, which was relatively unpopular before QO-100 but it is seeing a lot of use due to its good performance. It uses a single carrier MSK modem. This is probably the most popular medium speed mode on the NB transponder, but it is only 1200bps.

One important characteristic of the NB transponder is that there is a lot of SNR available. The rule is that no signal should be stronger than the beacons, but the BPSK beacon has a CN0 of around 54dB as received in my station. It is also not difficult (in terms of uplink EIRP) to achieve the same power as the beacon. Therefore, it is a reasonable assumption that stations interested in using a medium speed data modem will adjust their uplink power to be as strong as the BPSK beacon. I already hinted at what is possible with such a strong signal in this post.

I have decided to do some preliminary tests to check the performance of a 2kbaud 8PSK signal over the NB transponder. This post summarizes my results. The material for the post can be found in the qo100-modem Github repository.

Decoding FloripaSat-1

FloripaSat-1 is a 1U cubesat developed by Universidade Federal Santa Catarina, Brazil. It was launched two days ago from Taiyuan, China, together with the Chinese-Brazilian Earth observation satellite CBERS 4A and other small satellites. FloripaSat-1 transmits in the 145MHz and 436MHz Amateur satellite bands using the NGHam protocol developed by Jon Petter Skagmo LA3JPA in 2014. NGHam is intended as a modern replacement for AX.25 in packet radio. It uses a 32 bit syncword, a CCSDS scrambler, and Reed-Solomon FEC. Additionally, FloripaSat-1 transmits also using AX.25, for retrocompatibility and performance comparison.

The information published online about the protocols used by FloripaSat-1 makes a great impression at first. There are descriptions of the coding and telemetry format and an open source decoder. However, a deeper look reveals many flaws. The documentation doesn’t describe accurately or in enough detail what the satellite is transmitting, and several functions are not implemented in the open source decoder. To my best knowledge, the NGHam Reed-Solomon and the whole AX.25 implementations in the satellite seem to be broken, and these are not implemented in the decoder.

Nevertheless, I have added a decoder for FloripaSat-1 to gr-satellites maint-3.8 branch, covering the functions that do work. This post gives a closer look at some of the technical details.

Plotting spectrum measurements by SMOG-P

The SMOG-P 1P PocketQube that was launched recently has an interesting payload: a UHF spectrum monitor that records power spectral density measurements. Lately, I have been adding support in gr-satellites to decode the telemetry frames transmitted by SMOG-P and ATL-1 (which also carries a similar spectrum monitor), using the code published here as a reference.

As a result of this work, now it is possible to save and plot the spectrum data transmitted by SMOG-P and ATL-1 using gr-satellites. This post explains how.

SMOG-P short codes

In my previous post I talked about the FEC used by the SMOG-P and ATL-1. In there, I reverse-engineered the long frames transmitted by SMOG-P and found that they use the AO-40 FEC protocol.

After publishing that post I started reverse-engineering the short frames. Meanwhile, Peter Horvath pointed me to a Github repository containing an implementation of the FEC used for short frames and long frames. I hadn’t seen that repository before (it’s not easy to search for SMOG-P or ATL-1 in Google, as many unrelated results come up). Indeed this repository contains the source of a FEC decoder for the short frames, so there is no need to reverse-engineer it.

Timur Kristóf, the author of that repository, says that the team plans to release the source for the decoder, but that they are currently very busy with the early operations of the satellites. This is very good news.

I have studied the code in the Github repository and included a decoder for the short FEC frames in gr-satellites.

Decoding SMOG-P and ATL-1

Last Friday, an Electron rocket from Rocket Lab was launched from Mahia Launch Complex, New Zealand, carrying the ALE-2 microsatellite and 6 PocketQubes into a 400km polar orbit. Two of these PocketQubes are SMOG-P and ATL-1 from Budapest University of Technology and Economics.

They transmit in the 70cm Amateur satellite band, and although they have beeen successfully coordinated with IARU (see here and here), documentation about the protocols they use has not been published. There is some groundstation software available here, but the interesting part is implemented in the atlgnd_x86_64 and smogpgnd_x86_64 binary executables, for which source code is not available. As far as I know both satellites transmit using the same (or very similar) protocols.

In this post I describe my first attempts at reverse-engineering the transmissions of SMOG-P, with successful results. Preliminary support for decoding SMOG-P and ATL-1 has been added to gr-satellites in the maint-3.8 branch.