DFS Wait Time unexpected

I just updated my B5-Lites to 1.2.3. I was watching them to see where the Auto Everything would settle to this time. It had initially picked 5210 @ 80MHz, which was frankly a stupid choice, but the link had barely been up a minute at the time, so I gave it some time. It decided after a several minutes to change to 5605 @ 20MHz, a much smarter move. But I noticed that the traffic stopped for a minute…
I was, perhaps erroneously, under the impression that the Spectrum Analyzer was capable of monitoring the proposed channel for RADAR well enough to satisfy the FCC DFS Wait Time before moving to the new DFS channel, thus eliminating the down time. Is this not the case?

DFS rules require a wait time (listen to a frequency) before transmitting, as well as requiring monitoring at all times. In the US, the DFS wait is one minute. In some EU countries, at least on some frequencies (typically 5600-5650), the wait can be as long as 10 minutes.

It’s not the spectrum analyzer doing the monitoring. The radar detection requirements in the US are extremely strict, requiring five different types of radar to be detected. Mimosa and Quantenna did a good job on that; the new tests have stymied others. The EU’s detection requirements are a lot simpler.

One proposal that I don’t think the FCC has acted on is to allow receivers to monitor a second DFS channel while using one; if they detect radar, they can then jump without the wait. That would help.

Ok, so it’s not a manufacturer oversight, it’s the FCC being sticks in the mud on sensible new techniques. I have no choice but to accept that…

Correct. One comment, the B5 full versions (not the lites) have the advantage of “Dual Link” 2 non-contiguous channel operation, so you are able to make a DFS change on one channel (and listen for 1 minute) while the other channel continues to operate without impact. Aside from Collocation Sync, the dual channel is the big differentiation versus the lites.

Let me jump in on this topic and ask a question… Are people using DFS for tower backhauls or is that a bad idea? I have steered clear of using DFS in the past because I have had clear channels outside of that band. I don’t at this tower site. I need to put my APs on the few clean non-DFS channels (for ERP reasons). That leaves no room for backhaul.

My link is going to be using B5 integrated radios and the distance is only 1.9 miles. I need as much bandwidth as possible since it is the tower’s backhaul. We are just west of Denver were there is a radar site… However, 3/4 of my link path is well protected geographically from RF noise.

If I am using dual link, should I worry about the backhaul going down for any period of time if it is changing channels? And if I am in manual frequency mode, does it only change to other DFS channels if it has to change?

Not really up to speed (no pun) on DFS operations since I’ve avoided it in the past…

I’m hundreds of miles from the nearest radar site, so for me DFS works fine even with the B5-Lite as long as I only change frequencies in the middle of the night. It’s my understanding that if you use two frequencies with the B5 then the 1 minute DFS wait shouldn’t take you down, but might cause some temporary congestion.
As to what a radar hit will do, the FCC requires that the radio, in this case the one channel, stop transmitting and switch to a random channel. If the new channel is also DFS, then the radio must silently watch the channel for 1 minute before it can resume communications. It also must stay off the frequency that had the radar hit for a minimum of 30 minutes. I don’t know if Mimosa has gotten the FCC to agree to a more sensible reaction to a radar hit than picking a channel at random. Than would be one for @Jaime to answer.

Actually, spectrum history is maintained in a table such that when a DFS event occurs, and the radio is forced to move to another channel, the next best channel in the list is selected instead of a random channel.

We often recommend using DFS channels in conjunction with non-DFS channels (when available) such that the non-DFS channel carries the traffic, albeit at reduced capacity, without dropping the link.