## DSLWP-B camera planning for the beginning of November

I have spoken in other occasions about planning the appropriate times to take pictures with the DSLWP-B Inory eye camera. In the beginning of October there was a window that allowed us to take images of the Moon and Earth. A lunar month after this we have new Moon again, so it is an appropriate time to take images with the camera.

This time, the Moon will pass nearer to the centre of the image than on October, and at certain times the Earth will hide behind the Moon, as seen from the camera. This opens up the possibility for taking Earthrise pictures such as the famous image taken during the Apollo 8 mission.

I have updated my camera planning Jupyter notebook to compute the appropriate moments to take images. The image below shows my usual camera field of view diagram.

The vertical axis represents the angular distance in degrees between each object and the centre of the image (Assuming the camera is pointing perfectly away from the Sun. In real life we can have a couple degrees of offset). The red lines represent the limits of the camera field of view, which are measured between the centre and the nearest edge, and between the centre and one corner. Everything between these two lines will only appear if the camera rotation is adequate. Everything below the lower line is guaranteed to appear, regardless of rotation.

We see that between November 6th and November 9th there are four times when the camera will be able to image the Earth and the Moon simultaneously. On the 6th it is almost guaranteed that the Earth will appear inside the image, and on the 9th it depends on the orientation of the camera. On the 7th and 8th it is guaranteed that the Earth will be in the image.

To compute appropriate times for taking an Earthrise picture, I have made the graph below. This shows the angular distance between the Earth and the rim of the Moon. If the distance is negative, the Earth is hidden by the Moon. We see that the Earth hides behind the lunar disc on each of the four days mentioned above.

In the figures below, we zoom in each of the events. In this level of zoom we can plot the “inner” and “outer” Earth rim, so we can see when the Earth is partially hidden by the Moon.

On November 6th the situation is the most interesting in my opinion. It turns out the the Earth will not even hide completely between the Moon. In theory, a tiny sliver will remain visible. Also, it will take more time for the Earth to hide behind the Moon and then reappear. As we will see, the next days this will happen faster. Here, it takes 15 minutes for the Earth to hide, and another 15 minutes to reappear. It spends 10 minutes almost hidden.

It can be a good idea to take a series of 10 images with an interval of 5 minutes between each image, and spanning from 12:40 UTC to 13:30 UTC, to get a good coverage for this event.

On November 7th the Earth goes deeper into the lunar disc, taking 5 minutes to hide, spending 70 minutes hidden, and taking 10 minutes to reappear.

On November 8th the Earth goes even deeper into the lunar disc. It takes around 7 minutes to hide, spends 105 minutes hidden and takes 10 minutes to reappear.

On November 9th the configuration is quite similar to November 7th, but the hiding speed is slower. It takes 15 minutes to hide, spends 100 minutes hidden and takes 15 minutes to reappear.

Overall, I think that the best would be to take a good series of images on November 6th, since this shallow occultation is a rarer event. The challenge will be perhaps to download all the images taken during these days. On average, I think we are downloading around 2 new images per 2 hour activation, taking into account repeats due to lost blocks and dead times. DSLWP-B is able to store 16 images onboard, and every time the UHF transmitter comes on, a new image is taken, overwriting an old image (more information in this post). Thus, if we take many images during these days, we have the danger of overwriting some when trying to download them over the next few days.

Perhaps a good strategy is to arrange for a series of 10 images to be taken on the 6th, and then programming the UHF transmitter to take an image as the Earth comes out of its occultation on the 7th, 8th and 9th. In this way, the 2 hour periods of these three days can be used to download some of the images taken on the 6th, and there are still 3 images of margin in the buffer in case something goes wrong during the downloads over the next few days.

## Upcoming DSLWP-B Moon occultations

In my previous post I showed that during the DSLWP-B observation on 2018-10-27 17:20 UTC, the orbit of DSLWP-B would take it behind the Moon. This doesn’t happen every orbit (read as every day, since the orbit period is around 22 hours). It depends on the angle from which the orbit is viewed from Earth, and hence on the lunar phase.

