Space – Page 19 – Daniel Estévez

Światowid image decoder

Yesterday I spoke about the Światowid image downlink protocol. Today, Piotr Kuligowski SQ4NOW has published an image that he has been able to decode from Światowid. The image was taken at around 3:29 UTC and downlinked at 6:38 UTC over Warsaw.

Looking at SatNOGS recordings of this event, I have noticed that the image data is sent with sequence numbers, contrary to what I stated in the description of the protocol in my previous post. This is something that SatRevolution must have added down the road, since it wasn’t present when I worked with them in June.

The protocol is as I described, but the first two bytes of each Reed-Solomon block are used as a little-endian block counter. The remaining 46 bytes are used to send the JPEG file data. The block counter is reset to zero at the start of a new file, and is increased for each Reed-Solomon block.

This block counter allows for automatic detection of lost blocks and start of new images, so I have added an image decoder to the Światowid decoder in gr-satellites. The decoder is based on the 1KUNS-PF image decoder. If there are missing blocks, gaps full of zeros are inserted in the JPEG file in their position. This allows easily merging files decoded from different groundstations just by ORing the files.

As an example showing the image decoder, I have processed this SatNOGS recording, which was made by the station of Cees Bassa in the Netherlands. To process a SatNOGS recording with the gr-satellites decoder, the OGG audio must be converted to WAV (using oggdec, for example), and the gain of the “Multiply Const” block in swiatowid.grc must be changed from 10 to 1, since SatNOGS recordings usually have too much gain.

The recording only contains the beginning of the transmission. The pass was west to east and the transmission was done when the satellite was in view of Warsaw, so by the middle of the transmission the satellite is already below the horizon in the Netherlands. Still, 1128 blocks could be decoded correctly. This amounts to 51888 bytes. The complete file is 204796 bytes long.

The partial image decoded from the SatNOGS recording is shown below.

Image transmitted by Światowid on 2019-08-31 06:38 (partial)

This image matches the one that Piotr has shown on Twitter. I find it interesting that the SatRevolution logo is already added on-board the satellite to the top left corner of the image.

Decoding Światowid

Światowid is an Earth observation 2U cubesat built by the Polish company SatRevolution. It carriers a camera with a resolution of 4 metres per pixel and an Amateur radio U/V FM transponder that was never activated due to power budget constraints. The cubesat was launched to the ISS on April 17 this year and released in orbit on July 3. It transmits on the 70cm Amateur satellite band, using 1k2 AFSK AX.25 APRS plaintext for telemetry and 9k6 FSK with a custom protocol for downlinking the camera images. According to the IARU frequency coordination sheet and SatRevolution, it can also transmit images in the 13cm Amateur satellite band at 500kbps.

During June, I worked under a contract with SatRevolution to adapt gr-satellites for their use with Światowid and KRAKsat. Since I am well aware of the problem of private companies using the Amateur satellite bands as “free spectrum” for their satellites, when I was first contacted by SatRevolution regarding this project I did a small background check and saw that Światowid and KRAKsat had obtained an IARU frequency coordination successfully.

I also showed my IARU R1 proposal to SatRevolution and told them that, even though I was signing an NDA for the project, according to ITU regulations they had to publish all the details for the protocols they used on Amateur bands. Formally, these details were not covered by the NDA, and we also agreed that the modified version of gr-satellites would be publicly released under the GPLv3. The decoder was released here on July 4, and this was also announced by SatRevolution on Twitter.

Some Amateurs were not at all happy with the news that the FM transponder was not going to be activated, and accused SatRevolution of adding only the FM transponder to get through the IARU coordination, without having any real intention to activate it, of possibly causing interference to SO-50 and of not giving back anything to the community. However, all of this happened by the time I was already finishing my project with SatRevolution.

After finishing this project, I didn’t merge back to the main version of gr-satellites any of the modifications I did for SatRevolution, and I am not aware of SatRevolution having published any technical information about the 9k6 custom protocol used by Światowid. I didn’t see any reports of people receiving the 9k6 signal (only the APRS telemetry beacon was often seen), so I didn’t consider sorting this out as a priority, since I wasn’t even sure if the 9k6 protocol was actually being used (maybe they were only using S-band to download the images).

