Atheros HAL: Ambient Noise Immunity (ANI)
| Driver | HAL | Supported Hardware |
Overview
Ambient Noise Immunity (ANI) is a software driven method for controlling radio sensitivity in the face of noise sources. It tunes various parameters based on OFDM/CCK errors and beacon RSSI levels.
Details
The patent document provides a good overview to the operation of the ANI code in FreeBSD. The AR5212 implementation is almost verbatim from the ANI patent.
ANI attempts to work around a noisy, unpredictable environment. Given that there are a variety of noise sources - other stations, spread spectrum sources, non-802.11 devices (eg video bridges) and 2.4ghz devices (eg microwaves), ANI attempts to set various packet and signal detection thresholds to minimise errors.
The inputs to ANI are:
- OFDM error rate;
- CCK error rate;
- The time spent "busy" but not necessarily transmitting or receiving anything (ie, the total portion of air time that the CCK/OFDM PHY errors will have occured in.)
The variables being modified by ANI are:
- OFDM weak signal detection enable/disable;
- CCK weak signal detection threshold;
- Coarse signal high/low - which provide the signal level low/high size to control the AGC gain choice made;
- Total signal size desired - which determines the total signal size desired after the AGC gain has been modified;
- FIRPWR;
- FIRSTEP_LEVEL;
- CYCPWR_THR1.
ANI debugging
The athstats tool in src/tools/tools/ath/athstats provides live ANI statistics. Try 'anistats -o ani 1'.
Known issues
[http://www.freebsd.org/cgi/query-pr.cgi?pr=169336]: On at least the 802.11n chips (and maybe legacy), a very busy environment with lots of CCK or OFDM errors seems to somehow not trigger ANI.
- Recovery under high traffic load doesn't happen - partly because listenTime doesn't quickly make it to the lower threshold value; partially because it's reset whenever a CCK/OFDM counter overflow interrupt occurs.
What could be done in the future
Currently these parameters are programmed into ANI and raised/lowered to a very strict set of values in a strict order. It may be a good project to instead modify these values along a continuum, track what affect they have on error rates, signal TX/RX error rates, channel busy conditions, etc, and then choose optimal values based on that.
There's currently very limited debugging and inspection tools for ANI. It would be nice to have some more tools.
The ANI API supports the concept of manually controlled ANI - ie, instead of the parameters being dynamically changed over time, they are changed via an ioctl() API. It would be a good mini-project to implement this in the ath(4) driver and ath_hal(4) layer.