NPR: Hamnet over 70cm

Some days ago, Guillaume F4HDK emailed me to introduce me his latest project, NPR (New Packet Radio). This is an open-source modem designed to carry IP traffic over the 70cm Amateur radio band, with data rates of up to 500kbps. The goal of this modem is to be used for the Hamnet Amateur radio IP network, to give access to end users where coverage on the 2.3GHz and 5GHz bands is poor due to the terrain.

Guillaume knew that I had worked on IP over 70cm with my CC1101 and Beaglebone black project, so he wanted to know what I though about NPR. After reading all the available documentation, I found NPR very interesting. Indeed, Guillaume has come up with clever ways of solving some of the difficulties I foresaw when planning out my experiments with the CC1101.

The most important aspect about NPR is that it is already a finished product that people can build as a kit and start using. My experiments with the CC1101 were a mixture of proof of concept and play around, and never progressed from that stage due to lack of interest in my local Amateur community. However, Guillaume has put a lot of time, thought and effort in developing NPR. Of course the project can evolve further, but it is usable in its present stage. In what follows, I do a detailed analysis of the technical aspects of NPR.

Recovering an image transmitted by DSLWP-B

The image accompanying this post has a nice story to it. It was taken by the Amateur camera in DSLWP-B, the Chinese microsatellite in lunar orbit. On February 27, a download of this image was attempted by transmitting the image in SSDV format in the 70cm band and receiving it in the Dwingeloo radiotelescope, in the Netherlands.

The download was attempted twice, but due to errors in the transmission, a small piece of the image was still missing. Today, the Amateur payload of DSLWP-B was active again, and the plan was to download the missing piece, as well as other images. However, after the payload turned on and transmitted its first telemetry beacons, we discovered that the image had been overwritten.

The camera on-board DSLWP-B has a buffer that stores the last 16 images taken. Any of these images can be selected to be transmitted (completely or partially) while the Amateur payload is active. An image can be taken manually by issuing a command from ground. Besides this, every time the Amateur payload powers on, an image is taken. Of course, taking new images overwrites the older ones.

This is what happened today. The image we wanted to download was the oldest one in the buffer and got overwritten as soon as the payload turned on. This is a pity, especially because there was another activation of the payload last Friday, but a large storm in Germany prevented Reinhard Kuehn DK5LA’ from moving his antennas safely, so the satellite couldn’t be commanded to start the download.

After seeing that the image had been overwritten, Tammo Jan Dijkema suggested that I try to recover manually the missing chunk in the recording made on February 27. As you can see, I was successful. This is a report of how I proceeded.

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

An STRF crash course

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. 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.

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.

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.

FUNcube telemetry submitter for gr-satellites

After doing a PW-Sat2 telemetry submitter, I’ve set out to add an telemetry submitter for the FUNcube telemetry server. I’ve been in contact with Dave Johnson G4DPZ, who has been kind enough to send me a Java example explaining how the submission protocol works.

The protocol is very simple. It is based on a HTTP POST request whose content is the telemetry frame in hex. To prevent spoofing, some sort of HMAC formed by an MD5 digest of the message concatenated with a user-specific authorization code is used in the POST url. The authorization code is distributed to each user when registering on the server. The Python implementation of the telemetry submitter is here.

To use the submitter in gr-satellites, you need to obtain your Site Id (or username) and the Authorization code (which is usually sent to you by email when registering). See the README for how these parameters have to be specified in the decoder.

Decoding ESEO

ESEO is an educational satellite project for university students led by ESA. It is a microsatellite based on the S-50 platform by SITAEL and indeed serves as an in-orbit validation of that platform. It carries payloads developed by students in 10 European universities, and also a FUNcube payload from AMSAT-UK. It was launched last Monday in the SSO-A launch.

The satellite transmits 9k6 GFSK telemetry in the 70cm Amateur satellite band (do not confuse this telemetry with the telemetry sent by the FUNcube payload in the 2m Amateur satellite band). Last week I wrote an open letter to the directors of the ESEO program requesting the publication of the complete specifications for this telemetry. The existing documentation is published here as two documents called attachment 1, which describes the coding of the frames, and attachment 2, which describes the structure of the telemetry frames.

The main problem motivating my open letter was that the information in attachment 2 was insufficient to produce a telemetry decoder for ESEO. However, last Tuesday an updated version of this document was published. This new version seems to include all the information we need. Apparently, this new version has been published due to my open letter and the pressure made by some people at ESA surrounding the ESEO project.

I would like to thank all the people that have expressed their opinion about the importance of having well documented protocols in the Amateur radio service, as well as all the people in ESA that have pushed for the publication of the documentation, and understood that this is an important matter.

In this post we look at the coding used by ESEO, that is, everything described in attachment 1, and how the decoder in gr-satellites is implemented.