Can't figure out transmission problems (WiFi)

[daniel-kukiela]

Hi there.

I've been trying to setup video transmission in April then left it for a while as I could not figure things out, but now I'm back to this topic.

So what I have is Raspberry Pi 2, 2x Alfa AWUS036NHA (AR9271), 2x Alfa AWUS036ACH.

The problem I have is like bandwidth is very narrow. I can get any video stream only if I set bitrate to like 100 and very low resolution. And even then there is big delay and some packet loss and key frames are not being still sent (received?) quite often.

I tried to read whatever is possible, apply patches, use modded drivers when possible (everything according to docs) and nothing works for me. What does work is changing TX power but that's only by setting up limits by rules (none of commands worked for me iirc).

Anyway what I have tried:

• different channels
• 2G/5G
• different drivers
• both WiFi cards (in pairs and in different combinations) along with some random cards
• powering up WiFi card from external source
• setting up things like iw dev wlan0 set bitrates legacy-2.4 18
• different commands found across internet that supposed to change something
• I saw a suggestion of using EZ-WifiBroadcast's image and setting wifibroadcast up there as it includes various patches and things (no luck here as well)
• different antennas - stock, bigger ones, no antennas
• different antenna connectors
• disabling managing interfaces by OS

And what I constantly see are dropped packets or when I test it today also override block 0xabcd with n fragments.

When I connect my RPi and a Laptop (receiver) to the same wired network and I set gst-launch-1.0 to stream to a wired network, I can send high quality video without any problem, so the problem is somewhere in the WiFi setup or within the thing I did not think of.

Any tips are going to be very appreciated as I have no idea what else I might try. I know that this works for people, so I don't know why it doesn't for me. I'm open to test any ideas.

[svpcom]

1. Try to setup latest WFB. It support IP tunnel now. Test it with ping and ssh.
2. If works, test video link with using artificial video steam:
   Transmitter (1280x720 h264 4mbit/s bitrate):

gst-launch-1.0 videotestsrc ! videoconvert ! video/x-raw,format=NV12,framerate=30/1,width=1280,height=720 ! vaapih264enc bitrate=4000 rate-control=vbr max-bframes=0 ! rtph264pay config-interval=1 ! udpsink host=127.0.0.1 port=5602

Receiver:

gst-launch-1.0 -vv udpsrc do-timestamp=true port=5602 caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264' ! rtph264depay ! avdec_h264 ! xvimagesink sync=false

First try it without WFB, then change udp port (it use 5602 by default) to fit to your wifibroadcast settings.

[daniel-kukiela]

I set up latest WFB following:

• https://github.com/svpcom/wifibroadcast
• https://github.com/svpcom/wifibroadcast/wiki/Setup-HOWTO
  (git clone of the repo)

