https://docs.banana-pi.org/en/BPI-R4/BananaPi_BPI-R4-NIC-BE14
on line wiki documents:
https://docs.banana-pi.org/en/BPI-R4/BananaPi_BPI-R4-NIC-BE14
https://docs.banana-pi.org/en/BPI-R4/BananaPi_BPI-R4-NIC-BE14
on line wiki documents:
https://docs.banana-pi.org/en/BPI-R4/BananaPi_BPI-R4-NIC-BE14
Is this a 1-on-1 replacement for the original flawed BE14 V1? Does this fit in the original BPI-R4 small housing? Does it need a cooling pad attached to the bottom for cooling through the bottom plate of the housing?
Interesting that it’s shielded on both sides.
Good idea of making use the aluminium housing as heatsink. The whole purpose of using aluminium for the housing is for it to act as a heatsink in some way.
Good morning @Michael Fischer, but that only dissipates heat. What do we know about the noise?
Or should we spend the money and figure it out ourselves?
Why hasn’t the beloved leader @sinovoip announced the product like he has here?
We need you to show us this:
It fixes the problems people observed with BE14.
RSSI without SNR/noise is meaningless. High RSSI at short distances can still occur with a poor link (high retries, errors, MCS drops). The BE14 “range” reports look more like a noise/isolation/EMI issue than a simple “TX power” issue. Without SNR / noise floor (or at least serious proxies like retries/failed under load), no conclusion can be drawn.
Publish the minimum reproducible metrics (required) If you want the community to validate “fixes BE14”, you must provide at least:
Exact distance + obstacles (LOS / 1 wall / 2 walls; wall material: brick/concrete/drywall, etc.) Channel + bandwidth + TX power + regulatory domain/country (especially for 6 GHz) RSSI and SNR (or noise floor + RSSI) Actual PHY: Tx/Rx rates, MCS, NSS, EHT/HE mode, GI, retries, failed, packet error / loss Real throughput (iperf3 TCP and UDP) at 1 m / 5 m / 10 m / 1 wall / 2 walls Stability over time (30–60 min sustained load), temperature, and whether shielding/heatsink is installed Without these, results are anecdotal and not comparable.
No “marketing screenshots”: we need repeatable results. If there is no distance-based measurement table plus the exact settings/logs/commands needed to reproduce it, then it is not evidence.
Let’s see if our beloved leader @sinovoip shows up and clarifies this for us.
Or do we have to spend our own money to draw our own conclusions?
Let’s see if he deigns to answer, or if @simon comes by and tells us everything the community is asking for.
I await developments, since my ventilation in the BE14000 is more than proven, and I don’t need that board. What I need is proof of the noise and the actual range.
Not to mention the BE19000, here’s the thread, we’ll be mass-producing it a year and three months ago

