BepiColombo is a joint mission between ESA and JAXA to send two scientific spacecraft to Mercury. The two spacecraft, the Mercury Planetary Orbiter, built by ESA, and the Mercury Magnetospheric Orbiter, built by JAXA, travel together, joined by the Mercury Transfer Module, which provides propulsion and support during cruise, and will separate upon arrival to Mercury. The mission was launched on October 2018 and will arrive to an orbit around Mercury on December 2025. The long cruise consists of one Earth flyby, two Venus flybys, and six Mercury flybys.
The Earth flyby will happen in a few days, on 2020-04-10, so currently BepiColombo is quickly approaching Earth at a speed of 4km/s. Yesterday, on 2020-04-04, the spacecraft was 2 million km away from Earth, which is close enough so that Amateur DSN stations can receive the data modulation sidebands. Paul Marsh M0EYT, Jean-Luc Milette and others have been posting their reception reports on Twitter.
Paul sent me a short recording he made on 2020-04-04 at 15:16 UTC at a frequency of 8420.535MHz, so that I could see if it was possible to decode the signal. I’ve successfully decoded the frames, with very few errors. This post is a summary of my decoding.
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.
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:
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.
In May 25, the Moon passed through the beam of my QO-100 groundstation and I took the opportunity to measure the Moon noise and receive the Moonbounce 10GHz beacon DL0SHF. A few days ago, in July 22, the Moon passed again through the beam of the dish. This is interesting because, in contrast to the opportunity in May, where the Moon only got within 0.5º of the dish pointing, in July 22 the Moon passed almost through the nominal dish pointing. Also, incidentally this occasion has almost coincided with the 50th anniversary of the arrival to the Moon of Apollo 11, and all the activities organized worldwide to celebrate this event.
The figure below shows the noise measurement at 10366.5GHz with 1MHz and a 1.2m offset dish, compared with the angular separation between the Moon and the nominal pointing of the dish (defined as the direction from my station to Es’hail 2). The same recording settings as in the first observation were used here.
The first thing to note is that I made a mistake when programming the recording. I intended to make a 30 minute recording centred at the moment of closest approach, but instead I programmed the recording to start at the moment of closest approach. The LimeSDR used to make the recording was started to stream one hour before the recording, in order to achieve a stable temperature (this was one lesson I learned from my first observation).
The second comment is that the maximum noise doesn’t coincide with the moment when the Moon is closest to the nominal pointing. Luckily, this makes all the noise hump fit into the recording interval, but it means that my dish pointing is off. Indeed, the maximum happens when the Moon is 1.5º away from the nominal pointing, so my dish pointing error is at least 1.5º. I will try adjust the dish soon by peaking on the QO-100 beacon signal.
The noise hump is approximately 0.085dB, which is much better than the 0.05dB hump that I obtained in the first observation. It may not seem like much, but assuming the same noise in both observations, this is a difference of 2.32dB in the signal. This difference can be explained by the dish pointing error.
The recording I have made also covers the 10GHz Amateur EME band, but I have not been able to detect the signal of the DL0SHF beacon. Perhaps it was not transmitting when the recording was made. I have also arrived to the conclusion that the recording for my first observation had severe sample loss, as it was made on a mechanical hard drive. This explains the odd timing I detected in the DL0SHF signal.
The next observation is planned for October 11, but before this there is the Sun outage season between September 6 and 11, in which the Sun passes through the beam of the dish, so that Sun noise measurements can be performed.
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.
During this week, the Amateur payload of DSLWP-B has been active on the following slots:
2019-07-09 12:30 to 14:30 UTC
2019-07-10 13:50 to 15:50 UTC
2019-07-12 02:00 to 04:00 UTC
2019-07-12 16:30 to 18:30 UTC
In these activations, the last remaining image of the eclipse was downloaded. Also, images of the lunar surface as well as stars have been taken and downloaded. This post is a summary of the activities made with DSLWP-B over the week.
I have devoted the lastfewpoststo the planning of the imaging times for the eclipse test run and the validation of the test run done on June 30. This post is a detailed account of the results of the eclipse imaging. Between July 3 and 5, five of the six eclipse images taken on July 2 were downloaded, as well as some other images taken later. Here I give a summary of the downloads during these days and compare the images to the predictions I made.
As described in one of my latest posts, today DSLWP-B has made a test imaging run in preparation for the solar eclipse on July 2. A series of images was taken just before the Moon hid the centre of the camera field of view and just after the Moon left the centre of the image, in approximately the same relative positions as for the July 2 eclipse imaging run.
The activation of the Amateur payload started at 05:30 UTC and the payload was commanded to change the configuration of the camera to use 2x zoom. The satellite was occulted by the Moon at 05:40 UTC, preventing the reception of telemetry until it reappeared at 06:16 UTC. The first series of images was taken automatically between 05:51 and 05:54, with the satellite behind the Moon.
After the satellite reappeared from behind the Moon, telemetry confirmed that three images, with IDs 0xD9, 0xDA and 0xDB had been taken. Between 06:29 and and 06:32, the satellite took the second series of images. Telemetry confirmed that these images were taken correctly with IDs 0xDC, 0xDD and 0xDE.
The priority was to use the rest of the activation to download images 0xDA and 0xDD, taken respectively at 05:52:40 and 06:31:10 UTC (when reading the times given in the planning post, note that the times listed there are the moments when the command is sent to the payload by the satellite, but the payload needs about 20 additional seconds to take the image). However, there were difficulties in commanding the payload, so half an hour was lost trying to command the satellite and only image 0xDA could be downloaded before the payload went off at 07:30 UTC.
Image 0xDA was downloaded without errors in a single transmission. It is shown below.
As we see, the exposure of the image is correct, so this image validates that the camera configuration can be used for the eclipse imaging run. Additionally, the image can be used to evaluate camera pointing and ephemeris errors.
As computed in this Jupyter notebook, the separation between the Moon rim and the centre of the field of view in the image shown above is 6.47 degrees. Using the camera calculations Jupyter notebook that I have shown in previous posts, we see that, according to the 20190630 ephemeris from dslwp_dev and my GMAT calculations, the angular distance between the Moon rim and the centre of the image at 05:52:40 UTC should be 3.25 degrees, assuming that the camera points perfectly away from the Sun.
The rate at which the Moon rim moves through the field of view is approximately 0.029 degrees per second. Thus, if the camera was pointing perfectly away from the Sun, this would indicate that DSLWP-B is 110 seconds earlier in its orbit that what predicted by the ephemeris, so that events concerning the relative position of the satellite and the Moon happen 110 seconds later than predicted.
However, one should take these calculations with a grain of salt. In my astrometry post, I showed that the camera was pointing 3.25 degrees off-axis. Therefore, it is convenient to assume an error of +/-3.25 degrees in the angle measurement done with the image. In units of time, this is +/-111 seconds.
So the data seems to suggest that DSLWP-B is one or two minutes earlier in its orbit and that the imaging times should be compensated by making them one or two minutes later, but there is not enough statistical evidence to support this argument. It will be very interesting to see image 0xDD, which will be downloaded tomorrow. The analysis of this image will give additional data.
In any case, so far it seems that orbit and pointing errors are within the tolerance given by the series of three images, which are taken at -1, 0, and +1 minutes offset from the nominal imaging time computed by Wei.
In my last post, I spoke about the possibility of imaging the July 2 solar eclipse using the Inory eye camera on-board DSLWP-B. After discussing the plans for the observations with Wei Mingchuan BG2BHC, we have decided to activate the DSLWP-B Amateur payload during the following intervals:
2019-06-30 05:30 to 07:30
2019-07-01 05:30 to 07:30
2019-07-02 18:00 to 20:00
2019-07-03 06:00 to 08:00
2019-07-04 06:30 to 08:30
2019-07-05 07:30 to 09:30
The camera will be used in 2x zoomed mode, which has a field of view of 14×18.5, degrees. Using the zoomed mode requires careful planning, since part of the Moon needs to appear inside the image, to help the camera auto-exposure algorithm, but the Moon shouldn’t hide the Earth.
The June 30 activation will be used to test the camera, taking images of the Moon in similar positions to those on July 2. The Earth will not be in view of the camera on this day, but these tests will serve to validate camera pointing, exposure, and satellite ephemeris errors.
The following imaging times have been proposed:
The idea for July 2 is to take an image of the Earth and Moon just before the Earth becomes hidden behind the Moon and just after it reappears. Determining these moments accurately is difficult. The Moon will be moving rather fast across the field of view of the camera, since the orbit altitude is rather low. Therefore, the timing of these events is sensitive to the satellite ephemeris and the orbit propagation algorithm. To try to mitigate this effect, we will take a series of three images spaced one minute instead of taking a single image.
On June 30, the same imaging run is mimicked: a series of three images will be taken before the Moon hides the centre of the image (this time the Earth will not be present) and a series of three images will be taken after the centre of the image becomes unblocked again.
The figure below shows the camera view prediction for the June 30 imaging run. The calculations have been done with the 20190630 ephemeris from dslwp_dev.
We note that the second run of three images seems a little early. Wei is doing his calculations with STK and apparently he is getting slightly different orbital predictions compared to my predictions done in GMAT. We haven’t tried to study these differences, but this gives an idea of how sensitive the imaging times are to ephemeris and orbital propagators. Hopefully the series of three images will account for orbital errors. Additionally, after doing the test run on June 30, the results can be compared with the orbital prediction and the imaging times for July 2 can be modified slightly if necessary.
The figure below shows the camera view for the July 2 eclipse imaging run. The 20190630 ephemeris have been used for this plot also. We have the same effect, where the second proposed imaging times seem somewhat early.
Since this time the Earth is also visible in the image, it is convenient to plot the “Earthrise view” plot, which I have used on other occasions. This shows the angular distance between the Earth and the Moon rim, so it can be used to determine if the the Earth is hidden by the Moon (negative distance) or not.
As we can see below, according to my GMAT prediction, the Earth will not be visible in the images around 19:30. It seems these should be taken a few minutes later. However, Wei has obtained different results with STK. In any case, these imaging times can be corrected based on the results obtained on June 30.