I am curious about the hardware support for Mediatek's MT7915 AX chipset in OpenWrt. How good is support for it? I see there are some PCIe cards available for it now, and I'm wondering if it's reasonable to use them in devices like a Unielec U7623 or a Banana Pi R64.
Is this a workable scenario? I see no reason why it wouldn't work, but it seems to me to me to be almost too ideal of an AX solution (to be true).
The 12V PSU isn't the real problem. It can easily be replaced. The question is the 3.3V regulator on the board. That's the limiting factor. And the 2.5A minimum required by the MT7915 module is quite a lot.
No. I've actually already been talking to UniElec about this. They say the board itself can source 1A on the 3.3V line.
I suspect this is a combination of over-drawing the 3.3v line, and the card's power amplifiers running under-powered. AsiaRF's board must be pretty well designed - I would be worried that as the power amplifiers cause the 3.3v line voltage to sag that the chipset would start acting funny. It must be designed to back off the power amplifier output.
I have my AsiaRF cards now, but not my UniElec order yet (got caught in the Chinese New Year shutdown). I will know more when it all arrives and I can get some test equipment on it. I have a solution for the 3.3v issue, in any case.
My AsiaRF 7915 card is populated on both sides and has a metal cladding over the chips on the top AND bottom. The bottom cladding comes in contact with the half-height card mounting screw spacer on my board (photo below). I'm not 100% sure if that spacer is soldered to the board or not and I'm reluctant to try to forcibly unscrew it off the board if it is soldered. Did you take yours out? Was it soldered?
I've spent some time with my U7623 and pretty much every pcie card that both UniElec and AsiaRF offer. Here is what I've found:
The AsiaRF 7915does work very well on this board. It has an FCC ID and OpenWrt picks up on the MAC address printed on the card. More on the 3.3v supply later.
The AsiaRF 7615 card also works well on this board. What I have not yet got to work well is DBDC mode, but otherwise this adapter is fantastic.
The ONLY UniElec-manufactured PCIe board I have got to work properly is their half-height 7612 board. No FCC ID, though, and you'll get a random MAC address.
UniElec's own 7615 adapter is particularly hard to get to work and I don't recommend it. It needs EEPROM settings sent to it during its initialization, and OpenWrt isn't set up to do that. Without those settings, it is limited to a paltry 6dbm output power. The Vendor-customized version of OpenWrt has this card's EEPROM settings in a separate raw partition and then feeds it to the card on initialization. But the card is so physically big you can't use the main board's second card slot with it, and it has no RF shielding, so even if I get modern vanilla OpenWrt to configure the board properly, I'm still not sure I'd want to use it anyway.
I solved the 3.3V problem with a small 12v->3.3V buck regulator module. It's easy to draw the module's 12V input from the SATA power plug and back feed the module's 3.3V output into the 3.3v "supply" of the U7623's serial plug, so no soldering on the board is required. I installed the module, drilled 4 more antenna holes in their case, and now have the device running with both the 7615 and 7915 cards simultaneously:
So anyone wanting good Wi-Fi 6 support in OpenWrt, it seems to be a reasonable solution. I'd recommend contacting UniElec and seeing if you can get the board plus case WITHOUT any of their cards, and getting you cards from AsiaRF.
I had just turned off a space heater in the room an hour before, which is why the general cooling trend above. I'm not unhappy with the temperatures, but I'm watching it. The case has ventilation slits on the bottom, but not the top. It is anodized aluminum, though, so radiates fairly well.
It's important to note that there is a bug in the .dtsi file for the MT7623 which limits the CPU to getting to 47°C before the kernel scales back the speed, all the way down to 98MHz. This bug is in all versions of OpenWrt. I am running with a kernel I patched that raises this to 67°C.