BPI-R4 WiFi range

“I was very excited to have found in the BPI-R4 a board that integrated everything I need, in a compact design and with a single governing chip providing everything: 2 SFP+ 10Gbit, 4 RJ45 Gb, PCIe ports for NVMe SSD, Wi-Fi and 5G.”

  • 2 SFP+ 10Gbit → working ?
  • 4 RJ45 Gb → working ?
  • PCIe ports for NVMe SSD → working ?
  • Wi-Fi and 5G. → working ?

→ So right now, we’re only having an issue with the Wi-Fi range? → I just wanted to point out / ask whether everything else is free of hardware-related problems?


“I purchased two AsiaRF (AW7916 and AW7915) thinking to avoid the problems of the BE14, but I have to say that the performance is completely disappointing. I feel like I’ve thrown my money away.”

  • You’re avoiding the Wi-Fi 7 problems! I think that’s a good choice :slightly_smiling_face:!

!!!

  • “Performance is completely disappointing” — now we’re getting somewhere! Did you have issues with Wi-Fi range? Noise as well?

Maybe we could investigate the noise issues using this?:

  • And supplying clean voltage?

    • What I want to say → this is not the end

    • We will gain more knowledge

    • This will continue with the release of adapters, the BE19, and the BPI-R4 Pro

I’m interested in your AW7915 and AW7916 if you’re thinking about selling them :slightly_smiling_face:

!!!


“Which makes me think that the Wi-Fi problem rather than being in the boards, both the official and AsiaRF boards, is in the design of the BPI-R4 board itself. Either it is an amateur electronic design, or the tracks are not properly electrically isolated. Either the electronic components are not of high quality or they are insufficient. I have no explanation.”

  • If you’re experiencing noise problems too, then now we know:

    • it’s not just a 12V-related issue, because the AW7915/6 run at 3.3V

    • and it shouldn’t be BE14-related either, since the AW7915/6 are completely different modules

You’ve helped us :slightly_smiling_face: :+1: :slightly_smiling_face:

theres a few threads on the aw7916 here… mine works perfectly on 2.4 and 5.8g channels, 6g isnt supported after openwrt 22? in 24 snapshot if you try switching to 6g by doing a command, it basically fails to start the radio. and luci wireless config glitches out

echo “mt7915e enable_6ghz=1” > /etc/modules.d/mt7915e

also ordered a shield and a bidirectional signalbooster to amplify the be14 5g, maybe the lower 6g channels, but havnt tested yet because aw7916 is working so good. the txpower patch was causing problems, be14 and luci were more stable without it, so bidirectional amplifier is next best alternative

1 Like

Thanks for sharing :+1:.

This restores my hope for the R4 working with the AW7916 (and possibly the AW7990)!

And you have no problems with the range?

What does “works perfectly” and “works very well” mean to you? What do you contrast it with? Can you provide more data? Because what I have said about this card and its sister AW7915 is with data that I can share. Otherwise, I wouldn’t have said that they leave a lot to be desired since I wouldn’t have anything to compare with.

At the very least, the 6GHz band does not work. And that the driver is more mature than the Wi-Fi 7 chips…

Thanks for sharing.

mostly going off of measuring range by how far i can get in the house while streaming virtualdesktop to a quest3. compared against my old asus ac1300 router. or running wifi analyzer/speedtests from my phone.
pic is taken with me standing right at the edge of reception range, asus can’t be connected to without failing, aw7916 still can, on both bands. lightmode openwrt is the asus, darkmode is the bpi-r4

thanks for sharing that. Could you do one more test to have similar environment:

  • on Asus switch channel from 44 to 100 (usually 100> has more power)
  • for 2.4GHz set also 40MHz, or change on Asus also to 20MHz
  • disable power saving on your phone

Thanks!

2g on the asus starts fluctuating a bit wildy if i set it down to 17dBm to match the aw7916. test isn’t very clean, i am going through atleast 3 walls, and standing maybe 30 or 40m from where the routers are. with tons of interference. :man_shrugging:

thank you for making that test. Now it is more clean for others to understand and compare results.

May the gods of irony be damned, there was a brief power failure here at home, the R4 got stuck on the boot prompt. For an internet gateway, this is unacceptable. Well, time to find a replacement router.

Now back on topic, via Wifi, on openwrt, ssh gets very slow sometimes. Respective bug

Got similar - when it crash it stuck on boot prompt or it goes to recovery mode. That’s why I set in NAND to reboot into “production system”

fw_printenv  | grep bootmenu

From the list, I pick:

(...)
bootmenu_2=Boot production system from NAND.=run boot_production ; run bootmenu_confirm_return
(...)
bootmenu_default=0

To set default:

fw_setenv bootmenu_default 2

To verify:

fw_printenv  | grep bootmenu_default
bootmenu_default=2

So many times I agree with you @Casulo - it is just a router that can not trust fully. Unexpected reboots, it did not return back to main system. The whole situation with 2.5G PoE version…

I have wondered this a bit, with the “official” case;

The basis of the case might be grounded from the board on attachment screws, but what about the slideable top plate? Because of surface treatment, doesn’t look like it would be electrically connected to the rest of the case.

Before I go ahead and cook up a threaded “corner block” inside the case - and associated counter-sunk screw holes on the frame side and top cover plate - has anyone already tried if it’d make any change grounding the top lid plate properly?