Lately, I have been testing the GPSDO that I will use to discipline my Es’hail 2 groundstation. One of the tests I have done is to measure the frequency of the TCXO that I use in my Hermes-Lite 2.0beta2 over a few days. Here I show the details of the measurement process and how to process the data in Python.Continue reading “Measuring the stability of a TCXO”
I have made a Python script to plot the Doppler and geometry for a DSLWP-B observation. This can be useful for several things: predicting the downlink and uplink Doppler corrections, checking for the Doppler of the Moonbounce signal, checking the position of DSLWP-B in the sky, and studying Moonbounce geometry.Continue reading “Plotting DSLWP-B observations Doppler and geometry”
While writing my previous report, I had to keep track of when each of the images had been taken and when it was downloaded. This can be a bit tricky, since the images do not carry a timestamp. Here I describe the techniques that can bee used to identify and keep track of the images.Continue reading “Keeping track of DSLWP-B images”
On August 15, during a Russian EVA on the ISS, a total of four Russian nanosatellites were deployed by hand. Although different online sources give incomplete and contradictory information about which satellites were released, it seems that they were SiriusSat 1 and 2, from the Sirius educational centre in Sochi, and Tanusha 3 and 4 from the Southwest State University in Kursk (see also Jonathan McDowell’s space report).
The SiriusSats are using 4k8 FSK AX.25 packet radio at 435.570MHz and 435.670MHz respectively, using callsigns RS13S and RS14S. The Tanushas transmit at 437.050MHz. Tanusha-3 normally transmits 1k2 AFSK AX.25 packet radio using the callsign RS8S, but Mike Rupprecht sent me the other day a recording of a transmission from Tanusha-3 that he could not decode.
It turns out that the packet in this recording uses a very peculiar modulation. The modulation is FM, but the data is carried in audio frequency phase modulation with a deviation of approximately 1 radian. The baudrate is 1200baud and the frequency for the phase modulation carrier is 2400Hz. The coding is AX.25 packet radio.
Why this peculiar mode is used in addition to the standard 1k2 packet radio is a mystery. Mike believes that the satellite is somehow faulty, since the pre-recorded audio messages that it transmits are also garbled (see this recording). If this is the case, it would be very interesting to know which particular failure can turn an AFSK transmitter into a phase modulation transmitter.
I have added support to gr-satellites for decoding the Tanusha-3 phase modulation telemetry. To decode the standard 1k2 AFSK telemetry direwolf can be used. The decoder flowgraph can be seen in the figure below.
The FM demodulated signal comes in from the UDP source. It is first converted down to baseband and then a PLL is used to recover the carrier. The Complex to Arg block recovers the phase, yielding an NRZ signal. This signal is lowpass filtered, and then clock recovery, bit slicing and AX.25 deframing is done. Note that it is also possible to decode this kind of signal differentially, without doing carrier recovery, since the NRZI encoding used by AX.25 is differential. However, the carrier recovery works really well, because there is a lot of residual carrier and this is an audio frequency carrier, so it should be very stable in frequency.
The recording that Mike sent me is in tanusha3_pm.wav. It contains a single AX.25 packet that when analyzed in direwolf yields the following.
RS8S>ALL:This is SWSU satellite TANUSHA-3 from Russia, Kursk<0x0d> ------ U frame UI: p/f=0, No layer 3 protocol implemented., length = 68 dest ALL 0 c/r=1 res=3 last=0 source RS8S 0 c/r=0 res=3 last=1 000: 82 98 98 40 40 40 e0 a4 a6 70 a6 40 40 61 03 f0 ...@@@...p.@@a.. 010: 54 68 69 73 20 69 73 20 53 57 53 55 20 73 61 74 This is SWSU sat 020: 65 6c 6c 69 74 65 20 54 41 4e 55 53 48 41 2d 33 ellite TANUSHA-3 030: 20 66 72 6f 6d 20 52 75 73 73 69 61 2c 20 4b 75 from Russia, Ku 040: 72 73 6b 0d rsk. ------
The contents of the packet are a message in ASCII. The message is of the same kind as those transmitted in AFSK.
If you’ve being following my latest posts, probably you’ve seen that I’m taking great care to decode as much as possible from the SSDV transmissions by DSLWP-B using the recordings made at the Dwingeloo radiotelescope. Since Dwingeloo sees a very high SNR, the reception should be error free, even without any bit error before Turbo decoding.
However, there are some occasional glitches that corrupt a packet, thus losing an SSDV frame. Some of these glitches have been attributed to a frequency jump in the DSLWP-B transmitter. This jump has to do with the onboard TCXO, which compensates frequency digitally, in discrete steps. When the frequency jump happens, the decoder’s PLL loses lock and this corrupts the packet that is being received (note that a carrier phase slip will render the packet undecodable unless it happens very near the end of the packet).
There are other glitches where the gr-dslwp decoder is at fault. The ones that I’ve identify deal in one way or another with the detection of the ASM (attached sync marker). Here I describe some of these problems and my proposed solutions.
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.
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.
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”
K2SAT is a cubesat developed by the Aeroespace Systems and Control Lab in KAIST, a university in Daejeon, South Korea. It will be launched later this year, between September and October. The main mission of the satellite is to test the transmission of images taken with its onboard camera using an S-band QPSK transmitter that supports up to 2Mbps data rate. This will use the 2.4GHz Amateur satellite band, and the satellite has already coordinated a downlink frequency of 2404MHz. The K2SAT team at KAIST is the same one that built the QB50 KR01 (LINK) cubesat.
Since February, I have been collaborating with Pilwon Kwak and the rest of the K2SAT team to produce a GNU Radio receiver for the S-band image downlink and add it to my gr-satellites project. This receiver has now been publicly released. Here I explain the main details of the transmitter and protocol used by K2SAT and the implementation of the receiver.
Following the success of my JT4G detector, which I used to detect very weak signals from DSWLP-B and was also tested by other people, I have made a similar detector for the 250baud GMSK telemetry transmissions.
The coding used by the DSLWP-B GMSK telemetry follows the CCSDS standards for turbo-encoded GMSK/OQPSK. The relevant documentation can be found in the TM Synchronization and Channel Coding and Radio Frequency and Modulation Systems–Part 1: Earth Stations and Spacecraft blue books.
The CCSDS standards specify that a 64bit ASM shall be attached to each \(r=1/2\) turbo codeword. The idea of this algorithm is to correlate against the ASM (adequately precoded and modulated in GMSK). The ASM spans 256ms and the correlation is done as a single coherent integration. As a rule of thumb, this should achieve a reliable detection of signals down to around 12dB C/N0, which is equivalent to -12dB Eb/N0 or -22dB SNR in 2500Hz. Note that the decoding threshold for the \(r=1/2\) turbo code is around 1.5dB Eb/N0, so it is much easier to detect the GMSK beacon using this algorithm than to decode it. The difficulty of GMSK detection is comparable to the difficulty of JT4G decoding, which has a decoding threshold of around -23dB SNR in 2500Hz.
Here I explain the details of this GMSK ASM detector. The Python script for the detector is dslwp_gmsk.py.