4 ms·

Very cool project. I think efforts like these are among the most promising to get a FOSS WiFi cards. Because these WiFi-capable MCUs are: designed to be general

Very cool project. I think efforts like these are among the most promising to get a FOSS WiFi cards. Because these WiFi-capable MCUs are: designed to be generally programmable, have quite a lot of open documentation, are available for purchase in both small and large quantities, have s availability over long time-frames (10 years), can tap into the larger community knowledge-base. This is in contrast to the more specialized chips that dedicated WiFi cards use.

DeathArrow 2y ago
What do you mean by FOSS Wi-Fi cards? Aren't there lots of open source drivers for Wi-Fi cards?
- MaximilianEmel 2y ago
  They're talking about open-source firmware, I would guess.
  - jononor 2y ago
    Exactly. And if that is managed, perhaps the codebase can be further adapted on the future to actually open hardware.
- MadnessASAP 2y ago
  While many wifi cards have open driver interfaces they still have closed basebands (the software that actually drives the RF hardware) this is usually done for a combination of intellectual property and regulatory reasons. That is, they get to keep their secrets and the user can't make the radio do something it's not licensed to do. These devs are aiming to open up the baseband of the ESP32 which allow for all kinds of interesting hacks, and probably all kinds of opportunities to run afoul of your countries laws regard spectrum use. I do foresee some cases not entirely unlike the Flipper Zero arising from this but still wholeheartedly support it.
  - treflop 2y ago
    You can already do those interesting hacks with some electrical engineering knowledge. What this is going to allow is what Flipper Zero did: allow you to do something that was already possible but now it only costs money instead of requiring education.
