For most people, adding WiFi to a project means grabbing something like an ESP8266 or an ESP32. But if you are developing your own design on an FPGA, that means adding another package. If you are targeting Linux, the OpenWifi project has a good start at providing WiFi in Verilog. There are examples for many development boards and advice for porting to your own target on GitHub. You can also see one of the developers, [Xianjun Jiao], demonstrate the whole thing in the video below.
The demo uses a Xilinx Zynq, so the Linux backend runs on the Arm processor that is on the same chip as the FPGA doing the software-defined radio. We’ll warn you that this project is not for the faint of heart. If you want to understand the code, you’ll have to dig into a lot of WiFi trivia.
The good news though is that a lot of the higher-level functions fall to the generic Linux drivers. Other than a user-space control program, OpenWiFi only provides a driver and an FPGA configuration. All of the higher details occur in the Linux WiFi system that can talk to many different chipsets.
The team didn’t produce any hardware but used multiple FPGA development boards that were commercially available. It’s fair to say that if you really wanted to add WiFi to a project and you weren’t making many copies of it, there are easier ways. But even if you aren’t targeting a custom ASIC with WiFi, reading the Verilog and understanding the code can teach you a lot about WiFi internals.
If you need something simpler to get started on FPGAs, try our bootcamp. Don’t think you need to know WiFi internals? Maybe. But maybe you want to know what kind of attacks you might have to guard against, too.
Could it run on an ECP5? You can get those ECP5 light controlling boards with 25 LUTs for 20EUR.
Hello, sounds interesting. openwifi design currently need around 20k LUT, 110 DSP, 75 BRAM on Xilinx FPGA. But, besides these, some peripheral logic is needed, such as DMA, AXI4 bus, etc.
Hello, sounds interesting. openwifi design currently need around 20k LUT, 110 DSP, 75 BRAM on Xilinx FPGA. But, besides these, some peripheral logic is needed, such as DMA, AXI4 bus, etc.
So to replace our $3 ESP32 all we have to do is take up half the LUTs on a $50 FPGA and then provide an RF front end that almost certainly costs more than an ESP32? I guess we make up the losses in volume?
What am I missing here?
I think what Xianjun Jiao is attempting is software reconfigurable wireless communications. Instead of hardwiring the radio to work on say, 802.11n, you could use the openWiFi hardware to operate on 802.11ax or any newer standards with a software upgrade.
Only if the newer standards wouldn’t involve a new frequency band or additional antennae.
Either of these changes requires different sets of antennae that are tuned for frequency bands that FPGA cannot change. RF frontend might also require changes if the new frequency bands are outside of analog ranges. e.g. old 2.4GHz vs 5GHz
Future proofing with expensive hardware isn’t cost effective vs the massively produced consumer hardware. It might make sense if you were a wireless operator.
The hard part of dealing with standards is interoperability. ie working with products that may interpret the standard in a slightly different way that the standard does not fully cover. Good luck debugging it.
Changing antennas isn’t really a big deal, you’d have to be nuts to put an integrated antenna on a development board. The problem would mainly be if a standard increases the channel bandwidth, power requirements or number of antennas needed.
The analog bandwidth of this setup is up to 6 GHz, so that’s not going to be a problem. Future standards are very unlikely to push past that.
The joy of learning.
Lol thank you, I’m baffled by some of these comments. Obviously this isn’t done from a practical production standpoint. When did hackaday people get so focused on shipping products?
Yeah I get that everyone likes to play make believe that whatever their doing is the worlds most important project.
But people seem to forget that we are playing make believe and very few (to none) of us will ever have this particular project have a meaningful impact on our work / commercial projects…
On the other hand what we learn may well have a significant impact!
You miss difference between development/experiment and production platforms.
LOL, I think this is trying the WiFi manufactures. Will there be another info take down (Casio style) in here !
This is a good catch! Indeed, like I said in fosdem2020, our current design is more expensive than commercial chip, and less advanced than commercial chip. If people is satisfied by commercial wifi chip, then no reason to use openwifi. But you should also realize some of our counter parts in the world: “National Instruments The LabVIEW Communications 802.11 Application Framework”; “Mango Communications 802.11 MAC/PHY Design”. Those (hardware software and license fee) are way more expensive than ours (we are AGPLv3)! Another thing is that you don’t realize how much money has been spent when the company develop ESP32. openwifi basically is a reference design for people to develop their own WiFi chip/system if they are not happy with the existing WiFi chip. So for now, openwifi’s user is not the normal consumer.
But again indeed, you catch a good point. Our long term goal is to find enough funding/resource to tape out a real openwifi chip! But again, I believe the real openwifi chip still can’t beat wifi chip from other big commercial companies regarding many aspect that normal consumer care. But it will still make sense, because openwifi chip could be the first opensource wifi chip that people know exactly what is happening in it when use it, which is not possible currently for other commercial wifi chips.
What if a commercial wifi chip company also opensource one of their low-end wifi chip? Then we will also feel very happy if that actually happens. Because we know that without openwifi project, most probably they won’t do opensource. So our efforts are still there to make the wifi communication more transparent/safe.
Sounds like job for plutoSDR. It has Analog Devices RF/SDR frontend, Xilinx Zynq and lot of other goodies.
Indeed, many people are thinking about plutoSDR. If that can be done, it will be a big step. A full porting of openwifi to plutoSDR is challenging: openwifi design currently need around 20k LUT, 110 DSP, 75 BRAM on Xilinx FPGA. But, besides these, some peripheral logic is needed, such as DMA, AXI4 bus, etc.
But take some part (like the ofdm tx/rx only) to plutoSDR is possible.
don’t you need a licence to transmit in these WIFI frequency bands ? I always thought receiving (any) signals is ok, but transmitting needs approval.
My understanding (in the USA, anyway) is that you need a radio license to operate past something like 200mW.
In the USA anyways (unless it’s changed), “…receiving (any) signals is ok…” is not true. For example, one is not allowed to receive/intercept older cell phone signals. Your mileage/country may vary…
I recall it’s more like you’re free to receive whatever you want, but decrypting it without permission (even if trivial to do so) is generally not allowed. Something about how in the early days of satellite TV, they had a problem with pirates selling boxes that received satellite TV without paying the provider. They tried to stop that but couldn’t because it was just a kind of radio receiver, so they encrypted the signal in order to stop them on grounds of unauthorized decryption.
That said, if you just receive and don’t tell anyone, it’s hard to detect.
This is a complicated aspect. Yes, people should be careful on this by checking the regulation. But nevertheless, there are lots of SDR platform, that is capable of transmitting a very wide range of frequency, on sale by many companies (even some big companies). Fortunately, the Analog Devices’s AD9361 boards have little tx power (I think maximum < 10dBm), and regulation of ISM band is not as strict as licensed band, like what the operators/forces have.
Nice to know one doesn’t have to pay money to an organization to get the secret sauce in order to implement.