This is a signal acquisition and HRPT decoder component of the STaR project which reads the NOAA 18 and NOAA 19 polar orbiting weather satellites. It is an enhanced version of the GnuRadio gr-noaa module.
- 1 Description
- 2 Graphical Displays
- 3 Software Defined Radio Receivers
- 4 Required Software
- 5 Post-acquisition processing
Use this module in conjunction with a tracking antenna, such as STaR.
This module digitizes the antenna signal and decodes a High Resolution Picture Transmission (HRPT) into a file that can be used to produce image and sounder data. Current applicable satellites include NOAA-18 and NOAA-19. Broadcast frequency, local oscillator frequency, and gain can be specified. Sample rate is set in the GRC, nominally at 2MS/s. The module can be run from the GnuRadio Companion or from the command line. The command line version is typically used in automated acquisition. For example,
> hrpt_lime.py -d /data/pi/SCRB/process -s noaa-19 -g 28 -f 1698.0e6 -l 1565.0e6
where: hrpt_lime.py is this module using a LimeSDR receiver -d specifies the directory for the output file -s names the satellite -g is the SDR gain -f is the satellite broadcast frequency -l is the LO mixer frequency
This is an enhanced version of the GnuRadio gr-noaa module with some parameter tweaks and added graphics. It can be modified for different receivers or a file input can be used. You can find STaR's versions of gr-noaa module at https://gitlab.com/planetaryimaging/STaR under the scripts/noaa directory with hrpt_XXXX.grc where XXXX is the receiver used.
Graphical displays can be turned on or off by enabling or disabling them in the GRC glyph code. Depending on compute power, only one or two displays should be active. Display options are given below.
The time domain display is used to see the voltage range driven by the antenna and SDR amplifiers. Voltages are typically in the range of +- 0.4v to +- 0.8v and can vary depending on the satellite distance from the ground station and receiver interfaces and software. Be careful not to overload the receiver with a strong signal, use an attenuator if input voltage exceeds receiver specs.
This display shows the relative power gain for the signal in the frequency domain and the noise floor. It is also interesting that the Doppler effect can be seen by following the carrier spike as the satellite approaches towards and recedes from the ground station.
The display (below and right) shows the FFT of an over-sampled signal at 4MS/s.
BPSK and RMS
The binary phase shift keying can be seen by enabling the glyphs in the lower right side of the GRC module. This display was motivated by the TyNet.eu version of gr-noaa.
A Root Mean Square bar for voltage can also be displayed and is a handy and efficient way to gauge the signal.
Software Defined Radio Receivers
Most current Software Defined Radios (SDR) can be used with this module, as the required sample rate is as low as 2MS/s. Higher sample rates can also be used. In addition, it is important to consider data delivery interfaces and rates. For example, USB devices inserted into slower USB port versions can impact data delivery. Be sure to check device interfaces with programs like "lsusb -t".
Based on experience, the input signal power to the SDR can range from -44dBm to -15dBm and is dependent on the acquisition electronics of the antenna rig. The objective is to match the output power from the acquisition to the input power range of the receiver while maintaining maximum linear amplification throughout the stream, including the front-end SDR amplification.
Different rigs and receivers will need to be individually matched to maintain amplification linearity. For example, on a -44dBm input signal to a LimeSDR receiver with a front-end amplification of 28dB is sufficient to give a -0.6 to 0.6 voltage signal to the digitizer (voltage does vary with satellite distance). Using a greater power range can introduce non-linearities and so minimal input power is generally preferred. Keep in mind that the optimal amplification occurs at the antenna and that subsequent amplifications can distort the signal. Also be aware not to exceed the input voltage of the receiver.
A (draft) list of necessary software to run the NOAA 18,19 module follows below.
SDR Receiver Software
Software Defined Receivers (SDR) have their own software that should be installed, so if you are using a USRP you should install the software from https://Ettus.com, or using a LimeSDR install software from https://myriadrf.org, or an RTL-SDR install software from https://osmosdr.org, etc. You should consider downloading the Osmosdr software even if you are not using RTL-SDR receivers as they provide an API for other receivers (USRP, LimeSDR included). Hints: Install the receiver code in /usr/local (default) before installing GnuRadio. Also, be sure to test the receiver with its own software before using it with GnuRadio.
Download locations (not all are needed, just the ones to acquire):
UHD git clone --recursive https://github.com/EttusResearch/uhd.git
RTL-SDR git clone git://git.osmocom.org/rtl-sdr.git use: cmake -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON ../
SOAPYSDR git clone --recursive https://github.com/pothosware/SoapySDR.git
SOAPYUHD git clone --recursive https://github.com/pothosware/SoapyUHD.git
The NOAA 18,19 module has been tested on GnuRadio version 126.96.36.199. Previous versions may work. Be sure to install the SDR receiver software first so that GnuRadio installer can find them. If you add a new receiver later you can re-run the GnuRadio install to incorporate it. Be sure to include the GnuRadio Companion in the install.
NOTE: I do not install receiver software or GnuRadio from package managers as these have a tendency to trip over each other. I install from source in /usr/local/src and recommend the default locations (/usr/local/bin,/usr/local/lib, etc.).
GnuRadio is now at version 3.8 and is a substantial revision from 3.7. The out-of-tree modules used in this module have not been ported to 3.8 and will require some effort. To get the 188.8.131.52 version go to https://www.gnuradio.org/releases/gnuradio and download the tarball.
Below are the post-acquisition packages used in STaR for the NOAA18,19 satellites. These packages will extract image and sounder data, calibrate values, and reproject. The HRPT and CoastWatch packages stand alone from the AAPP and Polar2Grid packages.
Terrenus HRPT 2.2 package
A Java-based, High Resolution Picture Transmissio (HRPT) ingestor from Terrenus Earth Sciences http://www.terrenus.ca/ is used to produce an intermediate data file that is value calibrated and georeferenced but not projected. The program hrptingest takes a raw HRPT file (eg. In STaR, output from the hrpt module) and produces a NetCDF output file which is used in the CoastWatch package described below. Note that raw HRPT file may need to be byte swapped.
Visible band radiance (reflections) calibration requires an external file found in the $HRPT_HOME/resource/orbit directory, one for each satellite, eg. noaa18.properties, noaa19.properties. This file contains the coefficients needed to adjust the visible radiance and should be updated monthly from data available at https://www.ospo.noaa.gov/Products/ppp/notices.html.
Calibration coefficients to update with typical values: avhrr.ch1.s1 = 0.05203 avhrr.ch1.i1 = -2.023 avhrr.ch1.s2 = 0.1535 avhrr.ch1.i2 = -52.76 avhrr.ch1.cut = 496.43
avhrr.ch2.s1 = 0.05909 avhrr.ch2.i1 = -2.292 avhrr.ch2.s2 = 0.1760 avhrr.ch2.i2 = -60.76 avhrr.ch2.cut = 500.37
Orbital two line elements (TLE)
The hrptingest program requires an external file for the orbital elements (TLE) for each satellite and is found in the $HRPT_HOME/resource/orbit directory, eg. noaa18.txt, noaa19.txt. The STaR package provides the script $STAR_HOME/aux/getelements_terrenus which retrieves the current TLEs and appends them to the satellite TLE file. If the HRPT package is installed in /usr/local then root will have to update the files, in a crontab or manually.
Review the script "hrpt_process" for implementation details.