Space – Page 20 – Daniel Estévez

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.

DSLWP-B mission end prediction

Back in May, I spoke about the future collision of DSLWP-B with the lunar surface. It would happen on July 31, thus putting and end to the mission. Now that the impact date is near, I have run again the calculations with the latest ephemeris in order to have an accurate simulation of the event.

The ephemeris I’m using consist of a Moon centred ICRF Keplerian state vector which has been shared by Wei Mingchuan BG2BHC. In GMAT, this state vector is as follows:

DSLWP_B.Epoch = '25 Jul 2019 02:30:00.000';
DSLWP_B.CoordinateSystem = LunaICRF;
DSLWP_B.SMA = 8708.404;
DSLWP_B.ECC = 0.747921;
DSLWP_B.INC = 44.157;
DSLWP_B.RAAN = 52.405;
DSLWP_B.AOP = 86.261;
DSLWP_B.TA = 165.00062091131025;

Using this GMAT script, I have obtained that the impact will happen on 2019-07-31 14:19:57 UTC, near Mare Moscoviense, in the lunar far side. This result is quite close to the calculations I did in May, which predicted an impact at 14:47 UTC.

The images below show the impact simulation in GMAT. Since the impact happens on the far side of the Moon, it will not be visible from Earth. There is an activation of the Amateur payload onboard DSLWP-B for 2019-07-31 13:24 to 15:24 UTC. The satellite will hide behind the Moon around 14:08 UTC. If the Moon was not solid, DSLWP-B would reappear around 14:35 UTC. The absence of radio signals after this moment will confirm that the impact has occurred.

DLSWP-B impact orbit in GMAT (view of Earth and Moon)

Ground track and location of DSLWP-B impact in GMAT

Lucky-7 TLE matching using GPS data

SkyFox Labs is having some trouble identifying the TLE corresponding to their Lucky-7 cubesat. The satellite was launched on July 5 in launch 2019-038 and a good match among the TLEs assigned to that launch has not being found yet. Over on Twitter, Cees Bassa has analyzed some SatNOGS observations and he says that NORAD ID 44406 seems the best match. However, this TLE has already been identified by Spire as belonging to one of their LEMUR satellites.

Fortunately, Lucky-7 has an on-board GPS receiver, and the team has been collecting position data recently. This data can be used to match a TLE to the orbit of the satellite, and indeed is much more accurate than the Doppler curve, which is the usual method for TLE identification.

Jaroslav Laifr, from the Lucky-7 team, has sent me the data they have collected, so that I can study it to find a matching TLE. The study is pretty simple to do with Skyfield. I have obtained the most recent TLEs for launch 2019-038 from Space-Track and computed the RMS error between each of the TLEs and the GPS measurements. The results can be seen in this Jupyter notebook.

The best match is NORAD ID 44406, with an RMS error of 8.7km. The second best match is NORAD ID 44404 (which is what SatNOGS has been using to track Lucky-7), with an RMS error of 51.3km. Most other objects have an error larger than 100km.

Therefore, my conclusion is clear. It is very likely that Spire misidentified NORAD ID 44406 as belonging to LEMUR 2 DUSTINTHEWIND early after the launch, when the different objects hadn’t drifted apart much. NORAD ID 44406 is a good match for Lucky-7. It will be interesting to see what Spire says in view of this data.

Lucky-7 decoded

Lucky-7 is a Czech Amateur 1U cubesat that was launched on July 5 together with the meteorological Russian satellite Meteor M2-2 and several other small satellites in a Soyuz-2-1b Fregat-M rocket from Vostochny. The payload it carriers is rather interesting: a low power GPS receiver, a gamma ray spectrometer and dosimeter, and a photo camera.

It transmits telemetry in the 70cm Amateur satellite band using 4k8 FSK with an Si4463 transceiver chip. Additional details about the signal can be found here.

After some work trying to figure out the scrambler used by the Si4463, I have added a decoder for Lucky-7 to gr-satellites. This post shows some of the technical aspects of the decoder.

DSLWP-B activities for the third week of July

During this week, the Amateur payload of DSLWP-B was active during the following slots:

14 Jul 19:00 to 21:00
15 Jul 12:00 to 14:00
17 Jul 04:40 to 06:50
18 Jul 20:50 to 22:50
20 Jul 14:20 to 16:20
21 Jul 05:30 to 07:30

Among these, the Moon was visible from Europe only on July 14, 18 and 21, so Dwingeloo only observed these days, which were mainly devoted to the download of SSDV images of the lunar surface. As usual, the payload took an image automatically at the start of each slot, so some of the slots were used for autonomous lunar imaging, even though no tracking was made from Dwingeloo.

This post is a detailed account of the activities done with DSLWP-B during the third week of July.

Galileo operational again

In my previous post I wrote about the outage of the Galileo EU satellite navigation constellation that started on 2019-07-12 01:50 GST. For several days, all the Galileo satellites kept transmitting the same batch of ephemeris, which corresponded to 2019-07-11 21:50 GST, rather than sending updated batches of ephemeris.

This situation continued until around 2019-07-16 19:00, when several people reported that they were receiving updated ephemeris from some Galileo satellites. These ephemeris could be used for navigation correctly. The NAVSAS group from University of Torino has published a post where they show, for each satellite, when the updated ephemeris were first received by their equipment in Torino, Italy.

The restoration of the system was publicly announced with NAGU 2019027, published on 2019-07-18 08:20. This NAGU stated that starting from 2019-07-17 20:52 the service was restored, but users might experience some instability.

It is interesting to look at the MGEX broadcast ephemeris to see what happened between 2019-07-16 19:00, when users started to see updated ephemeris, and 2019-07-18, when the system was considered to be fully restored. In this post, I do a detailed analysis of the broadcast ephemeris.