From owner-freebsd-wireless@FreeBSD.ORG Wed Aug 1 03:22:47 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B4B11065672 for ; Wed, 1 Aug 2012 03:22:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id E1FF38FC15 for ; Wed, 1 Aug 2012 03:22:46 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so353544pbb.13 for ; Tue, 31 Jul 2012 20:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9op6nkZbMfau3uYe5vJDwFTLSW9ujvQLK2X9Cg8q+OM=; b=sX6faSgwjtAZwZdCp6/Fvj/ndl30bpDKuxNzzW/gHSmU2i4E/z+SHQom8VMeMGZO3N ScX26XAJjEkR8XPhIrF02QPIboYLxLfRuxJ2FAsvyEc67i58IgNRrpgzj2Z+2JJMbfn3 SQc+Hv3FN21yjf88ziJ+ZoW/ZdDGk5ntOlozNJLUdfrV2RgEF7Jqh79VZpdmVUuF36ay pBorG9lAu4U/wuD82piVOsra4vM5OUED5LQkjnIXp1xJR9a5nc4aIlgqg+W1FOV0Sr5p MDks9E8mCWBxgSpt0YBcbAhaloMtOFfv7YcyZVrOlErLUNa+jBo4hTasrB3Mjgh05qh4 AjeA== MIME-Version: 1.0 Received: by 10.68.212.138 with SMTP id nk10mr48849217pbc.93.1343791366436; Tue, 31 Jul 2012 20:22:46 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.66.136 with HTTP; Tue, 31 Jul 2012 20:22:46 -0700 (PDT) In-Reply-To: <475A4E02EFF4724A9E58F55A56AC1316063B3323@APEVS1.ap.ci.root> References: <475A4E02EFF4724A9E58F55A56AC1316063B3323@APEVS1.ap.ci.root> Date: Tue, 31 Jul 2012 20:22:46 -0700 X-Google-Sender-Auth: ZLhWfTjDGxa1ordYdpqNgo5JGEs Message-ID: From: Adrian Chadd To: "Wright, Brett" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: Atheros DFS radar detection X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 03:22:47 -0000 Hi! On 31 July 2012 20:13, Wright, Brett 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