The overlapping of WiFi and radars in Europe and America is a HUGE headache. In comparison, for example in Australia, they have channels 116-128 forbidden (see the table at https://en.wikipedia.org/wiki/List_of_WLAN_channels#5_GHz_(8... ) and it is so much easier to operate there (yeah, I get it, with lower available bandwidth to 5GHz wifi).
As you can see in the article, the radar pulse sequence to trigger DFS requires pretty short pulse widths, but you want to use pulse compression (with longer pulses) in modern radars, so you won't trigger DFS. Additionally, you may scan over particular location only once per 5 minutes, so again you have lower chance to trigger it. And another challenge are ever-changing atmospheric conditions - maybe sometimes you won't see the wifi device and so you won't trigger the DFS (https://en.wikipedia.org/wiki/Anomalous_propagation) and then the conditions change and you suddenly start getting interference until the DFS on the remote end re-evaluates.
We have a radar on the Czech-German border and it's interesting that we have way worse interference coming from the Czech side. But this may also be because of some local conditions.
In the comments, it is suggested to transmit a pseudorandom code and then correlate it with the received signal to filter out uncorrelated interference. I'm of course doing this, but it helps for point targets (towers, airplanes) - not so much for distributed targets (clouds), especially when they are not stable in time (the droplets all vibrating in turbulences) - so the replicas you receive are distorted by various means, instead of a single reflection you get from e.g. an airplane.
What helps A LOT is a wifi packet detector, which completely blanks the data when the remote station is transmitting, so our radar is basically operating in the gaps between the packets. For some products (such as reflectivity), we have enough oversampling so we can interpolate the gaps; for other products this degrades the data. But at least you get gaps, not giant "lightsabers".
As you can see in the article, the radar pulse sequence to trigger DFS requires pretty short pulse widths, but you want to use pulse compression (with longer pulses) in modern radars, so you won't trigger DFS. Additionally, you may scan over particular location only once per 5 minutes, so again you have lower chance to trigger it. And another challenge are ever-changing atmospheric conditions - maybe sometimes you won't see the wifi device and so you won't trigger the DFS (https://en.wikipedia.org/wiki/Anomalous_propagation) and then the conditions change and you suddenly start getting interference until the DFS on the remote end re-evaluates.
We have a radar on the Czech-German border and it's interesting that we have way worse interference coming from the Czech side. But this may also be because of some local conditions.
In the comments, it is suggested to transmit a pseudorandom code and then correlate it with the received signal to filter out uncorrelated interference. I'm of course doing this, but it helps for point targets (towers, airplanes) - not so much for distributed targets (clouds), especially when they are not stable in time (the droplets all vibrating in turbulences) - so the replicas you receive are distorted by various means, instead of a single reflection you get from e.g. an airplane.
What helps A LOT is a wifi packet detector, which completely blanks the data when the remote station is transmitting, so our radar is basically operating in the gaps between the packets. For some products (such as reflectivity), we have enough oversampling so we can interpolate the gaps; for other products this degrades the data. But at least you get gaps, not giant "lightsabers".