Random wifi speed drops

It is not a big problem, but really annoying. When streaming from my PC with Moonlight I have the “slow connection, pls, change the video bitrate” for about every half an hour (for 2 secs). First I thought it is about my wifi connection, or my PC, but I have tried other devices, then I tried usb LAN with the radxa itself, and it haven’t done that, but I don’t want to use cable, because the Wifi speeds are very good (about 250 mbps) and I don’t really know why this is happening, but I have measured the speeds and it is just lowering for 2 seconds maybe (every half an hour). It is not a temperature related issue either because I have a fan on it, and it is about 32 degree (celsius).

Can you tell us the version of your Radxa Zero, the model of wireless module, and OS you are using?

I think I am using Radxa Zero 1.0 (but I’m not sure). How can I check the model of wireless module?
Also I have checked it with different OS-es, mostly custom Android ones (Aiden’s custom, and a russian one from 4pda), which are based on the original Android 9 (nonatv), but the original android version is also doing this. I think it is not OS related. I can try with other systems if you have an idea, but it is used for Moonlight and on a TV, so it needs to be optimized for that (I don’t want to use pure Debian or Ubuntu, cause it’s hard to use with a remote).

So I’ve checked, and the Zero is not saying any version information on the board (or it is covered by my cooler) only a date I can see: 2021.07.09. From the picture on the site I think that should be version 1.4.
And the wifi module is AP6256, so a Broadcom BCM43435.

What I haven’t considered testing yet is the power supply, which is from the usb port (2.0 i think) of the TV. I will test it with another one if I don’t forget it somehow, but nothing else shows that the power is not enough, even I can set the CPU to fix 1.8 GHz on all cores, and it is okay with running anything, also it doesn’t happen with USB lan with the same settings.

First things first would be to disable power save mode, which has been been discussed in the forum. I also find overclocking the board helps a lot as well and keeping the governor set to performance.

There could also be other reasons why this is happening, such as connecting to a modem where the 2.4/5GHz SSID is the same name. Which can confuse the board and make it connect the widest signal available. 2.4GHz being a wider signal, but in general not as strong as 5GHz and prone to drop outs.

In that case there is a remedy, but I would see if turning off powersave mode helps first.

1 Like

I’m not sure I can do that in android (yes, it is easy in debian), without root, and don’t really know how to root this device, but I have a rom, where rooting is just a switch, but I have to change to that before I can tell you if this is working. Also, I don’t like SSIDs named the same, so I don’t do that bs :D, and the device is about 3m close to the wifi modem which give a very strong signal.

Ah my bad. I missed this was an issue you were having on Android.

It is definitely not the power supply (tried 3 different ones), I will test it with Debian, and higher version of android.

I can’t test it on Debian because hardware encoding is not working at all for h264 or h265 so there is no way to really test Moonlight or Parsec or Steamlink to know if it is a driver problem or what. I’m pretty sure it’s about some kind of driver or parameter bug with the wifi, because all of the game streaming apps are doing the speed drops (but Parsec is also unbarebly bad for android ATV). I’m looking deeper into android wifi settings, but I’m starting to think that this is some kind of bug which is associated with all of the zero’s, but if you don’t use high speed demanding apps like Moonlight, you are not really going to see the problem at all (because it needs 6 to 30 minutes to appear, according to the bitrate you are streaming).
@RadxaYuntian do you have any idea on this? or how to make h264/h265 working on not android systems?

We actually found this issue affecting our ROCK 4 products and I spent past weeks trying to work out a solution. One way to trigger this is simply running iperf3 with -t 86400 and the issue occurs after around 2 hours on ROCK 4 with 5.10 kernel.

Hardware decoding is unlikely to work on upstream 5.10 kernel which is what we are using right now. We will see if we can provide Amlogic 4.9 kernel in the future with this feature enabled.

1 Like

So this is not something I am able to overcome right know. I’m very glad to hear it from a dev, thanks for all of your answers. Keep up the good work, and I’m looking forward to hearing from this “bug”, because it is annoying but not unbearable.