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.
Fortunately the satellite team has made some IQ recordings (alternative link in Mega) of the transmitter. Quick inspection of these shows that the modulation is 4FSK at 4800baud. The tone separation is 1600Hz, so the tones are at -2400Hz, -800Hz, 800Hz and 2400Hz. I will denote the symbols encoded by these four tones as 0, 1, 2 and 3 respectively. I don’t know yet how to decode these symbols to pairs of bits.
I am using a simple GNU Radio flowgraph to demodulate the 4FSK into soft symbols. It can be found in equisat.grc. Then I open the soft symbols with Audacity to look at the packets and try to discern any patterns.
There are two interesting recordings. In one of them the packets contain a long string of zeros, and in the other one the packets contain a long string of ones. These kinds of packets are very convenient to try to reverse-engineer the coding, because not only the contents of the packet are known, but they are also extremely simple.
The figure below shows the beginning of four of the packets which are composed only of zeros. The packet starts with a preamble which consists of 46 repetitions of the sequence 0033 (only the end of the preamble can be seen in the figure). Then something that looks like a syncword follows. It seems that there are 26 symbols that are always the same: 2121203032130021331023101. If I had to guess, I would say that the syncword should be shorter than these. Probably the first of these symbols are the syncword and the remaining form part of the beginning of the header.
Then there is some part which looks like a header. For some reason this header is slightly different in all the four packets. After this, the packet continues with a long sequence of symbols 2.
The figure below shows the end of the four packets. They are very similar but not exactly the same. After the end of the packet, the transmitter transmits a tone at 0Hz for a while and the goes off.
The packets containing ones are much more interesting. They also start with the preamble, syncword and header. Note that the header is also rather similar between all the four packets below, but also quite different from the headers of the packets containing zeros.
After the header, the packet contains a periodic repetition of 80 symbols: 3-0(x19)-3-0(x9)-2-0(x9)-3-0(x9)-1-0(x9)-3-0(x9)-1-0(x9). It is interesting that sequence of 80 symbols is not something random-like. It has a lot of structure.
The end of the packets is similar to the packets containing only zeros.
There are other recordings that can be interesting to look at in depth. I’ve only looked at them briefly. In particular, the sweep_0to255 recording contains a packet with many 0x00 bytes, then a packet with many 0x01 bytes, etc, until the last packet, which contains many 0xff bytes. All of the packets show a periodic pattern of 80 symbols, as the packet with all ones did. See the figure below.
All this leaves me quite puzzled. I can’t think of any coding (scrambler, convolutional code, etc.) that encodes a sequence of zeros as a constant sequence of symbols but on the other hand produces a repeating sequence when encoding a sequence of ones. The satellite team reports that they have tried to switch off all forms of whitening, FEC, etc., and that the transmitter should be set to “transparent” mode. What “transparent” means is by now quite a mystery, but it is clear that the bits are not transmitted in any straightforward manner. Perhaps someone might be able to give us a good idea.
We used to use Pacific crest radios running 4 level FSK there are many protocol
Settings on the radios
We use satel radios now much better design . I will see what I can find in the notes at work. I service Leica surveying equipment in Australia. Might have to hook up a radio and see if we can receive some signals from the sat
Hi Peter,
Thanks for your message. Any information would be good, since this hasn’t progressed any further due to lack of specification.
Has any further progress been made on this issue? My team is using the same radio and having trouble decoding as well.
Hi Rithu,
Eventually, McKenna Cisler, from the EQUiSat team, figured everything out and built a GNU Radio decoder. See here: https://github.com/BrownSpaceEngineering/gr-equisat_decoder
Hi Peter,
Thanks! I know it’s been a while, but were you able to setup Brown’s decoder?
I’m also wondering if you were able to understand what’s happening in the brown decoder? I’ve tried looking over the code and it’s a little confusing for me as someone without a strong Communications background.
Yes. I was able to use and test the decoder using some EQUiSat recordings. At that time I had a look at the decoder code and, with some explanations from McKenna about what he found when reverse-engineering the radio, I had a good understanding of how the peculiar line coding used by this modem worked. These days I’ve mostly forgot about the stuff.