WXSAT Reception

I’ve been spending a lot of time this year playing with weather satellite reception, specifically the NOAA APT satellites, NOAA 15, 18 and 19, that broadcast their imagery in the 137 MHz band.  These are surprisingly easy to receive with basic equipment and provide really interesting imagery of the current weather overhead.

There’s lots of tutorials out there on the web about the many methods there are of receiving these signals so I won’t replicate those here, this page is intended to outline my particular setup and show some of the results.  One of the aims of my setup is to see what can be achieved at low cost to support a school project detailed elsewhere on this site.

System overview

Click on the system diagram above for an overview of the setup here.  Basically a Raspberry Pi 3 (RPi3) is the star of the show running the satellite prediction software, software-defined radio and image decoding software.  A Python script also runs on the RPi3 to automatically detect new recordings made by the SDR application, opens them in Wxtoimg for decoding into basic images and then uploads them to this website for review.  This allows me to easily sort through the (many) noisy images of low elevation or night-time passes and recognise the passes that have produced good images for further processing.  OK, let’s go through it in a little more detail below…

Antenna

selection_010The antenna I’ve built for this purpose is a Quadrifilar Helix (QFH) type based on G4ILO’s notes.  I’ve added some extra horizontal struts to keep the helix shape better in the wind and strengthened the main mast by inserting a steel clothes rail (a perfect fit into the plastic pipe) inside the lower section of the mast where the clamps are holding it to the wall bracket.  The antenna is mounted deliberately low on my garage to avoid exposing it to the full breadth of pager interference in the local area.  It’s a compromise and really just a first attempt to get something up and running.  Over time this will be compared against the active V/UHF antenna I have installed my chimney.  Nevertheless, the QFH antenna seems to do quite well.

Low Noise Amplifier

My one extravagence in this setup is the inclusion of a Low Noise Amplifier (LNA), specifically an LNA4All.  It’s still a relatively low cost item at about £40 delivered to the UK but it’s the most expensive component in use here.  The LNA is placed almost immediately after the antenna (about 2.5m of RG58 between the antenna and LNA).

RTL Dongle/ Raspberry Pi

RTL SDR dongles again, specifically one from RTL-SDR.com where they supply dongles with the 1PPM temperature-controlled oscillator to reduce the number of settings that have to be fiddled with, important for the use in schools.  The dongle receiver is now run from a Raspberry Pi 3 (I previously used a BeagleBone Black to make this dongle available on my home network and hosted the SDR software on an old spare laptop in the house, the same way I run my other network receivers).  Wired networking is used to connect the RPi3 to the home network and I operate this system mostly by the VNC desktop shown below.

The software component of the receiver is Alexandru Csete’s excellent GQRX SDR application.  This now runs on Raspberry Pi (2 and 3) although care needs to be taken with some of the settings to avoid working the RPi3 CPU too hard.

Settings I use for weather satellite reception on GQRX:

  • Dongle sample rate: 300000 (set fairly low in an attempt to narrow the bandwidth of the receiver and lower its susceptibility to pager interference on nearby frequencies)
  • Dongle LNA gain setting: 44dB (set really high even with the additional LNA4All in the system, I’m sure there’s scope for reducing this but I haven’t tried yet)
  • Demodulation mode: NFM, max deviation = 25kHz (APT setting), Tau = Off
  • Filter bandwidth: about 38 kHz (GPredict will control the Doppler correction on the receiver so I don’t need to set this any wider than is necessary for the APT signal)

Settings specifically to reduce the CPU load on the RPi:

  • Lower FFT refresh rate to 10 frames per second or lower
  • Don’t run GQRX full screen, use a small window size to set GQRX running and then minimise during operation – not having to display the spectrum and waterfall has a big impact on RPi CPU loading

Automatic Recording

The satellite tracking software application GPredict (also written by Alexandru Csete) can control external radios and Alexandru has written in a neat feature to send signals to start and stop GQRX recording at the beginning and end of satellite passes.  The key bit of information to get this working is that the AOS and LOS signals to control recording are only implemented in the development version of GPredict, NOT the version that is in the Ubuntu repo at this time.  One I’d followed these instructions to install the latest version from git I found GPredict was happy to control GQRX and could be left running to record all passes of the selected satellite, see screenshot above.

Processing The Recorded Audio

Update text here to include the Python script and wxtoimage CLI

Recorded satellite passes are decoded using free software – wxtoimg is a very popular application for this.  I simply open the audio files in wxtoimg after they have been recorded.

Some tip and tricks I’ve learned here:

  • Change the sample rate – Linux works natively at 48 kHz sampling rate and so that’s what my gqrx recordings are using.  Wxtoimg only accepts audio files at 11.025 kHz sampling rate.  Use “sox” in Linux to resample the recorded audio files e.g. “sox <existing-filename> <new-filename> rate 11025”.
  • Wxtoimg generates map overlays and false colour for land masses if it matches the created/modified time of the audio file to the time of a satellite pass.  Initially I thought this was based on the filename (all the SDR programs seem to include the recording start time in the filename by default) but it’s actually the file properties that wxtoimg looks to for this.  So, given that we’ve had to create new audio files during the resampling process in Linux, how can we get wxtoimg to match them to the right satellite pass?  Change the file properties to match those of the original recorded audio file – use the “touch -r <file1> <file2>” command in Linux to copy the file properties from file1 to file2.  Another useful technique is to create a new file with the accessed/modified times within the satellite pass time and then copy that files properties to the audio file you want to decode, some example commands here.

Results

Need to update this results section to show that NOAA 15, 18 and 19 are now being received here with very little pager interference on the imagery… This started when I switched over to rtl_fm for my automatic recevier project and appears to be a case of finding the right gain settings for each satellite (gain started high and was then progressively tweaked downwards to find the position of “plenty of gain without overloading the receiver”).

Latest received (unprocessed) images are now being uploaded to this page.

A selection of the best processed images can be found on this page.

Some example images received using this setup (QFH, LNA, RTL dongle)…

NOAA 18 on 137.9125 MHz… An early morning pass in winter so the full spectrum isn’t available for the better looking enhancements.  Quite a lot of pager interference on this channel.

gqrx_20161122_141825_137103019_11025-mcir-crop

NOAA 19 on 137.100 MHz… Again, lots of pager interference on this channel.

NOAA 15 on 137.620 MHz… much less pager interference on this channel at my location (I wonder if this is nationwide or a local?).