- LukeShu 2y ago
  There are no newer-than-803.11n cards that are usable with a Linux-libre kernel (which doesn't load binary blobs).
  - crote 2y ago
    The whole "no binary blob" argument has always felt very arbitrary to me. Everyone seems fine with read-only firmware permanently burned into chips during production. It is part of the hardware, so it would be silly to treat it like software. Most people seem fine with firmware stored on in-device flash chips. It's basically the same story as before, only it might in some cases be able to update that firmware. But then you get to devices which store their firmware in-memory and it's suddenly a problem - even if it's exactly the same software the device would otherwise be loading from a ROM area or flash chip. Why the sudden shift? And then there are even people who are fine with their CPU executing its burned-in microcode, but updating that very same microcode with a blob during bootup is suddenly a deadly sin? I just don't get it. I get the appeal of a system which only runs open-source code and which is provably free of any kind of backdoors or restrictions, but that fight was already lost when Intel's 8086 and Motorola's 68k entered the market. I don't think there has ever been a truly "free" computer which wasn't a toy project, so why intentionally kneecap your daily compute experience?
    - jononor 2y ago
      The proponents of open firmware and open hardware that I know consider built-in firmware as bad-but-slightly-better-than-updatable. Slight better because it is theoretically easier to validate, as one does not need to take into account firmware updates when doing so. But still something that is ideally avoided. Yes, the struggle for libre hardware has generally been a losing one. But electronic devices are just getting more and more important, so it is just as important a mission as ever.
    - ssl-3 2y ago
      For me, the distinction is simple. Binary blobs in software are incompatible with the GPL, and can't be included in the Linux kernel. Binary blobs in firmware, meanwhile, can exist entirely on the hardware. There isn't any licensing issue because there is nothing to license. (And, sure. That's an incomplete solution if truly libre hardware is the goal. But we humans accept and deal with incompetent solutions all the time in every aspect of life, and I'm not willing to die on this particular hill.)
- pantalaimon 2y ago
  This is about ESP32, it does not run Linux. And doesn’t have a WiFi card, the WiFi hardware is part of the MCU. It’s single processor is tasked with running both the user application as well as the 'baseband' or MAC layer
  - jdiff 2y ago
    With it reverse engineered, you could write software for the ESP32 to have it become the only fully open WiFi card for a Linux host.
echoangle 2y ago
What would the performance be like though? Would you want to use a ESP32 for watching Videos? Would that be doable?
- perbu 2y ago
  You can do that today with the closed source wifi driver. This is not something limited by the wifi performance. Note that neither the framerate not resolution would be something to write home about. We're talking abot an aging MCU here.
  - iamflimflam1 2y ago
    It’s a dual core MCU that runs at around 240MHz. One of the main limitation tends to be to be around pushing pixels to the screen - most displays are serial (SPI) based which tops out at 80Mhz. The other limitation is a lack of hardware video decoding. Some of the latest ESP32 chips are RISCV based and have SIMD instructions which can improve decode performance. But if you pick an easy to decode codec (MJPEG) is popular. The you can get decent performance with the size of displays available. https://youtu.be/2NLblyCvJBU?si=_c-ycaS4cNZEJBaD https://youtu.be/2NLblyCvJBU?si=_c-ycaS4cNZEJBaD
    - echoangle 2y ago
      I understood the parent coment as wanting to build a WIFI card, i. e. the ESP32 connects to the WIFI and transfers the data to a connected computer over PCIe or so. The ESP32 would have to do no decoding of the payload, only transfer the packets to the PC.
      - iamflimflam1 2y ago
        Ah, makes more sense.
- jononor 2y ago
  Not great by modern standards... The standard ESP32 supports 802.11n, but only 2.4 GHz (not 5). So theoretical rates maybe up to 40-50 Mbps. In tests that I have seen people do on ESP32 they have reported practical speeds of 5-10 Mbps. Which is basically just in the typical range for Full HD video. The ESP32-C6 has WiFi 6 support and 5 GHz, so theoretically that can be order of magnitude faster. But it might have completely different hardware and require separate reverse engineering. And practical speeds will still be limited compared to dedicated WiFi hardware.
robert_foss 2y ago
The ESP32 is 802.11n over 2.4ghz with no MIMO, so the bandwidth will always be bad.
- janice1999 2y ago
  They're popular in battery powered IOT type devices where BW is not a huge concern.
- anakaine 2y ago
  If you want bandwidth on an ESP32z you've chosen the wrong hardware in all senses. If you were referring to the intricacies of the driver and how it might apply elsewhere, that's fair.

DeathArrow 2y ago

What do you mean by FOSS Wi-Fi cards? Aren't there lots of open source drivers for Wi-Fi cards?

MaximilianEmel 2y ago
They're talking about open-source firmware, I would guess.
- jononor 2y ago
  Exactly. And if that is managed, perhaps the codebase can be further adapted on the future to actually open hardware.
MadnessASAP 2y ago
While many wifi cards have open driver interfaces they still have closed basebands (the software that actually drives the RF hardware) this is usually done for a combination of intellectual property and regulatory reasons. That is, they get to keep their secrets and the user can't make the radio do something it's not licensed to do. These devs are aiming to open up the baseband of the ESP32 which allow for all kinds of interesting hacks, and probably all kinds of opportunities to run afoul of your countries laws regard spectrum use. I do foresee some cases not entirely unlike the Flipper Zero arising from this but still wholeheartedly support it.
- treflop 2y ago
  You can already do those interesting hacks with some electrical engineering knowledge. What this is going to allow is what Flipper Zero did: allow you to do something that was already possible but now it only costs money instead of requiring education.
LukeShu 2y ago
There are no newer-than-803.11n cards that are usable with a Linux-libre kernel (which doesn't load binary blobs).
- crote 2y ago
  The whole "no binary blob" argument has always felt very arbitrary to me. Everyone seems fine with read-only firmware permanently burned into chips during production. It is part of the hardware, so it would be silly to treat it like software. Most people seem fine with firmware stored on in-device flash chips. It's basically the same story as before, only it might in some cases be able to update that firmware. But then you get to devices which store their firmware in-memory and it's suddenly a problem - even if it's exactly the same software the device would otherwise be loading from a ROM area or flash chip. Why the sudden shift? And then there are even people who are fine with their CPU executing its burned-in microcode, but updating that very same microcode with a blob during bootup is suddenly a deadly sin? I just don't get it. I get the appeal of a system which only runs open-source code and which is provably free of any kind of backdoors or restrictions, but that fight was already lost when Intel's 8086 and Motorola's 68k entered the market. I don't think there has ever been a truly "free" computer which wasn't a toy project, so why intentionally kneecap your daily compute experience?
  - jononor 2y ago
    The proponents of open firmware and open hardware that I know consider built-in firmware as bad-but-slightly-better-than-updatable. Slight better because it is theoretically easier to validate, as one does not need to take into account firmware updates when doing so. But still something that is ideally avoided. Yes, the struggle for libre hardware has generally been a losing one. But electronic devices are just getting more and more important, so it is just as important a mission as ever.
  - ssl-3 2y ago
    For me, the distinction is simple. Binary blobs in software are incompatible with the GPL, and can't be included in the Linux kernel. Binary blobs in firmware, meanwhile, can exist entirely on the hardware. There isn't any licensing issue because there is nothing to license. (And, sure. That's an incomplete solution if truly libre hardware is the goal. But we humans accept and deal with incompetent solutions all the time in every aspect of life, and I'm not willing to die on this particular hill.)
pantalaimon 2y ago
This is about ESP32, it does not run Linux. And doesn’t have a WiFi card, the WiFi hardware is part of the MCU. It’s single processor is tasked with running both the user application as well as the 'baseband' or MAC layer
- jdiff 2y ago
  With it reverse engineered, you could write software for the ESP32 to have it become the only fully open WiFi card for a Linux host.

echoangle 2y ago

What would the performance be like though? Would you want to use a ESP32 for watching Videos? Would that be doable?

perbu 2y ago
You can do that today with the closed source wifi driver. This is not something limited by the wifi performance. Note that neither the framerate not resolution would be something to write home about. We're talking abot an aging MCU here.
- iamflimflam1 2y ago
  It’s a dual core MCU that runs at around 240MHz. One of the main limitation tends to be to be around pushing pixels to the screen - most displays are serial (SPI) based which tops out at 80Mhz. The other limitation is a lack of hardware video decoding. Some of the latest ESP32 chips are RISCV based and have SIMD instructions which can improve decode performance. But if you pick an easy to decode codec (MJPEG) is popular. The you can get decent performance with the size of displays available. https://youtu.be/2NLblyCvJBU?si=_c-ycaS4cNZEJBaD https://youtu.be/2NLblyCvJBU?si=_c-ycaS4cNZEJBaD
  - echoangle 2y ago
    I understood the parent coment as wanting to build a WIFI card, i. e. the ESP32 connects to the WIFI and transfers the data to a connected computer over PCIe or so. The ESP32 would have to do no decoding of the payload, only transfer the packets to the PC.
    - iamflimflam1 2y ago
      Ah, makes more sense.
jononor 2y ago
Not great by modern standards... The standard ESP32 supports 802.11n, but only 2.4 GHz (not 5). So theoretical rates maybe up to 40-50 Mbps. In tests that I have seen people do on ESP32 they have reported practical speeds of 5-10 Mbps. Which is basically just in the typical range for Full HD video. The ESP32-C6 has WiFi 6 support and 5 GHz, so theoretically that can be order of magnitude faster. But it might have completely different hardware and require separate reverse engineering. And practical speeds will still be limited compared to dedicated WiFi hardware.

robert_foss 2y ago

The ESP32 is 802.11n over 2.4ghz with no MIMO, so the bandwidth will always be bad.

janice1999 2y ago
They're popular in battery powered IOT type devices where BW is not a huge concern.
anakaine 2y ago
If you want bandwidth on an ESP32z you've chosen the wrong hardware in all senses. If you were referring to the intricacies of the driver and how it might apply elsewhere, that's fair.