Posts

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.

In the QO-100 (Es’hail 2) narrow band transponder, the recommendation for the adjustment of your downlink signal power is not to be stronger than the beacon. This was also the recommended usage of the old AO-40. Since the transponder has two beacons marking the transponder edges: a CW beacon marking the lower edge and a 400baud BPSK beacon marking the upper edge, there has been some debate on Twitter about which beacon does this recommendation refer to and what does “stronger” mean.

Of course, more formally, signal strength means power, which is a well defined physical concept, so there should be no argument about what does power mean. However, there are two different power measurements used for RF: average power and peak envelope power. I will assume that the recommendation refers to average power, not to peak envelope power. This makes more sense from the point of view of the power budget of the satellite amplifier (The total average power it needs to deliver is just the sum of the average powers of the signals of all the users, while the behaviour of the peak envelope power is much more complicated).

Also, I think that using peak envelope power for this restriction would be a very strict requirement on high PAPR signals. Note that the PAPR of CW is 0dB and the PAPR of BPSK is between 2 and 3dB, depending on the pulse shaping, so these are rather low PAPRs. For comparison, a moderately compressed SSB voice signal has a PAPR of 6dB.

In my opinion, the main problem with these discussions about “signal strength” is that many people are trying to judge power by looking at their waterfall or spectrum display and seeing what signal looks “higher”. This kind of measurement is not any good, because it doesn’t take signal bandwidth into account, depends on the FFT size, the window function, etc. It doesn’t help that many popular SDR software don’t have a good signal meter displaying the average power of the signal tuned in the passband.

In any case, I was curious about whether the power of the two beacons is the same and whether there is any interesting change over time. I have made a GNU Radio flowgraph that measures the power of each of the two beacons and of the transponder noise, and saves them to a file for later analysis.

As you may know, between January 14 and February 18 I have been away from home on a research expedition to Antarctica. Several people have asked me for a post detailing my experiences, and I was also thinking to write at least something about the trip. I could spend pages talking about the amazing landscapes and fauna, or daily life in Antarctica. However, in keeping with the spirit of this blog, I will concentrate on the radio related aspects of the trip (and there are indeed enough to tell a story). If I see that there is much interest in other topics, I might be persuaded to run a Q&A post or something similar.

Apparently, my trip and my posts in Twitter raised the attention of a few Hungarian Amateurs, who even discussed and followed my adventures in their Google group. Thanks to Janos Tolgyesi HG5APZ for his interest and for some good discussion over email during my voyage.

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:53Packet number 69L 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

As you may know, I am on a scientific expedition in Antarctica until mid-February. Currently I am in the Spanish base Gabriel de Castilla, where we have relatively good satellite internet access. As I have some free time here, I have updated the DSLWP-B camera planning to reflect the upcoming observations announced by Wei Mingchuan BG2BHC on 2019-02-03 14:30 and 2019-02-04 08:20.

As we can see in the figure below, the Earth will be very near to the centre of the image, since there is a new Moon on February 4 (recall that the DSLWP-B camera points away from the Sun, so the Earth is visible on the camera when there is a new Moon, as the Earth is then opposite to the Sun, as seen from the Moon).

The observation times have been selected taking into account the orbit around the Moon, so that the Moon is also visible on the image. On February 3 the Moon should be completely visible inside the camera field of view. On the contrary, on February 4, the Moon will only be partially visible inside the frame.

The figure below shows the angular distance between the centre of the Earth and the rim of the Moon. This kind of graph can be used to compute the times when the Earth crosses the Moon rim, allowing us to take an “Earthrise” image. There is an Earthrise event on February 4, during the time when the Amateur payload is active. Generally, an image is taken whenever the Amateur payload powers up, but in this case it could be possible to command the payload manually to take an image near the Earthrise event.

The figure below shows in detail the Earthrise event, with both edges of the Earth plotted. It seems that a good time to take the Earthrise image is on 2019-02-04 10:00 UTC.

Together with URE and AMSAT-EA, I have presented a proposal for the upcoming IARU R1 Vienna interim meeting 2019 addressing the problems derived from the use of Amateur satellite spectrum by universties, research institutions and private companies. The title of the proposal is “Satellites transmitting on Amateur bands with undocummented protocols or without permission”, and the text of the proposal can be found here.