Knowing beforehand when DSLWP-B will hide behind the Moon allows to perform radio occultation studies. These consist in measuring the RF signal from DSLWP-B as it gets blocked by the lunar disc. Interesting phenomena such as diffraction can be observed.

I have calculated the occultations that will be visible from the Dwingeloo radiotelescope in the remaining part of this year.

Continue reading “Upcoming DSLWP-B Moon occultations”

## Report of the DSLWP-B Amateur observations of the Moon and Earth

The Chinese microsatellite DSLWP-B has been in lunar orbit since 25 May 2018. This satellite carries an Amateur radio payload which includes a small 640×480 CCD camera. The JPEG images taken by the camera can be transmitted using the SSDV protocol at 125 bits per second in the 70cm Amateur satellite band.

Update 17:00 UTC: Wei comments that the camera sensor is CMOS, not CCD, and it has 2592×1944 pixels. The image is resampled to 640×480 to save memory and bandwidth.

The orientation of the camera is fixed: the camera is mounted looking in the opposite direction of the solar panel, which is usually kept pointing directly to the Sun. Therefore, the camera is usually looking  directly away from the Sun. The possibility of imaging celestial bodies such as the Moon and the Earth depends on the relative positions of these and the Sun.

During the first week of October there was a new Moon, which implied that it was possible to take images of the Moon and the Earth, as I have described in this post and this other post. This is a report of all the images taken and downloaded during the observation window.

Continue reading “Report of the DSLWP-B Amateur observations of the Moon and Earth”

## DSLWP-B upcoming observations of Moon and Earth

Yesterday I looked at the photo planning for DSLWP-B, studying the appropriate times to take images with the DSLWP-B Inory eye camera so that there is a chance of getting images of the Moon or Earth. As I remarked, the Earth will be in view of the camera over the next few days, so this is a good time to plan and take images.

I asked Wei Mingchuan BG2BHC to compare his calculations with mine and shortly after this he emailed me his planning for observations between October 8 and 10. After measuring the field of view of the camera as 37×28 degrees, we can plot the angular distances between the Moon or Earth and the centre of the camera to check if the celestial body will be in the field of view of the camera.

The image below shows the angular distance between these celestial bodies and the centre of the camera. As we did in the photo planning post, we assume that the camera points precisely away from the Sun. Since the Moon and Earth (especially the Moon) have an angular size of several degrees, we plot the centre of these objects with a dashed line and the edges which are nearest and furthest from the camera centre with a solid line.

The field of view of the camera is represented with dotted red lines. Since the field of view is a rectangle, we have one mark for the minimum field of view, which is attained between the centre of the image and the centre of the top or bottom edge, and another mark for the maximum field of view, which is attained between the centre of the image and each of the corners.

The rotation of the spacecraft around the camera axis is not controlled precisely, so objects between the two red lines may or may not appear in the image depending on the rotation. Objects below the lower red line are guaranteed to appear if the pointing of the camera is correct and objects above the upper red line will not appear in the image, regardless of the rotation around the camera axis.

To calibrate the exposure of the camera, an image was taken yesterday on 2018-10-06 13:55 UTC. This time is marked in the figure above with an orange line. The image was downloaded this UTC morning. The download was commanded by Reinhard Kuehn DK5LA and received by Cees Bassa and the rest of the PI9CAM team in Dwingeloo. This image is shown below.

The image shows an over exposed Moon. Here we are interested in using the image to confirm the orientation of the camera. The distance between the centre of the image and the edge of the Moon is 240 pixels, which amounts to 14 degrees. The plot above gives a distance of 11 degrees between the edge of the Moon and the camera centre.

Thus, it seems that the camera is pointed off-axis by 3 degrees. This error is not important for scheduling camera photos, since an offset of a few degrees represents a small fraction of the total field of view and the largest error in predicting what will appear in the image is due to rotation of the spacecraft around the camera axis.

The observations planned by Wei for the upcoming days are shown in the plot above by green lines. The start of the observation is marked with a dashed line and the end of the observation (which is 2 hours later) is marked with a dotted line. The camera should take an image at the beginning of the observation and then we have 2 hours to download the image during the rest of the observation.

