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>