DSLWP-B activities for the third week of July

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.

2019-07-14

On July 14, the payload was active between 19:00 and 21:00. DSLWP-B was behind Moon until 19:30, and when telemetry was first received, some problems were detected with the decoder at Dwingeloo. After some investigation, it was detected that the problems were caused by the tracking files in dslwp_dev. Usually, Wei Mingchuan BG2BHC generates the tracking files using STK, but he had some problems with the software and was unable to generate the files. Thus, I used GMAT to generate tracking files for the whole week.

I tried to use exactly the same format as in Wei’s tracking files, but I made a mistake in the zero padding of some fields. This caused problems with the Doppler correction code in the decoder. After disabling the Doppler correction, Dwingeloo was able to decode telemetry, but some time was lost trying to debug these issues.

First, image 0xF7, which was partially downloaded on July 12, was fixed by downloading the missing chunks. The download of this image started while Tammo Jan Dijkema was rushing to fix the Dwingeloo decoder. I ran a decoder in my computer through the Dwingeloo WebSDR, but unfortunately the WebSDR uses variable resampling that prevents successful decoding of a good fraction of the packets. While we attempted to transmit the missing chunks several times, Tammo Jan managed to fix the decoder at Dwingeloo, and image 0xF7 was completed. It is shown below. The image belongs to a series of four images of Mare Anguis taken on July 12.

Image 0xF7, taken on 2019-07-12 03:02, completed on 2019-07-14 19:45 to 20:09

After image 0xF7 was fixed, we downloaded image 0xF5, which is another of the images in the Mare Anguis series. This image took 40 minutes to transmit due to the large amount of detail present, which makes the JPEG file larger. Some of the chunks of the image were corrupted due to frequency jumps in the on-board TCXO.

Image 0xF5, taken on 2019-07-12 02:59, partially downloaded on 2019-07-14 20:19 to 20:50

After the download of this image finished, and with few minutes remaining until the payload shut down, the download of image 0xF6 (also in the Mare Anguis series) was started. The partial image received before shut down is shown below.

Image 0xF6, taken on 2019-07-12 03:00, partially downloaded on 2019-07-14 20:56 to 21:00

2019-07-18

The activation of July 18 was supposed to start at 21:50. However, the team from Dwingeloo were surprised when they started receiving telemetry just after pointing the dish, at 21:37. After examining the runtime field of the telemetry, it was discovered that the payload had powered on at 20:50 instead, so only a bit more than one hour of activation remained. Later it was discovered that the stated activation start of 21:50 was due to a mistake when converting from Beijing time into UTC.

The original plan for this activation was to download the image that was taken coinciding with the payload activation at 21:50. I had already computed that this image would show an area not far from the Apollo 15 landing site from an altitude of 143km, much lower than previous lunar surface images. However, after discovering that the payload had activated at 20:50, we realized that the image had been taken at 20:50.

I quickly run a GMAT simulation and checked that the lunar surface was not in the camera field of view at 20:50, so there wasn’t much point in trying to download that image. Instead, it was decided to take an image manually. Since the time was close to 21:50, this image would be similar to the prediction I had made.

After an unsuccessful try, Reinhard Kuehn managed to command the payload to take an image. This image was then downloaded without errors. It is shown in the figure below.

Image 0xFD, taken on 2019-07-18 around 21:54, downloaded on 2019-07-18 21:59 to 22:28

The figures below show the GMAT simulation for this image. See my previous post for more information about these simulations.

GMAT simulation for image 0xFD field of view
GMAT ground track for image 0xFD

The GMAT simulation shows this area of the lunar surface, but I haven’t been able to recognize the features that appear in the image. Maybe someone can help? Keep in mind that the camera image is rotated, so that north is not the top of the image. Most likely, north is towards the right side of the image.

