DSLWP-B crash site found

Back in August, I posted about my calculations of the site where DSLWP-B impacted with the lunar surface on July 31. The goal was to pass the results of these calculations to the Lunar Reconnaissance Orbiter Camera team so that they could image the location and try to find the impact crater.

Yesterday, the LROC team published a post saying that they had been able to find the crash site in an image taken by the LRO NAC camera on October 5. The impact crater is only 328 metres away from the location I had estimated.

This is amazing, as in some way it represents the definitive end of the DSLWP-B mission (besides all the science data we still need to process) and it validates the accuracy of the calculations we did to locate the crash site. I feel that I should give due credit to all the people involved in the location of the impact.

Wei Mingchuan BG2BHC from Harbin Institute of Technology was the first to take the orbital information from the Chinese Deep Space Network, perform orbit propagation and compute the crash location assuming a spherical Moon, thus obtaining an approximate position in Van Gent X crater. Cees Bassa from ASTRON refined Wei’s calculations by including a digital elevation model. Phil Stooke from Western University first suggested to use a digital elevation model, helped us contact the LROC team, and filled in an observation request for the camera. And of course the LROC team and the Chinese DSN, since the quality of their ephemeris for DSLWP-B allowed us to make a rather precise estimate.

The LROC team has posted the images shown below, where in a comparison between an image taken in 2014 and the image taken in October the small crater can be seen.

DSLWP-B crash site image

The image of the crash is M1324916226L, an image taken by the left NAC camera. However, I can’t find this image yet in the LROC archive, so it seems this image hasn’t been made public yet.

The small crater, which the LROC team estimate to be 4×5 metres in diameter, is visible more clearly if we compute the difference between the before and after images (an idea of Phil Stooke). The figures below show this difference both as a signed quantity and as an absolute value.

Difference in the before and after images
Absolute value of the difference between before and after images

Though my eye fails to see it, the LROC team says that the long axis of the crater is oriented in a southwest-northeast direction. This is consistent with the direction of the impact, since DSLWP-B was travelling towards the northeast.

For the comparison with the October 5 image, the LROC team has chosen an image taken with a similar illumination angle. In fact, the lunar phase in both images only differs in 10º, so the shadows are very similar, with the sun located towards the southwest. In fact, the newest image of the area was taken on 2018-10-16, but the one from 2014 probably gave the most similar illumination conditions.

In my post in August I included a link to Quickmap showing the estimated area of the impact. Now I have marked in red the location of the crash. For a sense of scale, the large crater northwest of the crash is some 50 metres in diameter. You can see both points in Quickmap here.

Location of DSLWP-B crash (red) and estimate (blue)

It is good to go back to all the simulations I did to have an idea of what the 328m error represents. My final simulation was done with the ephemeris from July 25, so they were 6 days old at the moment of impact. When I used the ephemeris from July 18, the position of the impact changed by 231m, while the ephemeris from June 28 yielded a change of 496m. Therefore, it seems that an error of 300m is well in line with what we could expect of the precision of the Chinese DSN ephemeris.

The impact location computed by Cees Bassa was 2786m away from my estimate. The main problem with Cees’s estimate is that the orbital model he used considered spherical gravity for the Moon, while my studies showed that it was important to consider non-spherical gravity.

I did most of my simulations with a 10×10 spherical harmonic model for the Moon gravity, but to assess whether this was enough, I also made a simulation with a 20×20 spherical harmonic model. This yielded an impact point which was 74m away from the impact computed with the 10×10 model.

According to my Monte Carlo simulations with a 1km ephemeris error, the 1-sigma ellipse semi-axes of the impact position were 876m in the northeast direction and 239m in the southeast direction. With this information, I gave an educated guess of the position error of 600m in the northeast direction and 200m in the southeasth direction. The actual impact point is 328m northwest of my estimate, so somewhat higher than my error estimate but still within the 2-sigma ellipse. This leaves me quite happy with the quality of my estimate.

Can my station measure the QO-100 NB transponder LO stability?

Following a long discussion with Bernd Zoelgert DL2BZ about the frequency stability of the local oscillator of the QO-100 narrowband transponder, I have decided to try to measure the Allan deviation of the transponder. The focus here is on short-term stability, so we are concerned with observation intervals around \(\tau = 1 \mathrm{s}\).

Of course, as with any measurement problem, the performance of the measurement equipment should be better than the “device under test”. In this case, to measure the QO-100 LO it is necessary to compare it against a reference clock which is more stable (ideally an order of magnitude better).

My whole station is locked to a DF9NP GPSDO, which is a 10MHz VCTCXO disciplined by a uBlox LEA-4S GPS receiver. That’s great to measure long-term stability, but for short-term measurements you are essentially relying on the stability of the VCTCXO, which is not so great. Therefore, the whole purpose of this experiment is first to determine whether my station is actually able to measure the QO-100 LO or not. Spoiler: it turns out the answer is “no”, as in most articles whose title is phrased as a question.