This proposal addresses the problems caused both by satellites that are using undocummented protocols for their telemetry, so Amateurs are unable to decode their signals, and satellites that are transmitting without having obtained the appropriate IARU frequency coordination.

The number of small satellites that are launched each year seems to be growing steadily, and many satellite developers are resorting to the Amateur satellite service as a way to obtain free spectrum access, regardless of whether their mission fits the requirements for an Amateur satellite. I think that we must try to defend our Amateur bands and ensure that proper use is made of them. Hopefully this proposal is a first step in making people aware of the problem and trying to find solutions.

If you’ve been following my posts about Es’hail 2, you’ll know that shortly after launch Es’hail 2 was stationed in a test slot at 24ºE. It remained in this slot until December 29, when it started to move to its operational slot at 26ºE. As of January 2, Es’hail is now stationed at 26ºE (25.8ºE, according to the TLEs).

The new GEO orbit at 26ºE is much more perfect than the orbit it had at 24ºE. This is to be expected for an operational orbit. Since December 30, I’ve been recording Doppler data of the satellite moving to its operational slot, and I have found some interesting effects of orbital dynamics in the data. This post is an account of these.

Recently, the STRF satellite tracking toolkit for radio observations by Cees Bassa has been gaining some popularity. This toolkit allows one to process RF recordings to extract frequency measurements and perform TLE matching and optimization via Doppler curves. Unfortunately, there is not a lot of documentation for this toolkit. There are some people that want to use STRF but don’t have a clear idea of where to start.

While I have tested very briefly STRF in the past, I had never used it for doing any serious task, so I’m also a newcomer. I have decided to test this tool and learn to use it properly, writing some sort of walk-through as I learn the main functionality. Perhaps this crash course will be useful to other people that want to get started with STRF.

As I have said, I’m no expert on STRF, so there might be some mistakes or omissions in this tutorial that hopefully the experts of STRF will point out. The crash course is organized as a series of exercises that explain basic concepts and the workflow of the tools. The exercises revolve around an IQ recording that I made of the QB50 release from ISS in May 2017. That recording is interesting because it is a wide band recording of the full 70cm Amateur satellite band on an ISS pass on May 29. During a few days before this, a large number of small satellites had been released from the ISS. Therefore, this recording is representative of the TLE lottery situation that occurs after large launches, where the different satellites haven’t drifted much yet and one is trying to match each satellite to a TLE.

The IQ recording can be downloaded here (16GB). I suggest that you download it and follow the exercises on your machine. After you finish all the exercises, you can invent your own. Certainly, there is a lot that can be tried with that recording.

A number of supporting files are created during the exercises. For reference, I have created a gist with these files.

Since I published my Es’hail 2 Doppler measurement experiments, Jean Marc Momple 3B8DU has become interested in performing the same kind of measurements. The good thing about having several stations measuring Doppler simultaneously is that you can perform differential measurements, by subtracting the measurements done at each station. This eliminates all errors due to transmitter drift, since the drift is the same at both stations.

Of course, differential measurements need to be done with distant stations, to ensure different geometry that produces different Doppler curves in each station. Otherwise, the two stations see very similar Doppler curves, and subtracting yields nothing.

The good thing is that Jean Marc is in Mauritius, which, if you look at the map, is on the other side of the satellite compared to my station. The satellite is at 0ºN, 24ºE, my station is at 41ºN, 4ºW, and Jean Marc’s is at 20ºS, 58ºE. This provides a very good geometry for differential measurements.

Some days ago, Jean Marc sent me the measurements he had done on December 22, 23 and 24. This post contains an analysis of these measurements and the measurements I took over the same period, as well as some geometric analysis of Doppler.

It would be interesting if other people in different geographic locations join us and also perform measurements. As I’ll explain below, a station in Eastern Europe or South Africa would complement the measurements done from Spain and Mauritius well. If you want to join the fun, note a couple of things first: The Doppler is very small, around 1ppb (or 10Hz). Therefore, you need to have everything locked to a GPS reference, not only your LNB. Also, the change in Doppler is very slow. The Doppler looks like a sinusoidal curve with a period of one day. To obtain meaningful results, continuous measurements need to be done over a long period. At least 12 hours, and preferably a couple days.

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.