Re: [ath9k-devel] [RFC 3/3] ath9k: add spectral scan feature
Not that I'm specifically getting into this in any deep way right now, but..
On 27 November 2012 11:01, Simon Wunderlich
wrote:
[snip] - this should apply to AR9380 and later I think.
> +void ar9002_hw_spectral_scan(struct ath_hw *ah)
> +{
> + struct ath_common *common = ath9k_hw_common(ah);
> +
> + REG_SET_BIT(ah, AR_PHY_RADAR_0, AR_PHY_RADAR_0_FFT_ENA);
> +
> + /* NOTE: this will generate a few samples ... lacking documentation,
> +* I'm not really sure what these parameters mean.
> +*/
> + REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN, AR_PHY_SPECTRAL_SCAN_ENABLE);
> + REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
> + AR_PHY_SPECTRAL_SCAN_SHORT_REPEAT);
> + REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
> + AR_PHY_SPECTRAL_SCAN_COUNT, 8);
> + REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
> + AR_PHY_SPECTRAL_SCAN_PERIOD, 0xF);
> + REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
> + AR_PHY_SPECTRAL_SCAN_FFT_PERIOD, 0xFF);
> +
> + /* Activate spectral scan */
> + REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
> + AR_PHY_SPECTRAL_SCAN_ACTIVE);
> +
> + /* Poll for spectral scan complete */
> + if (!ath9k_hw_wait(ah, AR_PHY_SPECTRAL_SCAN,
> + AR_PHY_SPECTRAL_SCAN_ACTIVE,
> + 0, AH_WAIT_TIMEOUT)) {
> + ath_err(common, "spectral scan wait failed\n");
> + return;
> + }
> +
> + /* Disable spectral scan */
> + REG_CLR_BIT(ah, AR_PHY_SPECTRAL_SCAN,
> + AR_PHY_SPECTRAL_SCAN_ENABLE);
> +}
> +
You shouldn't have to do this. There's two spectral scan modes (well, three) -
* when you're not decoding things, and you meet these parameters,
please send me some events (I think the patent mentions this);
* trigger _now_ and send me "X" events; then clear the spectral scan bit;
* trigger _now_ and just send me infinite events - on earlier chips
(AR9280 I think) the magic value may be 0; on the later values it may
be 255. Someone should experiment.
I suggest you separate out "configure/enable/disable" and "trigger" as options.
Grr, mumble mumble open source developers mumble mumble.. :-)
I suggest experimenting around with those particular parameters. You
should be able to coax out specific numbers of spectral scan events
when you set the COUNT parameter to something other than 8. But
polling that bit isn't needed. It should be asynchronous.
Good luck,
Adrian
Adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC 3/3] ath9k: add spectral scan feature
Adrian,
thanks a lot for your feedback!
On Fri, Nov 30, 2012 at 08:00:51PM -0800, Adrian Chadd wrote:
> Not that I'm specifically getting into this in any deep way right now, but..
>
> On 27 November 2012 11:01, Simon Wunderlich
> wrote:
>
> [snip] - this should apply to AR9380 and later I think.
>
Actually I have pretty much the same code in both ar9002_phy.c and ar9003_phy.c,
because they get different register definitions (addresses etc) from their
respective
header files.
You think that this wouldn't apply for AR9280? Is there something wrong or
different
with the register access?
I have put scan count of 8 in here, but on AR9380 I get much more samples (more
like
256). I haven't played with this very much, because "a couple" of samples was
all I
needed for my graphical analyzer.
> > +void ar9002_hw_spectral_scan(struct ath_hw *ah)
> > +{
> > + struct ath_common *common = ath9k_hw_common(ah);
> > +
> > + REG_SET_BIT(ah, AR_PHY_RADAR_0, AR_PHY_RADAR_0_FFT_ENA);
> > +
> > + /* NOTE: this will generate a few samples ... lacking documentation,
> > +* I'm not really sure what these parameters mean.
> > +*/
> > + REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN, AR_PHY_SPECTRAL_SCAN_ENABLE);
> > + REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
> > + AR_PHY_SPECTRAL_SCAN_SHORT_REPEAT);
> > + REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
> > + AR_PHY_SPECTRAL_SCAN_COUNT, 8);
> > + REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
> > + AR_PHY_SPECTRAL_SCAN_PERIOD, 0xF);
> > + REG_RMW_FIELD(ah, AR_PHY_SPECTRAL_SCAN,
> > + AR_PHY_SPECTRAL_SCAN_FFT_PERIOD, 0xFF);
> > +
> > + /* Activate spectral scan */
> > + REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
> > + AR_PHY_SPECTRAL_SCAN_ACTIVE);
> > +
> > + /* Poll for spectral scan complete */
> > + if (!ath9k_hw_wait(ah, AR_PHY_SPECTRAL_SCAN,
> > + AR_PHY_SPECTRAL_SCAN_ACTIVE,
> > + 0, AH_WAIT_TIMEOUT)) {
> > + ath_err(common, "spectral scan wait failed\n");
> > + return;
> > + }
> > +
> > + /* Disable spectral scan */
> > + REG_CLR_BIT(ah, AR_PHY_SPECTRAL_SCAN,
> > + AR_PHY_SPECTRAL_SCAN_ENABLE);
> > +}
> > +
>
> You shouldn't have to do this. There's two spectral scan modes (well, three) -
>
> * when you're not decoding things, and you meet these parameters,
> please send me some events (I think the patent mentions this);
> * trigger _now_ and send me "X" events; then clear the spectral scan bit;
> * trigger _now_ and just send me infinite events - on earlier chips
> (AR9280 I think) the magic value may be 0; on the later values it may
> be 255. Someone should experiment.
>
> I suggest you separate out "configure/enable/disable" and "trigger" as
> options.
OK, yeah I can do that - guess we should have different function calls for this
then, too. Don't know if all of this should be callable from mac80211 as well.
>
> Grr, mumble mumble open source developers mumble mumble.. :-)
What are you muttering about? :D
Should we rather keep this wonderful feature to the closed source world?
I don't think so :)
>
> I suggest experimenting around with those particular parameters. You
> should be able to coax out specific numbers of spectral scan events
> when you set the COUNT parameter to something other than 8. But
> polling that bit isn't needed. It should be asynchronous.
As I said, on AR9220 it appears I get 8 samples when doing setting
AR_PHY_SPECTRAL_SCAN_COUNT to 8 (plus maybe some other "stuff"/non-samples).
On AR9380 I'm not so sure. Probably need to play with it a little
more. Also, I don't know what "SHORT REPEAT" is supposed to mean, etc.
About polling, you mean the SCAN_ACTIVE bit? It is probably only
needed when I want to trigger for few samples and want to be informed when
it's finished - which is a good thing when doing spectral scan (change channel,
start and wait for samples, change again). But we probably don't need to wait
for the "background spectral scanning" mode, that's right. If someone wants
to implement detection for interfering radio users, that mode would be useful.
I don't need it, but can prepare the neccesary functions.
So I'd repost then:
* ath9k/debugfs only patch for now, as Johannes suggested - I think we
should concentrate on this for now (their are still a lot of open
questions in my initial mail regarding sample interpretation etc)
* split commands into enable/disable/configure/trigger
* maybe add some defines for magic values (if I find any)
I'd like this patchset to make the graphical spectral scan possible (as
a Ubiquiti Airview), and give others the opportunity to add own features
(pattern matching etc) on top of it. However I (currently) don't plan to
do the latter myself.
>
> Good luck,
>
>
>
> Adrian
Thanks!
Simon
signature.as
Re: [ath9k-devel] [RFC 3/3] ath9k: add spectral scan feature
On 2012-12-05 11:40 AM, Simon Wunderlich wrote: >> I suggest experimenting around with those particular parameters. You >> should be able to coax out specific numbers of spectral scan events >> when you set the COUNT parameter to something other than 8. But >> polling that bit isn't needed. It should be asynchronous. > > As I said, on AR9220 it appears I get 8 samples when doing setting > AR_PHY_SPECTRAL_SCAN_COUNT to 8 (plus maybe some other "stuff"/non-samples). > On AR9380 I'm not so sure. Probably need to play with it a little > more. Also, I don't know what "SHORT REPEAT" is supposed to mean, etc. > > About polling, you mean the SCAN_ACTIVE bit? It is probably only > needed when I want to trigger for few samples and want to be informed when > it's finished - which is a good thing when doing spectral scan (change > channel, > start and wait for samples, change again). But we probably don't need to wait > for the "background spectral scanning" mode, that's right. If someone wants > to implement detection for interfering radio users, that mode would be useful. > I don't need it, but can prepare the neccesary functions. > > So I'd repost then: > * ath9k/debugfs only patch for now, as Johannes suggested - I think we >should concentrate on this for now (their are still a lot of open >questions in my initial mail regarding sample interpretation etc) > * split commands into enable/disable/configure/trigger > * maybe add some defines for magic values (if I find any) > > I'd like this patchset to make the graphical spectral scan possible (as > a Ubiquiti Airview), and give others the opportunity to add own features > (pattern matching etc) on top of it. However I (currently) don't plan to > do the latter myself. How about using relay (Documentation/filesystems/relay.txt) to stream sample data to user space via the debugfs file? That way you don't have to keep a linked list of small struct fft_sample buffers in the kernel and you can stream much more data efficiently with little kernel side overhead. It also makes pushing the streaming data to a network socket via sendfile much more efficient. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC 3/3] ath9k: add spectral scan feature
On 5 December 2012 03:38, Felix Fietkau wrote: > How about using relay (Documentation/filesystems/relay.txt) to stream > sample data to user space via the debugfs file? > That way you don't have to keep a linked list of small struct fft_sample > buffers in the kernel and you can stream much more data efficiently with > little kernel side overhead. > It also makes pushing the streaming data to a network socket via > sendfile much more efficient. Yes, please do this. When *cough* I do this for FreeBSD, I'll just have people expose this via BPF. I already have code to pull radar PHY errors out via BPF, so this becomes just as trivial to do. Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [RFC 3/3] ath9k: add spectral scan feature
Hi,
I'll repost this, as it seems emailing lists.ath9k.org doesn't seem to work out.
The formats are as follows. Please note that if a pulse terminates
during an FFT, the final entry may be truncated. So yes, you may not
always get an integer multiple of the relevant frame length.
Note that you shift each of the readings by max_exp to get a total
reading. max_index and max_magnitude I think are just derived from the
existing dataset; they're just a shortcut for software so it doesn't
have to parse the whole frame looking for the peak.
Static 20 mode:
0 bin -28 magnitude[7:0] = (|i| + |q|) >> max_exp
1 bin -27 magnitude[7:0] = (|i| + |q|) >> max_exp
2 - 53 …
54 bin 26 magnitude[7:0] = (|i| + |q|) >> max_exp
55 bin 27 magnitude[7:0] = (|i| + |q|) >> max_exp
56 [7:0]: all bins {max_magnitude[1:0], bitmap_weight[5:0]}
57 [7:0]: all bins max_magnitude[9:2]
58 [7:0]: all bins {max_index[5:0], max_magnitude[11:10]}
59 [3:0]: max_exp (shift amount to size max bin to 8-bit unsigned)
Dynamic 20/40 mode:
0 bin -64 magnitude[7:0] = (|i| + |q|) >> max_exp or power (in dBm)
1 bin -63 magnitude[7:0] = (|i| + |q|) >> max_exp or power (in dBm)
2 - 125 …
126 bin 62 magnitude[7:0] = (|i| + |q|) >> max_exp or power (in dBm)
127 bin 63 magnitude[7:0] = (|i| + |q|) >> max_exp or power (in dBm)
128 [7:0]: lower bins {max_magnitude[1:0], bitmap_weight[5:0]}
Baseband DFS 2 (Radar) Micro-Architecture
129 [7:0]: lower bins max_magnitude[9:2]
130 [7:0]: lower bins {max_index[5:0], max_magnitude[11:10]}
131 [7:0]: upper bins {max_magnitude[1:0], bitmap_weight[5:0]}
132 [7:0]: upper bins max_magnitude[9:2]
133 [7:0]: upper bins {max_index[5:0], max_magnitude[11:10]}
134 [3:0]: max_exp (shift amount to size max bin to 8-bit unsigned)
Ok, now for radar it's a tad different. There's a bit that is set if
the signal is above a certain threshold. If so, the bit is set to 1.
There's also a 3 bit magnitude value which is calculated against the
maximum magnitude value (floor(m(i) * 8 / max magnitude.)
Adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
