jxj

To my understanding, the main difficulties are:

1. The investment needed for a real "free" Wi-Fi chip is much higher than most people's (FPGA, DIY, enthusiast and garage guys) imagination. I won't go through all the complications (not only design, but also tool chain, cell libs, etc.) here. Just one hint: think how many thousands pages are there in the Wi-Fi standard pdf, and how many test cases/vectors would be extracted from that before the actual tape out.

2. The chip business is purely the game of volume – if we want to not just burn money, but actually make it successful from the business point of view. We discussed with some businessman, investors and big companies in the chip/Wi-Fi industry regarding the "free" Wi-Fi chip business opportunities and failed to convince any of them. In other words, so far, no serious man actually believes that the "free" Wi-Fi chip could be financially successful.

(Keep in mind the game of volume). A key question to you: Will you buy a Wi-Fi dongle (with free Wi-Fi chip) with higher price and lower performance/functionalities (This is the result of low investment and low volume compared to those big players: Qualcomm, Broadcom, Mediatek, Realtek, etc.)? Even if you say you will, could you estimate how many people are there like you in this world? For chip: NO volume == NO business.

This is Xianju who created the opensource Wi-Fi chip project openwifi: https://github.com/open-sdr

It is still in FPGA status, not a real chip yet. We have been working on this for 7 years (starting from the time project setup internally).

We do even further. If we use openwifi as a router in home, it can fuzz the CSI and destroy those sensing method: https://github.com/open-sdr/openwifi/blob/master/doc/app_not...

"free software", "for any purpose", beautiful target. But maybe it can not be achieved in one step.

People select a license for purpose. No matter what is the purpose, the developer is free to choose, the user is free to accept or deny. If the license really brings some big hurt, people might change later.

Ok. Actually I never (and don’t know who) call AGPL software a free software. Let’s just call it AGPL software! Problem solved.

Just curious, if AGPL is so evil, who made it for what kind of purpose from the beginning? You give me an impression that AGPL is totally wrong and shouldn’t be born.

I am not saying that AGPL is born to prevent people to use AGPL software. Instead, AGPL definitely encourages people to use for free under the license, or use it after purchase commercial license. Why you have impression that AGPL was born to let people not use the software?

Like MongoDB, it selected AGPL from the beginning, and many people were using it (so you can’t say AGPL stop people to use MongoDB), until some big commercial companies began to deploy it in cloud and violate AGPL (refuse to open source). This hurt the protocol and MongoDB, so MongoDB decided to change the license to a more explicit and strict license written by themselves to rule explicitly that if you deploy the MongoDB in cloud you should be open source. Otherwise you need to purchase a commercial license. From this point of view AGPL or the more strict MongoDB protocol find a good balance between open source and commercial usage. Please tell me if MongoDB uses more free software style license, like GPL, Apache, MIT, I guess many companies will use it in non open source style without violating the protocol, then how MongoDB can survive? If MongoDB can not live a good life, who will contribute to it, maintain it, help user continuously? MongoDB dies and the world gets nothing. Happy ending?

I am glad that google doesn’t like AGPL. To me this implies that the thing, that is not liked by big company, could be interesting. Google has become a gigantic monster. AGPL just prevents the big companies , like google, amazon, to use open source software for free.

If you are saying AGPL's virus like behavior is much more severe than the GPL's virus like behavior, I am not professional on this aspect. Not sure.

If I understand correctly, the open source action is only required when you "re-distribute" it. So, if you play it only by yourself and never give your modified software to anyone else, it is OK for you to keep all code close. If you work on it together with other people in your organization, it is fair enough that you open the source code to those people for them to work together easily. But all the code are still kept inside your organization.

Only in a step that you want to re-distribute the software (or the service) to people (like external user or other company) who you don't want to show source code, you are facing violating the AGPLv3. But generally speaking, in this step you already have a plan to make money out of external people (like user or other company), so fair enough to pay a fee for commercial license.

"free software" or freedom zero is good, but how engineers/companies who develop free software make survival? Donations? If I am already a billionaire, I totally support your point.

