In part four, I demonstrated how a seemingly harmless baby monitor (or other similar consumer-grade electronics devices) can completely demolish a legitimate RF signal.
In this latest installment, I thought it prudent to take the fight to the other side of the link. Having one customer call in to complain about lack of service is one thing. Having 20 or more calling is entirely another. The wrath interference can plague at the tower level can feel biblical to say the least.
Using prediction software, RF engineers create coverage plots and path predictions by calculating values like equivalent isotropically radiated power (EIRP), path loss, fade margin and so forth when planning a tower installation. Measuring the RF levels in the area to gauge potential interference is usually not possible at the height at which the proposed system will be broadcasting. Thus, possibly the most important variable in the design phase is reduced to a low altitude, unrepresentative measurement, or an educated guess (especially in the unlicensed band). Not until the tower has been erected and the antennas installed can we get an accurate sense of what’s going on out there.
On the other hand, let’s say you have done everything in your power to guard against the threat of interference and you erect your tower. For the first few weeks to months everything’s gum drops and buttercups. Then Ma’s Ol’ ISP throws up a micro-CAP just down the street from you, in the same frequency band as you, to fill a coverage hole in her network for a handful of eager, broadband-starved households. Next thing you know the helpdesk phones are lighting up with screaming customers, SNMP alerts are snapping like bear traps, and your near-perfect RF baseline has gone from looking like the Bonneville Salt Flats to resembling an EKG attached to an angry wombat in heat.
Let’s break out the same tried-and-true process we have been using to date. As usual, we’ll apply it to a situation that occurred on a real production network, complete with all the rewards, challenges and headaches one is accustomed to when running a large area wireless network.
GENERAL ASSESSMENT
Scale: Omni sector at 11m AGL, approx. 20 customers affected.
Internal factors: No known changes or additions to the WISP network.
External factors: Strongly suspect the reactivation of a seasonal point-to-point link on a new frequency (compared with previous season).
Timing: Increasing calls to the helpdesk from customers in the sector’s coverage area over the span of a few days; seasonal business confirmed as having reopened during the same time period.
TROUBLESHOOTING PROCESS
| Step | Test | Result |
|---|---|---|
| 1 | Baseline review | Noisy (-65 to -60 dBm) mid to upper 900MHz band (910-930MHz), lower noise levels (-77 dBm) in operational channel of 905MHz |
| 2 | Configuration changes | No changes to hardware or software |
| 3 | Customer feedback | Instability and performance affected (‘like someone flicked a switch’) |
| 4 | Radio configuration | Configuration correct |
| 5 | Radio operation and monitoring | Daily automated and manual spectrum analysis results reviewed, new radio signal identified at 906.8MHz |
| 6 | Hardware inspection and component swapping | Site visit to seasonal business performed and vicinity scan performed to confirm interference source (see below) |
| 7 | Parallel system testing | Unnecessary (see conclusion and resolution below) |


CONCLUSION AND SOLUTION
Luckily enough the WISP I was managing already had a relationship with the owner of the business in question. Although I never received a reply from the voice message I left or email I sent explaining the ill effects his wireless system was bestowing upon my unassuming subscribers, I can only assume he changed the frequency or swapped out the link with a radio operating in a different band. Within a couple of days of releasing my abashed pleas, performance leveled out, the SNMP alerts reset and the barking RF wombat baseline returned to its consistent, megabit slumber. In a Hinting back to the first article in this series, the individual responsible for this system probably realized quite quickly that the degraded performance of his or her link was a product of my WISP sector interfering right back. The two-way street is complete!
That’s it for now. Tune in next time when I cover a truly perplexing event that can crop up from time to time in any wireless system: noise that isn’t actually noise!
Author Profile: Tim Preston is a Senior Network and Systems Analyst with experience dating back to 1998. He started on the front lines of technical support for a large northern Ontario Internet service provider while earning his diploma in Computer Programming and Network Analysis. After being hired by a major wireless broadband radio manufacturer, Tim moved to Toronto in 2001. In 2009 Tim started Haven IT Consulting. Examples of work he has done for his clients include providing management and troubleshooting services to wireless ISPs, interconnecting retail outlets for an equipment supplier, and providing technical auditing, network design, operations advice, and technical support for various local businesses and network solutions providers.
Recent Comments