Peregrine Mission One is a lunar lander built by Astrobotic Technology. It is the first mission to be launched under the NASA Commercial Lunar Payload Services program, and Astrobotic’s first mission. It was launched in January 8 from Cape Canaveral in the maiden flight of ULA‘s Vulcan Centaur. Shortly after the launch, the team detected an issue with a propellant leak that prevented the spacecraft from achieving a soft landing on the Moon. Since then, the team has continued operating the spacecraft to the best of their capacity and collecting as much engineering and science data as they can for the next mission. Astrobotic has been doing a superb work of communicating the progress of the mission with regular updates in the Twitter account, which should specially be praised because of the difficulties they’ve faced. Congratulations for all they have achieved so far, and best luck in the upcoming missions.
In this post I won’t speak about propulsion anomalies, but rather about low-level technical details of the communications system, as I usually do. Peregrine Mission One, or APM1, which is NASA DSN‘s code for the mission, uses the DSN groundstations for communications, as many other lunar missions have done. However, it is not technically a deep space mission. In CCSDS terms, it is a Category A mission rather than a Category B mission (see Section 1.5 in this CCSDS book), since it operates within 2 million km of the Earth. Communications recommendations and usual practices are somewhat different between deep space and non-deep space missions, but APM1 is specially interesting in this sense because it differs in several aspects of what typical deep space missions and other lunar missions look like.
MOVE-II is a cubesat from Technical University of Munich that was launched in December 2018. It transmits telemetry in the 145 MHz amateur satellite band using a protocol that uses CCSDS LDPC codewords. Back in the day, there was a GNU Radio out-of-tree module developed by the satellite team to decode this satellite. Given the additional effort required to support LDPC decoding for just this satellite and since there was already a GNU Radio decoder available, I never added a decoder for MOVE-II to gr-satellites.
Fast forward 5 years, and MOVE-II is still active, but apparently its GNU Radio out-of-tree module has bit rotten. The Gitlab repository where this was hosted (I believe it was a self-hosted Gitlab) has disappeared, and while it was originally developed for GNU Radio 3.7, it was never ported to newer GNU Radio versions. Some days ago, some amateurs including Scott Chapman K4KDR and Bob Mattaliano N6RFM started doing some experiments to try to get a decoder for MOVE-II working.
I have now added an example decoder flowgraph for MOVE-II to gr-satellites. Here I describe the details of this example, and why it is only an example instead of a fully supported decoder as the ones that exist for other satellites.
In my previous post I spoke about the recording of the telemetry signal from the Psyche spacecraft that I made just a few hours after launch with the Allen Telescope Array. In that post I analysed the physical aspects of the signal and the modulation and coding, but left the analysis of the telemetry frames for another post. That is the topic of this post. It will be a rather long and in-depth look at the telemetry, since I have managed to make sense of much of the structure of the data and there are several protocol layers to cover.
As a reminder from the previous post, the recording was around four hours long. During most of the first three hours, the spacecraft was slowly rotating around one of its axes, so the signal was only visible when the low-gain antenna pointed towards Earth. It was transmitting a low-rate 2 kbps signal. At some point it stopped rotating and switched to a higher rate 61.1 kbps signal. We will see important changes in the telemetry when this switch happens. Even though the high-rate signal represents only one quarter of the recording by duration, due to its 30x higher data rate, it represents most of the received telemetry by size.
On Friday, the Psyche mission launched on a Falcon Heavy from Cape Canaveral. This mission will study the metal-rich asteroid of the same name, 16 Psyche. For more details about this mission you can refer to the talk that Lindy Elkins-Tanton, the mission principal investigator, gave a month ago at GRCon23.
The launch trajectory was such that the spacecraft could be observed from the Allen Telescope Array shortly after launch. The launch was at 14:19 UTC. Spacecraft separation was at 15:21 UTC. The spacecraft then rose above the ATA 16.8 degree elevation mask in the western sky at 15:53 UTC. However, the signal was so strong that it could be received even when the spacecraft was a couple degrees below the elevation mask, so I confirmed the presence of the signal and started recording a couple minutes earlier. At this moment, the spacecraft was at a distance of 18450 km. The spacecraft continued to rise in the sky, achieving a maximum elevation of 32.9 degrees at 16:53 UTC, and setting below the elevation mask on the west at 19:22 UTC. At this moment the spacecraft was 103800 km away. The signal could still be received for a few minutes afterwards, but eventually became very weak and I stopped recording.
Since the recording started only 30 minutes after spacecraft separation, we get to see some of the events that happen very early on in the mission. Most of the observations of deep space launches that I have done with the ATA have started several hours after launch. This Twitter thread by Lindy Elkins-Tanton gives some insight about the first steps following spacecraft separation, and I will be referring to it to explain what we see in the recording.
I intend to publish the recordings in Zenodo as usual, but the platform has been upgraded recently and is showing the following message “Oct 14 12:03 UTC: We are working to resolve issues reported by users.” So far I have been unable to upload large files, but I will keep retrying and update this post when I manage.
Update 2023-10-19: Zenodo have now solved their problems and I have been able to upload the recordings. They are published in the following datasets:
On September 24, the OSIRIX-RExsample return capsule landed in the Utah Test and Training Range at 14:52 UTC. The capsule had been released on a reentry trajectory by the spacecraft a few hours earlier, at 10:42 UTC. The spacecraft then performed an evasion manoeuvre at 11:02 and passed by Earth on a hyperbolic orbit with a perigee altitude of 773 km. The spacecraft has now continued to a second mission to study asteroid Apophis, and has been renamed as OSIRIS-APEX.
This simulation I did in GMAT shows the trajectories of the spacecraft (red) and sample return capsule (yellow).
Trajectory of OSIRIX-REx and sample return capsule
Since the Allen Telescope Array (ATA) is in northern California, its location provided a great opportunity to observe this event. Looking at the trajectories in NASA HORIZONS, I saw that the sample return capsule would pass south of the ATA. It would be above the horizon between 14:34 and 14:43 UTC, but it would be very low in the sky, only reaching a peak elevation of 17 degrees. Apparently the capsule had some kind of UHF locator beacon, but I had no information of whether this would be on during the descent (during the sample return livestream I then learned that the main method of tracking the capsule descent was optically, from airplanes and helicopters). Furthermore, the ATA antennas can only point as low as 16.8 degrees, so it wasn’t really possible to track the capsule. Therefore, I decided to observe the spacecraft X-band beacon instead. The spacecraft would also pass south of the ATA, but would be much higher in the sky, reaching an elevation above 80 degrees. The closest approach would be only 1000 km, which is pretty close for a deep space satellite flyby.
As I will explain below in more detail, I prepared a custom tracking file for the ATA using the SPICE kernels from NAIF and recorded the full X-band deep space band at 61.44 Msps using two antennas. The signal from OSIRIS-REx was extremely strong, so this recording can serve for detailed modulation analysis. To reduce the file size to something manageable, I have decimated the recording to 2.048 Msps centred around 8445.8 MHz, where the X-band downlink of OSIRIS-REx is located, and published these files in the Zenodo dataset “Recording of OSIRIS-REx with the Allen Telescope Array during SRC reentry“.
In the rest of this post, I describe the observation setup, analyse the recording and spacecraft telemetry, and describe some possible further work.
For this post I have only used final solutions for the CODE precise clock biases. I have replaced the rapid solutions that I used in the last post by their final versions. The data under analysis now spans from day of year 225 (2023-08-13) to day of year 266 (2023-09-23).
The plot of the difference between the broadcast clock biases and the CODE precise clock biases now has the following aspect. Comparing with the previous post, we see that the difference has stayed around -15 ns until 2023-09-08, and then it has started increasing towards zero, but it has overshoot and it is at around 20 ns by 2023-09-23.
The plot of the system time differences in the broadcast messages is also quite interesting. For this I am using the IGS BRDC data until day of year 275 (2023-10-03). Recall that it appeared that the GST-UTC drift had the wrong sing, because it was clearly increasing but the drift had negative sign. Now the situation looks more complicated. Though it appears that the drift has the wrong sign around 2023-08-28 and 2023-09-22, there is also a segment around 2023-09-08 where the sign looks correct. Additionally, around 2023-09-01 the sign should be close to zero but is not.
For comparison, here is the same plot with the sign of the GST-UTC drift flipped. Arguably, the drift gives a better match most of the time, but certainly not around 2023-09-08. Therefore, the problem with the modelling of the GST-UTC drift in the Galileo broadcast message looks more complicated than just the sign bit being wrong.
The updated Jupyter notebook and data is in this repository.
Aditya-L1 is an Indian solar observer satellite that was launched to the Sun-Earth Lagrange point L1 on September 2. It transmits telemetry in X-band at 8497.475 MHz. This post is going to be just a quick note. Lately I’ve been writing very detailed posts about deep space satellites and I’ve had to skip some missions such as Chandrayaan-3 because of lack of time. There is a very active community of amateur observers doing frequent updates, but the information usually gets scattered in Twitter and elsewhere, and it is hard to find after some months. I think I’m going to start writing shorter posts about some missions to collect the information and be able to find it later.
Each GNSS system uses their own timescale for all the calculations. What this means is slightly difficult to explain, since anything involving “paper clocks” is conceptually tricky. In essence, the system, as part of the orbit and clock determination, maintains a timescale (paper clock) to which the ephemeris are referenced. This timescale is usually related to some atomic clocks in the countries that manage the GNSS system, and these clocks often participate in the realization of UTC, so that in the end this GNSS timescale is traceable to UTC. For instance, GPS time is related to UTC(USNO), and GST, the Galileo system time, is related to a few atomic clocks in Europe that are realizations of UTC.
Since all the information for a single GNSS system is self-consistent with respect to the timescale it uses, a receiver using a single system to compute position and velocity does not really care about the GNSS timescale. Everything will just work. However, when the receiver needs to compute UTC time accurately (for instance to produce a 1PPS output that is aligned to UTC) or to mix measurements from several GNSS systems, then it needs to handle the different GNSS timescales involved, and transfer all the measurements to a common timescale (and in the case of measuring UTC time or producing a 1PPS output, relating this timescale to UTC).
As part of their broadcast ephemeris, GNSS systems broadcast an estimate of the offset between the system timescale and UTC (this estimate is just a forecast; the true value of UTC is only known a posteriori, when the BIPM publishes its monthly Circular T). Additionally, some systems also broadcast the offset between their timescale and the timescale of another system. For example, Galileo broadcasts the offset GST-GPST, the difference between Galileo system time and GPS time. This is intended as a help to receivers that want to combine measurements from both systems. However, these values are somewhat inaccurate, so it is common for receivers to ignore them, and determine the offsets on their own (this is done by adding extra variables called intersystem biases to the system of equations solved to obtain the navigation solution). This trick only works for combining measurements of different systems. In the case of UTC, receivers do not have any way of directly measuring UTC, so they must trust the broadcast message. Alternatively, some receivers offer an option to align their 1PPS output to a GNSS timescale such as GPST.
These days, most GNSS systems, including GPS and Galileo usually keep their timescales within a few nanoseconds of UTC. According to the specifications of each system, the relation to UTC is much loose. GPS time promises to be synchronized to UTC(USNO) with a maximum error of 1 microsecond. GLONASS time only promises 1 millisecond synchronization to UTC. GST is supposed to be within 50 ns of UTC, and Beidou time within 100 ns. However, if timekeeping is done correctly, there is no reason why the GNSS timescale should drift from UTC by more than a couple nanoseconds (which is the typical drift of physical realizations of UTC). Receivers should assume that the offsets can be as large as the maximum errors in the specification, but might occasionally freak out if they see an offset which is large, either because of bugs if this case was never tested, as in practice the offsets are typically small, or because it suspects an error in its own measurements.
A few days ago, some people in the time-nuts mailing list, and Bert Hubert from galmon.eu noticed that the GST-UTC, the difference between Galileo system time and UTC, had increased to 17 ns and remain around this value during the end of August. This is highly unusual, because GST-UTC is usually smaller than 2 or 3 ns.
galmon.eu provides a public Grafana dashboard where this anomaly can be seen, though the dashboard (or web browser) tends to choke if we request to plot more than one week worth of data.
Broadcast GST-UTC in the galmon.eu Grafana dashboard
When hearing about this on Friday, I got interested and commented some ways in which this could be researched further. I also wondered: is the GST-UTC offset actually large, or is it just that the offset estimate in the navigation message is wrong? In this post I explore one of my ideas.
W-Cube is a cubesat project from ESA with the goal of studying propagation in the W-band for satellite communications (71-76 GHz downlink, 81-86 GHz downlink). Current ITU propagation channel models for satellite communications only go as high as 30-40 GHz. W-Cube carries a 75 GHz CW beacon that is being used to make measurements to derive new propagation models. The prime contractor is Joanneum Research, in Graz (Austria). Currently, the 75 GHz beacon is active only when the satellite is above 10 degrees elevation in Graz.
Some months ago, a team from ESA led by Václav Valenta have started to make observations of this 75 GHz beacon using a portable groundstation in ESTEC (Neatherlands). The groundstation design is open source and the ESA team is quite open about this project. I have recently started to collaborate with them regarding opportunities to engage with the amateur radio community in this and future W-band propagation projects (there is an amateur radio 4 mm band, which usually covers from 75.5 to 81.5 GHz, depending on the country). As I write this, some of my friends in the Spain and Portugal microwave group are running tests with their equipment to try to receive the beacon.
On 2023-06-16, the team made an IQ recording of the beacon using their portable groundstation. They have published some plots about this observation. Now they have shared the recording with me so that I can analyse it. One of the things they are interested in is to evaluate the usage of the gr-satellites Doppler correction block to perform real-time Doppler correction with a TLE. So far they are doing Doppler correction in post-processing, but due to the high Doppler drift, it is not easy to see the uncorrected signal in a spectrum plot.
Today is the third anniversary of Tianwen-1, which was launched in 23 July 2020. During the first year of the mission I was tracking it with great detail and writing a lot of posts. A fundamental part of this work was the help of AMSAT-DL. Using its 20 metre antenna in Bochum, they tracked the spacecraft, decoded telemetry and provided live coverage of many of the key mission events in their Youtube livestream. At some point the reception of Tianwen-1’s telemetry at Bochum got completely automated, as we described in a paper in the GNU Radio Conference 2021 proceedings.
To this date, the reception continues in Bochum almost every day, when the dish is not busy with other tasks such as tracking STEREO-A. This means that we get good coverage of the spacecraft orbital data, via the state vectors transmitted in its telemetry.
To celebrate the anniversary, I have updated my plot of the orbital parameters, which I made back in March 2022. The plot covers all the remote sensing orbit, from when it started on 8 November 2021, until the present day. To my knowledge, no manoeuvres have happened in this time (perhaps small station-keeping burns would be unnoticed without more careful analysis), so the changes in the orbit are just due to perturbations by forces such as the Sun’s gravity and the oblateness of Mars.
The updated plot can be seen below. We see that the periapsis latitude changes at a steady rate of 0.598 deg/day. The remote sensing orbit was designed so that the periapsis precessed in this way, which allows the spacecraft to cover all the surface of Mars from a low altitude in 301 days. The surface has now been covered twice, since the periapsis has moved from near the north pole to the south pole and back again to the north pole.
There is also an interesting change in eccentricity, which seems to be correlated with the latitude of the periapsis. The eccentricity is largest when the periapsis is over the south pole. In this case, the altitude of the periapsis decreases by 60 km, compared to when the periapsis is over the north pole. The inclination has remained mostly steady, although there seems to be a small perturbation with an amplitude of 0.1 deg.
The updated Jupyter notebook in which this plot was made can be found here.
