Astrocast 0.1 is an Amateur satellite built by the Lucerne University of Applied Sciences and Arts (Hochschule Luzern). It is an in-orbit demonstrator for a future constellation of small satellites providing L-band data services for internet of things applications. The Amateur payload includes an on-board GPS receiver and a PRBS ranging signal transmitter for precise orbit determination .
This satellite was launched on December 3 on the SSO-A launch, but we only have payed attention to it recently. Its IARU coordinated frequency is 437.175MHz (actually it is a bit strange, because the IARU coordination data speaks about Astrocast 0.2, which hasn’t been launched yet). However, the satellite appears to be transmitting on 437.150MHz.
As it turns out, we had an unidentified object transmitting on 437.150MHz. This object was first thought to be RANGE-A, which was also on the SSO-A launch, as this frequency was assigned to RANGE-A. However, the RANGE-A team confirmed that this wasn’t their satellite, and I wasn’t able to identify the modem used by the mystery 437.150MHz signal.
Yesterday, Mike Rupprecht DK3WN noticed that this unidentified signal corresponded to Astrocast 0.1, and sent me some technical documentation about the protocols used by this satellite. Using that information, I confirmed that the mystery satellite at 437.150MHz was indeed Astrocast 0.1 and now I have added a decoder to gr-satellites.
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 BG2BHCpersuaded 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.
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.
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.
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”
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.
Last week I presented a JT4G detection algorithm intended to detect very weak signals from DSLWP-B, down to -25dB SNR in 2500Hz. I have now processed the recordings of yesterday’s transmissions with this algorithm and here I look at the results. I have also made a Python script with the algorithm so that people can process their recordings easily. Instructions are included in this post.
Now that DSLWP-B has already been for 17 days in lunar orbit, there have been several tests of the 70cm Amateur Radio payload, using 250bps GMSK with an r=1/2 turbo code. Several stations have received and decoded these transmissions successfully, ranging from the 25m radiotelescope at PI9CAM in Dwingeloo, the Netherlands (see recordings here) and the old 12m Inmarsat C-band dish in Shahe, Beijing, to much more modest stations such as DK3WN‘s, with a 15.4dBic 20-element crossed yagi in RHCP. The notices for future tests are published in Wei Mingchuan BG2BHC’s twitter account.
As far as I know, there have been no tests using JT4G yet. According to the documentation of WSJT-X 1.9.0, JT4G can be decoded down to -17dB SNR measured in 2.5kHz bandwidth. However, if we don’t insist on decoding the data, but only detecting the signal, much weaker signals can be detected. The algorithm presented here achieves reliable detections down to about -25dB SNR, or 9dB C/N0.
This possibility is very interesting, because it enables very modest stations to detect signals from DSLWP-B. In comparison, the r=1/2 turbo code can achieve decodes down to 1dB Eb/N0, or 25dB C/N0. In theory, this makes detection of JT4G signals 16dB easier than decoding the GMSK telemetry. Thus, very small stations should be able to detect JT4G signals from DSLWP-B.
Following a discussion with Carlos Cabezas EB4FBZ over on the Spanish telegram group Radiofrikis about using Codec2 with DMR, I set out to study the error correction used in DMR, since it quickly caught my eye as something rather interesting. As some may know, I’m not a fan of using DMR for Amateur Radio, so I don’t know much about its technical details. On the other hand, Carlos knows a lot about DMR, so I’ve learned much with this discussion.
In principle, DMR is codec agnostic, but all the existing implementations use a 2450bps AMBE codec. The details of the encoding and FEC are taken directly from the P25 Half Rate Vocoder specification, which encodes a 2450bps MBE stream as a 3600bps stream. Here I look at some interesting details regarding the FEC in this specification.