All of lore.kernel.org
 help / color / mirror / Atom feed
* [ath9k] spectral scan update: HT40
@ 2013-02-01 19:02 ` Adrian Chadd
  0 siblings, 0 replies; 6+ messages in thread
From: Adrian Chadd @ 2013-02-01 19:02 UTC (permalink / raw)
  To: linux-wireless, ath9k-devel

Hi all,

I've been tinkering with the HT40 spectral scan data (in FreeBSD,
obviously :-) and I can finally state that I have it working and
working reliably.

The notes:

* The "MAC does silly things to the spectral scan payload" problem
there is in HT40 too, so you need similar correction code for that.
I've not yet committed that to FreeBSD, but I will soon.
* The HT40 lower and upper FFT bins in the radar / spectral scan are
just that - lower and upper halves of a 40MHz wide FFT.
* .. but the RSSI in the RX descriptor is Primary and Extension
channel RSSI, so you need to match them up correctly with what's
"lower" and "upper" - ie, in HT40- mode, the primary RSSI is the
upper, and the extension RSSI is lower.
* .. and yes, this means you calculate the bin power separately for
the lower and upper bins.
* On AR928x chips, the spectral scan FFT is done on chain 0. I don't
think that's changed in AR93xx series chips. So, use RSSI and NF from
chain 0, don't use the combined RSSI figures.
* RSSI can be below 0 dB, so make sure you factor that in.
* IIRC, RSSI from the RX header is in half-dB increments, so make sure
you factor that in.
* Because of the MAC corruption bug, you can't disable "short report"
- otherwise you don't know whether the spectral scan data results are
corrupted or not. So yes, you have to enable short report and thus you
get one result at a time in a PHY error.

I've mostly working code in FreeBSD's subversion tree -
http://svn.freebsd.org/base/user/adrian/ath_radar_stuff/ - look in
lib/libradarpkt and src/fft_eval .

I've begun fleshing out some documentation about spectral scan -
https://wiki.freebsd.org/dev/ath_hal%284%29/SpectralScan

I'm going to work on the invalid packet length detection and
correction, based on what our reference driver does and what Zefir has
done. But once that's done, the basic data parsing and power
calculation bits are done - I'll work on exporting it in a
jquery-compatible fashion over a network socket so people (read: not
me :-) can write some visualisation apps using HTML/javascript. That
way both Linux and FreeBSD (and whoever else!) wifi hackers can
leverage the same visualisation apps when hacking on this stuff.

HTH,



Adrian

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [ath9k-devel] [ath9k] spectral scan update: HT40
@ 2013-02-01 19:02 ` Adrian Chadd
  0 siblings, 0 replies; 6+ messages in thread
From: Adrian Chadd @ 2013-02-01 19:02 UTC (permalink / raw)
  To: ath9k-devel

Hi all,

I've been tinkering with the HT40 spectral scan data (in FreeBSD,
obviously :-) and I can finally state that I have it working and
working reliably.

The notes:

* The "MAC does silly things to the spectral scan payload" problem
there is in HT40 too, so you need similar correction code for that.
I've not yet committed that to FreeBSD, but I will soon.
* The HT40 lower and upper FFT bins in the radar / spectral scan are
just that - lower and upper halves of a 40MHz wide FFT.
* .. but the RSSI in the RX descriptor is Primary and Extension
channel RSSI, so you need to match them up correctly with what's
"lower" and "upper" - ie, in HT40- mode, the primary RSSI is the
upper, and the extension RSSI is lower.
* .. and yes, this means you calculate the bin power separately for
the lower and upper bins.
* On AR928x chips, the spectral scan FFT is done on chain 0. I don't
think that's changed in AR93xx series chips. So, use RSSI and NF from
chain 0, don't use the combined RSSI figures.
* RSSI can be below 0 dB, so make sure you factor that in.
* IIRC, RSSI from the RX header is in half-dB increments, so make sure
you factor that in.
* Because of the MAC corruption bug, you can't disable "short report"
- otherwise you don't know whether the spectral scan data results are
corrupted or not. So yes, you have to enable short report and thus you
get one result at a time in a PHY error.

