At least vlan tagging is natively supported in openwrt anyhow.
The rest I never needed, so no idea...
The metal case is one main issue.
With exchanging the metal one by the plastic case I jump from -84dBm to -92dBm noise. Another -8dBm were gained by not using 160/320mHz and routing higher shielded pigtails away from the mPCIe connectors.
1 Like
Congratulations. I was aware the metal case "raises the noise floor" as Betonmischer first reported in the Bananapi thread. Seems a couple other folks can reproduce the lower noise floor without the metal case.
The interference signal though must be generated by active components. I was saying it's likely from the PCIe lanes/traces on BPI-R4.
How the metal case (if so) amplifies the interference is an interesting pursuit IMO. Changing the case is one solution. Likely an acceptable one for most users anyway.
2 Likes
It is just cheap (but DIY - you need active cooling) solution…
For the mPCIe you are right I think - routing the pigtails directly across the mPCIe connectors and reducing bandwidth (means less power for the mPCIe-cards?!) lower noise by ~4dBm each.
But if the cards are shielded well enough (2xMT7916/1xMT7915E), this EMI has no effect. And also using another (generic) aluminium enclosure does not raise the noise level for these cards above -90dBm (another of my BPI-R4 installations). So it is only the BE14 that is suffering from this issue + there seems to be something special with the official BPI-R4 enclosure.
1 Like
A true riddle! Only if someone could solve or explain the riddle. I haven't looked at pictures of the BPI-R4 board for a long time. Just realised the two SFP cages sit right above the BE14 card or the two mini-PCIe slots:
And the "only" difference between the BE14 card and other WiFi cards is its double size. Other cards are half the size. Even if you put in two, there are the air gap / electrical isolation between the two cards.
1 Like
If people need help on re-imagining how your BPI-R4 could become? Here is a little commercial turn-key product that I just saw a moment ago: the Cloud Gateway Fiber from Ubiquiti, launched in Feb, 2025.
Same quad-core Cortex-A73 (but Qualcomm SoC). Well, with its beefy SoC cooler, I'm sure my BPI-R4 can also run stably at 2.2GHz.
Its 4 X 2.5GbE switch is a plus, and the additional 10 GbE RJ45 WAN port is convenient addition.
It gives people some hardware MOD ideas to your BPI-R4. Its software features aspire people what to work on for OpenWrt/BPI-R4.
Have fun.
1 Like
Maybe that is part of the problem, but I think the main and critical difference is that other wifi cards are shielded.
1 Like
Interesting. MediaTek once released TOPS driver v1.1 back in late 2023:
and then stopped. The removal comment said the firm decided to distribute the driver through a tar ball. Perhaps with signing a NDA I guess (?).
TOPS is a piece of ASIC that itself is a 5-core microprocessor, running its own operating system with a mini network stack. You can query its status and administer a bit how it works from the command line.
TOPS can offload processing PPP, L2TP, PPTP, GRE, VXLAN and etc from the main CPU. If any encryption/decryption in the tunnels, TOPS can offload to the EIP197 crypto engine. All without involvement of the main CPU after the initial tunnel setup.
How can we get the latest driver for OpenWrt ?
3 Likes
Last year there was a suggestion in this thread by changing MTK_QDMA_NUM_QUEUES to increase number of TX queues in HQoS.
I didn't try back then but I tried a few days ago. It didn't work for me. The whole ethernet stopped working actually.
Lucky or not. Coincidentally MediaTek just freshly released a patch which tells us what else was missing. They bumped from 16 to 32 queues in their builds. LOL
Note that BPI-R4 / MT7988A supports 128 queues (!).
Have fun.
p.s. It seems MediaTek still hasn't realised a serious bug in their code:
#define MTK_QDMA_QUEUE_MASK ((1ULL << MTK_QDMA_NUM_QUEUES) - 1)
I wish I had a contact into MediaTek. I have a couple other bugs to tell them.
5 Likes
Yay. Now I have 64 TX queues on my BPI-R4.
Next step is find a "traffic classifier". Don't want to reinvent the wheel if I could avoid it. Based on my very brief survey, I think DSCPclassify can be modified to work for MTK's HQoS.
I picked DSCPclassify because it's
- minimalistic approach
- solely based on nftables
- clean and neat working alongside
firewall4 - able to detect high-throughput traffic
The last point is very useful IMO. Likely fulfils 99% of QoS requirement for SOHO use.
Tried it in the past few days. It didn't work for HQoS out of the box. I believe it could be made to work.
Suggestions for other candidates are welcome. I think once it's made to work for MediaTek HQoS. The chosen package will get many new users from MTK device owners.
Update
Works. Needs more testing.
4 Likes