ATH10K Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Zach Sherin <zach@netblazr.com>
Cc: ath10k@lists.infradead.org
Subject: Re: Any tips on where per-packet antenna selection could be pushed?
Date: Mon, 6 Jun 2016 10:28:57 -0700	[thread overview]
Message-ID: <5755B2D9.7080207@candelatech.com> (raw)
In-Reply-To: <CAOiRWuUFvZU1b4Pn8nDVs5O5sNK-g0PPbckriP=RmBnB5f-5Gw@mail.gmail.com>

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 <greearb@candelatech.com> 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 <greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

  reply	other threads:[~2016-06-06 17:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-06 17:12 Any tips on where per-packet antenna selection could be pushed? Zach Sherin
2016-06-06 17:21 ` Ben Greear
2016-06-06 17:24   ` Zach Sherin
2016-06-06 17:28     ` Ben Greear [this message]
2016-06-06 17:59       ` Zach Sherin
2016-06-06 18:02         ` Ben Greear
     [not found]           ` <CAJ-VmomKzRAkJNQr2Sg=j57uPfptPiRs1Q026dPeuQv0jMx-Og@mail.gmail.com>
2016-06-06 18:48             ` Zach Sherin
2016-06-06 18:57               ` Ben Greear
2016-06-06 19:22                 ` Zach Sherin
2016-06-07  6:24                   ` Janusz Dziedzic
2016-06-07  7:40                     ` Adrian Chadd
2016-06-07  7:53                       ` Michal Kazior
2016-06-07 16:30                         ` Adrian Chadd
2016-06-08 13:53                           ` Michal Kazior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5755B2D9.7080207@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=ath10k@lists.infradead.org \
    --cc=zach@netblazr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox