Hello Felix and Simon,
I play with it since a while, but without proper results. Your patch
set, Simon helps a lot.
Thanks.
Am 14.12.2012 00:04, schrieb Felix Fietkau:
On 2012-12-13 11:06 PM, Simon Wunderlich wrote:
Hey Felix,
thanks, this looks like exactly what I was hoping for!
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
Here's my understanding of the data format:
HT20:
56 bytes bin magnitude data (8 bits per bin)
3 bytes bin maximum values (see below)
1 byte exponent:
[3:0] - number of bits to shift the magnitude data
Now that is exactly what I was looking for! So shifting the data makes it some
kind of exponent, so I wasn't so wrong. :D
BTW, does the 56 byte ever change, or may it happen that there is something in front
of the FFT bins? or in the middle? I still see different data lengths, and the
format looks pretty fixed to me. In theory:
* 56 bytes FFT bins
* 3 bytes maximum values
* 1 byte exponent
* 3 byte radar trailer (with bwinfo etc)
Thoughts? I'll check my data again, too.
I don't know about the data length, I haven't run any tests myself.
The data length should be between 62 and 65 bytes for HT20 and between
137 and 140 bytes for HT40. But most of the time I see only 62 for HT20.
HT40:
128 bytes bin magnitude data (64 lower bins, 64 upper bins)
3 bytes lower bin maximum values (see below)
3 bytes upper bin maximum values (see below)
1 byte exponent (like HT20)
I have not experimented in HT40 mode yet, but we should add that too. :)
Bin maximum values:
Byte 1: [1:0] - max_magnitude[1:0]
[7:2] - bitmap_weight[5:0]
Byte 2: [7:0] - max_magnitude[9:2]
Byte 3: [5:0] - max_index[5:0]
[7:6] - max_magnitude[11:10]
OK - not sure what "weight" means, max_magnitude might be the highest of the
FFT bins? What "index" is max_index?
No idea.
BTW, the FFT bins/magnitude values, are these absolute values or logarithmic
values? I'd guess it's absolute from the look of it (applying log() makes it
"look better" in the visualization), but not sure.
I also think it's probably absolute.
3. If other devices also offer spectral scan support: define a
common interface to use it (not debugfs).
Makes sense. The data should be in an extensible binary format that can
also cover vendor specific extra information. One suggestion would be to
prefix the FFT message data with a netlink-style TLV header describing
the message format (using an enum for data types and an enum for fields,
both of which we can extend if we need to add more data).
That way userspace can use the header to figure out the message size and
can ignore any fields that it does not support.
Yeah, sounds good. Although I'm still not sure how we could compose the
userspace interface. We might want to configure things like:
* count, interval, endless mode?
* trigger for a scan
* listen for samples (endlessly?) ...
The recent patch contains a control file and a listen file - maybe we could
have similar commands for iw?
Let's come up with a proper prototype using the intended data format via
debugfs in the driver before we add support to nl80211 and iw.
Also I'm not sure if the performance is very good for the case that we want
to stream a lot of samples. About the data format, keeping it somewhat flexible
for adding fields in the future is a good idea IMHO.
I think the TLV header struct description + fixed length messages is
good for performance. The header only has to be sent once at the
beginning of the stream, and the conversion to the struct format + the
relay can be quite fast.
Also as the exponent seems to be confirmed now, I'd directly apply it to the FFT
values when giving it to userspace, like FFT_bin[i] << exponent (if this is the
correct form)
Yes, userspace shouldn't have to deal with that.
- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