I've mostly working code in FreeBSD's subversion tree -
http://svn.freebsd.org/base/user/adrian/ath_radar_stuff/ - look in
lib/libradarpkt and src/fft_eval .

I've begun fleshing out some documentation about spectral scan -
https://wiki.freebsd.org/dev/ath_hal%284%29/SpectralScan

I'm going to work on the invalid packet length detection and
correction, based on what our reference driver does and what Zefir has
done. But once that's done, the basic data parsing and power
calculation bits are done - I'll work on exporting it in a
jquery-compatible fashion over a network socket so people (read: not
me :-) can write some visualisation apps using HTML/javascript. That
way both Linux and FreeBSD (and whoever else!) wifi hackers can
leverage the same visualisation apps when hacking on this stuff.

HTH,



Adrian

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [ath9k] spectral scan update: HT40
  2013-02-01 19:02 ` [ath9k-devel] " Adrian Chadd
@ 2013-02-05  9:59   ` Simon Wunderlich
  -1 siblings, 0 replies; 6+ messages in thread
From: Simon Wunderlich @ 2013-02-05  9:59 UTC (permalink / raw)
  To: Adrian Chadd; +Cc: linux-wireless, ath9k-devel

[-- Attachment #1: Type: text/plain, Size: 3079 bytes --]

Hey Adrian,

thanks a lot for your update!

On Fri, Feb 01, 2013 at 11:02:00AM -0800, Adrian Chadd wrote:
> Hi all,
> 
> I've been tinkering with the HT40 spectral scan data (in FreeBSD,
> obviously :-) and I can finally state that I have it working and
> working reliably.
> 
> The notes:
> 
> * The "MAC does silly things to the spectral scan payload" problem
> there is in HT40 too, so you need similar correction code for that.
> I've not yet committed that to FreeBSD, but I will soon.
> * The HT40 lower and upper FFT bins in the radar / spectral scan are
> just that - lower and upper halves of a 40MHz wide FFT.
> * .. but the RSSI in the RX descriptor is Primary and Extension
> channel RSSI, so you need to match them up correctly with what's
> "lower" and "upper" - ie, in HT40- mode, the primary RSSI is the
> upper, and the extension RSSI is lower.
> * .. and yes, this means you calculate the bin power separately for
> the lower and upper bins.
> * On AR928x chips, the spectral scan FFT is done on chain 0. I don't
> think that's changed in AR93xx series chips. So, use RSSI and NF from
> chain 0, don't use the combined RSSI figures.

Ah, OK, that's probably relevant for the ath9k part as well.

> * RSSI can be below 0 dB, so make sure you factor that in.
> * IIRC, RSSI from the RX header is in half-dB increments, so make sure
> you factor that in.
> * Because of the MAC corruption bug, you can't disable "short report"
> - otherwise you don't know whether the spectral scan data results are
> corrupted or not. So yes, you have to enable short report and thus you
> get one result at a time in a PHY error.

Could we (in theory) enable short report stuff for newer chipsets, e.g.
93xx and newer? I thought there was a fix for that in "latest silicon",
although I don't know specifics

> 
> I've mostly working code in FreeBSD's subversion tree -
> http://svn.freebsd.org/base/user/adrian/ath_radar_stuff/ - look in
> lib/libradarpkt and src/fft_eval .
> 
> I've begun fleshing out some documentation about spectral scan -
> https://wiki.freebsd.org/dev/ath_hal%284%29/SpectralScan

Excellent! That's provides a good resource. :)
> 
> I'm going to work on the invalid packet length detection and
> correction, based on what our reference driver does and what Zefir has
> done. But once that's done, the basic data parsing and power
> calculation bits are done - I'll work on exporting it in a
> jquery-compatible fashion over a network socket so people (read: not
> me :-) can write some visualisation apps using HTML/javascript. That
> way both Linux and FreeBSD (and whoever else!) wifi hackers can
> leverage the same visualisation apps when hacking on this stuff.

Again, thanks a lot for your work! I'm currently busy with a few other
things and probably won't find time to work on the 40 MHz spectral in the
next weeks, so if anyone else wants to pick up here - the code has been
prepared for that. :)

