If you’ve being following my latestposts, 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.
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.
CODAR is an HF radar used to measure surface ocean currents in coastal areas. Usually, it consists of a chirp which repeats every second. The chirp rate is usually on the order of 10kHz/s, and the signal is gated in small pulses so that the CODAR receiver can listen between pulses. The gating frequency can be on the order of 1kHz.
CODAR can be received by skywave many kilometers inland. Being a chirped signal, it is easy to extract the multipath information from the received signal. In this way, one can see the signal bouncing off the different layers of the ionosphere, and magnificent pictures showing the changes in the ionosphere (especially at dawn and dusk) can be obtained. For instance, see these images by Pieter Ibelings N4IP, or the image at the top of this post, which contains 48 hours worth of CODAR data.
Here I describe my approach to receiving CODAR. It uses GNU Radio for most of the signal processing, and Python with NumPy, SciPy and Matplotlib for plotting.
In a previous post I discussed my BER simulations with the LilacSat-1 receiver in gr-satellites. I found out that the “Feed Forward AGC” block was not performing well and causing a considerable loss in performance. David Rowe remarked that an AGC should not be necessary in a PSK modem, since PSK is not sensitive to amplitude. While this is true, several of the GNU Radio blocks that I’m using in my BPSK receiver are indeed sensitive to amplitude, so an AGC must be used with them. Here I look at these blocks and I explain the new AGC that I’m now using in gr-satellites.
In a previous post, I spoke about the cubesat D-SAT. The thing that first caught my attention about this satellite is its image downlink and the quality of some of the images that Mike DK3WN has managed to receive. Yesterday, Mike sent me an IQ recording of D-SAT downlinking a couple of images. After using the Groundstation software by the D-SAT team to verify that the images in the recording can be decoded, I have reverse engineered the protocol used to transmit images and added an image decoder to the D-SAT decoder in gr-satellites.
The image decoder can be tested with the dsat-image.wav recording in satellite-recordings. This WAV file contains the image below, which shows the Southwestern part of Spain and Portugal. The image was taken by D-SAT on 2017-08-17 10:09:54 UTC and received by Mike during the 19:10 UTC pass that evening.
According to the TLEs, at the time this image was taken, D-SAT was just above Rincón de la Victoria, in Málaga, passing on a North to South orbit. This means that D-SAT’s camera was pointing more or less in a direction normal to the orbit.
This image is a 352×288 pixels JPEG image with a size of 13057 bytes. It took 43 seconds to transfer using D-SAT’s 4k8 AF GMSK downlink (yes, the overhead is around 100%, more on that later). In the rest of this post, I detail the protocol used to transmit the images.
D-SAT is an Italian cubesat that will demonstrate a new deorbit hardware. Apparently this system uses dedicated propulsion to make the satellite re-enter from a 500km orbit in 30 minutes. It also carries three more experiments and it was launched in June 23 together with several other small satellites. According to the information from the team, it transmits 4k8 telemetry in the 70cm band. It is not stated explicitly, but we read attentively, we see that it uses a NanoCom U482C transceiver from GOMspace.
Recently, I have seen Mike DK3WN decode very nice images from D-SAT and I have investigated a bit to see what software he is using.
The satellite team provides some decoding software through their forum, which requires registration. Version 2 of their software can be downloaded directly here using the password dsatmission. Its software is based on GNU Radio and it uses a few components from gr-satellites, namely the U482C decoder and some KISS and CSP blocks. These have been incorporated into their decoder from before gr-satellites was restructured. They include a note thanking me in the README, but I didn’t ever hear from them that they were using gr-satellites. It would have been nice if they had contacted me, since this opens up many possibilities for collaboration.
Apart from that, they include a groundstation software which performs telemetry decoding and so on. Unfortunately, the groundstation software is closed-source, distributed only as an x86_64 Linux executable. This is not good for Amateur Radio. We should strive for open source software and open specifications for everything that transmits in our bands. The groundstation software is also distributed in a quite ugly manner as the remains of an Eclipse project (source code stripped, of course). However, it is interesting because it seems that this software is the same they use in their groundstation, and it supports sending commands to the satellite. Naturally, the command transmission is not implemented in the software they distribute, but it is still very interesting to have a peek and see what kinds of commands the satellite supports.
I have added a D-SAT decoder to gr-satellites. The decoder supports sending frames to their groundstation software. Here I describe how to set everything up.
David Rowe always insists that you should simulate the bit error rate for any modem you build. I’ve been intending to do some simulations of the decoders in gr-satellites since a while ago, and I’ve finally had some time to do so. I have simulated the performance of the LilacSat-1 decoder, both for uncoded BPSK and for the Viterbi decoder. This is just the beginning of the story, as the code can be adapted to simulate other modems. Here I describe some generalities about BER simulation in GNU Radio, the simulations I have done for LilacSat-1, and the results.
I am doing some BER simulations with GNU Radio (stay tuned for the next post), and during my experiments I have stumbled upon a bug in the “Decode CCSDS 27″ block. This block is a Viterbi decoder for the CCSDS convolutional code with \(r=1/2\), \(k=7\) (note that the convention used by this block is first POLYA then POLYB so it doesn’t match the NASA-DSN convention nor the CCSDS/NASA-GSFC conventions, as I have mentioned in another post).
The bug consists in the block entering a “degraded” state after it has processed many symbols (on the order of several millions). In this degraded state, it doesn’t decode properly, producing lots of bit errors even if no input symbols are in error. Fortunately, there is another block in GNU Radio which can decode the CCSDS convolutional code, the “CC Decoder” included in FECAPI. This block doesn’t seem to suffer this issue. Here I describe how to replicate the bug, how to replace “Decode CCSDS 27” by “CC Decoder” and some other miscellaneous things related to this bug.