From: Zefir Kurtisi <zefir.kurtisi@neratec.com>
To: Nick Kossifidis <mickflemm@gmail.com>
Cc: linux-wireless@vger.kernel.org, ath9k-devel@venema.h4ckr.net
Subject: Re: [PATCH] ath9k: spectral - simplify max_index calculation
Date: Thu, 18 Jun 2015 17:11:46 +0200 [thread overview]
Message-ID: <5582DFB2.7060308@neratec.com> (raw)
In-Reply-To: <CAFtRNNy009MVbOpHOWVZMuDAaJzmLed+nhBwgybgSS+hbjU=tQ@mail.gmail.com>
On 06/18/2015 04:13 PM, Nick Kossifidis wrote:
> [...]
> I have NDA documents as well stating that the indices are from -64 to
> 63 (-64 to -1, 1 to 63 and 0 is DC), you can check out for yourself
> that we get 128bins on dynamic HT20/40, see the header files too:
>
> #define SPECTRAL_HT20_40_NUM_BINS 128
>
Right, there are 128 in total, combined from 2 individual 64-bin sets. That's why
you need to swap upper and lower when operating in HT40MINUS, since chip always
puts primary channel to lower bin set.
> and/or the received packet length. Maybe you are talking about
> "static" HT40 (I don't see anything about that on the documents I
> have) or something else.
>
Yes, maybe different documents. Mine says that interpretation of upper/lower bin
values (max_magnitude, bitmap_weight, max_index) is the same in static and dynamic
modes - only the bin values differ.
>> I used the proposed method with the chirp detector for FFTs provided for long
>> radar pulses on an AR9590 (patch posted the same day). Max bin index is used there
>> the same way as with spectral, but now I realize my mistake: for chirp detection,
>> the relative max_index is sufficient, while for spectral the absolute value is needed.
>>
>> Toggling the MSB in HT20 shifts the signed values by 32 and leaves the index with
>> an offset of 4, therefore the correct operation should be:
>> ht20_max_index_absolute = (ht20_max_index ^ 0x20) - 4
>>
>
> Have in mind that on earlier chips (I did the testing on an AR9820) we
> get corrupted frames sometimes so we also need the sanity check I put
> there or else we can end up reading data out of bounds which is pretty
> dangerous so please leave the current implementation there as is.
>
>
The sanity checks / fixes are done before you look at the bin attributes and,
which therefore is not relevant for interpreting them.
But never mind - as said before, I proposed this to use the 3 functions for DFS
chirp detection. I'm fine not touching the running system and instead keep a local
copy of those.
Thanks,
Zefir
WARNING: multiple messages have this Message-ID (diff)
From: Zefir Kurtisi <zefir.kurtisi@neratec.com>
To: ath9k-devel@lists.ath9k.org
Subject: [ath9k-devel] [PATCH] ath9k: spectral - simplify max_index calculation
Date: Thu, 18 Jun 2015 17:11:46 +0200 [thread overview]
Message-ID: <5582DFB2.7060308@neratec.com> (raw)
In-Reply-To: <CAFtRNNy009MVbOpHOWVZMuDAaJzmLed+nhBwgybgSS+hbjU=tQ@mail.gmail.com>
On 06/18/2015 04:13 PM, Nick Kossifidis wrote:
> [...]
> I have NDA documents as well stating that the indices are from -64 to
> 63 (-64 to -1, 1 to 63 and 0 is DC), you can check out for yourself
> that we get 128bins on dynamic HT20/40, see the header files too:
>
> #define SPECTRAL_HT20_40_NUM_BINS 128
>
Right, there are 128 in total, combined from 2 individual 64-bin sets. That's why
you need to swap upper and lower when operating in HT40MINUS, since chip always
puts primary channel to lower bin set.
> and/or the received packet length. Maybe you are talking about
> "static" HT40 (I don't see anything about that on the documents I
> have) or something else.
>
Yes, maybe different documents. Mine says that interpretation of upper/lower bin
values (max_magnitude, bitmap_weight, max_index) is the same in static and dynamic
modes - only the bin values differ.
>> I used the proposed method with the chirp detector for FFTs provided for long
>> radar pulses on an AR9590 (patch posted the same day). Max bin index is used there
>> the same way as with spectral, but now I realize my mistake: for chirp detection,
>> the relative max_index is sufficient, while for spectral the absolute value is needed.
>>
>> Toggling the MSB in HT20 shifts the signed values by 32 and leaves the index with
>> an offset of 4, therefore the correct operation should be:
>> ht20_max_index_absolute = (ht20_max_index ^ 0x20) - 4
>>
>
> Have in mind that on earlier chips (I did the testing on an AR9820) we
> get corrupted frames sometimes so we also need the sanity check I put
> there or else we can end up reading data out of bounds which is pretty
> dangerous so please leave the current implementation there as is.
>
>
The sanity checks / fixes are done before you look at the bin attributes and,
which therefore is not relevant for interpreting them.
But never mind - as said before, I proposed this to use the 3 functions for DFS
chirp detection. I'm fine not touching the running system and instead keep a local
copy of those.
Thanks,
Zefir
next prev parent reply other threads:[~2015-06-18 15:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-16 9:21 [PATCH] ath9k: spectral - simplify max_index calculation Zefir Kurtisi
2015-06-16 9:21 ` [ath9k-devel] " Zefir Kurtisi
2015-06-18 8:43 ` Nick Kossifidis
2015-06-18 8:43 ` [ath9k-devel] " Nick Kossifidis
2015-06-18 10:36 ` Zefir Kurtisi
2015-06-18 10:36 ` [ath9k-devel] " Zefir Kurtisi
2015-06-18 14:13 ` Nick Kossifidis
2015-06-18 14:13 ` [ath9k-devel] " Nick Kossifidis
2015-06-18 15:11 ` Zefir Kurtisi [this message]
2015-06-18 15:11 ` Zefir Kurtisi
2015-06-18 15:59 ` Nick Kossifidis
2015-06-18 15:59 ` [ath9k-devel] " Nick Kossifidis
2015-06-18 15:34 ` Nick Kossifidis
2015-06-18 15:34 ` [ath9k-devel] " Nick Kossifidis
2015-06-18 15:46 ` Nick Kossifidis
2015-06-18 15:46 ` [ath9k-devel] " Nick Kossifidis
2015-06-18 16:40 ` Zefir Kurtisi
2015-06-18 16:40 ` [ath9k-devel] " Zefir Kurtisi
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=5582DFB2.7060308@neratec.com \
--to=zefir.kurtisi@neratec.com \
--cc=ath9k-devel@venema.h4ckr.net \
--cc=linux-wireless@vger.kernel.org \
--cc=mickflemm@gmail.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.