All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.