A couple days ago, I saw that Piotr Kuligowski SQ4NOW, Maciej Nowak and Tomek SP9TMQ, from the PW-Sat2 team managed to decode one of the images transmitted by Światowid using the 9k6 custom protocol. Talking with Piotr, I learned that they had used my modified gr-satellites version, but as it didn’t provide a complete solution to decode images (below I explain what was missing), they had to do some reverse engineering of the custom protocol.

Now that I’ve learned about the effort of Piotr, Maciej and Tomek, I have decided to add a complete decoder solution for the Światowid 9k6 custom protocol to the main gr-satellites version and to write this post to document completely the protocol.

Software for my QO-100 groundstation

You may have heard about my groundstation for QO-100 (Es’hail-2), which is based on a BeagleBone black and a LimeSDR Mini. A description of this station appeared in a LimeSDR field report. However, I haven’t spoken in detail about the software yet, since I was testing various things and using a makeshift setup until I had some time to put together a solution that I really liked.

Now I am quite happy with the result and indeed I have decided to start up a Github repository with the software I am using in case anyone finds it useful. This post is a description of the software I am using for the narrowband transponder.

Galileo outage revisited

A few weeks ago, a presentation by Octavian Andrei, of the Finnish Geospatial Research Institute, appeared in YouTube showing technical details about the Galileo constellation outage that happened between July 12 and 16. In the presentation, Octavian studies the navigation data gathered by a geodetic receiver in Metsähovi, showing anomalies in some of the parameters of the navigation message, such as the \(\text{IOD}_{\text{nav}}\), the SISA (signal in space accuracy) and the DVS (data validity status).

Back in July, I looked at the navigation data from the outage in this post, where I used navigation RINEX files collected by the IGS MGEX to study changes and anomalies in the navigation message. In that post I concentrated on July 16 and 17, to show what happened as the system was coming back online. Octavian has discovered some very interesting anomalies that happened before the incident, on July 10 and 11. Indeed, the first anomaly happened at 13:40 GST on July 10, well before July 11 21:50 GST, when the navigation message stopped being updated.

Thus, in view of Octavian’s discoveries, I have revisited my study, including also data from July 10 and 11, and paying special attention to the \(\text{IOD}_{\text{nav}}\) parameter, which can be seen to have the most interesting behaviour in Octavian’s presentation.

Trying to find the DSLWP-B crash site

As you may well know, DSLWP-B, the Chinese lunar orbiting Amateur satellite crashed with the Moon on July 31 as a way to end its mission without leaving debris in orbit. I made a post with my prediction, which showed the impact point southeast of Mare Moscoviense, in the far side of the Moon. Phil Stooke was more precise and located the impact point near the Van Gent crater.

Our plan is to get in contact with the LRO team and try to find the crash site in future LRO images. We are confident that this can be done, since they were able to locate the Beresheet impact site a few months ago. However, to help in the search we need to compute the location of the impact point as accurately as possible, and also come up with some estimate of the error to define a search area where we are likely to find the crash. This post is a detailed account of my calculations.

Transmitting through QO-100 with the LimeNET Micro and LimeRFE

A couple weeks ago, I did a demo where I showed the LimeRFE radio frequency frontend being used as an HF power amplifier to transmit WSPR in the 10m band. Another demo I wanted to do was to show the LimeNET Micro and LimeRFE as a standalone 2.4GHz transmitter for the QO-100 Amateur radio geostationary satellite.

The LimeNET Micro can be best described as a LimeSDR plus Raspberry Pi, so it can be used as an autonomous transceiver or remotely through an Ethernet network. The LimeRFE has a power amplifier for 2.4GHz. According to the specs, it gives a power of 31dBm, or a bit over 1W. This should be enough to work QO-100 with a typical antenna.

