From owner-freebsd-wireless@FreeBSD.ORG Wed Aug 27 23:38:06 2014 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E6ED114; Wed, 27 Aug 2014 23:38:06 +0000 (UTC) Received: from a.mx.bartk.us (173-10-122-205-BusName-Washington.hfc.comcastbusiness.net [173.10.122.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5141C3B5D; Wed, 27 Aug 2014 23:38:06 +0000 (UTC) Received: from [192.168.45.6] (unknown [192.168.45.6]) by a.mx.bartk.us (Postfix) with ESMTP id 14F9D3D004A; Wed, 27 Aug 2014 16:38:05 -0700 (PDT) Message-ID: <53FE6BDC.5030306@bartk.us> Date: Wed, 27 Aug 2014 16:38:04 -0700 From: Bart Kus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: FreeBSD TDMA: Legalizing 440MHz 802.11 modems References: <53FE5CF4.1000901@bartk.us> <53FE6513.8040107@bartk.us> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Aug 2014 23:38:06 -0000 I'm guessing the chip generates its own internal clocks from an external reference. Can that PLL be slowed down ahead of timers overflowing? Hopefully the PCI clock is generated independently. Also, I think Mikrotik implements narrower bands by dropping subcarriers instead of slowing down their symbol rates. I'll try to get a good spectrum picture of their 5MHz mode tonight. Keeping the subcarrier symbol rates relatively higher might offset some analog droops, at the cost of OFDM skirt sharpness. Also, a slight correction. I think you meant the subs are 312.5kHz wide, which would result in a 200kHz emission having 3.125kHz wide subs. Or, perhaps more realistically, running at 1/128th the speed, 2.44140625kHz wide. How can you not love a number like that? :) Does the project have a map of all these clocks + timers which might need tweaking for spectrum reduction? I know you can't cite original Atheros docs, but perhaps there's been derivative documentation works created? --Bart On 08/27/2014 04:13 PM, Adrian Chadd wrote: > On 27 August 2014 16:09, Bart Kus wrote: >> Is the underclocking affecting the digital domain only? Or would there be >> some analog frequency response curves that would start falling off too? If >> it's a digital-only underclock I don't see why there would be any >> degradation (aside from the obvious speed decrease). Is this easily >> testable somehow, with a single clock variable? > It isn't a single clock variable. The chip is a huge state machine and > lots of timers, so all of the timing related things that are counts > that reflect time (eg number of ticks for 802.11 things to occur) need > to be recalculated. > >> Yes, the subcarriers would get really narrow, but the sampling time would >> increase proportionately, so the FFT resolution would stay the same. I >> wonder if we'd be exceeding the hold time of the S&H circuit(s)... I don't >> really know anything about these chips, just making wild ass guesses based >> on generic modem architecture. :) > Well, there's an FFT going on, and you still will have 52 subcarriers, > so divide your 200KHz up into 64 bins (52 subcarriers + guard bits + > sync tones.) > > normally for 20MHz they're 31.25KHz wide. > > For 200KHz that's 0.3125KHz wide, or 312.5Hz wide. There's not a lot > of gap between each carrier and we aren't over-sampling. I don't think > the chip was ever really designed for that. > > Also yes, there's AGC and other bits that have likely only been > characterised for a max hold time of hm, 12mS? Whatever the 1MHz CCK * > maximum packet length is. > > > -a