While developing Blink, our CCSDS compatible satellite data parser, an idea was born. What if we build our own little, improvised, satellite ground station in the office, and capture images from a real satellite? We were all very excited because it sounded like a fun project, and also a good way to test Blink on a real satellite data stream. Surprisingly, there are a lot of weather satellites (NOAA, Meteor, MetOp, Feng-Yun) that transmit unencrypted images of Earth, and with the right equipment and decoding software anyone can capture these images. With the recent rise in popularity of Software Defined Radios this has become both simple and cheap. SDR is a fascinating and promising technology that has gained momentum with the increase of CPU processing power. Using the SDR approach you use a simple device that just samples an analogue signal and transfers the data via ethernet or USB to a PC/server. After that, you can do most of the signal processing (filtering, amplifying, demodulation) in software. A cheap USB connected SDR chip can be bought for as little as $20. Signal processing in software can be done using any of the many available open-source tools, but the most popular one is the excellent GNU Radio.
Our initial plan was to:
- build and install an antenna
- get an SDR device
- implement signal recording and processing in GNU radio
- process the demodulated stream with Blink and extract an image
- automate the recording process and build an image gallery
We considered a couple of satellites, but in the end we chose the Russian polar-orbiting Meteor M2 satellite. We chose it because it transmits data in a CCSDS compatible stream, so we could use Blink to decode the signal. Also, it transmits in the VHF band (137.9 MHz), which means that a simple stationary antenna can be used. The most common type of antenna used to capture satellite images in this band is a quadrifilar helix antenna (QFH). So Toni, our CEO, built one and since you only need a couple of plastic pipes and some coaxial cable, the total cost was around $10.
Not the prettiest antenna in the world… but it works :)
We put the antenna in the back yard behind our office building. We found out later that this was not a good location. The reason is that our office is in the centre of Zagreb, which means that there is a lot of RF interference/noise. On top of that, the yard is surrounded by other buildings, which means that there is no clear view of the antenna and the satellite when the satellite is flying low. We had to leave our antenna in the back yard and settle with lower signal quality, but our advice for someone building their system would be to place the antenna on the roof, in a location without other tall buildings blocking the view, and if possible, somewhere outside of the city centre. In our experience, this is the single most important factor that will determine the size and the quality of recorded images. The difference is visible in the image below where you can see the signal spectrum on two locations, one outside of the city, and the other in the city centre.
The next step after building the antenna was to get an SDR device. We tried two of them: the professional Ettus x310 and the RTL-SDR dongle. They both worked fine and both of them support GNU radio but the Ettus was clearly an overkill (the main reason we got it is to do tests with more demanding, high-bandwidth missions). What we use now for capturing Meteor images is the USB RTL-SDR dongle.
Analogue to digital
After installing drivers for the dongle, we set up a GNU radio script that controls the SDR, records the signal and demodulates it. Meteor uses QPSK, a widely used modulation scheme. After some trial and error, we managed to record and demodulate the data successfully. So we had a stream of 1s and 0s as the output of GNU Radio, and the next step was to extract the image from the stream.
This proved to be difficult, mostly because of a lack of documentation of the data format used by Meteor. The only source of information for us was this Russian forum. We wanted to use Blink for processing recorded data, but we didn't know the exact data format and algorithms used by Meteor. After a lot of digging and reverse-engineering, we finally managed to decode the stream correctly. We first do Viterbi decoding (r=½, k=7) and after that, we do frame synchronisation to find frames. Then we do descrambling, deinterleaving and check Reed-Solomon code of each frame, and use frames that pass the check to assemble packets. From the resulting packets we extract the final image. Blink also produces an excellent processing report each time it runs this process.
The final step was to automate the process so that images are recorded automatically for every flyover of Meteor M2 over Zagreb (which happens 3-4 times a day). We wrote a simple Python script that fetches time and duration of the next flyover from NORAD, and when the time comes GNU Radio script starts to record and demodulate data in real time. After the satellite is no longer visible, the script runs Blink to extract data and generate an image. If an image is extracted, then it is uploaded (along with the processing report) to our public image gallery (http://meteor.amphinicy.com/).
Although very challenging at times, the whole process was both fun and educational. We learned a lot, and since most of us are software engineers, the most valuable things we learned were in the domain of radio-frequency/signal processing. We might improve our system in the future, the main issue being the not-so-optimal location of the antenna. We also think about doing processing on a Raspberry Pi. Our colleagues from the Luxembourg office saw the image gallery and were so impressed that they decided to build a similar system. They are almost finished, so stay tuned, because in a couple of weeks our gallery will host images recorded over Luxembourg.
(this blog was originally written by Tihomir Meščić)