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.
In my previous post I looked at the first SSDV transmission made by DSLWP-B from lunar orbit. There I used the recording made at the Dwingeloo radiotelescope and showed how to decode the SSDV frames and produce a JPEG image.
Only four SSDV frames where transmitted by DSLWP-B, and out of those four, only two could be decoded correctly. I wondered why the decoding of the other two frames failed, since the SNR of the signal as recorded at Dwingeloo was very good, yielding essentially no bit errors (even before FEC decoding).
Now I have looked at the signal more in detail and have found the cause of the corrupted SSDV frames. I have demodulated the signal in Python and have looked at the position where an ASM (attached sync marker) is transmitted. As explained in this post, the ASM marks the beginning of each Turbo codeword. The Turbo codewords are 3576 symbols long and contain a single SSDV frame.
A total of four ASMs are found in the GMSK transmission that contains the SSDV frames, which matches the four SSDV transmitted. However, the distance between some of the ASMs doesn’t agree with the expected length of the Turbo codeword. Two of the Turbo codewords where cut short and not transmitted completely. This explains why the decoding of the corresponding SSDV frames fails.
This is rather interesting, as it seems that DSLWP-B had some problem when transmitting the SSDV frames. I have no idea about the cause of the problem, however. It would be convenient to monitor carefully future SSDV transmissions to see if any similar problem happens again.
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.
In my last post I commented that one of the motivations for the periapsis raise manoeuvre of DSLWP-B on July 20 was to prevent the satellite from crashing into the Moon in a few months. When Wei Mingchuan BG2BHC told me this, I found it a bit surprising, since I had the impression that the periapsis had been raising naturally since the satellite was injected in lunar orbit on May 25. Thus, I decided to propagate the orbit for a period of 2 years using GMAT and study the long-term effects in the Keplerian elements.
A few days ago I discussed the manoeuvre performed by DSLWP-B in preparation for the lunar eclipse. The manoueuvre raised the periapsis of DSLWP-B by around 385km. Wei Mingchuan BG2BHC has now informed me that the manoeuvre was performed on 20 Jul 2018 10:47:09.657. There were two motivations for this manoeuvre: first, to avoid eclipse, as I showed in the previous post; second, as Wei tells me, to prevent DSLWP-B from crashing into the Moon in a few months (more on this in a future post).
Wei doesn’t know the delta-v used for the manoeuvre, but estimating it is an easy exercise using GMAT, which is what I will do in this short post. In this simulation I am taking the orbital state for DSLWP-B from the first line of the 20180714 tracking file published in dslwp_dev. I will assume that the manoeuvre was a prograde burn performed at apoapsis that raised the periapsis by 385km. The GMAT script I have used is lunar_eclipse_manoeuvre.script.
First I propagte the orbit to the date mentioned by Wei. I note that the spacecraft is a little short of apoapsis, so I propagate to apoapsis, which happens at 20 Jul 2018 10:49:33.178 UTC. Then I propagate to periapsis and take note of the periapsis radius, which is 3030.91km. Finally, I use GMAT to estimate a burn that will achieve a periapsis radius of 3415.91km using a differential corrector.
The differential corrector finds a delta-v of 17.2m/s. The iterations of the differential corrector can be seen in the figure and text below. A more difficult exercise is to find a burn that stitches together the orbits described by the 20180714 and 20180727a tracking files. I will leave this as an exercise for the reader. Something very similar was done in DSLWP-B’s journey to the Moon: part II.
EQUiSat is a cubesat from Brown University that was launched to the ISS on May 21 with the Cygnus CRS-9 supply ship. It was released from the ISS on July 13. The payload of EQUiSat is rather interesting: an optical beacon, formed by an array of 4 high power LEDs designed to flash and be visible with the naked eye.
The EQUiSat radio system is also quite interesting and unusual. It uses the PacificCrest XDL Micro transmitter in 4FSK mode. This UHF transmitter is normally used to transmit data between survey GNSS receivers. Unfortunately, there is very little documentation about the radio protocol used by this transmitter.
I am in communication with the satellite team, since they are interested in producing a GNU Radio decoder. However, they don’t know much about the radio protocol either. Here is my first try at trying to decode transmissions from EQUiSat. Continue reading “Trying to decode EQUiSat”