On 15th August, a Chinese CZ-2D rocket launched three satellites from Juiuquan (Mongolia). The main payload was the Chinese satellite QSS, designed to do some experiments in quantum communications and entanglement. As anything that has the word quantum on it, this satellite even made it to the mainstream news in Spain. The rocket also launched Lixing 1, another Chinese satellite which will research the upper atmosphere, and 3CAT2, from the Universidad Politècnica de Catalunya (Spain).
3CAT2’s main payload is a GNSS reflectrometer designed to measure the altitude of the Earth and map the oceans. This means that it uses reflections of satellite navigation signals off the surface of the earth and sea to perform mapping. It will mainly use the L1 and L2 signals from GPS, but it can also work with Galileo, GLONASS and BeiDou signals. It also carries a prototype of a magnetometer designed for the eLISA project. This project consists in setting up a laser interferometer in space to observe gravity waves. It is roughly the same as the Earth-based LIGO, that recently confirmed the first detections of gravity waves. However, since eLISA will be in space, its laser arms will much longer than LIGO’s. This permits to study much lower frequencies than it’s possible Earth-based interferometers.
3CAT2 has a downlink in the Amateur 2m band, at 145.970MHz, and transmits 9600bps BPSK. It also has a faster BPSK downlink in the S-band, presumably at 2401MHz (inside the Amateur 13cm band). The days following 3CAT2’s launch I tried to receive its VHF signal, without any luck. I have been in contact with other Amateurs who also listened and didn’t hear anything.
This morning, I’ve received email from Scott K4KDR telling me that he has heard the satellite for the first time and he has managed to do a recording, but he is unable to decode the data.
We where unsure about which encoding that 3CAT2 is using. It could be AX.25, or some custom protocol using FEC. As far as I know, the only other satellite that transmits 9k6 BPSK in the Amateur bands is LilacSat-2, which uses strong FEC. Nevertheless, I’ve taken a good look at Scott’s recording and I’ve been able to decode one packet. This is, as far as I’m aware, the first decoding of 3CAT2 by an Amateur operator.
It turns out that 3CAT2 is using AX.25. This is easy to guess from the spectral lines in the preamble and postamble of the packets. In an AX.25 packet, these consist of a repeating sequence of flag bytes (0x7e). Since AX.25 uses NRZ-I encoding, these produce the repeating sequence 01111111 or 10000000, which causes many spectral lines when modulated using BPSK. You can see this effect in the image below, which shows the packet that I’ve managed to decode. Other protocols employ different preambles that produce fewer spectral lines. For instance, the sequence 01010101, which is used by Funcube, produces only two spectral lines spaced 1Hz per bps (1.2kHz for the 1k2 BPSK used by Funcube). If you go back to my LilacSat-2 post, you can see that it only produces 6 spectral lines.
A total of 7 packets are clearly visible in Scott’s recording. Weaker traces of other packets are also present. However, only one of the packets seems to have a high enough SNR to be decoded. Keep in mind that AX.25 uses no error correction, so all the bits have to be received without error or the CRC-16 check will fail (still, you may pull out some data from packets with some bit errors, if you know what you’re looking for). As I’ve said, I only managed to decode the stronger packet in the recording, which is shown above. When trying to decode the remaining packets, their constellation diagrams didn’t show the points -1 and 1 clearly separated, so bit errors are likely. I’ve also needed to fine-tune the parameters in the polyphase clock sync that I’m using in my GNUradio decoder to be able to decode the packet properly. LilacSat’s FEC is very effective, and its packets can be decoded horizon-to-horizon without problems. However, 3CAT2 will prove tricky to decode.
Below, you can see the AX.25 packet, analysed with Wireshark. The AX.25 spec is not followed properly, so Wireshark has a bit of trouble with some fields. It is clear that a 14 byte address field is used. This means that the packet only contains the destination and source address, and it doesn’t specify repeaters addresses. However, the address extension bit is not set. The bit 0 of all the bytes in the address field should be 0 except in the last byte, where it should be 1. This marks the end of the address field and distinguishes 14 byte address fields from longer address fields, which include repeaters. This is the reason why Wireshark tries to parse repeater addresses and shows an invalid “Via 1” field.
The control field is thus the byte following the addresses. Its value is 0x03. This marks an UI (unnumbered information frame), normally used to transmit other protocols such as APRS, IP or raw data on top of AX.25. The next byte after the control field in an UI frame is the PID, which specifies which L3 protocol is contained in the frame. Its value is 0xf0, which means no L3 protocol. This is used for APRS and to send raw data. I’m not sure why the next byte is 0xff, but the rest of the bytes are clearly numbers in ASCII separated by spaces. Most likely these are the values of different telemetry. Perhaps the UPC team in charge of the satellite can identify which are the channels measured. The values are as follows:
3 7781 0245 07 06 1 0 3.5e-01 2.5e-01 1.6e-01 6.8e-09 1.2e-09 1.8e-08
As we’ve seen, the only real problem with the AX.25 header on the packet is that the extension bit is missing. One can modify the packet to include the extension bit. Then Wireshark and other tools can analyse the packet properly (see below). I’ve only changed the 15th byte to 0x61 (it was 0x00 before).
The packet that I’ve decoded can be found in this wav file, which is just an excerpt from Scott’s recording. It’s a 48kHz wav file which contains the BPSK signal at around 10kHz. I’ve added the GNURadio flowgraph I’ve used to my gr-kiss OOT module. It’s in examples/3cat2.grc. I’ll try contact the UPC team to see if they can give me any details about the telemetry channels. Many thanks to Scott K4KDR for his recording.
Update 16:47UTC Jan PE0SAT has uploaded an IQ recording done on 24/08/2016 at 10:54. Without much effort in optimizing decoding parameters or tracking Doppler, this recording produces the following decode. Each line is one telemetry line. The header is always the same.
3 8258 0233 04 08 1 0 4.9e-01 4.2e-01 1.0e+00 6.9e-09 1.7e-09 1.7e-08 3 8277 0221 05 08 1 0 1.6e-01 8.7e-01 5.7e-01 6.7e-09 1.4e-09 1.7e-08 3 8287 0245 05 08 1 0 2.6e-01 9.6e-01 4.6e-01 6.7e-09 1.4e-09 1.7e-08 3 8296 0257 05 08 1 0 6.2e-01 7.8e-01 4.2e-01 6.7e-09 1.4e-09 1.7e-08 3 8305 0257 05 09 1 0 6.4e-01 7.2e-01 4.9e-01 6.7e-09 1.4e-09 1.7e-08 3 8305 0245 05 09 1 0 6.4e-01 6.6e-01 5.9e-01 6.8e-09 1.5e-09 1.7e-08 3 8296 0245 05 09 1 0 6.0e-01 6.0e-01 7.1e-01 6.8e-09 1.5e-09 1.7e-08 3 8296 0245 05 09 1 0 5.4e-01 5.4e-01 8.6e-01 6.8e-09 1.6e-09 1.7e-08 3 8287 0245 05 10 1 0 4.5e-01 4.9e-01 1.0e+00 6.9e-09 1.7e-09 1.7e-08 3 8277 0245 05 10 1 0 3.2e-01 4.4e-01 1.0e+00 6.9e-09 1.7e-09 1.7e-08
2 comments