My 802.11 implementation has, apparently, been working ever since I finished it just over a year ago – and exceedingly robustly too [1]. I thought noise or some real-world thing confused the receiver, but no:

It’s just very slow.

Generating 1MB of samples took 7.7 seconds on my 1.7GHz Pentium M, and since USB 2.0 can do a bit more than 32MBps my code clearly can’t keep the bus saturated. Finding and demodulating an 802.11 packet that would be 464 microseconds long at 1Mbps takes 15 seconds.

If you check out and build my current code [2], you’ll get a new pair of tools, tx and rx. tx outputs a stream of 16-bit little-endian samples to stdout, with a repeating pre-programmed test pattern: a valid 802.11 packet with a payload of the integers from 0 to

  1. rx takes a stream of samples, finds the first 802.11 packet it can decode, and outputs that packet’s header and payload.

To test these with hardware, I wrote a trivial GNU Radio program, committed as loopback_file.py. It reads samples from a file and dumps them to the USRP; simultaneously, it reads from the USRP for one second and writes the samples it gets to a file. First I tested this with the FPGA in digital loopback mode, which bypasses the analog path; then I used short SMA loopback cables to test the analog components as well. The analog components mangle the waveform in interesting ways, but nonetheless when the resulting log file is fed back through rx, I get back the correct test pattern.

I have a few next steps in mind, several of which can happen in parallel.

  • Extend the transmitter to arbitrary data payloads.

  • Make my Haskell implementation resemble a sane FPGA-based version. I now have a test environment where I can easily prototype things like using IIR filters instead of FIR, and I’d like to try them with known good code before porting this work to Verilog.

  • Port the Haskell code to Verilog, using a Verilog simulator to read and write files of samples like the tx and rx tools do. Test with the same GNU Radio script.

  • Test over-the-air between two USRPs.

  • Test at 2.4GHz. I have our Flex2400 daughterboard; we also bought quadrature mod/demod and oscillator hardware for this band.

  • Eventually: Implement simultaneous receive/transmit. Receive until data is to be sent, then wait for the channel to be clear and transmit.

  • Eventually: Implement higher-speed modulation schemes, starting with 2Mbps DQPSK.

  1. [In addition]{#1} to the tests we did in May – http://wiki.cs.pdx.edu/~sdr/Meeting20060523 – and some experiments with quantizing to 16-bit ints instead of doubles, today I also tried duplicating every sample, effectively cutting the carrier and pseudo-noise frequencies in half. The Costas and code tracking loops still locked, and gave me correct output.

  2. [svn co http://svcs.cs.pdx.edu/svn/wifi/trunk/wifi]{#2}