In any case, please keep us posted, and keep up your good work!
Thanks,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [ath9k-devel] [ath9k] spectral scan update: HT40
@ 2013-02-05  9:59   ` Simon Wunderlich
  0 siblings, 0 replies; 6+ messages in thread
From: Simon Wunderlich @ 2013-02-05  9:59 UTC (permalink / raw)
  To: ath9k-devel

Hey Adrian,

thanks a lot for your update!

On Fri, Feb 01, 2013 at 11:02:00AM -0800, Adrian Chadd wrote:
> Hi all,
> 
> I've been tinkering with the HT40 spectral scan data (in FreeBSD,
> obviously :-) and I can finally state that I have it working and
> working reliably.
> 
> The notes:
> 
> * The "MAC does silly things to the spectral scan payload" problem
> there is in HT40 too, so you need similar correction code for that.
> I've not yet committed that to FreeBSD, but I will soon.
> * The HT40 lower and upper FFT bins in the radar / spectral scan are
> just that - lower and upper halves of a 40MHz wide FFT.
> * .. but the RSSI in the RX descriptor is Primary and Extension
> channel RSSI, so you need to match them up correctly with what's
> "lower" and "upper" - ie, in HT40- mode, the primary RSSI is the
> upper, and the extension RSSI is lower.
> * .. and yes, this means you calculate the bin power separately for
> the lower and upper bins.
> * On AR928x chips, the spectral scan FFT is done on chain 0. I don't
> think that's changed in AR93xx series chips. So, use RSSI and NF from
> chain 0, don't use the combined RSSI figures.

Ah, OK, that's probably relevant for the ath9k part as well.

> * RSSI can be below 0 dB, so make sure you factor that in.
> * IIRC, RSSI from the RX header is in half-dB increments, so make sure
> you factor that in.
> * Because of the MAC corruption bug, you can't disable "short report"
> - otherwise you don't know whether the spectral scan data results are
> corrupted or not. So yes, you have to enable short report and thus you
> get one result at a time in a PHY error.

Could we (in theory) enable short report stuff for newer chipsets, e.g.
93xx and newer? I thought there was a fix for that in "latest silicon",
although I don't know specifics

> 
> I've mostly working code in FreeBSD's subversion tree -
> http://svn.freebsd.org/base/user/adrian/ath_radar_stuff/ - look in
> lib/libradarpkt and src/fft_eval .
> 
> I've begun fleshing out some documentation about spectral scan -
> https://wiki.freebsd.org/dev/ath_hal%284%29/SpectralScan

Excellent! That's provides a good resource. :)
> 
> I'm going to work on the invalid packet length detection and
> correction, based on what our reference driver does and what Zefir has
> done. But once that's done, the basic data parsing and power
> calculation bits are done - I'll work on exporting it in a
> jquery-compatible fashion over a network socket so people (read: not
> me :-) can write some visualisation apps using HTML/javascript. That
> way both Linux and FreeBSD (and whoever else!) wifi hackers can
> leverage the same visualisation apps when hacking on this stuff.

Again, thanks a lot for your work! I'm currently busy with a few other
things and probably won't find time to work on the 40 MHz spectral in the
next weeks, so if anyone else wants to pick up here - the code has been
prepared for that. :)

In any case, please keep us posted, and keep up your good work!
Thanks,
	Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130205/8fd84684/attachment.pgp 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [ath9k-devel] [ath9k] spectral scan update: HT40
  2013-02-05  9:59   ` [ath9k-devel] " Simon Wunderlich
  (?)
@ 2013-02-09 19:27   ` Oleksij Rempel
  2013-02-10 17:14     ` Adrian Chadd
  -1 siblings, 1 reply; 6+ messages in thread
From: Oleksij Rempel @ 2013-02-09 19:27 UTC (permalink / raw)
  To: ath9k-devel

