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.

Continue reading “Extracting AX.25 satellites from SatNOGS DB”

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.

Continue reading “Third alpha for gr-satellites 3”

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.

Continue reading “First tests of a narrowband data modem for QO-100”

Decoding SSDV from JY1SAT

JY1SAT is a Jordanian 1U Amateur cubesat that carries a FUNcube payload by AMSAT-UK. As usual, the FUNcube payload on-board JY1SAT has a linear transponder with uplink in the 435MHz band and downlink in the 145MHz band, and a 1k2 BPSK telemetry transmitter in the 145MHz band. The novelty in comparison to the older FUNcube satellites is that the BPSK transmitter is also used to send SSDV images and Codec2 digital voice data.

Here I show how to decode the SSDV images using gr-satellites.

Continue reading “Decoding SSDV from JY1SAT”

An overview of IARU R1 interim meeting proposals

The IARU R1 interim meeting is being held in Vienna, Austria, on April 27 and 28. This post is an overview of the proposals that will be presented during this meeting, from the point of view of the usual topics that I treat in this blog.

The proposals can be found in the conference documents. There are a total of 64 documents for the meeting, so a review of all of them or an in-depth read would be a huge work. I have taken a brief look at all the papers and selected those that I think to be more interesting. For these, I do a brief summary and include my technical opinion about them. Hopefully this will be useful to some readers of this blog, and help them spot what documents could be more interesting to read in detail.

Continue reading “An overview of IARU R1 interim meeting proposals”

QO-100 beacon FEC decoder

Since the BPSK beacon on the QO-100 narrowband transponder was first activated, I had thought that it only transmitted messages using the AO-40 uncoded protocol. However, a Twitter conversation a few days ago with Rob Janssen PE1CHL convinced me that FEC messages might be sent in between uncoded messages.

The AO-40 FEC protocol used a concatenated code with a (160, 128) Reed-Solomon code and an r=1/2, k=7 convolutional code, together with scrambling and interleaving to achieve very good performance. The same protocol has then been used in the FUNcube satellites, so I have an AO-40 FEC decoder in gr-satellites since I added support for AO-73.

It is quite easy to notice that the QO-100 beacon transmits both uncoded and FEC messages. Indeed, using my gr-satellites decoder, I see that an uncoded message is transmitted every 23 seconds approximately. Since an uncoded message comprises 514 bytes, it takes 10.28 seconds to transmit it at 400baud, so something else must be sent between uncoded messages.

A FEC message is formed by 5200 symbols (after applying FEC), so it takes 13 seconds to transmit at 400baud. This gives us the total 23.28 seconds that I had observed between uncoded messages. Note that the contents of the uncoded and FEC blocks are different. An uncoded block contains 8 lines of 64 characters plus 2 bytes of CRC. A FEC block only contains 4 lines of 64 characters, and no CRC.

I have added a FEC decoder to the QO-100 decoder in gr-satellites, so that it now decodes both FEC and uncoded messages.

New decoders for Astrocast 0.1

A couple months ago, I added a decoder for Astrocast 0.1 to gr-satellites. I spoke about the rather non-standard FX.25 protocol it used. Since then, Mike Rupprecht DK3WN and I have been in contact with the Astrocast team. They noticed the mistake about using NRZ instead of NRZ-I, and in February 13 they sent a software update to the satellite to use NRZ-I instead of NRZ. However, the satellite has some failsafe mechanisms, so sometimes it is seen transmitting in the older NRZ protocol.

Mike has also spotted Astrocast 0.1 transmitting sometimes in 9k6, instead of the usual 1k2. This is used to download telemetry, and it is only enabled for certain passes. The coding used for this telemetry download is different from the FX.25 beacon. The team has published the following information about it. The coding follows CCSDS, using five interleaved Reed-Solomon encoders. A CCSDS scrambler is also used.

Following this variety of protocols, I have added new decoders for Astrocast 0.1 to gr-satellites. The astrocast.grc decoder does NRZ-I FX.25, and should be used for the beacon. The astrocast_old.grc decoder implements NRZ FX.25, and should be used for the beacon when the satellite is in failsafe mode. The astrocast_9k6.grc decoder serves to decode the 9k6 telemetry downloads. Sample recordings corresponding to these three decoders can be found in satellite-recordings.

Decoding the QO-100 beacon with gr-satellites

On February 14, the Amateur transponders on Es’hail 2 (which now has the AMSAT designation QO-100) were inaugurated. Since then, two beacons are being transmitted by the groundstation in Doha (Qatar) through the narrowband transponder. These beacons mark the edges of the transponder.

The lower beacon is CW, while the upper beacon is a 400baud BPSK beacon that uses the same format as the uncoded beacon of AO-40. I have already talked about the AO-40 uncoded beacon in an older post, including the technical details.

Based on my AO-40 decoder in gr-satellites, I have made a decoder for the QO-100 beacon. Patrick Dohmen DL4PD has been kind enough to write some instructions about how to use the old ao40_uncoded decoder with the BATC WebSDR. I recommend that you use the new qo100 decoder. You just have substitute ao40_uncoded by qo100 in Patrick’s instructions

As additional hints, I can say that for the best decoding, the beacon must be centred at 1.5kHz into the SSB passband. The centre of the signal is easy to spot because there is a null at the centre, due to the use of Manchester encoding. Frequency stability is somewhat important with this decoder, so if your LNB drifts too much you may run into problems.

The SNR of the beacon over the transponder noise floor is rather high, so you should achieve a clean decoding unless you are using a very small station and you have the transponder noise way below your receiver noise floor.

The following data is being currently transmitted on the beacon (the timestamps and packet numbers are added by gr-satellites):

2019-02-19 21:56:27
Packet number 68
K HI de QO-100 (DL50AMSAT BOCHUM
UPT: 3d 0h 29m CMD: 91 LEI_REQ: 0 LEI_ACT: 0
TEMP: 56 C VOLTAGES: 1.0 1.8 1.0 1.0 1.8 1.5 1.3 0.0 0.5 Volts
TFL: 0 TFE: 0 TFH: 0 HFF: 0 HTH: 0 HR: 0

2019-02-19 21:56:53
Packet number 69
L HI de QO-100 (DL50AMSAT BOCHUM
EXPERIMENTAL MODE. Measurements and tests being conducted,
experimental transponder use OK, but expect ground station tests
Watch this space and www.amsat-dl.org for further announcements

Decoding Astrocast 0.1

Astrocast 0.1 is an Amateur satellite built by the Lucerne University of Applied Sciences and Arts (Hochschule Luzern). It is an in-orbit demonstrator for a future constellation of small satellites providing L-band data services for internet of things applications. The Amateur payload includes an on-board GPS receiver and a PRBS ranging signal transmitter for precise orbit determination .

This satellite was launched on December 3 on the SSO-A launch, but we only have payed attention to it recently. Its IARU coordinated frequency is 437.175MHz (actually it is a bit strange, because the IARU coordination data speaks about Astrocast 0.2, which hasn’t been launched yet). However, the satellite appears to be transmitting on 437.150MHz.

As it turns out, we had an unidentified object transmitting on 437.150MHz. This object was first thought to be RANGE-A, which was also on the SSO-A launch, as this frequency was assigned to RANGE-A. However, the RANGE-A team confirmed that this wasn’t their satellite, and I wasn’t able to identify the modem used by the mystery 437.150MHz signal.

Yesterday, Mike Rupprecht DK3WN noticed that this unidentified signal corresponded to Astrocast 0.1, and sent me some technical documentation about the protocols used by this satellite. Using that information, I confirmed that the mystery satellite at 437.150MHz was indeed Astrocast 0.1 and now I have added a decoder to gr-satellites.

Continue reading “Decoding Astrocast 0.1”

D-STAR One Mobitex protocol decoded

D-STAR One are a series of Amateur satellites with an on-board D-STAR digital voice repeater. The first satellite of the series, called D-STAR One, was launched on November 2017 but was lost due to a problem with the upper stage of the rocket. The second satellite, called D-STAR One v1.1 Phoenix, was launched in February 2018 but never worked. On 27 December 2018, a Soyuz rocket launched the next two satellites in the series: D-STAR One Sparrow and D-STAR One iSat. I hear that, unfortunately, these two newer satellites haven’t been coordinated by IARU.

Besides using the D-STAR protocol, these two satellites also transmit telemetry in the 70cm Amateur satellite band using the Mobitex protocol, as described in the CMX990 modem datasheet. They use GFSK at 4800 baud.

In the past, I have talked about the Mobitex protocol in the context of the BEESAT satellites by TU Berlin. I described some notes about the Mobitex-NX variant used in these satellites, and contributed to the beesat-sdr GNU Radio decoder for the Mobitex-NX protocol.

Now, I have adapted the Mobitex-NX decoder to work also with the D-STAR One satellites, and added a decoder to gr-satellites. The decoder requires my fork of beesat-sdr to be installed.

Continue reading “D-STAR One Mobitex protocol decoded”