Re: [ath9k-devel] ath9k-devel Digest, Vol 56, Issue 19

2013-02-09 Thread remy_liaw
Dear Compex ‘s  Partner and Friends 
 
We are having Chinese New Year holiday till 18th Feb 2013 . 
We will reply your email as soon as we back from holiday 
 
Remy Liaw
Sales Account Manager
www.compex.com.sg
T +65 62862086 | F +65 62809947
Let's Connect! 
Facebook Twitter Blog Youtube
Compex Systems – Your Trusted Partner in Wireless Co



___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


Re: [ath9k-devel] [ath9k] spectral scan update: HT40

2013-02-09 Thread Oleksij Rempel
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
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel