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
next prev parent 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