On April 28, I got together with a few Spanish radio Amateurs to perform some experiments. One of the things we did was an angle of arrival experiment in the 145MHz Amateur band. The ultimate goal of the experiment was to be able to measure the angle of arrival of meteor reflections of the GRAVES radar at 143.05MHz. However, we also recorded a few other signals, such as the Amateur satellite band at 145.9MHz (intended to perform calibration of the setup) and the APRS terrestrial signals at 144.8MHz.
Posts
DSLWP-B lunar impact prediction
In my last post, I spoke about the future lunar impact of DSLWP-B on July 31. Edgar Kaiser DF2MZ asked over on Twitter if the impact would be visible from Earth. As I didn’t know the answer, I have made a simulation in GMAT to find this out.
The figure below shows the orbit of DSLWP-B between July 28 12:00 UTC and the moment of impact, on July 13 14:47 UTC. The orbital state used for DSLWP-B is the 20190426 tracking file from dslwp_dev. The reference frame is arranged so that the +X axis points towards the Earth, and the Y axis lies on the Earth-Moon orbital plane. As we can see, unfortunately, the impact will happen on the far side of the Moon, where it is not observable from Earth.
However, it is possible to arrange a manoeuvre to modify the orbit slightly and make the impact point fall on the near side of the Moon, where it is visible from Earth. In the previous post we observed that, ignoring the collision with the lunar surface, the periapsis radius would continue to decrease after July 31, until reaching a minimum value in January 2020.
Therefore, it is possible to raise the periapsis radius slightly in order to delay the collision approximately half a lunar month, so that the periapsis faces the Earth at the moment of impact. The delta-v required to make this manoeuvre is small, as the adjustment to the orbit is subtle.
For instance, performing a prograde burn of 7m/s at the first apoapsis after July 1 delays the collision until August 13, producing an impact in the near side of the Moon. The resulting orbit can be seen in the figure below, which shows the path of DSLWP-B between July 28 and the moment of impact.
Adjusting the delta-v more precisely would make it possible even to control the time of the impact, so as to guarantee that the Moon will be in view of the groundstations at China and The Netherlands when the collision happens. However, this adjustment requires a very precise delta-v and is quite sensitive to the orbital state, so perhaps it is not feasible without performing a precise orbit determination and maybe some smaller correction manoeuvres following the periapsis raise.
Another possible problem that can affect the prediction of the impact point are the perturbations of the orbit caused by the lunar mascons, which can be noticeable when the altitude of the orbit starts getting small, and which haven’t been considered very carefully in this simulation (the non-spherical gravity of the Moon was only simulated up to degree and order 10).
The GMAT script used for this post can be found here.
DSLWP-B deorbit and mission end
On January 24, the periapsis of the lunar orbit of DSLWP-B was lowered approximately by 500km, so that orbital perturbations would eventually force the satellite to collide with the Moon. This was done to put an end to the mission and to avoid leaving debris in orbit. It is expected that the collision will happen at the end of July, so there are only three months left now for the DSLWP-B mission. Here I look at the details of the deorbit.
Planning Moon observations with my QO-100 station
There is a saying that goes like “even a broken clock is right twice a day”. In the same spirit, even a QO-100 station, which is installed with a fixed dish aiming to Es’hail 2, can sometimes be used for observing the Moon, as it happens to pass in front of the beam.
My station has a 1.2m offset dish with a GPSDO disciplined LNB. There are a few things that can be done when the Moon passes in front of the beam of the dish, such as measuring moon noise (though the increase in noise is only of around 10K with such a small dish), or receiving the 10GHz EME beacon or other EME stations. Therefore, it is interesting to know when these events happen, in order to prepare the observations.
I have made a simple Jupyter notebook that uses Astropy to compute the moments when the moon will pass through the beam of the dish (say, closer than 1º to the position of Es’hail 2 in the sky). Of course, the results are highly dependent on the location of the groundstation, so these are only valid for my groundstation and perhaps other groundstations in Madrid. Other people can run this notebook again using their data.
It turns out that each year the Moon passes roughly a dozen times in front of the dish beam. The next observation for me is on May 16. The separation in degrees between the centre of the Moon and the centre of the dish beam can be seen in the figure below.
This notebook can be used to plan for transits of other astronomical objects, but besides the Moon and the Sun, there are no other objects that are visible at 10GHz with a small dish. It is well known when the Sun passes in front of the beam, since this disturbs communications with GEO satellites. This is called Sun outage and it happens during a few days around the equinoxes (a few weeks sooner or later, depending on the latitude of the station). On the other hand, the transits of the Moon happen throughout the whole year, at rather unpredictable moments, so I think this notebook is quite useful to plan observations.
Rain fade in the QO-100 downlink
The Amateur transponders of Es’hail 2 have their downlink in the 10GHz Amateur band. Even though the path to the satellite through the atmosphere is rather short, in extreme weather conditions it is possible to observe a small amount of fading in the signal. Two days ago there was intense rain over Madrid. As I’m often recording the power of the narrowband transponder beacons and the transponder noise floor, I have examined my data to see if the effect of the rain is visible.
The data is plotted in the figure below. See this post for an explanation of the measurements.
The power of the beacons is not very stable. It can vary up to 2 or 3dB along the course of the day. Therefore, it is not so easy to measure the drop in signal power caused by rain. However, it is noticeable that on April 24, between 05:00 and 17:00 UTC, the power of the beacons varies much more rapidly than usually. A small ripple of 0.5dB of amplitude is visible on the data. I think that this ripple is caused by varying rain intensity. Therefore, the data seems to suggest that the rains two days ago caused up to 0.5dB of fading in the signal.
As seen from my station, the satellite is at an elevation of \(\theta = 33.6^\circ\), so assuming a slant factor of \(1/\sin \theta = 1.8\), so taking a typical height of around 1km for the column of rain (see the corresponding METAR for Madrid airport), we get an attenuation on the order of 0.3dB/km. However, all the measurements used here are too imprecise to obtain any good conclusions. See this related post, in which I measured a 2.5dB increase in the noise floor at 12GHz during a hailstorm, but no change in signal power.
Decoding SSDV from JY1SAT
JY1SAT is a Jordanian 1U Amateur cubesat that carries a FUNcube payload by AMSAT-UK. As usual, the FUNcube payload on-board JY1SAT has a linear transponder with uplink in the 435MHz band and downlink in the 145MHz band, and a 1k2 BPSK telemetry transmitter in the 145MHz band. The novelty in comparison to the older FUNcube satellites is that the BPSK transmitter is also used to send SSDV images and Codec2 digital voice data.
Here I show how to decode the SSDV images using gr-satellites.
Diffraction in DSLWP-B lunar occultations
In February this year, the orientation of the orbit of DSLWP-B around the Moon was such that, when viewed from the Earth, it passed behind the Moon on every orbit. This opened up the possibility for recording the signal of DSLWP-B as it hid behind the Moon, thus blocking the line of sight path. The physical effect that can be observed in such events is that of diffraction. The power of the received signal doesn’t drop down to zero in a brick-wall fashion just after the line of sight is blocked, but rather behaves in an oscillatory fashion, forming the so called diffraction fringes.
The signal from DSLWP-B was observed and recorded at the Dwingeloo 25m radiotelescope for three days in February: 4th, 13th and 15th. During the first two days, an SSDV transmission was commanded several minutes before DSLWP-B hid behind the Moon, so as to guarantee a continuous signal at 436.4MHz to observe the variations in signal power as DSLWP-B went behind the Moon. On the 15th, the occultation was especially brief, lasting only 28 minutes. Thus, DSLWP-B was commanded to transmit continuously before hiding behind the Moon. This enabled us to also observe the end of the occultation, since DSLWP-B continued transmitting when it exited from behind the Moon. This is an analysis of the recordings made at Dwingeloo.
An overview of IARU R1 interim meeting proposals
The IARU R1 interim meeting is being held in Vienna, Austria, on April 27 and 28. This post is an overview of the proposals that will be presented during this meeting, from the point of view of the usual topics that I treat in this blog.
The proposals can be found in the conference documents. There are a total of 64 documents for the meeting, so a review of all of them or an in-depth read would be a huge work. I have taken a brief look at all the papers and selected those that I think to be more interesting. For these, I do a brief summary and include my technical opinion about them. Hopefully this will be useful to some readers of this blog, and help them spot what documents could be more interesting to read in detail.
Detecting the Sprites from KickSat-2
The Sprites chipsats are tiny satellites built on a 3.5×3.5cm PCB with the bare minimum electronics to do something useful: a CC430 microcontroller with integrated FSK transceiver, an IMU, and solar cells.
The Sprites have been developed as part of the KickSat project, led by Zac Manchester, from Stanford University. The idea is to carry up to 128 Sprites in a cubesat and deploy them in a swarm once the cubesat is in orbit. The first test of this concept was done by the KickSat 3U cubesat in 2014. The test was a failure, since the Sprites couldn’t be deployed before KickSat reentered.
The second test was made this year with the KickSat-2 3U cubesat, a reflight of the KickSat mission carrying 104 Sprites. KickSat-2 was launched to the ISS onboard Cygnus NG-10 in November 2018 and deployed into orbit in February 2019.
On March 19, the Sprites were successfully deployed from KickSat-2, as Zac announced in Twitter, requesting help from the Amateur radio community to receive the signals from the Sprites at 437.240MHz. On March 22, Cees Bassa and Tammo Jan Dijkema tried to detect the Sprites by doing a planar scan with the Dwingeloo 25m radiotelescope. They were successful, detecting several transmissions from the Sprites in the waterfall. At that moment, the Sprites were up to 5 minutes ahead KickSat-2, due to their much higher drag to mass ratio. They all probably reentered a few days after this.
All the Sprites transmit in the same frequency using CDMA, so further analysis is required to identify which Sprites were observed by Dwingeloo. Zac said he was working on decoding the recording, however, I haven’t seen any results published yet. Here I show my analysis of the recording made at Dwingeloo. I manage to detect 4 different Sprites.
QO-100 beacon FEC decoder
Since the BPSK beacon on the QO-100 narrowband transponder was first activated, I had thought that it only transmitted messages using the AO-40 uncoded protocol. However, a Twitter conversation a few days ago with Rob Janssen PE1CHL convinced me that FEC messages might be sent in between uncoded messages.
The AO-40 FEC protocol used a concatenated code with a (160, 128) Reed-Solomon code and an r=1/2, k=7 convolutional code, together with scrambling and interleaving to achieve very good performance. The same protocol has then been used in the FUNcube satellites, so I have an AO-40 FEC decoder in gr-satellites since I added support for AO-73.
It is quite easy to notice that the QO-100 beacon transmits both uncoded and FEC messages. Indeed, using my gr-satellites decoder, I see that an uncoded message is transmitted every 23 seconds approximately. Since an uncoded message comprises 514 bytes, it takes 10.28 seconds to transmit it at 400baud, so something else must be sent between uncoded messages.
A FEC message is formed by 5200 symbols (after applying FEC), so it takes 13 seconds to transmit at 400baud. This gives us the total 23.28 seconds that I had observed between uncoded messages. Note that the contents of the uncoded and FEC blocks are different. An uncoded block contains 8 lines of 64 characters plus 2 bytes of CRC. A FEC block only contains 4 lines of 64 characters, and no CRC.
I have added a FEC decoder to the QO-100 decoder in gr-satellites, so that it now decodes both FEC and uncoded messages.