I did not configure mavlink (at least for now, for now I'm trying to get video stream working)

I set both rx and tx in a suggested way. Before I've been using developement compilation (make) and shell scripts which are obsolete now.

IP tunnel works - I can ping tx from rx, ~20ms and there are no dropped packets (at least I haven't seen any).

Because I'm on RPi (tx side), there are no vaapih264enc (Nvidia hardware encoder), so instead of:

gst-launch-1.0 videotestsrc ! videoconvert ! video/x-raw,format=NV12,framerate=30/1,width=1280,height=720 ! vaapih264enc bitrate=4000 rate-control=vbr max-bframes=0 ! rtph264pay config-interval=1 ! udpsink host=127.0.0.1 port=5602

I used:

gst-launch-1.0 videotestsrc ! videoconvert ! video/x-raw,framerate=30/1,width=1280,height=720 ! omxh264enc target-bitrate=4000000 control-rate=variable ! rtph264pay config-interval=1 ! udpsink host=127.0.0.1 port=5602

First try it without WFB - I'm not sure what you mean here, but I assumed my method of using LAN connection - works perfectly fine. When I try with WFB, results are more or less the same as described above (in the first post) - I can see color pattern sometimes but mostly screen is gray with only "noise" part changing at ~2 FPS (or less). In var/log/syslog I can see messages informing about lost packets for video rx and tunnel rx. ping shows response times more than ~1000ms (1s) and this time packets are being lost.

When I go pretty low with transmission bandwidth, like:

gst-launch-1.0 videotestsrc ! omxh264enc target-bitrate=100000 control-rate=variable ! rtph264pay config-interval=1 ! udpsink host=127.0.0.1 port=5602

so with default small test image and 100kbps of stream, I can see color pattern but it turns gray as well, FPS is better but even under those conditions still well below expected one. There's also delay, so all that suggests some issues with bandwidth.

I also tried to stream A video from RPi camera:

raspivid --nopreview --awb auto -ih -t 0 -w 1640 -h 922 -fps 60 -b 4000000 -g 30 -pf high -o - | gst-launch-1.0 fdsrc ! h264parse !  rtph264pay !  udpsink host=127.0.0.1 port=5602

And sadly it looks exactly the same as before.

Any additional ideas what I might check?

I also think I found a bug (should I fill an issue?) - ON my laptop with Ubuntu 18.04 LTS installed, when I ran make deb it created a deb file with python3- prefix, I checked and after I installed deb file, I was able to import for example telemetry or telemetry.server under python3, but when I start a service it's trying to run it using Python 2. I edited service script to use Python 3 interpreter to fix (workaround) this issue.

[svpcom]

Run wfb-cli on the laptop (rx side). What packet rate and loss it reported?

[Mysnomer0]

I'm having the same issue, running a very similar setup. I set both rx and tx in a suggested way. I've tried streaming video over LAN and I can get good video, but over WFB I'm getting a lot of gray and noise, <2 FPS most of the time, and very delayed. Laptop running Ubuntu 18.04 LTS, Raspberry Pi 3, 2x Alfa AWUS036NHA.

[Mysnomer0]

@svpcom Since you asked, here is a pretty good sample of the packet rate and loss reported:

[Mysnomer0]

@daniel-kukiela Just noticed this guy seems to be having a similar problem, if you haven't seen this already: #47

[svpcom]

@Mysnomer0 First of all try without RPI - i.e. connect both wifi adapters to PC or laptop. And try with debug video stream (using gst-launch videotestsrc ...)

[daniel-kukiela]

@Mysnomer0 I haven't and I did not solve my problem yet. I had to put it on-hold for a while, but I'm going to look at that again soon. Thank you.

[Mysnomer0]

@svpcom Will do, thanks for the advice.

@daniel-kukiela No problem.

I tried turning down the bitrate to 200000, fps to 30, and increasing the bandwidth from 20 to 40 mhz on the video stream, and I managed to get some acceptable video with color and little delay.
About what I was expecting for 2.4ghz. I'll continue to tweak it, I think I can get it better.

[massimilianonball]

I'm just tweaking my 2.4GHz setup too.
Until now i can't acheive more than 3-400000 as bitrate..
But looking at some youtube videos like the one below ..i can see 6Mbit/s with a similar 2.4GHz setup ..how it's possible so much difference??

https://youtu.be/FAmTJRY3dpY

[svpcom]

Try to increase "mcs_index". It is 1 by default which give you ~6mbit/s. It your radio channel is busy (which is true for 2.4 ghz band in urban area) you will get less bandwidth due to collisions.

[massimilianonball]

You're right, i've acheived the best results turning off my (2.4ghz) wifi home network.
I must incrase the "mcs_index" in a particolar section of the master.cfg or in all the 5 times that It Is present?

[svpcom]

No, you can use /etc/wifibroadcast.cfg to override parameters. master.cfg hold default values.
Also you can use different modulation for different streams (video, telemetry and IP tunnel)
for example:

[drone_video]
bandwidth = 20     # bandwidth 20 or 40 MHz
short_gi = False   # use short GI or not
stbc = 1           # stbc streams: 1, 2, 3 or 0 if unused
ldpc = 0
mcs_index = 1      # mcs index

[drone_mavlink]
bandwidth = 20     # bandwidth 20 or 40 MHz
short_gi = False   # use short GI or not
stbc = 1           # stbc streams: 1, 2, 3 or 0 if unused
ldpc = 0
mcs_index = 1      # mcs index

[gs_mavlink]
bandwidth = 20     # bandwidth 20 or 40 MHz
short_gi = False   # use short GI or not
stbc = 1           # stbc streams: 1, 2, 3 or 0 if unused
ldpc = 0
mcs_index = 1      # mcs index

[drone_tunnel]
bandwidth = 20     # bandwidth 20 or 40 MHz
short_gi = False   # use short GI or not
stbc = 1           # stbc streams: 1, 2, 3 or 0 if unused
ldpc = 0
mcs_index = 1      # mcs index

[gs_tunnel]
bandwidth = 20     # bandwidth 20 or 40 MHz
short_gi = False   # use short GI or not
stbc = 1           # stbc streams: 1, 2, 3 or 0 if unused
ldpc = 0
mcs_index = 1      # mcs index

[massimilianonball]

Ok many thanks! I've already read this in the Wiki, but i've never try It. I'll give It a try 👍👍

[Mysnomer0]

Thanks for the info, that would explain a few things. I've been doing my testing right next to my home router also on 2.4ghz. :)

[massimilianonball]

Last night i've spent a copule of hours intesting and tweaking following svpcom suggestions.
I have used a pi 3b+ for the drone and a laptop with ubuntu 18.04 as groundstation with a setup at 2.4GHz; i've make my tests with my home wifi network shut down, with 4-5 meters between the two antennas and without phisical obstacles.

Tx string:
gst-launch-1.0 videotestsrc ! video/x-raw,width=640,height=480 ! v4l2h264enc extra-controls="encode,video_bitrate=600000;" ! h264parse ! rtph264pay config-interval=1 pt=96 ! udpsink host=127.0.0.1 port=5602
Rx string:
gst-launch-1.0 -vv udpsrc do-timestamp=true port=5600 caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264' ! rtph264depay ! avdec_h264 ! xvimagesink sync=false

At the end of those tests, i've reached a maximum video_bitrate=550000 which gives me, looking at the system monitor, 100KB/s.
In the wiki, i can read about 4 Mbit of bandwith with that string; looking at the wifi specs, a 5GHz setup should be more ore less 3 times faster than a 2.4GHz one, this make sens respect to the 1 Mb/s that i have reached with my 2.4GHz setup, it's more ore less 3 times slower than the 5GHz setup of the wiki.
But generally speaking i can't understand how it's possible for wifibroadcast or OpenHD to reach 6Mbit with a 2.4GHz setup and at home with a busy radio channel, the network collision and so on..
An ultimate test could be to write an openhd image on the same hardware to find what is the limit with their software.

One last stange think to mention: during my tests, tweaking the bitrate and the parameters, looking at the system monitor for a precise data about the network speed i have noticed a sort of strong cut, a limit at 124KB/s.
Whatever parameter or bitrate i've tried, i colud see the network speed line on the system monitor change but never above that 124KB/s limit.. is there a sort or software limitation or something else? Someone else have acheived similar results?

[Mysnomer0]

Fascinating, thanks for sharing your work! For practical uses on a drone with this kind of setup, I've been trying to answer the question of 2.4ghz or 5.8ghz, and what you've shared is very helpful. I'd love to hear what svpcoms has to say about the possible bitrate limit you've observed.

[massimilianonball]

@Mysnomer0 many thanks!!
I think that for a pratical use on a drone the 2.4 version should be better due to the range, but i'm afraid about the interferences with the rc radio..
I'd like to try the 5.8GHz version to stream the video only from a diy hand gimbal. But apart those consideration i can't understand at the moment this difference in bandwith with other project like openhd or ez/wifibroadcast. Do you have find that limit at 124KB/s too? Or may be do you have tried that projects on your hardware to test the difference in speed??

[Mysnomer0]

Right, there are a lot of factors. Not too concerned about interferences with RC radio, I'll either run my 900 mhz Crossfire or have the RC control sent via the wifibroadcast datalink. With the right antennas, I can get 5.8ghz to do the range, but it just isn't as robust of a link being higher frequency. Then again, 3x the bandwidth would make for some pretty nice video...

No, I haven't observed that limit, but then again, I wasn't really looking. I've tried the EZ-OSD on the same hardware and got very similar video results, if that helps. I'll let you know if I do see it in my further testing.

[Launchpad-McQ]

Hi. Using a raspberry pi 3b on tx side and have the same problem. Cant use higher bitrate than ~500 000 before picture gets gray. The video stream works with higher bitrate for the first 2 seconds of the stream though it seems. As I understand it @svpcom is using a nanopi to actually run wfb, so I am thinking if maybe it could be the memory bandwidth or something like that could be the bottle neck. If it isnt memory bandwidth or some code bug and @svpcom can run it fine on his setup with a bitrate of 4000 000 without problem I'm kinda clueless.

Would very much appreciate some insight from @svpcom.

[svpcom]

@Launchpad-McQ What wifi card and driver do you use?

[Launchpad-McQ]

Hi. I'm using TL-WN722N on both rx and tx. Ive used these very wifi cards with the befinitiv wifibroadcast a while back. I have new os installations on both rx and tx so I dont know if the driver are the same used back then. I found on the manual setup guide by befinitiv (https://befinitiv.wordpress.com/wifibroadcast-analog-like-transmission-of-live-video-data/wifibroadcast-fpv-manual-setup/) how to patch the firmware. Will give it a try and get back to you.

Thank you for your reply :)

[pasdVn]

Hi, I also have a testing setup with 2 AWUS036NHA (i.e. AR9271) and investigated low bandwith problems. The issue is, that AR9271 (or any driver module of the kernel or the device firmware itself) does obviously not support to set the mcs index via the radiotap header. This is why changing the mcs_index in the configuration (or setting it directly via the -M switch of wfb_tx) does not have any effect. You always stick to mcs index 0 (1MBit). As much as I found out, it is also not possible, to set the bitrate somehow else when the device is in monitoring mode (iw iwconfig, etc).
That is why the original author of wifibroadcast (befi) published a patch of the AR9271 firmware, that changes the default mcs index to 3 (26MBit, see https://befinitiv.wordpress.com/wifibroadcast-analog-like-transmission-of-live-video-data/wifibroadcast-fpv-manual-setup/). The original repository seems to be offline, but here is a mirrow containing the patch and the firmware file. In contrast to the blog post, I had to (additionally) replace /lib/firmware/ath9k_htc/htc_9271-1.4.0.fw with the patched firmware (on ubuntu 18.04 but also on a current raspperry pi OS). With this firmware I can get a stable 6MBit data rate.

One more note for AWUS036NHA: I found out, that the transimission has much less packet losses and fec corrections (in fact nearly none at all) if you remove the antenna from the receiver side device (at least for my indoor low-distance tests). I guess that (maybe) the signal is too strong and causes distortions on the receiver side on very low distance!?

[svpcom]

@pasdVn Settings mcs index via radiotap header is in kernel since early 4.x.x. (i need patches only for old 3.x.x kernels). I've test it with rt2x00 (ralink card) which has driver inside of mainline kernel. What kernel version do you have? But maybe injection in ath9k is broken - I don't use these card in my setup. My primary cards now are rtl8812au and previous were rt2x00.

Yes. It is known issue for rtl8812au - you need to reduce tx power (via driver patch or via wifi_txpower in config file - see telemetry/conf/master.cfg for default value) on the short distance.

[pasdVn]

Yes - I think this is just an issue with ath9k (kernel modules or the device firmware).
Here are some comments and discussions on this issue.
I am using kernel 4.15.0 (on the ubuntu macine) & 5.4.79 (on the rpi).
Setting the tx power is also not supported for AR9271.

[svpcom]

Try ath9k patches from here: https://github.com/rodizio1/EZ-WifiBroadcast/tree/develop/kernel
and firmware from: https://github.com/OpenHD/Open.HD/tree/master/firmware/AR9271

[pasdVn]

Already had a look at those patches. I think, that they do not address this issue. From what I see the firmware patch is just as mentioned above, and the kernel patches are the modifications for allowing 2,3GHz, and 30dbm, as well as some kernel parameters to ard override some settings in at9k (e.g. setting the txpower, which indedd would be interesting).
However this is just out of reading the patches (I might be wrong) - I did not try them...

Btw.: Is there some way to hack wfb_rx code a bit, to dump out the mcs indexed of a received packet?

[svpcom]

The easiest way is to run wireshark or tcpdump in parallel to wfb_rx. It shows mcs index for captured packets

[pasdVn]

Ah great, thank you!