[ath9k-devel] [RFC] ath9k: add EVM reporting

[Felix Fietkau <nbd@openwrt.org>]

On 2011-01-09 1:07 AM, Brian Prodoehl wrote:
> This patch adds error vector magnitude collection to AR9001 and
> AR9002, as well as my best attempt at making sense of what the EVM
> numbers actually mean.  There was an obvious problem with the
> AR_RxEVMn macros (parts of status4 were being used for rssi, and all
> of status4 was also being used for EVM0, so the EVM block probably
> actually starts at 5, since 5, 6 and 7 aren't used in the code for any
> other purpose).  The AR6002 driver has a bit for the PCU MISC register
> related to EVM.  A lot of the other bits line up in that register
> between AR9002 and AR6002, so this patch also sets that bit.  I'm
> assuming that enables something related to EVM, but so far it seems
> like the default behavior for the AR9220 reports EVM just fine (so
> this change doesn't appear to be necessary).
>
> The EVM readings themselves are a bit peculiar.  They seem broken up
> by octet.  Legacy rates yield 0x80808080, and HT rates yield numbers
> like 0x1a1e1f21.  MCS0-7 produce non-zero results in EVM0, and MCS8-15
> produce non-zero results in EVM0 and EVM1.  At close range, the octets
> are typically between 0x1a and 0x24.  At greater range, the octets go
> down to between 0x04 and 0x13.  My best guess so far is that all
> 32-bits of each EVM reading is significant, and each octet of that is
> the EVM of a pilot carrier in negative dB.  EVM0, then, is probably
> the EVM for spatial stream 0, and so on.  Does that make sense to
> anybody?
>
> To aid in figuring this out, I track the last valid EVM reading for
> each bitrate in the debug rx_stats struct, and these EVM stats can be
> dumped by reading the recv file in debugfs.  There's also a lookup
> table to handle conversion between EVM(dB) and EVM(%), since
> percentage makes more sense to me in this context.
>
> I'm just guessing on this stuff, based on experimentation.  Opinions
> and insight are very welcome.  This is an RFC, and I haven't put much
> thought into how this might actually be tracked and presented.  In the
> short-term, I just want it for a better quality control metric.  It
> does seem to shed some light on situations where RSSI is high, but
> minstrel_ht settles on a mid-level bitrate.  In a few cases where I've
> seen that now with EVM reporting, often I see what I assume is a pilot
> carrier having an EVM 5 or 7 dB worse than the rest (perhaps due to
> frequency-dependent multipath interference knocking down one block of
> carriers).
I haven't fully reviewed the patch yet, but I figured I'd give you a few 
bits of information about the EVM data:

The unit of the EVM data is a signed number of dB above noise floor.
The order in which the EVM fields are populated apparently not only 
depends on the number of streams, but also on whether HT40 was used for 
the packet or not.

Here's a list of the EVM word to pilot mapping (LSB to MSB, 
stream:pilot), HT40 adds pilots 4, 5

For single stream rates:
EVM0 = 0:0, 0:1, 0:2, 0:3
EVM1 = 0:4, 0:5

For dual stream rates:
EVM0 = 0:0, 1:0, 0:1, 1:1
EVM1 = 0:2, 1:2, 0:3, 1:3
EVM2 = 0:4, 1:4, 0:5, 1:5

For triple stream rates (AR9003 only):
EVM0 = 0:0, 1:0, 2:0, 0:1
EVM1 = 1:1, 2:1, 0:2, 1:2
EVM2 = 2:2, 0:3, 1:3, 2:3
EVM3 = 0:4, 1:4, 2:4, 0:5
EVM4 = 1:5, 2:5

To handle this with little coding effort, it would probably make sense 
to convert the EVM data to little endian, storing all of it in a single 
buffer and then using something like this to access the data:
evm = buf[pilot_idx * n_streams + stream_idx]

I hope this helps,

- Felix