Have a good day.
First of all, it is a good sign that Banana Pi has reworked their boards!
Yes, I wish they had never released the R4 V1.1 and BE14 V1.1. But they reworked them.
I am also not satisfied with the hardware documentation. It is not a real datasheet, but they are getting better.
We still know almost nothing. That is not enough for me to buy it right now. ![]()
→ If I didn’t, I’m sure he would do it:
→ I’m afraid we will have to wait for people who are willing to spend the money and share their results with us.
→ You too! ![]()
Good morning, @Michael Fischer, my friend. I’ll have a review soon, so I’m just being silly and want to know what they sold us: a simple heat sink plate, or have they actually done their job properly and eliminated the noise?
Have a good day…
My temperatures are low enough that I don’t need a heatsink.
so you ordered one?
looking forward for the results
Oh, what’s the issue with R4 V1.1 (that I might not be aware of)? It seems fine to me.
Good afternoon, my friend @Michael Fischer. I’ve already seen it announced by our beloved leader @sinovoip with his results. Thank God we have the same card on which his measurements are based.
I eagerly await receiving it and sharing the truth about it.
As soon as I have it, I’ll do a review. My son, the IT guy, has the same card and his pc is two walls away from the main router, so we’ll test one in the main room where my computer is and another with two walls in between and see the real results.
I have a Xiaomi BE19000, and my son gets 2 gigabits from where the main router is in the house, with two walls in between, on the 6GHz band, so there won’t be any misleading information. I’ll include both routers and the measurements from both, since we both use the same Wi-Fi card, which is the same one our beloved leader @sinovoip uses. It’s just another toy I have in a long list.
I’ll keep you posted.
By the way, you could update your Wi-Fi card drivers; you probably missed it.
You already wrote in the chat:
additionally:
This was shortly discovered after R4 v1.1 launch. Only the very first batch had the “two resistors”. Subsequent production batches no longer have those two resistors.
Anyone with a soldering iron & basic soldering skill can remove those two resistors from the development board which R4 is.
Fool proof feature like this is welcome. I would consider the reported rate of suspect debug port death due to electrostatic is extremely low.
This variation is rare. Most ppl chose the version of two SFP+ cages.
I didn’t bother wasting time to read the linked long thread to understand what the issue was.
Doesn’t matter R4 v1.1 or v1.3. A soft reset of the host is required to reset the WiFi. What suggested in the thread is good to have for a future product.
None of the above justified the conclusion that “I wish they had never released the R4 V1.1”
R4 v1.1 is fine. Improvements in later revisions are welcome.
So, we do not disagree about the fact that these problems exist.
If I understand it correctly, we only disagree about the interpretation.
By the way, Revision 1.3 also addresses:
SFP mod-def0 - Problem
and
Sim-card holder design:
We even have a problem counting … __
Justification?
I think I have a right to my opinion — not because of any particular reason, but simply because I have that right.
My view is not only about how these problems affect me personally, but about the whole environment.
Including the reputation of Banana Pi! But that is not my main concern. ![]()
I do not want to clutter this topic any further with general stuff.
We still need a clearly laid-out R4 bug thread, which I would have expected on the Banana Pi homepage. ![]()
__
What matters for the new BE14 V2.1 is this:
The “MT7996 WiFi error -11” still exists!
In one of my technical support cases, I installed an R3, and it has been running reliably ever since. Before that, there was a 4G Huawei router that would hang after a few months.
So the question is: can I really recommend the R4 V1.3 with BE14 V2.1?
Full agree with your comments
To be honest im interesting to get BPI R4 mini ![]()
… I know BPI have a lot of issues but bpi team need to think and act faster… Because selling faulty /damaged /un-functional products inside many of countries will but you under Law of country to return and refund the money
to users/customers as what happened with Intel Gen 12 ( Overheating problem) in US and UK users raised appeal for return and the government forced these companies to accept as per law … but in BPI in China so we will follow AliExpress and Alibaba Rules …
Mypoint: BPI company need to test and fix issues before through product in Market- send samples for 30-60 Different Engineer and Developers to dig and find issues - at the you need to save your company name
You (or everyone else) are entitled to your opinion. I didn’t challenge your right of an opinion. Since it’s open discussion, all people should be prepared for challenges to your opinion expressed publicly. I was truly interested in what made R4 v1.1 not justified for launch.
This is SFP+ compatibility issue. Revisiting your linked thread, for R4 v1.1 actually offers control over GPIO. While R4 v1.3 removes this control but always wired to 3.3V. The control can be implemented in drivers of enterprising developers if missing.
Ironically enough, the design decision of mod_def0 is the opposite to that of 12V supply to WiFI module in which missing GPIO is labelled as poor design. lol
Again fool-proof improvement is welcome.
The thread you linked to in your previous reply was of secondary order effect.
The primary focus should be to figure out why the processor onboard the WiFi module hangs sometimes.
After it’s hung, whether the WiFi module can be soft reset alone in driver or has to be done together with the host board is of secondary order effect. From end user perspective, the difference is little not of significance.
Does your recommendation bring in many sales? Truly curious ![]()
It’s obvious from R4 releasee. The board is not well tested. Perhaps BPI didn’t pay enough attention given its increased complexity compared to earlier models such as R3.
Testing and validation of course increase cost of development and end product prices. While BPI markets R4 as “development board,” for people not blind can see they want to sell as many as possible including to less tech savvy users.
I think in future perhaps BPI can consider: 1) going more test & validation; 2) limit sales of initial batch to tech savvy users with lower price to solicit test & validation; and then 3) open sales to wider audience (like clueless end users) with a higher price tag.
I think you should have stopped after your last contribution.
I. It is too personal. II. You are wrong, which makes it even worse.
We should stop here. Your interesting assessment of the “MT7996 WiFi error -11” should in this chat:
Improvements are always welcome
As I mentioned before BPI company should do more tests and sending more sample for developers or engineers
But lets look to fact :
BPI R4 is better than other devices consider their issues where other open source routers are not reaching to this level —fact …
Nice conversation lets be optimistic maybe BPI Team will give us aa free router BPI R5 ![]()