Hack 18. Why You Cant Watch Broadcast TV

Hack 18 Why You Can t Watch Broadcast TV

Find out why radio and TV reception can be poor, even if you're near a broadcast tower.

Do not adjust your set! Fiddling with that dial may do your crackly reception no good at all. Much like Wi-Fi, broadcast television signals need a clear line of sight for transmission and can be blocked by hills or other large obstructions. In this hack, we'll use a free software application for *NIX called SPLAT! to explain why you canor can'twatch your favorite broadcast TV station where you live.

According to its web site, SPLAT! is a "terrestrial RF path analysis application for Linux/Unix." Radio frequency path analysis models how radio signals travel over different terrains to figure out how far a radio signal can reach. This technique gives reasonable estimates for the spectrum between 20 MHz and 20 Ghz: from FM radio to satellite-based microwaves. Using SPLAT! we can work out coverage areas for FM radio, television, and even Wi-Fi [Hack #17], but not AM or shortwave radio. (At lower frequencies, these kinds of radio signals bounce off the underside of Earth's ionosphere. This is why lower frequency radio can travel a long way, but it's harder to estimate how far away that may be.)

SPLAT! relies on the 1:250k digital elevation models provided for free by the U.S. Geological Survey, making it only useful for plotting radio and television reception in the United States. Fortunately, GRASS, that Swiss Army chainsaw of free GIS tools, can be persuaded to plot line-of-sight viewsheds using any terrain data [Hack #74] .

2.6.1. Getting Started with SPLAT!

You can download SPLAT! from its homepage at http://www.qsl.net/kd2bd/splat.html. Grab the latest tarball, which as of this writing was splat-1.1.0.tar.gz, and unpack and build it as follows. The SPLAT! application and utilities will install under /usr/local by default:

# tar zvfx splat-1.1.0.tar.gz
# cd splat-1.1.0
# ./configure
# ./install all

You'll need to make sure you have the zlib and bzip2 development libraries installed on your system in order to build SPLAT! correctly. On Debian Linux, try apt-get install zlib1g-dev libbz2-dev. On Red Hat and Fedora, install the RPMs for bzip2-devel and zlib-devel.

Now you need a model of your terrain: a digital elevation model, or DEM. You can get the 1:250k (a.k.a. "1 degree") DEMs from the USGS EROS Data Center at http://edc.usgs.gov/geodata/. Click on the "1:250k DEM" link, and then select "FTP via State" or "FTP via Graphics." As of this writing, the "FTP via Graphics" link will show you a map that you can click to zoom in on, but clicking the actual quadrangle to download the model caused a 404 File Not Found error. Still, you can use this map to figure out which quadrangles you need and then use the "FTP via State" link to actually download them. Be sure to get the compressed, rather than uncompressed, DEM files.

For our example, we'll look at reception for KQED-TV, San Francisco's public television station, in the Bay Area. We need to download the compressed DEMs for both the eastern and western halves of the Santa Rosa, Sacramento, San Francisco, San Jose, and Monterey quadrangles. We also need the eastern half of the Santa Cruz quadrangle (because there isn't a western half). These files range in size from a few dozen kilobytes to about a megabyte and a half.

2.6.2. Making Terrain Models for SPLAT!

After downloading the DEM data, you should end up with a directory full of files with .gz extensions. You can convert these DEMs to SPLAT!'s data format using the postdownload utility that ships with SPLAT!. Do this for each of the compressed DEM files you downloaded:

$ postdownload san_francisco-e.gz
Uncompressing san_francisco-e.gz...
Adding record delimiters...
2402+1 records in
17261+1 records out
8837884 bytes transferred in 3.280152 seconds (2694352 bytes/sec)
Reading "delimited_file"... 25%... 50%... 75%... Done!
Writing "37:38:122:123.sdf"... Done!
Removing temp files...
Done!

SPLAT! should create a bunch of files in the same directory with filenames like 36:37:120:121.sdf. The numbers in the filename correspond to the latitude and longitude of the edges of the original DEM file. If these files are going to live in a different directory than the one you're running SPLAT! from, you need to put that directory path on a single line in a file called .splat_path in your home directory.

SPLAT! uses the Longley-Rice Irregular Terrain Model to estimate how radio frequencies travel. The model needs some parameters to describe atmospheric conditions that affect how radio waves travel. SPLAT! provides sensible defaults in a file called sample.lrp. Copy this file from the splat-1.1.0/ source directory into your current directory, and rename it splat.lrp. Here's a snippet from the beginning of the file:

15.000 ; Earth Dielectric Constant (Relative permittivity)
0.005 ; Earth Conductivity (Siemens per meter)
301.000 ; Atmospheric Bending Constant (N-units)
300.000 ; Frequency in MHz (20 MHz to 20 GHz)
5 ; Radio Climate (5 = Continental Temperate)
0 ; Polarization (0 = Horizontal, 1 = Vertical)
0.5 ; Fraction of situations (50% of locations)
0.5 ; Fraction of time (50% of the time)

These values are fed to the Longley-Rice model to calculate radio propagation properties. Though the defaults work for most purposes, you might want to change them. For example, to model San Francisco, we changed the Radio Climate value to 6 for "maritime temperate," and altered the dielectric constant and conductivity for an urban environment. This is described in detail in the comments that accompany splat.lrp, which are recommended reading for serious SPLAT! hackers.

2.6.3. Finding Your Radio Frequency Transmitter

In the United States, the Federal Communication Commission publishes information about all licensed transmissions on their web site. To make our maps, we need to know the location and height of the antenna, and the radio frequency that the station broadcasts on. You can search for a TV station at http://www.fcc.gov/mb/video/tvq.html or search for an FM radio station at http://www.fcc.gov/mb/audio/fmq.html. Try entering a call sign, such as KQED or WGBH. If you don't know the call sign, just enter your location and, optionally, the broadcast channel you wish to search on. Select the "TV Short List" or "FM Short List" output. This should return a list of one or more station facilities, with hyperlinks to view the full details. We found three results for "KQED," two of them ordinary analog television, and one digital TV transmitter. Here's a bit of the query result:

KQED CA SAN FRANCISCO USA
 
 Licensee: KQED, INC.
 Service Designation: TV 'Full Service' TV Station or Application (analog)
 
 Channel 9 (186-192 MHz) Licensed 
 File No.: BLET -356 Facility ID No: 35500 
 CDBS Application ID No.: 301073 
 
 Antenna Structure Registration Number (ASRN): 1001289
 
 37 
 45' 19.00" Latitude Zone: 2
 122
 27' 6.000" Longitude (NAD27) Frequency Offset: + (plus) 
 Polarization: Horizontally Polarized (H)
 Effective Radiated Power (ERP): 316. kW ERP
 Ant. Height Above Average Terrain (HAAT): 509.0 meters HAAT 
 Ant. Radiation Center Above Mean Sea Level: 541.0 meters RCAMSL
 Ant. Radiation Center Above Ground Level: 530. meters RCAGL

All the information we need is right there. SPLAT! expects to find its transmitter and receiver locations in individual text files with a .qth extension, which is the Amateur Radio code for "location." Create a file called kqed.qth with the following contents:

KQED
37 45 19.0
122 27 6.0
530m

The .qth file has a simple format. The first line is the transmitter label. The second and third lines are latitude north and longitude west, respectivelyin degrees, minutes, and seconds (DMS). You can also provide decimal degrees, instead of DMS values. Finally, the last line in the file specifies the antenna height above ground level in meters, which we took from the RACGL value given earlier. If you leave off the "m," SPLAT! assumes you mean height in feet, instead.

Don't forget that SPLAT! expects degrees of longitude west of the prime meridian as positive values instead of the negative values used for west longitude by most mapping tools! (The author got tripped up by this.)

Also, note that KQED-TV transmits on Channel 9, which has a mean transmission frequency of 189 MHz, instead of the 300 MHz value we gave in splat.lrp. If you're feeling particular, you can make a copy of splat.lrp with the same name as the .qth filein this case, kqed.lrpand update the transmission frequency. SPLAT! will look for this file and use it instead, if it exists.

2.6.4. Drawing Maps with SPLAT!

Now, let's make some maps! The following command tells SPLAT! to make a coverage, or viewshed, map for the transmitter listed in kqed.qth, given receivers with antennas 20 feet above ground level, which is probably a reasonable height for a television antenna mounted on the roof of a house. The map will be output in Portable Pixmap (PPM) format to a file called kqed.ppm.

$ splat -t kqed -c 20.0 -o kqed.ppm

SPLAT! should report loading the .sdf files we created earlier and then announce that it will compute line-of-site coverage for the given location. Finally, after a great deal of computation, it should spit out the requested map file. Most X11 graphics viewers can read PPM files with no trouble, but the format itself is uncompressed, and the maps that SPLAT! produces can be quite large. In the case of the KQED example, the generated PPM was 3600 pixels on a side and weighed in at over 38 megabytes! We can use the fantastic netpbm tools that ship with most Linux distributions to massage this file into something a little more manageable, like a PNG file:

$ pnmtopng kqed.ppm > kqed.png

If you don't have netpbm installed, you can get it pretty easily. It's available from Debian APT, and binary packages exist for most other *NIX distributions.

Assuming 3600 pixels is a little wide for your viewing preferences, you can use the netpbm tools to scale down the image before converting it to another format:

$ pnmscale -xsize 1200 kqed.ppm | pnmtojpeg > kqed.jpg

After scaling down the file and converting it to a JPEG, our coverage map of KQED-TV is now a mere 118k. If you take a look at the map in a graphics viewer, you'll see something that looks like Figure 2-13.

Figure 2-13. A SPLAT! broadcast coverage map for KQED-TV

As you can see, SPLAT! generated a nice grayscale topographic map of the Bay Area using the terrain data, with water features colored blue. The transmitter is shown as a small, labeled red dot near the center of the map (which may be hard to see if you scaled down the image before viewing it, but it's there), and the coverage area is shown in green.

If your map has large blocks of blue where you were expecting to see land, then you may need to obtain and convert more DEMs to cover the missing ground, as described above. If you've converted the additional files, but you're still seeing errant ocean, double-check the filenames of the converted .sdf files to make sure that the latitude and longitude values in the filename are correct.

 

2.6.5. Adding Context to the Coverage Map

Now, although the coverage map we made for KQED-TV is interesting, and quite cool in its own right, it's lacking personal context. We can see where the reception coverage extends to, but it's hard to tell where exactly that is on your mental map. Fortunately, SPLAT! offers a way of adding city locations and political borders to help orient you and readers of your coverage map.

You can get city location data from the U.S. Census Bureau at http://www.census.gov/geo/www/cob/. Download the Incorporated Places data for California in Arc/info Ungenerate format from this site, unzip it, and feed it to the citydecoder utility that ships with SPLAT! Use the sort command to put the list in alphabetical order, and direct it to a text file:

$ unzip pl_d00_ascii.zip
Archive: pl06_d00_ascii.zip
 inflating: pl06_d00.dat 
 inflating: pl06_d00a.dat
$ citydecoder pl06 | sort > cities.txt

This program parses the Arc/info data and builds a list of cities like this:

Acton, 34.482799, 118.177736
Adelanto, 34.559360, 117.440527
Adelanto, 34.584723, 117.336024
Agoura Hills, 34.149436, 118.764436
Alameda, 37.784305, 122.294460
Alamo, 37.861848, 121.992778

The list of cities simply contains a name, a north latitude, and a west longitude, separated by commas. As you can see, there are two entries for the town of Adelantothis is quite common, and a little bit frustrating! Let's draw the KQED coverage map again, but this time with the city location file we just created:

$ splat -t kqed -c 20.0 -s cities.txt -o kqed_with_cities.ppm

Figure 2-14 shows our new map, which has a constellation of inhabited places marked with red dots and labels. SPLAT! only displays cities within the current area of interest, and only those cities whose labels do not overlap with each other. If we zoom in a bit, we can see that KQED-TV can not only be picked up throughout San Francisco, but also across the Bay in Oakland and away south toward Santa Clara. But KQED reception is likely to be crackly in Walnut Creek, Sacramento, or Santa Cruz.

Figure 2-14. KQED-TV's potential broadcast coverage, including cities

The frustrating thing about this map, however, is that, because of the way that SPLAT! shows city data, the one point that it chooses to show for San Jose, out of the five available in cities.txt, happens to be an urban-area outlier that extends beyond the coverage region of KQED-TV. In fact, most of the city lies to the north of the plotted point, well within the green area. As a result, this map makes it seem as if KQED cannot be received in downtown San Jose, when in fact it probably can. The only good way around this is to check the cities.txt file against another source of data and pare it down by hand to just the cities you're interested in.

Figure 2-15. Overlapping broadcast coverage in SPLAT!

 

2.6.6. Hacking the Hack

The astute reader will have noticed that KQED-TV has not one, but two antennas listed with the FCC. It happens that the second KQED-TV antenna on Sutro Tower, a mere 57 meters above ground level, is the station's backup antenna. In the event that the main antenna at the top of the tower, 500 meters above, malfunctions in an earthquake, the station can switch over to the backup antenna to give us our natural disaster news. By how much is KQED-TV's reception radius reduced when their main antenna is knocked out? SPLAT! can help us visualize the answer to this question.

First, we'll make a kqed_backup.qth file, containing the same location as kqed.qth, but with a different description and antenna height.

KQED (Backup)
37 45 19.0
122 27 6.0
57m

Then we'll ask SPLAT! to show us the viewsheds of both antennas overlaid.

$ splat -t kqed kqed_backup -c 20.0 -s cities.txt -o kqed_overlap.ppm

Figure 2-15 shows the coverage of the first antenna listed in green, and the overlap between them in yellow. KQED-TV's two antennas are well placed on Sutro Tower. Even if the main antenna ceases to function, the backup antenna will still reach many of KQED's loyal viewers.

2.6.7. Caveats

Clearly, SPLAT! is useful software. It does a small set of thingsRF propagation and coverage analysisand it does them fairly well. Still, there are minor caveats to using it. The map size isn't really configurable, there's not much way to control which cities get shown and/or which color they get shown in, and the only supported base map is the digital elevation model used to calculate lines of sight. In [Hack #74], we'll look at how to circumvent some of the limitations of SPLAT! by replicating its basic functionality in GRASS.