As mentioned last Wednesday, we’ve been cleaning up our SatNOGS setup in preparation for reception of OPS-SAT. Its beacon was to be turned on 13:55 UTC the same day, and we were very excited to see whether we’d receive it or not. We had also enabled IQ data dumping in order to decode the beacon and hopefully send in a small log with decoded frames to ESA.

The nice thing about the SatNOGS network in this case is that we could follow along as the various stations in the network were able (or not able) to receive the beacon as the satellite passed overhead. COSPAR got a nice, decodeable signal. Then the next ground stations reported bad, bad, bad, good… Would be able to do it?

We didn’t receive anything on our first pass 15:50 UTC, which wasn’t that surprising due to low max elevation and the Samfundet roof probably being in the way, but we got something during our second pass 17:24 UTC:

Got it! The SatNOGS flowgraph even decoded a few of the frames. Having turned on IQ data dumping, we then thought decoding as according to ESA’s requirements would be easy and finished by the evening, maximum. The author of this post was in for four days of annoyance, however. I am usually motivated by my own rage and irritation to get things done, so this was fine.

Everything began with some problems with the GNU Radio installation on my own computer. Path problems gave way to silent failures that gave no clue other than apparent missing modules, until they could be traced back to linking errors and/or to a nice and fat segfault when importing one of the Python modules. Precognizant of future frustrations, I found that my time was probably better spent on decoding the data rather than figuring out the root cause of the current problems, and found a live distro where I could obtain a working GNU Radio install.

Installing and running gr-opssat (and its dependency, gr-satellites) went fine on the fresh live distro, example data worked fine. Stringing through the recorded IQ data, I waited and waited for the first burst to be decoded, but it was suspiciously absent.

Unfortunately, it turned out that the recorded IQ data looked like this:

Even though this is just the noise floor, not much OPS-SAT beacon is expected to be obtainable from data with such characteristics. The reason for this behavior was rather simple (though getting to the reason was not). Measuring the noise floor at a similar frequency, we get the following from our USRP N210: Extremely low signal amplitudes.

SatNOGS has built-in support for dumping IQ data to file, which is easily enabled in the settings. Real and imaginary parts of the data (originally complex float32 data (complex64)) are scaled up and converted to int16 before being dumped to file. The assumption on the data is that it has a dynamic range between -1 and +1, and the data is therefore scaled by 16384 in order to utilize the full range of the int16 datatype.

Since our data has an amplitude of 0.0001, this doesn’t work that well. 0.0001 * 16384 is still only 1.68, and a conversion to integers yields that values that are either 0, -1, 1 og maybe 2 and -2 at the most. In addition, the data is output after some resampling blocks which further reduce the amplitude by around one order of magnitude.

In the process, we discovered that our gain settings were set rather low. Acquisition of LA2UHF at 20 dB RF gain (the default):

LA2UHF at 38 dB RF gain:

Increasing the gain increases the SNR, which we can see by the increase of the ratio of the LA2UHF beacon amplitude to the noise floor amplitude (which could be a nice thing for improved reception). This also increases the amplitudes, which could be a nice thing for the int16 conversion.

… but the amplitude was increased only by one order of magnitude at the upper gain limit. Output using the int16 file block therefore only increases the resolution marginally:

I suspected that the low amplitudes by itself was an error, and that the N210 was in fact broken (especially when compared against our USRP B210 on the same antenna, which had “normal” signal amplitudes). But we probably shouldn’t have been able to receive any satellites at all in that case, and LA3WUA Øyvind was arguing pretty intensely that this could not be the case.

After going a bit back and forth, I realized that the final solution should be to modify the SatNOGS flowgraph to output complex float data directly after the USRP source block and avoid use of the int16 file block entirely – since despite the low amplitudes, the complex float32 data did at least seem to have a suitable resolution and good SNR. With these modifications, we were really excited to see the results from a good OPS-SAT pass Sunday evening:

OPS-SAT waterfall

Compared to our earlier reception, either our gain adjustments had improved reception, or ESA had just turned up the OPS-SAT transmission power. Regardless, we were able to finally obtain good IQ data that were more than just a long list of 1s and 0s, thanks to the hacked-in file sink. Here are five of the frames from the IQ file:

Once we had IQ data with high enough resolution, using gr-opssat to decode the data was rather effortless (or, well, as effortless as it can be setting up the entire GNU Radio chain one more time on the live disk).

Sweet success

We decoded the five frames and sent ’em to ESA, and could finally take Christmas vacation. We were a bit late in the game, five days after launch, but when you’re at it that long it is nice to finally manage to do it.

All in all we have learned a lot about how SatNOGS is put together during the debugging process. We’ve also got some experience in what to do and what not to do the next time we want to do something similar and need to acquire IQ data from our SatNOGS setup. In any case, Merry Christmas! Here is a photo of ARK’s Christmas tree. It resonated at 105 MHz this year, perfect for FM DX hunting.

What will the new year bring? Maybe reasons why my GNU Radio installation is being obstinate. It could also have brought good FM DX, except that LA3WUA threw out the Christmas tree already on Monday.