After the image was downloaded, it was planed to fix image 0xF5 shown above, by downloading the missing chunks. However, image 0xF4 was selected instead by mistake. This is the first image in the series of images of four images of Mare Anguis taken on July 12, which we also planned to download in the future. Since there were only 10 minutes until the payload shut down, we let the download continue instead of wasting time by cancelling the download. The partial image is shown below. It will be interesting to make a panorama with all the Mare Anguis images.

Image 0xF4, taken on 2019-07-12 02:58, partially downloaded on 2019-07-18 to 22:40 to 22:50

Another activity done on July 18 was attempting to command the B0 transmitter to send an SSDV image. The Amateur payload on DSLWP-B has two independent radios, B0 and B1, which work with different downlink and uplink frequencies. Usually, B1 is used to transmit the SSDV images, and B0 only transmits occasional GMSK and JT4G telemetry.

Having B0 and B1 transmit an SSDV image simultaneously in different frequencies (spaced 1MHz apart) would give very interesting possibilities for VLBI observations (see my conclusions to the 2018-11-21 VLBI experiment). However, this experiment hasn’t been performed yet due to worries of overheating the payload with both transmitters on for several minutes. Now that the mission of DSLWP-B has almost finished, this is no longer a concern.

Therefore, we tried to command the B0 radio to transmit an SSDV image while B1 was transmitting the images shown above. However, the radio didn’t seem to accept Reinhard’s commands. This will be tested again in the next activations.

2019-07-21

On July 21, the payload was active between 05:30 and 07:30 UTC. First, image 0xFF, which was taken at payload power on was downloaded. It was already known that the Moon was not visible in this image, so this image shows a faint field of stars. I haven’t managed to identify the image with astrometry.net. Probably there are not enough stars visible.

Image 0xFF, taken on 2019-07-21 05:30, downloaded on 2019-07-21 05:43 to 05:53

After downloading the field of stars, image 0xF4 was downloaded. Part of this image had been downloaded on July 18, but the image was downloaded again completely. The download succeeded without any lost chunks. This is one of the images in the Mare Anguis series.

Image 0xF4, taken on 2019-07-12 02:58, downloaded on 2019-07-21 06:10 to 06:40

Next, the download of image 0xFA was started. This image was taken at the payload activation on July 15 and it was supposed to show an area close to the Apollo 14 landing site. However, it was quickly seen that the image was a purple background, so the download was interrupted.

Image 0xFA, taken on 2019-07-15 12:00, partially downloaded on 2019-07-21 06:49 to 06:56

It is not completely known why this image doesn’t show the Moon surface, as it should according to the simulation. The leading theory is that the flywheels of DSLWP-B weren’t working properly when the image was taken, so the attitude of the satellite was different from the nominal. This makes sense, because the image is a purple background probably because it is over exposed due to the Earth being inside the field of view (or near it). However, with the nominal attitude the Earth shouldn’t be near the field of view of the camera, even if the image was taken at a different time.

The two figures below show the GMAT prediction corresponding to this image.

GMAT simulation for image 0xFA field of view
GMAT simulation for image 0xFA ground track

Finally, image 0xFE, which was taken at payload power on on July 20, was partially downloaded until the payload turned off at 08:30 UTC. According to the GMAT simulation, this image should show an area of the lunar surface around the Schlüter crater. For some unknown reason this image is purple, unlike most other lunar surface images, which are yellowish.

Image 0xFE, taken on 2019-07-20 14:20, partially downloaded on 2019-07-21 07:06 to 08:30

The figures below show the GMAT prediction for the image. In the field of view image, Schlüter crater is clearly visible towards the bottom right. The bottom part of the image shows the northern rim of Mare Orientale.

GMAT simulation for image 0xFE field of view
GMAT simulation for image 0xFE ground track

Below, I have marked the imaged area in Google Moon. The northeastern large crater is labeled as Riccioli P in this lunar chart, but I haven’t found any names for the other craters. Update 2019-07-23: This other chart labels the large crater as Schlüter P instead.

Imaged area for image 0xFE, taken from Google Moon

2 comments

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.