Sythesizable, modular Verilog implementation of 802.11 OFDM decoder.
Go to file
Jinghao Shi 2f0e0ba953 faq
2017-12-09 19:05:26 -05:00
docs usrp 2017-04-25 15:19:32 -04:00
scripts rewrite test.py 2017-04-21 13:41:03 -04:00
testing_inputs testing inputs init 2017-04-03 12:52:31 -04:00
verilog fix dot11 port pinout 2017-04-21 13:42:09 -04:00
.gitignore doc init 2017-04-03 14:42:37 -04:00
LICENSE.txt license 2017-04-26 14:47:59 -04:00
Readme.rst faq 2017-12-09 19:05:26 -05:00
requirements.txt working 2017-04-03 15:48:25 -04:00

OpenOFDM

This project contains a Verilog implementation of 802.11 OFDM PHY decoder. Features are:

  • Fully synthesizable (tested on Ettus Research USRP N210 platform)
  • Full support for legacy 802.11a/g
  • Support 802.11n for MCS 0 - 7 @ 20 MHz bandwidth
  • Cross validation with included Python decoder
  • Modular design for easy modification and extension

See full documentation at http://openofdm.readthedocs.io.

Environment Setup

This project has the following dependencies:

Input and Output

In a nutshell, the top level dot11 Verilog module takes 32-bit I/Q samples (16-bit each) as input, and output decoded bytes in 802.11 packet. The sampling rate is 20 MSPS and the clock rate is 100 MHz. This means this module expects one pair of I/Q sample every 5 clock ticks.

License

Apache License 2.0

FAQs

Q: Is there any need to change host driver UHD to incorporate new changes in FPGA?

A: No. In fact OpenOFDM relies on the current UHD-USRP communication mechanism. However, since the logic of the FPGA is changed in OpenOFDM, its behavior is also different. For instance, utilities such as rx_samples_to_file do not work as expected since the FPGA in OpenOFDM does not dumping RF signals back to host.

Q: Any example code to communicate with OFDM core in FPGA from host?

A: OpenOFDM FPGA module is configurable via USRP user setting registers (set_user_reg function). The register address definition is in common_params.v. The whole OpenOFM FPGA module takes 32 bit I/Q samples and outputs decoded bytes. It is supposed to be placed in the receive chain of the USRP (e.g., custom_dsp_rx.v.

Q: Is there any change in ZPU firmware?

A: No.