You may have seen the field report article about the QO-100 groundstation I have in my garden. It is based around a LimeSDR Mini and BeagleBone Black single board ARM computer. The groundstation includes a driver amplifier that boosts the LimeSDR to 100mW, and a large power amplifier that gives up to 100W. The LimeSDR Mini and BeagleBone Black give a very similar functionality to the LimeNET Micro, but the LimeNET Micro CPU is more powerful.

The idea for this demo is to replace my QO-100 groundstation by the LimeNET Micro and LimeRFE, maintaining only the antenna, which is a 24dBi WiFi grid parabola, and show how this hardware can be used as a QO-100 groundstation.

Precise orbit determination for Lucky-7

In one of my previous posts, I used measurements from the GPS receiver on-board the Lucky-7 cubesat in order to find the TLE that best matched its orbit, and help determine which NORAD ID corresponded to Lucky-7.

Now I have used the same GPS measurements to perform precise orbit determination with GMAT. Here I describe the results of this experiment.

More DSLWP-B lunar surface images identified

In my last posts about DSLWP-B, I have been showing all the images of the lunar surface that were taken by the satellite during the last weeks of the mission, and tried to identify to which area of the Moon each image corresponded. For several of them, I was able to give a good identification using Google Moon, but for many of the latest images I was unable to find an identification, since they show few or none characteristic craters.

Thus, for these images I only gave a rough prediction of which area of the Moon was imaged by using GMAT and the published ephemeris from dslwp_dev. This doesn’t take into account camera pointing, orbit or shutter time errors.

Phil Stooke has become interested in this and he has managed to identify many of the images, even some containing very little detail, which I find impressive. No wonder, Phil is the author of several atlases of space exploration of the Moon and Mars, so he knows a lot of lunar geography.

Phil tells me that he has used Quickmap, which is a very nice tool that I didn’t know of. It is much more powerful than Google Moon. He recommends to switch to an equidistant cylindrical projection and set as a basemap layer the “WAC mosaic (no shadows) map”, which contains images with the sun directly overhead. This resembles the images taken by DSLWP-B better, since these are always taken with the sun at a high elevation, because the camera always points away from the sun. It is interesting to see how the appearance of the surface changes between the “no shadows” and “big shadows” maps.

In this post I show the locations of the images identified by Phil.

DSLWP-B last activities and end of mission

As probably you all know, the Chinese Amateur lunar orbiting satellite DSLWP-B was expected to collide with the Moon on July 31 at 14:20 UTC, so this is the last report about the DSLWP-B activities. The collision was planned since January this year, and was done as a means to end the mission without leaving debris in lunar orbit.

The activation slots for the Amateur payload on-board DSLWP-B for this week were the following:

29 Jul 00:15 to 02:15
29 Jul 04:30 to 06:30
29 Jul 20:00 to 22:00
30 Jul 05:30 to 07:30
30 Jul 16:20 to 18:20
31 Jul 06:30 to 08:30
31 Jul 13:24 to 15.24
1 Aug 05:30 to 07:30

I had calculated a periapsis height of -62km for the July 31 orbit, so the collision with the Moon was quite certain, even taking orbit errors into account. However, a slot was set on August 1 just in case the collision didn’t happen.

This post summarizes the activities done this week with DSLWP-B and the end of the mission.

DSLWP-B activities for the fourth week of July

During the fourth week of July, the Amateur payload on-board DSLWP-B was active in the following slots.

22 Jul 06:14 to 08:14
22 Jul 22:40 to 23 Jul 00:40
23 Jul 23:20 to 24 Jul 01:20
25 Jul 00:30 to 02:30
26 Jul 10:55 to 12:55
27 Jul 02:30 to 04:30
28 Jul 03:30 to 05:30

Additionally, Wei Mingchuan BG2BHC shared on Twitter the 10 minute slots for the activations of the X band transmitter. This transmitter uses a frequency of 8478MHz (in the Deep Space X band) and 2Mbps BPSK with CCSDS standards. The transmit power is 2W and the gain of the small X-band dish is 22dBi. The signal is detectable with small stations (as shown here), but to demodulate the data a large dish is needed. The Chinese DSN uses 35m and 50m antennas to receive this signal.