OT Wireless
Search/Menu

Search the field guide, causes, requirements, and glossary

False DFS radar detections

An access point can mistake Wi-Fi bursts or other pulsed energy for radar, and the rules make it vacate the channel exactly as if the radar were real.

Ben RutterIndustrial network engineer
  • Updated
  • Reviewed
  • 2 min read
  • 6 sources
On this page5 sections
  1. How it presents
  2. Why it happens
  3. How to confirm it
  4. The fix
  5. Prevent it at design time

Is this your problem? It presents like this

  • One access point logs radar while its neighbors on the same channel log nothing.
  • The same access point logs radar on several different channels over time.
  • Events rise during busy shifts and fall away when the plant is quiet.
  • Every client on that radio drops at the same moment, exactly as in a real radar event.
  • Events cluster in dense client areas or near particular equipment.
Bands
5 GHz DFS
Not sure?
Rank the likely causes from your symptoms

Why it happens

The rules do not ask whether the radar was real. Under FCC rules, a channel flagged as containing a radar system by the access point’s own monitoring is subject to the non-occupancy period. ETSI says the channel containing the detected frequency becomes an Unavailable Channel. A false positive costs exactly what a true one costs.

Detection is pattern matching on energy, and patterns can fool it. One vendor’s DFS troubleshooting note describes a false event as a radio seeing an energy pattern that it believes is radar, possibly from a nearby client radio. Its rule of thumb is simple: if a single access point detects radar, it is probably false, and if several detect it at once, it is likely real.

The pattern matcher is software, so an upgrade can change how often it fires. One vendor’s release notes list false radar detection on one access point model as a defect fixed in a maintenance release. Count radar events per access point before and after every upgrade.

The pattern over time differs too. One practitioner’s analysis found genuine radar hits a specific subset of channels at a steady rate, while false positives spread across a wide part of the band and fall off outside office hours. Dense clients, bad client drivers, co-channel access points, and local non-Wi-Fi equipment are the suspects. Another vendor’s radio management learns which APs see the most radar and keeps them off those channels.

You cannot prove any single event false, and neither can the access point, which is why it leaves. Treat a radio that keeps hearing radar as a fault to fix, not weather to wait out.

What one radar detection does to a DFS channel

The access point has to leave. How long clients wait depends on where it goes next.

Schematic, not to scale

Channel A, a DFS channelNormal trafficRadar detectednormal trafficends in 200 msleaves the channelwithin 10 sNext channel has no DFS requirementtransmits at once; clients can rejoinNext channel is also DFSlistens 60 s first, silentclients rejoinChannel A stays closed to this access point for at least 30 minutes

US rules: after a detection, normal traffic may continue for at most 200 ms, and every transmission on the channel must stop within 10 seconds. Before using any DFS channel, the access point must listen for radar for 60 seconds. A channel where radar was detected stays off limits for at least 30 minutes. Segments are not drawn to scale.

Source: 47 CFR 15.407(h)(2).

How to confirm it

  1. Pull radar events for every access point over at least a week, with channel and timestamp.
  2. For each event, check whether other access points on the same channel nearby detected radar at the same time. One radio alone suggests a false detection.
  3. Check whether the access point logs radar across many channels or a small set. Real radar tends to hit the same few channels.
  4. Compare the event rate with shift patterns and client counts.
  5. Read the access point firmware release notes for radar detection fixes, and sweep the area with a spectrum analyzer for pulsed non-Wi-Fi sources.

The fix

  • Take the affected access points, or the affected area, off DFS channels.
  • Upgrade access point firmware where the vendor documents better radar filtering, after testing it.
  • Narrow channel width so the plan needs fewer DFS channels.
  • Find and move or shield the local pulsed source if a spectrum capture shows one.

Prevent it at design time

  • Keep critical clients on non-DFS channels, so a false detection costs capacity, not connections.
  • Alert on radar events per access point, so a single misbehaving radio stands out.
  • Include radar event history in the checks you run after every firmware upgrade.

Related causes

Terms on this page

About this page

Built from 6 sources: 1 standards body or lab, 1 regulator or government source, 3 vendor documents and 1 other source. Researched and drafted with AI assistance, then reviewed and approved by Ben Rutter on . How pages are made

First published
Last updated
Change history (1)
  • First published
Cite this page

Plain

Ben Rutter. "False DFS radar detections." OT Wireless, published October 5, 2026. https://otwireless.com/causes/dfs-false-detections/

APA 7

Rutter, B. (2026, October 5). False DFS radar detections. OT Wireless. https://otwireless.com/causes/dfs-false-detections/

BibTeX

@misc{rutter2026dfsfalsedetections,
  author = {Rutter, Ben},
  title = {{False DFS radar detections}},
  year = {2026},
  howpublished = {\url{https://otwireless.com/causes/dfs-false-detections/}},
  organization = {OT Wireless},
}