Our SatNOGS station has been very QRT for a long time, first when the USRP broke down and yet more when the antenna fell down. The antenna has since been fixed, the USRP has not been fixed, but we also have an RTL-SDR we could just have plugged straight in back in March. We opted not to since having antennas tracking satellites on top of the roof would look rather bad when the rest of the Student Society was in full Covid-19 lockdown, and we might have had some problems if the antenna for some reason got stuck. This is no longer a problem, if it ever was a problem, so it was time to do something about it.

On the TODO-list was: 1) Set up the RTL-SDR, 2) calibrate the antenna heading and 3) test that everything worked as expected. 1) and 2) turned out to be quite the adventure that was so exciting that I never got to 3).

Battling against old librtlsdr packaging bugs

The baby steps of action point 1) were actually done back in March.

RTL-SDR connected to the SatNOGS NUC to the left.

Once connected, the RTL-SDR was behaving rather weirdly. The SDR was tested using GQRX, where GQRX was run over SSH, which normally causes some glitches in the waterfall display due to network latency, but the glitches were worse than anything I’ve ever seen, and I’ve seen quite a few weird waterfalls in my time.

RTL-SDR showing weird waterfall.

The “LNA gain” setting was also grayed out. Everything was working nicely on my own personal computer, however.

Nice and high signal/noise levels, no weird artifacts, and discernible CW code from one of our beacons. There was even a working LNA gain setting! Everything a man can wish for.

The internal tuner turned out not be detectable. On my own computer:

$ rtl_test -t
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001
Found Fitipower FC0012 tuner

On the SatNOGS computer:

$ rtl_test -t
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001
No supported tuner found

This was most probably due to an already fixed bug in the Debian package, which was consistent with the version available the SatNOGS Ubuntu installation and the release date of the distribution (0.5.3-13, Ubuntu LTS 18.04). Right now we have the option to upgrade to the next Ubuntu LTS version (20.04), but we didn’t have that back in March, so we quickfixed it by just installing a more recent librtlsdr package directly from the Debian repository. Not the best solution, but luckily this worked fine despite some complaints from the packaging system. Sorry, packing system, we’ll fix you more properly later on.

GQRX over SSH still has enough artifacts due to network lag to make it less than clear that the RTL-SDR now was working fine, so we have plotted the frequency bin from an IQ recording instead:

Nice and clear beacon signal! RTL-SDR working nicely. Now onto the antenna heading.

Not calibrating the antenna heading

Everyone knowledgeable about SatNOGS antenna calibration, i.e. LB6RH and LA3WUA, were either a) on a forest hike or b) refurbishing their kitchen. Leave everything to Asgeir! He can fix it and/or damage it beyond repair.

Calibration of the antenna heading can be quite a stressful event if you are all alone and forget that you have wondrous electronic tools available for adjusting the antenna without doing such stressful things.

First, you have to turn the rotor.

Then you have to walk to the ladder.

Then you have to climb the ladder.

And then you have to observe whether the antenna is pointing correctly towards the intended heading.

And then you have to walk all the way back again.

After some back and forth and challenging basic trigonometry exercises you can verify that, yes, the antenna is pointing towards Vassfjellet, our well-defined heading of choice.

This could reveal that reality’s 180 degrees azimuth corresponded to 270 degrees azimuth on the rotor controller. Time to adjust the rotor controller!

The problem is that this is not actually possible with this type of rotor controller. The rotor itself needs to be physically positioned so that rotor controller 270 degrees azimuth actually corresponds to the physical 270 degrees azimuth. Sorry, Øyvind, you mounted the rotor 90 degrees off! Finalization of this adventure will therefore have to wait until LA3WUA can finish his kitchen adventures and come back and rotate the rotor 90 degrees.