Hey there, just to bump the issue again - isn't there anyone here who can answer some of these questions? Adrian gave me some hints, but the FFT format is still completely unclear - I would really like to integrate/fix things before bringing this patch(set) to the next level. I'm begging all the Qualcomm/Atheros-affiliated guys on the list to have a look on the questions below and help me out here. :) Thanks a lot! Simon On Thu, Dec 06, 2012 at 05:36:07PM +0100, Simon Wunderlich wrote: > This patch(set) is the second iteration of the request for comments for > upcoming spectral scan feature. It adds spectral scan control and dump > features to debugfs. When the open questions regarding interpretation > are answered, I would like to build an interface to nl80211/mac80211. > Please see the open questions below, every hint is kindly appreciated. :) > > This feature has been enabled for AR92xx and AR93xx based chipsets. > We've also written a visual evaluation program for these samples (see > screenshot [1] and sourcecode [2]). > > Many details are not known due to the fact that I don't have access to > Atheros specifications and details. Many things are done by guessing > and might be wrong. I'm therefore requesting help from Qualcomm/Atheros > guys to confirm or correct my findings. Apart from that, after > discussion I think we could integrate this patchset to allow other > people to work on this as well, even if it is experimental now. > > Questions from my end: > 1. There are many TODOs/Comments in the patches regarding details, > please answer if you can. :) See code comments, e.g. regarding phy error type which are not defined in the headers, etc. > 2. The output format is very Atheros-dependent. If my finding that > byte n-4 is some kind of offset/exponent, I'd integrate this in > the debugfs output as well still unclear. > 3. The data length varies pretty much, there might be some false > positives/PHY errors which are not FFT data - what should be > the correct length? still unclear. > 4. Is there any special handling for HT40? At least the proprietary > driver symbol names suggest so [3] -> this one is solved: yes, there is. it has more FFT bins. Although I didn't see that yet (I doubt they are the "small" variations I have seen, like up to 4 byte, I'd expect like double frame size). > > (Possible) further work: > 1. Integrate this patchset, confirm/correct findings > 2. If anyone would like: Atheros proprietary driver seems to > support some kind of classification [3] (is this microwave? cordless > phone? whatever?) > 3. If other devices also offer spectral scan support: define a > common interface to use it (not debugfs). > > Changes to RFCv1: > * remove nl80211/mac80211 stuff for now, to build a proper interface > after intepretation/output stabilized > * split spectral scan call into config, trigger and wait call, which can > be called as desired (or depending on the mode) > * use relay(fs) to stream spectral scan results (thanks for the hint Felix), > this seems to be much cleaner - as long as we stay in debugfs > > [1] http://packetmixer.de/sdl_spec_scan2.png > [2] https://github.com/simonwunderlich/FFT_eval > [3] http://www.wehavemorefun.de/fritzbox/Ath_spectral.ko#Symbole > > Simon Wunderlich (1): > ath9k: add spectral scan feature > > drivers/net/wireless/ath/ath9k/ar9002_phy.c | 52 ++++++++++ > drivers/net/wireless/ath/ath9k/ar9003_phy.c | 52 ++++++++++ > drivers/net/wireless/ath/ath9k/ath9k.h | 36 +++++++ > drivers/net/wireless/ath/ath9k/debug.c | 148 +++++++++++++++++++++++++++ > drivers/net/wireless/ath/ath9k/debug.h | 5 + > drivers/net/wireless/ath/ath9k/hw.h | 26 +++++ > drivers/net/wireless/ath/ath9k/init.c | 6 ++ > drivers/net/wireless/ath/ath9k/mac.h | 7 +- > drivers/net/wireless/ath/ath9k/main.c | 97 ++++++++++++++++++ > drivers/net/wireless/ath/ath9k/recv.c | 28 +++++ > 10 files changed, 455 insertions(+), 2 deletions(-) > > -- > 1.7.10.4 > >
Attachment:
signature.asc
Description: Digital signature
