change in FFT format from libradarpkt.
* the RSSI from the hardware is in units of dB*2, so we need to divide it by 2 to get an actual dB value; * Do the frame length check at the beginning of the loop, in case we get frames that are 0 bytes in length. * Don't print out the full spectral data here. This doesn't fix the MAC/BB issues surrounding corrupted HT20/HT40 frame lengths; that'll come later.
HT40 spectral / radar frames report both the lower and upper 20MHz worth of samples (128 in total.) The two 20MHz halves have different RSSI values, so use the primary / extension values to calculate two sets of channel power, rather than doing it over the full 128 samples. The two 20MHz halves have different noise floor and RSSI values, so the right NF/RSSI values need to be lined up with the right half of the 40MHz channel. For HT40D (ie, extension channel below primary channel), swap the RSSI/NF values when calculating the power level. So: * remove the pri/ext FFT results - they're kind of pointless now; * calculate channel power separately for each 20MHz half; * Figure out which RSSI/NF to use based on the current channel flags; * Use chain 0 ctl/ext RSSI and NF (when the per-chain and per-half NF cal data is eventually used) in the signal level calculations. Tested: * AR9280, HT20 and HT40 spectral scan report modes
of the main loop. The rendering is still done in the main loop, but it's done as a response to a posted timer event. This removes the whole "just keep running and chewing CPU" hack that was going on before.
* modify acceleration max to 40, rather than 20, so I can quickly scroll around the 5ghz range * change the scroll to be left/right, rather than pageup/pagedown.
process of turning it into a (kind of) stand-alone class.
…plement a really stupidly simple heatmap (blue -> blue+green) for points that saturate the blue opacity. This makes the "very frequent" points very obvious.
decaying max-hold implementation. Plot the max in red, and the current average-ish in blue.
* Hard-code the fft source to an AR9280 on wlan0 for now, sorry! * Change the pcap code to be: + a data source; + that runs in a thread; + and calls a cb on each radar entry decoded; * Modify the rendering code to use the fft histogram, rather than a list of frames to render; * Populate the histogram via a cb, with relevant locking; * never wait/delay, always just poll for events. I'm not doing correct locking or conditional wakeups _at all_ in the rendering loop as this is quite honestly a terrible piece of code. But it's good enough to do initial test rendering with.
it in the draw loop. This breaks the Linux decoder for now.
reused. * Update radiotap to use the net80211 radiotap fields. I'll add those to FreeBSD shortly.
and decode it. The -HEAD driver now includes the correct xchan flags for PHY errors, so I can figure out whether it's a HT20/HT40 configured channel.
These haven't yet even remotely been verified as correct; please don't try to use it. The frequency is hard-coded; I need to decode ic_freq. Also, it's assuming HT20 format; I need to decode the MCS channel flags from the radiotap header to determine whether it's a HT20 or HT40 channel (and subsequent channel configuration for pri/ext frequencies.)