I'm getting 2-3 AP DFS channel changes/day, whereas in the past I'd get months of uninterrupted service. Still since this scheme follows installations of 2-3APs on shared masts and having set them up in a non-overlapping-channel way to avoid cross-interference between them this all gets out of control too much as of late..

RTouris wrote

I'm getting 2-3 AP DFS channel changes/day, whereas in the past I'd get months of uninterrupted service. Still since this scheme follows installations of 2-3APs on shared masts and having set them up in a non-overlapping-channel way to avoid cross-interference between them this all gets out of control too much as of late..

I experienced a decrease of throughput on 2 APs on a shared mast, too, but I didn't check back then if DFS false positives were the cause. Probably it's not the cross-interference of the APs making trouble (they have a relatively small antenna beamwidth), but the signal from nearby clients. What's the distance of your clients to the AP? Did you already try to lower TX power on the client side?

In the most profound case distance to the CL(STA)s served on one of the shared masts is 0.5/1.5/2.5km. Lowering Tx power on the APs/CLs only slows things down even more as the asocciated CPEs get less dB of signal...Consequently it's pretty evident that the broadcast's dBm power is not the culprit here.

Update: In an effort to pinpoint the culprit I performed a series of downgrades to lower 2.1.xx firmware to no avail. An interesting bit of info during this procedure was that one of the asocciated APs in question for some reason doesn't follow the 2-minute-to-broadcast rule of thumb as the other 2 on the same mast and plainly sits there 9/10 times scanning the band while at the same time showing all it's LEDs but failing to broadcast. Funny enough this one is passing power and data to a second AP that does not exhibit this ill-effect. In changing the orientation of said mast there was NO change in said behaviour of respective AP (maybe this one started to go bad?)..

On a sidenote is there such a beast/device as a DFS generator on the market that could be bought and employed by it's owner to bring down DFS enabled links? One strange thing I noticed while looking back at the survey of this particular site in question (where the 3APs share a mast at about 120º to one another) is that there's 8-10 new non-SSID broadcasting APs with relating MAC addresses (all UBNT) that only appeared about a month ago...Could these somehow cause extra DFS strain and bring down the link every so often?!

I have not heared about DFS simulation devices, but probably vendors have such equipment, maybe a setup in a signal generator.

As for radar detection, a conventional radar signal is a burst of high-energy pulses with a specific frequency and pulse duration. When one burst is over, it is repeated after some duration (sweep time), which is a result of a slow rotate through 360º.

I don't know whether the Atheros AR9350 chip of CPE510 has a special mode to detect radar signals or whether it sees zero-length frames and CRC errors in the payload as an indication of a possible radar signal as the Atheros AR5210/AR5213 chips do. Maybe you should ask an engineer from TP-Link how DFS is implemented on the CPE510 and whether theoretically it is possible that high-energy pulses from other regular WiFi equipment could lead to a (false) radar detection.