Experiments – Page 11 – Daniel Estévez

Aircraft reflections of a 2.3GHz beacon

A couple months ago, Andrés Calleja EB4FJV installed a 2.3GHz beacon in his home in Colmenar Viejo, Madrid. The beacon has 2W of power, radiates with an omnidirectional antenna in the vertical polarization, and transmits a tone and CW identification at the frequency 2320.865MHz.

Since Colmenar Viejo is only 10km away from Tres Cantos, where I live, I can receive the beacon with a very strong signal from home. The Madrid-Barajas airport is also quite near (15km to the threshold of runway 18R) and several departure and approach aircraft routes pass nearby, particularly those flying over the Colmenar VOR. Therefore, it is quite easy to see reflections off aircraft when listening to the beacon.

On July 8 I did a recording of the beacon from 10:04 to 11:03 UTC from the countryside just outside Tres Cantos. In this post I will examine the aircraft reflections seen in the recording and match them with ADS-B aircraft position and velocity data obtained from adsbexchange.com. This will show the locations and trajectories which produce reflections strong enough to be detected.

Amateur stations in the Perseids recording

In one of my latest posts I analysed the meteor scatter pings from GRAVES on a recording I did on August 11 (see that post for more details about the recording). The recording covered the frequency range from 142.5MHz to 146.5MHz and was 1 hour and 34 minutes long. Here I look at the Amateur stations that can be heard in the recording. Note that Amateur activity in meteor scatter communications increases considerably during large meteor showers, due to the higher probabilities of making contacts.

Detecting meteor scatter pings from GRAVES during the Perseids

GRAVES is a French space surveillance radar that transmits with very high power at 143.050MHz. It is easy to receive it from neighbouring countries via meteor scatter. During this year’s Perseids meteor shower I did a recording of GRAVES and the 2m Amateur band for later analysis. The recording was done at 08:56 UTC of Saturday 12th August and it is about 1 hour and 34 minutes long. Here I present an algorithm to detect and extract the meteor scatter pings from GRAVES.

Report for today’s DSLWP-B SSDV session

Today an SSDV transmission session from DSLWP-B was programmed between 7:00 and 9:00 UTC. The main receiving groundstation was the Dwingeloo radiotelescope. Cees Bassa retransmitted the reception progress live on Twitter. Since the start of the recording, it seemed that some of the SSDV packets were being lost. As Dwingeloo gets a very high SNR and essentially no bit errors, any lost packets indicate a problem either with the transmitter at DSLWP-B or with the receiving software at Dwingeloo.

My analysis of last week’s SSDV transmissions spotted some problems in the transmitter. Namely, some packets were being cut short. Therefore, I have been closely watching out the live reports from Cees Bassa and Wei Mingchuan BG2BHC and then spent most of the day analysing in detail the recordings done at Dwingeloo, which have been already published here. This is my report.

DSLWP-B corrupted SSDV frames

In my previous post I looked at the first SSDV transmission made by DSLWP-B from lunar orbit. There I used the recording made at the Dwingeloo radiotelescope and showed how to decode the SSDV frames and produce a JPEG image.

Only four SSDV frames where transmitted by DSLWP-B, and out of those four, only two could be decoded correctly. I wondered why the decoding of the other two frames failed, since the SNR of the signal as recorded at Dwingeloo was very good, yielding essentially no bit errors (even before FEC decoding).

Now I have looked at the signal more in detail and have found the cause of the corrupted SSDV frames. I have demodulated the signal in Python and have looked at the position where an ASM (attached sync marker) is transmitted. As explained in this post, the ASM marks the beginning of each Turbo codeword. The Turbo codewords are 3576 symbols long and contain a single SSDV frame.

A total of four ASMs are found in the GMSK transmission that contains the SSDV frames, which matches the four SSDV transmitted. However, the distance between some of the ASMs doesn’t agree with the expected length of the Turbo codeword. Two of the Turbo codewords where cut short and not transmitted completely. This explains why the decoding of the corresponding SSDV frames fails.

The detailed analysis can be seen in this Jupyter notebook.

This is rather interesting, as it seems that DSLWP-B had some problem when transmitting the SSDV frames. I have no idea about the cause of the problem, however. It would be convenient to monitor carefully future SSDV transmissions to see if any similar problem happens again.

DSLWP-B long-term orbit evolution

In my last post I commented that one of the motivations for the periapsis raise manoeuvre of DSLWP-B on July 20 was to prevent the satellite from crashing into the Moon in a few months. When Wei Mingchuan BG2BHC told me this, I found it a bit surprising, since I had the impression that the periapsis had been raising naturally since the satellite was injected in lunar orbit on May 25. Thus, I decided to propagate the orbit for a period of 2 years using GMAT and study the long-term effects in the Keplerian elements.

Update on DSLWP-B eclipse manoeuvre

A few days ago I discussed the manoeuvre performed by DSLWP-B in preparation for the lunar eclipse. The manoueuvre raised the periapsis of DSLWP-B by around 385km. Wei Mingchuan BG2BHC has now informed me that the manoeuvre was performed on 20 Jul 2018 10:47:09.657. There were two motivations for this manoeuvre: first, to avoid eclipse, as I showed in the previous post; second, as Wei tells me, to prevent DSLWP-B from crashing into the Moon in a few months (more on this in a future post).

Wei doesn’t know the delta-v used for the manoeuvre, but estimating it is an easy exercise using GMAT, which is what I will do in this short post. In this simulation I am taking the orbital state for DSLWP-B from the first line of the 20180714 tracking file published in dslwp_dev. I will assume that the manoeuvre was a prograde burn performed at apoapsis that raised the periapsis by 385km. The GMAT script I have used is lunar_eclipse_manoeuvre.script.

First I propagte the orbit to the date mentioned by Wei. I note that the spacecraft is a little short of apoapsis, so I propagate to apoapsis, which happens at 20 Jul 2018 10:49:33.178 UTC. Then I propagate to periapsis and take note of the periapsis radius, which is 3030.91km. Finally, I use GMAT to estimate a burn that will achieve a periapsis radius of 3415.91km using a differential corrector.

The differential corrector finds a delta-v of 17.2m/s. The iterations of the differential corrector can be seen in the figure and text below. A more difficult exercise is to find a burn that stitches together the orbits described by the 20180714 and 20180727a tracking files. I will leave this as an exercise for the reader. Something very similar was done in DSLWP-B’s journey to the Moon: part II.

Differential corrector solving for the periapsis raise burn

Comparison of DSLWP-B orbit determination with tracking files

In the last post I compared the results of my orbit determination for DSLWP-B using one lunar month of Doppler data with the observations in the VLBI experiment done on June 10. In this post I will compare my orbit determination with the tracking files published by Wei Mingchuan BG2BHC in gr-dslwp. These tracking files are produced from the orbit determination performed by the Chinese Deep Space Network using two-way S-band Doppler measurements.

The tracking files contain a listing of the position \(x\) and velocity \(v\) vectors for DSLWP-B in ECEF coordinates. The entries are given at intervals of one second. The tracking files can be used directly to compute Doppler as received in a groundstation. In fact, if the ECEF coordinates of the groundstation are \(x_0\), then \(R = \langle x – x_0, v\rangle/\|x-x_0\|\) is the range-rate, and so the Doppler can be computed as \(D=-fR/c\), where \(f\) is the downlink frequency and \(c\) is the speed of light in vacuum. Here I have used this method to compute the Doppler according to the tracking files.

All the tracking files published so far have been considered in this study, except for the first two, which contained an incorrect anomaly at epoch. The figure below shows the residuals between the Doppler measurements made by Scott Tilley VE7TIL and my orbit determination (called “new elements”) and each of the tracking files. It seems that the residuals are quite similar.

The figure below shows the difference between the Doppler according to each of the tracking files and the Doppler predicted by my orbit determination.

It seems that the match is quite good for the central days, but not so good towards the edges. My orbit determination is numerically propagated from a single set of elements at MJD 28264.5 for the whole period, while the tracking files probably use different sets of elements that are propagated numerically over a few days only. Therefore it might happen that my orbit determination is affected by some accumulative error due to numerical integration or an inaccuracy in the force model.

Validation of DSLWP-B orbit determination using VLBI observations

In my last post I presented my orbit determination of DLSWP-B using one lunar month of S-band Doppler measurements made by Scott Tilley VE7TIL. In this post, I will use the delta-velocity measurements from the VLBI experiment on 2018-06-10 to validate my orbital elements.

In the figures below, I compare between the sets of data: The old elements, obtained in this post:

DSLWP_B.SMA = 8762.40279943
DSLWP_B.ECC = 0.764697135746
DSLWP_B.INC = 18.6101083906
DSLWP_B.RAAN = 297.248156986
DSLWP_B.AOP = 130.40460851
DSLWP_B.TA = 178.09494681

The new elements obtained in my last post:

DSLWP_B.SMA = 8765.95638789
DSLWP_B.ECC = 0.764479041563
DSLWP_B.INC = 23.0301858287
DSLWP_B.RAAN = 313.64185464
DSLWP_B.AOP = 113.462338342
DSLWP_B.TA = 178.5519212

The elements obtained from the 20180610 tracking file published by Wei Mingchuan BG2BHC in dslwp_dev. This tracking file contains a list of ECEF position and velocity vectors for DSLWP-B. The first entry is taken as the orbital state and the orbit is propagated in GMAT, as done in this post. It would also be possible to calculate the delta-velocity directly from the ECEF data, but the results would be fairly similar and I already have a script to do it with GMAT orbit propagation.

A degree 2 polynomial fit to the VLBI observations. It turns out that the delta-velocity during the VLBI experiment can be approximated fairly well by a parabola, so it makes sense to use this as a reference. Note that this also implies that this set of delta-velocity measurements alone would be insufficient to perform orbit determination, as a degree 2 polynomial gives us 3 coefficients, while we would need to determine 6 parameters for the orbital state. Adding delta-range would only give us an extra variable, so orbit determination using VLBI would need several sets of measurements well space in time so that the orbit can be observed at different anomalies.

The figures below show a comparison between the four sets of data and the VLBI measurements.

The RMS errors are respectively 0.248m/s for the old elements, 0.167m/s for the new elements, 0.156m/s for the tracking file, and 0.137m/s for the polynomial fit. Thus, we see that the newer elements represent a good improvement over the older elements. The tracking file gives a slightly better result than the new elements. However, the new elements should give good results over a long time span of over 20 days, as we have seen in the previous post, while the orbital parameters derived from the tracking files tend to change often.

The Jupyter notebook used to make these calculations has been updated in here.

DSLWP-B first month in orbit

DSLWP-B has now been for more than a month in lunar orbit, since the orbital injection was made on May 25. Scott Tilley VE7TIL has sent me his latest batch of S-band Doppler measurements, including data for all this first lunar month. Having a complete lunar month of data is interesting for orbit determination purposes, since it gives observability of the orbit from all possible right ascension angles.
I have run my orbit determination with the new data.