Continue reading “Can my station measure the QO-100 NB transponder LO stability?”

Using an external reference with the LimeSDR Mini

A while ago I spoke about feeding an external reference to the LimeSDR USB. Now I wanted to use an external reference with the LimeSDR Mini that I have in my QO-100 groundstation to lock all the system to GPS. Preferably I wanted to use 27MHz as the reference, since this is what I am using in my LNB, so this would save me from having to run 10MHz or another frequency to the groundstation.

I wasn’t so sure how well this would work, since there are a few threads with questions in the MiriadRF forums, but I haven’t seen any explaining things in a clear way. There are different anecdotes of things that worked or didn’t work for several people, but not that many definitive answers. Among all the threads, this one seems mostly helpful.

Somewhat surprisingly, everything has worked well on the first try. I am now using a 27MHz external reference with my LimeSDR Mini. Hopefully this post will be of help to other people.

Continue reading “Using an external reference with the LimeSDR Mini”

Second alpha for gr-satellites 3

Following the first alpha, I have released today v3-alpha1, the second alpha for gr-satellites 3. As I introduced in September, gr-satellites 3 will be a large refactor of gr-satellites, bringing many UI and under-the-hood changes. I am releasing a series of alphas during the development to get feedback from users. Each of the alphas focuses on a different aspect.

The second alpha is focused on input and output formats. New functionality has been implemented to allow the user to choose the input and output in a flexible way. This post describes the main features added.

Continue reading “Second alpha for gr-satellites 3”

First alpha for gr-satellites 3

In my last post, I introduced my plans to do a large refactor of gr-satellites, which when ready will originate a version 3.0.0 running on GNU Radio 3.8. During the development of this refactor, I intend to release alpha versions showing important new concepts or functionalities. The main goal of this is both to test if my ideas work well in practice and that interested people can start testing the new software and give feedback.

I have now published the first alpha release, which is called v3-alpha0. In this post I describe the functionality implemented in this alpha and how to use the software.

Continue reading “First alpha for gr-satellites 3”

gr-satellites roadmap

In my talk at GRCon19 last week I presented the roadmap I have planned for gr-satellites for the next months and some longer term developments. The relevant slide can be seen below.

gr-satellites roadmap in my talk in GRCon19

Here I will describe the roadmap in more detail, including how certain things will be done (or how to find your way among the different releases and branches in the Github repository), in order to get feedback from the community.

Continue reading “gr-satellites roadmap”

Ephemeris quality during the Galileo outage

I have spoken about the Galileo incident that occurred in July in several posts already: here I took a look at the navigation message during the outage, here I used MGEX navigation RINEX files to look at the navigation message as the system was recovering, and here I did the same kind of study for the days preceding the outage. Other people, such as the NavSAS group from Politecnico di Torino, and Octavian Andrei from the Finnish Geospatial Research Institute, have made similar studies by looking at the \(\mathrm{IOD}_{\mathrm{nav}}\), data validity and health bits of the navigation message.

However, I haven’t seen any study about the quality of the ephemerides that were broadcast on the days surrounding the outage. The driving force of the studies has been whether the ephemerides were being updated or not, without taking care to check if the ephemerides that were broadcast were any good at all.

The NavSAS group commented seeing position errors of several hundreds of metres during the outage when using the broadcast ephemerides. That is to be expected, as the ephemerides were already many hours old (and indeed many receivers refused to use them, considering them expired). Here I will look at whether the ephemerides were valid (i.e., described the satellite orbit and clock accurately) in their time interval of applicability.

This post is an in-depth look written for a reader with a good GNSS background.

Continue reading “Ephemeris quality during the Galileo outage”

Measuring the ED4YAE 10GHz beacon

Last week, the 10GHz beacon ED4YAE on Alto del León was installed again after having been off the air for quite some time (I think a couple of years). The beacon uses a 10MHz OCXO and a 500mW power amplifier, and transmits CW on 10368.862MHz. The message transmitted by the beacon is DE ED4YAE ED4YAE ED4YAE IN70WR30HX, followed by a 5.8 second long tone.

On 2019-08-31, I went to the countryside just outside my city, Tres Cantos, to receive the beacon and do some measurements. The measurements were done around 10:00 UTC from locator IN80DO68TW. The receiving equipment was a 60cm offset dish from diesl.es, an Avenger Ku band LNB, and a LimeSDR USB. Everything was locked to a 10MHz GPSDO. The dish was placed on a camera tripod at a height of approximately 1.5 metres above the ground.

In this post I show the results of my measurements.

Continue reading “Measuring the ED4YAE 10GHz beacon”

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