Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Jul 2012 20:22:46 -0700
From:      Adrian Chadd <adrian@freebsd.org>
To:        "Wright, Brett" <Brett.Wright@cooperindustries.com>
Cc:        freebsd-wireless@freebsd.org
Subject:   Re: Atheros DFS radar detection
Message-ID:  <CAJ-VmomJOuu334UamvG7=t2oDyq-UNwdCzEUJ0ytT0REKfFxdA@mail.gmail.com>
In-Reply-To: <475A4E02EFF4724A9E58F55A56AC1316063B3323@APEVS1.ap.ci.root>
References:  <475A4E02EFF4724A9E58F55A56AC1316063B3323@APEVS1.ap.ci.root>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi!

On 31 July 2012 20:13, Wright, Brett <Brett.Wright@cooperindustries.com> wrote:
> Hi All,
>
> I've been trying to get DFS radar detection working with Atheros ar5212
> (and later).

Ruh roh. Pre-AR9160. There be dragons.

> As for matching the ETSI/FCC radar patterns that is OK - I can make the
> open source DFS code comply.

Which source? The stuff in madwifi-dfs? or elsewhere?

> The problem is that it is too sensitive (i.e. too many false detects).
> What I have found is that using ar5213 I get LOTS of radar phy errors
> just for normal crc error free data transfer.

Right. The pulse detection on the earlier chips can get quite noisy,
especially if it decides some marginal signal or out of band trigger
is good enough.

> Even just an iperf test on the bench will give me approx 1 radar phy
> error for every 5 or so tx/rx frame.

Which radar configuration parameters are you using?

> This means that any "real" data of sufficient data rate for these false
> pulses to match the radar patterns will trigger false detection of radar
> and a channel change... (usually iperfing for a couple of minutes is
> enough!)
>
> One approach I've been looking at is some "smarts" that look at how much
> real data is being received and try to decide what "pulses" are not real
> and discard them. However this risks having a radio that does not always
> detect real radar co-incident with when the radio is very busy. I also
> can't help but feel there is some other way to detect and weed out these
> "false" phy radar errors. (for example FreeBSD defines
> HAL_PHYERR_FALSE_RADAR_EXT - I'm not even sure what this is/does).

I don't believe that's relevant for the earlier chips. It's for later
chips where some RF event triggers an initial radar pulse, but it's
cancelled out (eg by another power increase from another frame, or
some other things I don't quite remember at the moment). The hardware
can optionally report those "false radar" events, even if they failed
some of the hardware sanity checks.

The biggest problem you're going to have with pre-AR9130 chips is
doing FCC chirp detection. There's no way to know whether you false
detected a ~50uS frame or saw an actual 40-90uS chirp. The AR9130 and
later chips report FFT data for longer pulses so you can actually
check in software whether it's a chirp pulse or not. But anything
before that revision won't - specifically, all the AR5212 era NICs as
well as the AR5416.

I'd first start by looking at the radar parameters that you're using.
What are they?




Adrian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomJOuu334UamvG7=t2oDyq-UNwdCzEUJ0ytT0REKfFxdA>