But in the MongoDB case (when it was still using AGPLv3), those companies who violated AGPLv3 did have a solution: pay a fee for a commercial license of MongoDB instead of AGPLv3 which is free. In this way, those companies don't need to open source their code built based on MongoDB. MongoDB get money to go further, because I guess MongoDB people need to raise their family.

So GPL doesn’t have this character? Like the GPLv2 taken by Linux kernel. I have an impression that AGPL only add “A” to GPL to adapt itself to the cloud era. Because a cloud/service deployment is not treated as redistribution in GPL, considering there wasn’t cloud at the time GPL was made. So some big cloud company can deploy GPL software on cloud without open source action because they are not actually “distribute” software, instead only distribute a service. AGPL fix only this hole created by cloud.

How so?

2000USD? Not really. Following two options are less than 1000USD:

1. zed board + fmcomms4 = 883 USD https://www.digikey.com/product-detail/en/digilent-inc/410-2... https://www.digikey.com/products/en?keywords=FMCOMMS4

2. adrv9364z7020 + crr bob board = 932 USD https://www.digikey.com/products/en/rf-if-and-rfid/rf-transc... https://www.digikey.com/product-detail/en/analog-devices-inc...

A short answer: yes you can.

A bit longer answer: Basically Linux gives packet to our driver, and then our driver gives the packet to our FPGA for further processing (queuing, modulation, CSMA, etc). So you can compose your packet in the driver or anywhere else that can communicate with the driver, then instruct the FPGA to send your packet at any frequency 70M~6GHz.

It will be very worth to read the README and project document word by word on the github: https://github.com/open-sdr/openwifi . I believe you can already find answers of more questions there.

Good and tough question. So far, we are not very successful to find enough funding to bring the design to the next mature level and tape out it. Working on it, but difficult.

No one can decide to pay 200~300k euro in a minute with very uncertain return (like charity), because no one can 100% answer the question of how many openwifi chips can be sold per year.

Indeed, not only the viterbi but also many basic building blocks in the Xilinx and Analog Devices reference design which is the starting point of our openwifi project.

Viterbi won't be an issue, we know how to write our own viterbi decoder on FPGA. It just need some time.

A Thorough and comprehensive IP block analysis will be needed and we will also evaluate how big the effort will be to replace all (almost) the big company owned blocks. We have to do this analysis and invest effort in the future, because we really want to tape out a real opensource WiFi baseband chip! As the first step, RF won't be integrated.

8bit I/Q definitely can be used for WiFi. I used HACKRF to send and capture Wifi packet without an issue (offline, use Matlab to process the captured I/Q samples).

Low resolution I/Q (8bit) will impact the RX sensitivity and TX EVM, but it won't be a factor that will totally fail the WiFi implementation.

I like this sentence "nothing works until just about everything is working".

Actually the first ping worked in the end of 2018 to the beginning of 2019. But like you also realize, it is complicated, and actually well beyond my original imagination. So between the first ping and the release status (at the end of 2019), there was a lot of work. Finally it comes to today, and it runs "normally": stable ping, stable throughput, less crash. Huge effort is needed just to make things work as normal.

Hello,

This is the author Xianjun.

When communicate with commercial device, tcp can achieve ~30M, UDP can achieve ~38M in 20MHz 11a/g non MIMO mode. We are still working hard to optimize the whole design, because we know it is not mature enough and there is still lots of work to be done. For example, the original PHY rx openofdm design is simplified a lot for a quite small fpga which means performance (like sensitive) is sacrificed. Now our FPGA is more advanced than the openofdm FPGA in USRP N210, so there is a chance to improve a lot on both performance and features (like MIMO and new standard). Recently nlnet.nl gives us a short term fund to complete the 802.11n feature: https://nlnet.nl/project/OpenWifi-80211n/index.html

There are lots of information (including throughout) in the readme and “project document” on GitHub (https://github.com/open-SDR/openwifi). Worth to read word by word.