Date: Wed, 24 Jul 2013 09:21:40 +0204 From: Johann Hugo <jhugo@meraka.csir.co.za> To: freebsd-wireless@freebsd.org Subject: Re: So, which IEEE<->Frequency mappings should we be all using? Message-ID: <1389802.8kPix1Pqsq@jeep> In-Reply-To: <CAJ-VmokHRAUsL7XEeM8HUNt2WEtj-G8o8uXM2=cQ2moaTbKe4w@mail.gmail.com> References: <CAJ-Vmo=yvHUgv6pwK42n%2BNhPrAu9shxc5pigRkhZE%2Bx91W_FoA@mail.gmail.com> <1374504059.14517.12.camel@jlt4.sipsolutions.net> <CAJ-VmokHRAUsL7XEeM8HUNt2WEtj-G8o8uXM2=cQ2moaTbKe4w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Which vendors are you talking about. Are you planing to add support for any of them. We have a UHF wifi pilot project and was thinking of doing a frequency down convert to UHF. Johann On Monday 22 July 2013 10:35:27 Adrian Chadd wrote: > Well, the UHF stuff is available now and vendors are making cards for > them. I'm happy just mapping them to 2.4GHz channels for now but it > severely restricts the channels (ie, spacing/width) we can use in that > range. > > > > adrian > > On 22 July 2013 07:40, Johannes Berg <johannes@sipsolutions.net> wrote: > > On Wed, 2013-07-17 at 10:42 -0700, Adrian Chadd wrote: > > > >> * 420MHz > >> * 700MHz > >> * 900MHz (which we already have, due to history); > >> * 3.6GHz > >> * 4.9GHz > > > > 3.6 should have been defined in the spec recently, 4.9 surely is defined > > already (though the whole stack will have to support the > > dot11ChannelStartingFactor) > > > > The others are kinda non-standard extensions, and you probably won't > > even be able to properly support them since they're kinda > > pretend-handled like 2.4 GHz. > > > > johannes > > > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@FreeBSD.ORG Wed Jul 24 08:39:16 2013 Return-Path: <owner-freebsd-wireless@FreeBSD.ORG> Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6E71BAF2; Wed, 24 Jul 2013 08:39:15 +0000 (UTC) (envelope-from qinchenchong@gmail.com) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B5C6E2242; Wed, 24 Jul 2013 08:39:15 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id n12so281533oag.8 for <multiple recipients>; Wed, 24 Jul 2013 01:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7ELaF+TTEFZopurqMdppiM1AQQCfYa4NS24b06ZusOM=; b=TGGKVi+zuXDYmPyMShZA52TqDtfJjLIODMC/fKzzaxvXKJI1mxYDVsSiGuJ0GjreK4 hB2nt35fmwZKRpErRFIRyt3vVK5dKPT6YttE1zdVnmmsXxS0jZASIBzu8SVWCDLqr5kD wyYYXerR+QSFlyiSJ3MeR7NC1kVbqum8llUP0aCguFlOc0KImjAFwOjsJoQGLOrxYvQB vyUNQZBvHiYUy3KTB5UVGApQeY3RU6A2O7/bqn+7vbROBwKsLO6Gm0yEZuIaiEI9sFKZ 5cVseIPL9G74Eehx4gJdJWHiQ0HXCaHfNiWIxE2bCGteT6koNQ9o5Yh0vamRn++bMSVh KGGA== MIME-Version: 1.0 X-Received: by 10.50.44.35 with SMTP id b3mr305749igm.7.1374655155042; Wed, 24 Jul 2013 01:39:15 -0700 (PDT) Received: by 10.64.228.70 with HTTP; Wed, 24 Jul 2013 01:39:14 -0700 (PDT) In-Reply-To: <CAJ-Vmom4sY7jcNwWmJkrDwfWjsok2fk8UEwTi5A=egj1JyerLw@mail.gmail.com> References: <CAFnsE3dYdPf5yGTFH683Q1Zh0mc-g+_YtCTraNNt28z2vBoSKw@mail.gmail.com> <CAJ-Vmom4sY7jcNwWmJkrDwfWjsok2fk8UEwTi5A=egj1JyerLw@mail.gmail.com> Date: Wed, 24 Jul 2013 16:39:14 +0800 Message-ID: <CAFnsE3cyg=msBfQqqKUMmLABSL=j24VoMBwbBjxQ6b7Dyy7Mqg@mail.gmail.com> Subject: Re: Chenchong's work on net80211_ratectl From: Chenchong Qin <qinchenchong@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." <freebsd-wireless.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-wireless>, <mailto:freebsd-wireless-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-wireless>; List-Post: <mailto:freebsd-wireless@freebsd.org> List-Help: <mailto:freebsd-wireless-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-wireless>, <mailto:freebsd-wireless-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 24 Jul 2013 08:39:16 -0000 Hi! Thanks for your constructive feedback! First, I've done some renaming things. IEEE80211_RATECTL_OPT_* became IEEE80211_RATECTL_CAP_* and options in ieee80211_ratectl became ir_capabilities. As for max4msframelen , I re-added this field and also ported ath_max_4ms_framelen[4][32] to ieee80211_ratectl. An error is also corrected (about initialization of ir_capabilities). On Tue, Jul 23, 2013 at 10:30 PM, Adrian Chadd <adrian@freebsd.org> wrote: > > * Why do you have IEEE80211_RATECTL_OPT_MULTXCHAIN ? > IEEE80211_RATECTL_OPT_MULTXCHAIN is used in ieee80211_ratectl_hascap_stbc() to assist the determination of whether we can enable STBC. * The reason why I check both the vap/ic and the node bits for HT > capabilities is that they're negotiated. The node bits are what the > remote peer supports. The vap/ic bits are what the local device/vap > supports. So, if the remote node supports STBC and the local node > doesn't, we shouldn't try transmitting short-GI. > uh... I also do the "double check" stuff. Do the ieee80211_ratectl_hascap_* functions do wrong things? And, I'm not very clear about the relation between STBC and short-GI now. It seems that I need some further reading. :) > * In ieee80211_ratectl_complete_rcflags(), enabling RTS/CTS but not > transmitting an 11n rate isn't "right." The 11n hardware supports > per-rate RTS/CTS for non-HT rates. You have to ensure that works. > You've added a capability bit for this (IEEE80211_RATECTL_OPT_MRRPROT) > so you should use it. > Yeah... here my logic messed up. It's corrected. > * the new rate field "options" should be "ir_options", like how the > rest of the fields are prefixed with ir_ > * .. and, nitpicking, it should be "ir_capabilities". > > It's already done. Thanks! Chenchong
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1389802.8kPix1Pqsq>