Spectral Scan Support

| Driver | HAL | Supported Hardware | 802.11n support | Debugging |

The AR9280 and later NICs have the ability to report FFT data from the baseband under user-controlled conditions.

The PHY has the ability to report FFT summary information about the received wireless signal. This is useful for a variety of reasons - visualising the radio spectrum is one obvious benefit; others have used it to build interference classifiers.

The FFT summary includes:

• Absolute magnitude (|i| + |q| - ie, the ABS() of both I and Q phases of a signal) for each FFT bin - 56 carriers in 20MHz mode, 114 in 40MHz mode
• An index indicating which FFT bin had the highest signal;
• The maximum signal magnitude.

It does not run in parallel with wireless transmission or reception - so either spectral scan FFT reporting can run, OR packet transmission/reception.

The spectral scan HAL API allows for a few tweaks:

• ss_count - how many samples to return each time an FFT sample is made.
• ss_short_rpt - whether to only run one FFT sample ('short repeat') or whether to run many FFT samples for each FFT sample period.
• ss_fft_period - when active and triggered, how often to sample FFT results. This is implemented as (fft_period+1)*4uS.
• ss_period - when active, how often to trigger the FFT sample. This is implemented as (period*256*Tclk). Where Tclk is the configured clock rate (eg 44MHz for HT20 operation, 88MHz for HT40 operation; 40/80MHz for 5GHz non-fast-clock operation.)

On the AR9280, an ss_count of 128 is interpreted as “never disable” returning samples. Otherwise, “ss_count” samples are returned, then the spectral scan mode is moved from active to stopped.

The athspectral tool in src/tools/tools/ath/ allows for command line control of the spectral scan code.

• athspectral set and get allows for parameters to be tweaked
• athspectral start and athspectral stop will start and stop a spectral scan, respectively
• athspectral enable_at_reset (1|0) will enable/disable spectral scan during channel change and reset.

The latter (enable_at_reset) is useful for sampling during channel scanning.

Spectral scan data is reported as a PHY error.

• 0x5 - RADAR
• 0x24 - RADAR, possible false, out of band or wideband signal
• 0x26 - SPECTRAL payload

HT20:

HT40:

The sum of all of the magnitudes in the sample should equal the reported RSSI. So to calculate a dBm value, the rough method is:

• Convert RSSI → dBm by assuming the noise floor is -96dBm (in 20 or 20/40 mode, as RSSI is reported separately for both 20MHz halves) and assume the dBm value is simply “RSSI” above the noise floor;
• .. this isn't as easy as it sounds, mainly because noise and spurs can cause the noise floor samples to rise, which reduces the “RSSI” value;
• .. and there's no easy way to figure out how far above -96dBm the calibrated NF really is;
• Then assume that the magnitude of each sample in a 20MHz bin equals the RSSI
• .. for 40MHz, you'd do this once for PRI with the PRI RSSI, and once in the SEC channel with the secondary channel RSSI;
• And then decompose each magnitude into a dBm value.

So do this programatically for a HT20 channel:

bin_sum = 10*log(sum[i=1..56](b(i)^2)

Where b(i) is the magnitude value in each bin, corrected by max_esp to give a true magnitude value;

Then the dBm value for each bin (i):

power(i) = noise_floor + RSSI + 10*log(b(i)^2) - bin_sum

• Since spectral sample FFT is done before any digital correction of DC carrier leak, the values at DC will be artificially high.
• The MAC sometimes mis-classifies these frames as data rather than PHY error payloads and helpfully “aligns” them for us. This partially corrupts one of the FFT results.
• The AR9280 has some issues with traffic throughput whilst spectral scan is enabled. Please keep this in mind if you're doing high traffic whilst trying to do spectral scanning.