Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: user/adrian/at…
Commits on Mar 11, 2013
Commits on Feb 1, 2013
  1. Oops, add missing file.

    adrian authored
Commits on Jan 31, 2013
Commits on Jan 30, 2013
  1. Update the FFT code to support the HT40 operating mode and the slight

    adrian authored
    change in FFT format from libradarpkt.
  2. Fixes!

    adrian authored
    * 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.
Commits on Jan 29, 2013
  1. Implement HT40 spectral frame format support.

    adrian authored
    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.
    * 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.
    * AR9280, HT20 and HT40 spectral scan report modes
Commits on Jan 9, 2013
  1. Break out the rendering into a timer-based event, rather than as part

    adrian authored
    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.
  2. * break out the width/height/scaling to fft_display.h

    adrian authored
    * 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.
  3. Break out the display specific code into a separate file and begin the

    adrian authored
    process of turning it into a (kind of) stand-alone class.
  4. Implement a separate pixel set function for the average points, to im…

    adrian authored
    a really stupidly simple heatmap (blue -> blue+green) for points that
    saturate the blue opacity.
    This makes the "very frequent" points very obvious.
Commits on Jan 8, 2013
  1. .. history depth is fun.

    adrian authored
  2. * Add home/end to skip between 2 and 5ghz

    adrian authored
    * Add a history buffer to the current readings, so i can get a better idea
      of what's going on graphically (and yes it's pretty)
    * change the default alpha for the max to not be 255 ,so there's some
      .. prettiness too.
  3. Fiddle wiht the decay rate a bit more.

    adrian authored
  4. Add in a very hacky and mostly incorrect rolling average and slightly

    adrian authored
    decaying max-hold implementation.
    Plot the max in red, and the current average-ish in blue.
  5. Biiig fft eval commit:

    adrian authored
    * 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.
  6. Add a very simple initial histogram data type, to populate and fetch

    adrian authored
    histogram entries.
  7. pthread-ise?

    adrian authored
  8. Process the HT20 data into dBm values.

    adrian authored
  9. Convert this code over to use the dBm value rather than calculating

    adrian authored
    it in the draw loop.
    This breaks the Linux decoder for now.
  10. * Disable printing debugging output for now;

    adrian authored
    * Move the channel frequency population into this function
  11. * Migrate the radiotap and chan code out into libradarpkt so it can be

    adrian authored
    * Update radiotap to use the net80211 radiotap fields. I'll add those
      to FreeBSD shortly.
Commits on Jan 4, 2013
  1. Add some logic to pull out the XCHANNEL field from the radiotap header

    adrian authored
    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.
  2. Add radiotap xchannel field support.

    adrian authored
  3. .. another part from the radiotap import.

    adrian authored
  4. Add a radiotap library from

    adrian authored
Commits on Jan 2, 2013
  1. More updates:

    adrian authored
    * add a debugging printing for now
    * don't "fix" up the index to be signed from DC; no need to do that
    * use combined RSSI for spectral scan printing for now rather than
      pri RSSI.  I need to see what the "right" RSSI value to use is.
Commits on Dec 31, 2012
  1. Begin fleshing out support to parse HT20 spectral scan samples.

    adrian authored
    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.)
  2. Add freeBSD support for this.

    adrian authored
  3. Break out the parsing code into fft_linux.c.

    adrian authored
    This (hopefully) will let me implement a FreeBSD-format version of this.
Something went wrong with that request. Please try again.