Rfl provides an easy to use interface to the Longley-Rice ITM (Irregular Terrain Model) to experiment and learn effects that various settings have on predicted propagation. Rfl performs a simple job simply. It calculates link budgets while offering dials and buttons to control ITM. These include ITM probabilities, choice of profile or area mode, and a variety of environmental properties. Output can be either coverage map or link budget csv file. If interest warrants, rfl could be put on github but I suspect will be limited to a niche group of us. :-)
Mike Markowski, ab3ap
mike.ab3ap@gmail.com
Download here (updated 14 May 2024)
The GUI is a bit fragile but generally functional. Similar items are grouped in individual tabs. If you are a GUI designer and so inclined, please feel free to improve it. It desperately needs some TLC from someone experienced at making GUIs. This is a hobby effort, so I can't provide much in the way of support but will be glad to help in ways that I can.
The biggest challenge to using rfl is getting terrain elevation data. The program is set up to use two sources: DTED level 1 and open-elevation.com. Open Elevation is easiest, but you will need 20 GB of space to download the program and terrain data. Adding GDAL to rfl would provide the best flexibility to read many common formats, but that is a large undertaking for me since I'm not at all familiar with the library.
Rfl calculations are based on the WGS84 model of the earth. Oblate spheroid subroutines that I converted from fortran to python are in earth.py.
The rfl program uses a configuration file and can be run in either command line mode or with a GUI to perform a set of link budget calculations. The configuration file can be named anything, but I like to use a .rfl suffix. The Longley-Rice ITM provides options for link path loss calculated using either terrain profile mode, which uses terrain elevation data. or area mode, which uses general terrain properties but not elevation. Output can be either an RF coverage map or a csv file of link budget results. This means rfl can be run in 4 ways:
| Profile | Area | |
| Map | Realistic map | Smooth map |
| CSV | Terrain-based | Average roughness-based |
In addition, the calculated median path loss can be further characterized using probabilities of reliability for fractions of time, location and situation. Terrain profile calculations have a probability 1 for location since it is known.
Link budgets are performed using NSMA antenna pattern files for gain calculations, ITM for path loss, and a basic noise model. The link budget as implemented by rfl looks like this:
where each block in the diagram is implemented by a different python file containing related subroutines. A benefit of doing so is that each file also has its own main() and can be run as a standalone program. For example, while the nsma.py file provides subroutines that read nsma files, the main() routine allows one to view antenna patterns, find gain at particular az/el, and so on. More detail is available on the NSMA viewer page. The Longley-Rice ITM is discussed in great detail on its dedicated ITM page.
Rfl is controlled completely by a configuration file which can be created by hand or by using a GUI. In both cases, the configuration file is converted to a python dictionary. Two sections follow describing how to run rfl with GUI or command line.
The rfl GUI is separated into 5 tabs, each grouped with a set of related data needed for the link budget calculation. The GUI is started by typing the program name rfl.py and the GUI pops up:
Radio boxes are pre-selected for the most common use, ITM profile mode and PNG coverage map output. Because a profile means there is no location ambiguity, the 'Location fraction' box is grayed out. Similarly, 'Terrain roughness' is grayed out because it is only needed for ITM area mode. (It is calculated from terrain data in profile mode.) When the mouse cursor hovers over a GUI item, usually a description pops up.
Each tab is clicked to move to it. The data in each tab is briefly summarized in the following list:
Unless a scenario is created from scratch, the first thing done is read in a config file. This is done by clicking the 'Open' button to navigate to a file. The GUI is now populated with data from the configuration file. After any modifications, the file name can be changed and the Create button clicked to save the new file.
The GUI is self-documented by hovering the mouse over items of interest. One important requirement is related to the Cancel and Update buttons on each tab. The in-memory data is not changed until the Update button is pressed. The Update button is tab-specific and must be pressed on every tab that is modified. (A pain, I know, but I'm clearly not a GUI designer!)
When the GUI values are entered, the 'Run!' button is pushed. A progress bar reflects speed of calculations. A large grid like the one shown can take quite awhile, on the order of minutes. The coverage shown can be recreated with the gmsWeb.rfl configuration file. Notice that the antenna directory 'ant' has the value 'dummy' because antenna patterns are not used. However, DTED level 1 is used and the cd's have been copied into the directory /data/dted1. Adjust the .rfl file accordingly for your computer.
| 
|
While significant detail is lost compared to the profile mode, area mode has the advantage of not needing terrain data and also providing gross coverage that is sometimes all that is needed. As the rightmost image shows, it can help better see where directional patterns potentially have best coverage.
CSV, comma separated value, file output is often more useful than a coverage map when modeling or other software will further build on rfl results. Rfl does not support files of GPS tracks for multiple stations, but it is potentially useful in emergency or spectrum management situations. Its implementation is left as an exercise for the reader. :-) Link output creates a file containing link budget results for all transmitter-to-receiver pairs. Tx-tx and rx-rx are not calculated and receive antenna polarization is assumed to be same as transmitter's. Here is a typical file viewed with libreoffice that would be paired with the input config file. It is generated with the 5nodeWeb.rfl configuration file. It expects to find the NSMA antenna pattern file in the /data/ant directory and DTED level 1 in /data/dted. These values must be changed for your computer, but the .rfl is an example how to make use of NSMA files.
In the spreadsheet, columns A and B are the names of transmit and receive stations and columns C through H are link budgets values. The last column indicates the type of propagation from transmitter to receiver. Notice that transmit antenna gains in column D are different. This is because the tx-rx RF ray cuts through a different part of antenna pattern. Not apparent, ITM calculates RF take off elevation angles. These are used by rfl to cut through the correct point in a 3d farfield pattern. Input values from the configuration file are not repeated in the output, so it is wise to keep both files together. I often name input and output files similarly, e.g., myTest.rfl and myTest.csv.
Looking at the propagation mode column, we might wonder why the propagation from sensor transmitter to Station 3 is diffraction. To explore that, run prof.py directly:
prof.py -n 200 -a1 24.4 -lat1 31.718025 -lon1 -110.375975 -a2 3 -lat2 31.664167 -lon2 -110.227833
using lat/lon data from the configuration file. The resulting plot shows that RF is indeed diffracted over the obstructing hilltop. Prof.py subroutines are normally run by rfl.py but when run directly also acts as a standalone program with its own capabilities.
rfl -d cfg.rfl
and an rfl configuration file named cfg.rfl is created. It is liberally commented and intended to be descriptive enough for easy use, but please let me know if more description is needed. The config file is an ascii file and can be modified for your scenario using your favorite editor.
Once a config file is created by either command line or GUI, rfl can be easily run from the command line generating the type of output specified:
rfl -c cfg.rfl
When using an NSMA antenna data file, rfl will quit if the specified frequency is not found in the NSMA data file. An easy way to find frequencies that you can use in rfl is to run the nsma.py program:
$ nsma.py -s /data/ant/ant.adf Line 402 warning: expected 180 points, got 179. ABC Antenna Company 800A-065-25-4N E-tilt: 4.0 deg. 851 MHz (-f 851): EL V/V (-p V/V) AZ V/V (-p V/V)
The -s (summary) option displays all cuts, frequencies and polarizations,
and we see that this pattern provides only one frequency that can be used
in rfl, namely, 851. Like prof.py, nsma.py contains subroutines called by
rfl.py, but as mentioned earlier is a fairly capable standalone program in
its own right. See the nsma.py page.