BananaPi R3 very unreliable over Wi-Fi despite strong signal

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi folks! I just got a Banana Pi that I set up with yesterday's OpenWRT snapshot, and so far fairly little custom configuration. I'm having serious issues getting a usable Wi-Fi connection. I have ping running in the background while I'm writing this, and I have packet loss going as high as 60% ("request timeout for icmp_seq <...>"). While I'm very comfortable using computers and programming, I'm a networking idiot in general. I was hoping you could help me figure out what my problem is. I'm currently running the r23372-51f57e7c2d snapshot.

I only enabled the 5GHz network, and I connected two antennas (out of 4 antenna sockets). I'm getting decent signal (-60dBm to -64dBm), which is comparable to what I had with my previous router, so I'm assuming that this isn't a problem. I put little heat sinks on the CPU, the network controller and each of the radios. Here's a picture of my setup, sitting naked on a shelf right now:

The Banana Pi R3 board
The Banana Pi R3 board1920Ă—1467 323 KB

I also installed the thermal module for collectd. It reports a single zone. The temperature stays within 1°C of 49.5, and the temporary increases do not appear to correlate with the periods during which Wi-Fi stops working. New users are limited to one embed per post, so you don't get to see that one in this post unfortunately. To the touch, the hottest heat sink is the one on top of the Ethernet controller, with the CPU a fairly distant second. The radio chip heat sink feels just a little warm. The chips without a heat sink are indistinguishable from room temperature to me.

Nothing special goes to logread when the Wi-Fi goes out. Here's a period of 15 minutes during which I lost Wi-Fi for about 40 seconds:

Fri Jun 16 20:24:45 2023 daemon.err uhttpd[3137]: [info] luci: accepted login on /admin/statistics/graphs for root from 127.0.0.1
Fri Jun 16 20:25:54 2023 daemon.warn odhcpd[1794]: A default route is present but there is no public prefix on lan thus we don't announce a default route by overriding ra_lifetime!
Fri Jun 16 20:31:30 2023 daemon.warn odhcpd[1794]: A default route is present but there is no public prefix on lan thus we don't announce a default route by overriding ra_lifetime!
Fri Jun 16 20:34:48 2023 authpriv.info dropbear[3282]: Exit (root) from <192.168.1.225:50714>: Disconnect received
Fri Jun 16 20:34:49 2023 authpriv.info dropbear[3577]: Child connection from 192.168.1.225:50874
Fri Jun 16 20:34:49 2023 authpriv.notice dropbear[3577]: Pubkey auth succeeded for 'root' with ssh-rsa key SHA256:<my public key> from 192.168.1.225:50874
Fri Jun 16 20:38:45 2023 daemon.warn odhcpd[1794]: A default route is present but there is no public prefix on lan thus we don't announce a default route by overriding ra_lifetime!

(LuCI reports connections from 127.0.0.1 because I configured uhttpd to listen only to localhost, and I use an ssh tunnel.)

Ping looks good and then suddenly it doesn't.

64 bytes from 192.168.1.1: icmp_seq=105 ttl=64 time=5.980 ms
64 bytes from 192.168.1.1: icmp_seq=106 ttl=64 time=4.495 ms
64 bytes from 192.168.1.1: icmp_seq=107 ttl=64 time=6.100 ms
64 bytes from 192.168.1.1: icmp_seq=108 ttl=64 time=6.025 ms
64 bytes from 192.168.1.1: icmp_seq=109 ttl=64 time=10.185 ms
Request timeout for icmp_seq 110
Request timeout for icmp_seq 111
Request timeout for icmp_seq <112...116>
Request timeout for icmp_seq 117
Request timeout for icmp_seq 118
64 bytes from 192.168.1.1: icmp_seq=119 ttl=64 time=6.926 ms
Request timeout for icmp_seq 120
Request timeout for icmp_seq <121...146>
Request timeout for icmp_seq 147
64 bytes from 192.168.1.1: icmp_seq=148 ttl=64 time=2.810 ms
64 bytes from 192.168.1.1: icmp_seq=149 ttl=64 time=5.307 ms
64 bytes from 192.168.1.1: icmp_seq=150 ttl=64 time=3.469 ms
64 bytes from 192.168.1.1: icmp_seq=151 ttl=64 time=6.109 ms
64 bytes from 192.168.1.1: icmp_seq=152 ttl=64 time=4.602 ms

When Wi-Fi goes out, the radio LED keeps blinking.

Even when it works, I'm getting pretty poor speeds. A speedtest running from the router itself, or from a device connected to it over Ethernet, gives me a cool symmetric 1Gbps. I barely break 100/30 over Wi-Fi from any of my devices, despite them being Wi-Fi6-capable.

I'm fairly positive that this isn't enough to diagnose the issue, but I was hoping that kind souls could help me go from there and help me find what I should look for.

Thanks!

2

That is not a good idea, you're actively breaking (Mu-)MIMO and beamforming, which are major parts of 802.11n and up (particularly -ac and -ax), beyond the unnecessary packet loss, you can also physically damage the phy and rf amplifiers that way (SWR). Never operate a wireless card without attaching all antennas (or terminating them properly).

That shouldn't have been step 1 either, before getting stuff to 'work', as the glue might not be thermally conductive or even create electrical shorts.

[I have no hands-on experience with filogic 830 yet, so I can't talk about the details]

1 Like
3

Maybe you connected the two antennas for 2.4 GHz... :dizzy_face:

4

it's like saying "i installed 2 wheels on my super car, and i don't understand why i can't achieve 250km/h" :sweat_smile: :sweat_smile:

attach all antenna and see if it's better, also check if antennas are not frequency-specific, maybe there is a little specification on it.

5

And are we going to have beamforming, the antennas cant be “just spread out on the table”. They will need to be placed around so the hardware knows where they are located physically.

1 Like
6

Thanks, I will attach two more antennas and see if that solves my problem.

7

How do I know what shape to arrange them in? There’s OEM cases that put all 4 together like 1in from each other.

8

That is one answer, the space between isn’t the real issue. Beamforming always sends on all antennas but with different power to every client so all the transmitting cones can be rotated 360° around the antenna park and pointed so the specific wifi signals follow the clients.

This can be seen if you quickly move a wifi client lateraly to another room, then the wifi signal gets weaker a couple of seconds until the AP has moved the transmit cone to your new position and you get 100% wifi again. But if you move radially to the AP the wifi strength will remain.

The other answer is that OEM is designed with help from the wifi chip manufacturer that has tested the design in screened rooms and made the datasheet for the specific transmitter where it defines the placement of the antennas to work with beamforming and the drivers.

9

Re: Beamforming and antenna placement/geometry

Is there a primer somewhere for this? I detect a severe gap in my knowledge.

I'm just wondering if some of the WiFi issues I have may be down to me wall-mounting my Archer C7 v[2|5] and setting the antennae vertical (Ethernet cables are hanging vertically down from the ports). I assumed it was designed for this (what with the holes for wall mounting in the base-plate). It's ac, not ax.