From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail2.candelatech.com ([208.74.158.173]) by merlin.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1b9yQt-0005Yr-1f for ath10k@lists.infradead.org; Mon, 06 Jun 2016 17:35:23 +0000 Subject: Re: Any tips on where per-packet antenna selection could be pushed? References: <5755B0FF.9010900@candelatech.com> From: Ben Greear Message-ID: <5755B2D9.7080207@candelatech.com> Date: Mon, 6 Jun 2016 10:28:57 -0700 MIME-Version: 1.0 In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Zach Sherin Cc: ath10k@lists.infradead.org On 06/06/2016 10:24 AM, Zach Sherin wrote: > I'm not sure I know exactly what you mean by per-peer. Do you mean > that the antenna switches only when we're delivering to a new > next-hop? I would absolutely be fine with that, by per-packet I do > actually mean selection based on destination/next hop so aggregating > deliveries for a single peer would be even better. > > Also, I forgot to mention that this is intended for static mesh > networks, so I'm not worried about moment-to-moment changes in peer > location. Maybe some of the official QCA devs will have some ideas on how to do this with stock firmware. I am guessing you would have to have some API in the firmware that could twiddle your antenna right before attempting to transmit a frame? Do you have physical output pins on your ath10k NIC to even do this? Thanks, Ben > > Thanks, > Zach > > On Mon, Jun 6, 2016 at 1:21 PM, Ben Greear wrote: >> On 06/06/2016 10:12 AM, Zach Sherin wrote: >>> >>> Hi all, >>> >>> I'm working on a device with antenna selection, similar to the ideas >>> behind Ruckus or Google's Onhub router. I've been looking into a >>> solution for per-packet antenna selection (based on destination/next >>> hop). I was hoping this list might be able to suggest where I should >>> investigate adding that switching code. My switches are currently USB >>> RF switches, but I'm going to be using some serial protocol for the >>> final version (we don't have much to switch, and it should be a single >>> byte per packet). >>> >>> The last suggestion I received was to emulate Netsed [1] by routing >>> all packets through a specific socket, running antenna selection, and >>> then pushing them to their final destinations. >>> >>> I assumed that the best place to do antenna selection would be within >>> ath10k itself (my devices all run on ath10k) so that I could introduce >>> the minimum possible latency with antenna selection. Should I be >>> looking at a different part of the networking stack? >>> >>> Does anyone have any suggestions, or perhaps an open-source project >>> out there already trying to do antenna selection? >> >> >> Would per-peer antenna selection work? That is probably more easily >> hacked into the firmware (I don't think stock firmware supports this >> feature, but I could be wrong.) >> >> Thanks, >> Ben >> >>> >>> Thanks, >>> Zach >>> >>> >>> [1] http://silicone.homelinux.org/projects/netsed/ >>> >>> _______________________________________________ >>> ath10k mailing list >>> ath10k@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/ath10k >>> >> >> >> -- >> Ben Greear >> Candela Technologies Inc http://www.candelatech.com >> > -- Ben Greear Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k