We see that Wei has taken care to schedule observations exactly on the next three times that the Moon will be closest to the camera centre. This gives the best chance of getting good images of the lunar surface (but the Moon will only fill the image partially, as in the picture shown above).

There are also two additional observations planned when the Moon is not in view. The first, on October 8 is guaranteed to give a good image of the Earth. The second, on October 10 will only give an image of the Earth if the rotation of the spacecraft is right.

The orbital calculations for the plot shown above have been done in GMAT. I have modified the photo_planning.script script to output a report with the coordinates of the Earth and the Moon in the Sun-pointing frame of reference (see the photo planning post).

The angle between the centre of the camera and the centre of the Earth of the Moon can be calculated as$\arccos\left(\frac{x}{\sqrt{x^2+y^2+z^2}}\right),$where $$(x,y,z)$$ are the coordinates of the celestial body in the Sun-pointing frame of reference. The apparent angular radius of the celestial body can be computed as$\arcsin\left(\frac{r}{\sqrt{x^2+y^2+z^2}}\right),$where $$r$$ is the mean radius of the body.

These calculations and the plot have been made in this Jupyter notebook.

## DSLWP-B photo planning

As you may already know, most of the pictures taken so far by the DSLWP-B Inory eye camera have been over-exposed purple things. In order to take more interesting pictures, such as pictures of the Earth and the Moon, we have to plan ahead and know when these objects will be in view of the camera.

The picture below shows a diagram of DSLWP-B. The solar panel is behind the main body, pointing towards the back right. The Inory eye camera points in the opposite direction, towards the front left of the diagram. The camera is located in the front panel of the Amateur radio module, which is one of the pink modules.

In the nominal flight configuration, the solar panel is pointed towards the Sun to gather the maximum amount of sunlight. Therefore, the camera should point opposite to the Sun. This is good, because objects in the field of view of the camera are guaranteed to be well illuminated and it also prevents the Sun from appearing in the image, causing lens flare.

In one of the images taken previously by the camera there is a very bright lens flare, possibly caused by the Sun hitting the camera directly. This seems to indicate that the spacecraft is not always in the nominal flight orientation. As the orientation is very important when doing photo planning, here we assume that the spacecraft is always oriented in the nominal flight configuration, with its camera pointing opposite to the Sun.

We use GMAT with the 20181006 tracking file from dswlp_dev for the orbital calculations. The GMAT script can be downloaded here.

To simulate the orientation of the camera in GMAT, I have used an ObjectReferenced coordinate system. The primary is the Sun, the secondary is DSLWP-B, and the axes are chosen as X = R, Z = N. Therefore, the X axis points away from the Sun, in the direction of the camera. The orbit view is centred on DSLWP-B and points towards +X, so it shows what the camera would see (except for the field of view, which is not simulated).

When propagating the orbit in GMAT we see that the Earth passes near the +X axis every Lunar month and that the Moon crosses the image every orbit.

The two images below show the dates when the Earth will pass nearby the +X axis. These dates are good candidates for taking images of the Earth. From the point of view of the camera, the Earth seems to orbit slowly from right to left in these images. Therefore, there should be a tolerance of a couple of days as to when the images of the Earth could be taken.

Thus, we see that the next good dates for attempting to take images of the Earth are October 9 and November 7 (plus/minus a couple days of margin).

The Moon is much larger from the point of view of DSLWP-B and we have seen already that it fills the field of view of the camera completely. Thus, even though in this GMAT simulation the Moon crosses the screen every orbit, we need to wait until the path taken by the Moon is near the centre of the screen.

In the image below we see a good moment to take an image of the Moon. From the point of view of the camera, the Moon crosses from top to bottom of the screen every orbit and its path moves slightly to the right every time, taking it closer to the centre as we progress towards December.

Therefore, a good moment to attempt to take an image of the Moon is late October and all of November. However, the time when the picture is taken is critical, because the Moon crosses the screen quickly. It is near the +X axis only for one or two hours. Therefore, starting in late October, there will be a window of a couple hours each orbit (or each day, since the orbital period is close to one day) where photos of the Moon can be attempted.

