Doug Lung
Monday the FCC Office of Engineering and Technology released updated OET-69 software and requested comment on the software to be used in conjunction with the proposed Incentive Auction.
You’ll need a fast Internet connection to download the 15 files needed to build the software. Seven of these files are 1.9 GB in size, and one is 700 MB, There are seven additional files with sizes of up to 266 MB. I haven't been in one place long enough with a fast enough connection to download the files, so I haven't been able to test the software.
One of the reasons for the huge size is that all the databases are included. These databases are larger than those for the previous OET-69 software as the new software uses higher resolution terrain data. The good news is that once you download the software, you will not need a special computer to run it. Any Unix-based operating system, including Linux and Apple OS-X, should be able to compile it. (If a reader has a high-speed Internet connection and is willing to spend some time downloading the files (at least five hours at 45 Mbps, assuming the FCC's computer can keep up) for me please email me at dlung@transmitter.com.)
In reviewing the Public Notice on the updated OET-69, I'm impressed with the improvements. I've written several articles on the inaccuracies in the current OET-69 software and presented a summary of them in my RF Delusions presentation at the 2006 NAB Show.
Comments filed in response to the FCC's NPRM on the Incentive Auctions supported the idea that in a repacking, service to all existing viewers and not just to the same number of viewers or the same coverage area, was important. See FCC's 'Preferred' Band Plan Panned for a summary of the comments with links to several of them. Cleaning up some of the inaccuracies and bugs in the present OET-69 software should make this easier to do.
Specific changes include using a one-arc-second terrain database derived from smaller-scale topographic maps with more granular elevation data and an improved method for extracting the elevation data from those maps. The current OET-69 software uses three-arc-second terrain data. Based on the analysis of the existing Longley-Rice code by Sid Shumate at Givens and Bell, it is possible that adding more terrain points may actually decrease accuracy. That needs to be studied.
In the new software, the error in calculating depression angle would be fixed, but this would have to be accompanied by use of accurate elevation patterns that include the impact of mechanical beam tilt to yield accurate results. If distorted horizontal plane azimuth patterns from antennas with mechanical tilt are used, additional errors will be introduced. If the software assumed the relative field was equal at all depression angles, it would likely show coverage much closer to real world results, but could potentially allow new real interference by showing more power in elevation pattern nulls than is really there. Many FCC applications include the true antenna azimuth pattern without tilt, but often only in a graph, not in an easy to extract tabular format.
Collecting the data to do an accurate coverage analysis of antennas with mechanical beam tilt would be difficult. One solution would be to allow stations to submit real antenna azimuth and elevation pattern data if they wanted the most accurate analysis of their coverage. Ideally this data would be accepted in a simple tabular text format that station engineers could obtain from their antenna manufacturers or cut and paste from existing antenna data, rather than the current XML format required for DTS applications. With full antenna pattern data, the software itself could apply the mechanical beam tilt if given the amount of tilt and its orientation.
Two of the proposed changes provide more clear-cut benefits--using more precise geographic coordinates (earlier versions of OET-69 rounded or truncated data to the nearest second – a problem on mountain tops where terrain changes rapidly) and treatment of internal Longley-Rice warnings. Under the current OET-69, if a cell returns “Error Code 3” (usually due to rapid changes in terrain) the result of the calculation is ignored and cells are treated as receiving service with no interference. This makes a station's coverage look better, but it doesn't reflect reality since there may not be any signal in this area, and if there is, it may be getting interference. If all analysis is done ignoring the Error Code 3 flag and coverage in specific cells is protected, this should provide the best protection for a station's real coverage. It’s important that individual cells with predicted service are protected. Otherwise the loss of fake EC3 coverage in 100 cells could be turned into loss of real coverage in a different 100 cells.
One of the proposals that would make it easier to protect coverage on a cell-by-cell basis is establishment of a calculation grid. This is a common grid used by all stations in an area, rather than different grids for stations at different locations. A common grid makes it easier to calculate interference between multiple stations (or wireless carriers) in different locations and test different scenarios without recalculating the coverage for unchanged stations.
Once I'm able to obtain a copy of the software, examine the code, and run some studies to compare with field test results, I'll be able to provide a better analysis of the proposed changes. However, improving the accuracy of the calculation will provide little benefit if the data used in the calculation is incomplete or inaccurate, especially for stations using mechanical beam tilt. I would hope the FCC would give broadcasters who want the best protection of their real world coverage an opportunity to correct and supplement their stations' technical data, and that stations would take advantage of that opportunity.