Am 05.02.2013 10:59, schrieb Simon Wunderlich:
> Hey Adrian,
>
> thanks a lot for your update!
>
> On Fri, Feb 01, 2013 at 11:02:00AM -0800, Adrian Chadd wrote:
>> Hi all,
>>
>> I've been tinkering with the HT40 spectral scan data (in FreeBSD,
>> obviously :-) and I can finally state that I have it working and
>> working reliably.
>>
>> The notes:
>>
>> * The "MAC does silly things to the spectral scan payload" problem
>> there is in HT40 too, so you need similar correction code for that.
>> I've not yet committed that to FreeBSD, but I will soon.
>> * The HT40 lower and upper FFT bins in the radar / spectral scan are
>> just that - lower and upper halves of a 40MHz wide FFT.
>> * .. but the RSSI in the RX descriptor is Primary and Extension
>> channel RSSI, so you need to match them up correctly with what's
>> "lower" and "upper" - ie, in HT40- mode, the primary RSSI is the
>> upper, and the extension RSSI is lower.
>> * .. and yes, this means you calculate the bin power separately for
>> the lower and upper bins.
>> * On AR928x chips, the spectral scan FFT is done on chain 0. I don't
>> think that's changed in AR93xx series chips. So, use RSSI and NF from
>> chain 0, don't use the combined RSSI figures.
>
> Ah, OK, that's probably relevant for the ath9k part as well.
>
>> * RSSI can be below 0 dB, so make sure you factor that in.
>> * IIRC, RSSI from the RX header is in half-dB increments, so make sure
>> you factor that in.
>> * Because of the MAC corruption bug, you can't disable "short report"
>> - otherwise you don't know whether the spectral scan data results are
>> corrupted or not. So yes, you have to enable short report and thus you
>> get one result at a time in a PHY error.
>
> Could we (in theory) enable short report stuff for newer chipsets, e.g.
> 93xx and newer? I thought there was a fix for that in "latest silicon",
> although I don't know specifics
>
>>
>> I've mostly working code in FreeBSD's subversion tree -
>> http://svn.freebsd.org/base/user/adrian/ath_radar_stuff/ - look in
>> lib/libradarpkt and src/fft_eval .
>>
>> I've begun fleshing out some documentation about spectral scan -
>> https://wiki.freebsd.org/dev/ath_hal%284%29/SpectralScan
>
> Excellent! That's provides a good resource. :)
>>
>> I'm going to work on the invalid packet length detection and
>> correction, based on what our reference driver does and what Zefir has
>> done. But once that's done, the basic data parsing and power
>> calculation bits are done - I'll work on exporting it in a
>> jquery-compatible fashion over a network socket so people (read: not
>> me :-) can write some visualisation apps using HTML/javascript. That
>> way both Linux and FreeBSD (and whoever else!) wifi hackers can
>> leverage the same visualisation apps when hacking on this stuff.
>
> Again, thanks a lot for your work! I'm currently busy with a few other
> things and probably won't find time to work on the 40 MHz spectral in the
> next weeks, so if anyone else wants to pick up here - the code has been
> prepared for that. :)
>
> In any case, please keep us posted, and keep up your good work!
> Thanks,
> 	Simon


Lots of thanks to all for this work!
It works on my AR9285.
I have one question. Some chips (for example ar9462) have "8-bit 
resolution for Spectral Analysis" in product overview. What dos it mean? 
Is it about Spectral Scan? What kind of bit resolution is on on ar9285?

-- 
Regards,
Oleksij

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [ath9k-devel] [ath9k] spectral scan update: HT40
  2013-02-09 19:27   ` Oleksij Rempel
@ 2013-02-10 17:14     ` Adrian Chadd
  0 siblings, 0 replies; 6+ messages in thread
From: Adrian Chadd @ 2013-02-10 17:14 UTC (permalink / raw)
  To: ath9k-devel

Hi,

There's 8 bit resolution on the AR9280, AR9285 and AR9287.

Starting with the AR9380 and later chips, only the enterprise versions
of the chips have 8 bit spectral analysis resolution.



Adrian

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-02-10 17:14 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-01 19:02 [ath9k] spectral scan update: HT40 Adrian Chadd
2013-02-01 19:02 ` [ath9k-devel] " Adrian Chadd
2013-02-05  9:59 ` Simon Wunderlich
2013-02-05  9:59   ` [ath9k-devel] " Simon Wunderlich
2013-02-09 19:27   ` Oleksij Rempel
2013-02-10 17:14     ` Adrian Chadd

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.