Judging by one of Wei Mingchuan BG2BHC’s lasts tweets, he has also been thinking about dates to take good images with the camera. It would be interesting to know if his findings match what I have exposed here.

A good question when doing this sort of planning is what is the field of view of the camera. Probably this can be estimated from some of the existing images.

As you may already know if you follow me on Twitter, on Saturday September 15 I was in Ávila in the IberRadio Spanish Amateur Radio fair giving a talk about DSLWP-B. The talk was well received and I had quite a full room. I recorded my talk to upload it later to YouTube as I did last year.

Since I know that many international people would be interested in this talk and the talk was in Spanish, I wanted to prepare something in English. As I would be overlaying the slides on the video (since the video quality is quite poor and it is impossible to see the projected slides), I thought of overlaying the slides also in English and adding English subtitles.

Doing the subtitles has been a nightmare. I have been working on this non-stop since Sunday morning (as my free time allows me). I intended to use YouTube’s transcript and auto-sync feature, where you provide a transcript (in the video’s original language) and presumably an AI will auto-sync this to the video’s audio. I say presumably because in my case the auto-sync was a complete failure, so I had to resync everything by hand.

Also, since I have listened to the video over and over, I have gotten a bit bored of my own voice and noted some expressions and words that I tend to use a lot. I think this is good, because now I am more conscious when talking in public and can try to avoid using these expressions so much.

In any case, here is the final result. First you have the video with English slides:

And also you have the video with Spanish slides:

Remember that you can use either Spanish or English subtitles with any of the videos. Also, I have the translation contributions enabled, so feel free to provide subtitles in your own language if you wish.

The PDF slides for the talk can be downloaded in Spanish here and in English here.

## Playing with LilacSat-1

Even though the cubesat LilacSat-1 was launched more than a year ago, I haven’t played with it much, since I’ve been busy with many other things. I tested it briefly after it was launched, using its Codec2 downlink, but I hadn’t done anything else since then.

LilacSat-1 has an FM/Codec2 transponder (uplink is analog FM in the 2m band and downlink is Codec2 digital voice in the 70cm band) and a camera that can be remotely commanded to take and downlink JPEG images (see the instructions here). Thus, it offers very interesting possibilities.

Since I have some free time this weekend, I had planned on playing again with LilacSat-1 by using the Codec2 transponder. Wei Mingchuan BG2BHC persuaded me to try the camera as well, so I teamed up with Mike Rupprecht DK3WN to try the camera this morning. Mike would command the camera, since he has a fixed station with more power, and we would collaborate to receive the image. This is important because a single bit error or lost chunk in a JPEG file ruins the image from the point where it happens, and LilacSat-1 doesn’t have much protection against these problems. By joining the data received by multiple stations, the chances of receiving the complete image correctly are higher.

## 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.

## First SSDV transmission from DSLWP-B

As some of you may know, DSLWP-B, the Chinese lunar-orbiting Amateur satellite carries a camera which is able to take pictures of the Moon and stars. The pictures can be downlinked through the 70cm 250bps GMSK telemetry channel using the SSDV protocol. Since an r=1/2 turbo code is used, this gives a net rate of 125bps, without taking into account overhead due to headers. Thus, even small 640×480 images can take many minutes to transfer, but that is the price one must pay for sending pictures over a distance of 400000km.

On Saturday August 3, at 01:27 UTC, the first SSDV downlink in the history of DSLWP-B was attempted. According to Wei Mingchuan BG2BHC, the groundstation at Harbin managed to command the picture download at 436.400MHz a few minutes before the GMSK transmitter went off at 01:30 UTC. A few SSDV frames were received by the PI9CAM radiotelescope at Dwingeloo.

The partial image that was received was quickly shared on Twitter and on the DSLWP-B camera webpage. The PI9CAM team has now published the IQ recording of this event in their recording repository. Here I analyze that recording and perform my own decoding of the image.