AWUS036ACH/AWUS1900 : only one antenna is sending data in monitor mode

[Yes21]

Making output power measurements with AWUS036ACH and AWUS1900 we did observe that only one antenna ( /2 or /4) is sending data in monitor mode. These testings has been made with Open.HD (EZ-Wifibroadcast), 5.2.20 driver, on Pis with a modified Raspbian 4.14.71. This has been confirmed by 3 users for AWUS036ACH and 1 for AWUS1900.

[ggerla]

yes, i can confirm the same behaviour. I have both devices. I tested only AWUS1900 and only one antenna sending data. I did the test using a wifi analyzer on my phone and remove one by one all antennas. Only when I remove antenna 2 I registered a cut off of the signal.

[aircrack-ng]

That is an entirely different driver and currently v5.3.4 branch of this driver is recommended.

How did they measure? Did they put dummy load on some of the antennas and noticed no change in rates/signal? In short, how to reproduce that behavior?

[ggerla]

I'm using the v5.3.4 branch. I forced tx power to 30dbm. I created an AP using hostapd at 5GHz with 80MHz of bandwith. I take my android phone with an app called WiFiAnalyzer and I used the real time graph feature. With the phone near the device I can measure -30dbm. If I remove 3 antennas I continue to measure the same signal, but if I remove the antenna on the back side on the left the signal goes to -70dbm.

[htcohio]

Hello,

I compiled a video to demonstrate some of the problems we're having with the Realtek RTL88XXAU Cards for Open. HD...

this has been going on for some time now. basically, 5.8ghz has always performed pretty well which is good for most users because the users who want these cards generally want 5.8.

But, 2.4 definitely has its advantages.

We are really trying to revolutionize the fpv Drone digital video and data link system which is dependent on the support of readily available wireless cards like this.

I understand that this is not a normal use case but there are a lot of advantages outside of fpv drone systems.

If you watch the video, you'll also notice screenshots showing measured transmit power on a single antenna (we have never measured any output from both antennas simultaneously).

Also, on 2.4ghz there is pretty high transmit power measured of about 800mw but unfortunately it's not usable because of the significant packet loss.

The poor performance of 2.4 is also occurring with very low transmit power settings.

These problems appear to be happening on v5.2.2 and v5.3.4.

Now, As for the transmission only being I'll put on a single antenna can be attributed to the lower MCS 0-9 data rates??? I think...

I'm not sure if using higher MCS rates would be much of an advantage considering a long-range digital data link because, the higher data rates themselves will reduce the range.

If that is the primary reason, could it be possible to modify the driver to allow MIMO transmission at full power using b/g rates (11, 12, 18 & 24Mbps)?

**I'm sorry I know this is kind of a lot in one message but I'm trying to get as much information to you as possible.

Many of us with Open.HD would greatly appreciate any feedback or bug fixes you could suggest/provide for this...

I would be available for any kind of remote session or additional information you would need on troubleshooting this...

Here is the YouTube video...

https://youtu.be/eYw-qllCmB8

[ggerla]

Cool. Great video and info... On my side I'm analyzing the hostapd configuration. AWUS1900 has MU-MIMO (as I understand) and this functionality should be configured in hostapd. I added this parameters to the 5GHz configuration [TX-STBC-2BY1][RX-STBC-1234][BF-ANTENNA-4][SOUNDING-DIMENSION-4] but nothing seems to change... I should aso add this [MU-BEAMFORMER] but it seems that driver doesn't support it.

I will inform you if I do some progress

[Yes21]

We did try to investigate this issue outside the driver. Perhaps one could find interesting informations here

[ggerla]

So... After a lot of check with hostapd configuration, I'm quite sure that the problem is inside the driver... It is not possibile to set MU_BEAMFORMEE, MU_BEAMFORMER and bitrate... Analizing driver core code, it seems that MU functionalities are supported, so I think that some define are missing... For example the define RTW_BEAMFORMING_VERSION_2 is present only for CONFIG_RTL8821C and CONFIG_RTL8822B, not for 8814 and 8812.

So the question is: why?

[kimocoder]

That question should Realtek answer, but again... 8814 HAL is OLD and buggy, 8812 and 8821 is newer. Don't have time to look into it right away, but if you find more interesting reading, post it here. Thanks!

[ggerla]

8814 HAL is OLD and buggy, 8812 and 8821 is newer. Yes I can agree... but 8812 has the same problem. Only one antenna works...

[ggerla]

Hi all I think that I found the problem. I did a lot of debug with the driver (v.5.3.4). In the end I focused on method

PHY_SetTxPowerIndex_8814A

in the file

hal/rtl8814a/rtl8814a_phycfg.c

This method is called for each antenna and set the tx power. The problem is that even if it is called for each antenna in the end only one works. I think that is because the RFPath is written in the registry in the wrong way.

Try to replace row 1258 with

txagc_table_wd |= (1 << (RFPath + 8)) | MRateToHwRate(Rate) | (PowerIndex << 24);

and now it seems work better. If I remove antenna 2 the signal decrease but lesser than before.

@htcohio can you do some test in this way?

[kimocoder]

Heads up, 8812au should move over to v5.6.4 which is stable and better

[htcohio]

Hi,

Ok, I will definitely try to test that out.

basically one thing I did learn was that our Open.hd system operates on the V5.2.2 Driver.

upgrading to the newer versions is not as simple as just changing the version number because there are other script, dependencies and patches for our system in addition to a customized raspbian OS.

the 5.2.2 was originally set some time I'd say back in October or November of last year because it worked the best at the time.

We have been following this driver development very closely and it seems as if we really need to upgrade to the latest driver.

Would you or anyone else familiar with this be willing to help us out on our telegram group?

we have a group of about 20 developers testers and interested parties in the wireless long-range HD video system.

additionally we've had successful flights on 5.8ghz from 7Km with Omni antennas and 40+Km with High gain antennas.

If you happen to know a little bit about wireless HD video you'll know that getting those types of ranges out of 5.8 HD really is a spectacular milestone!

unfortunately, we lack the expertise when it comes to the RF and driver side of things. if we could bring one of you guys on board there are so many other applications outside of drones where this commodity base system could be utilized.

Here is a link to our public telegram channel for the project. we also have a private group message that I can share with you if you'd be willing to join see where things are ;)

So, here is a link to our public telegram Channel

OpenHD Beta Test 2019_RCGroups Telegram Group. https://t.me/OpenHD_May_2019

And here are a couple links to the flights listed above. 6 KM Flight https://youtu.be/4t8SJ9tc_LI

42 KM Flight, RTL8812AU with ASUS AC56/ 12mbps/ 20db antenna https://youtu.be/-eKEXIrHjAw

On Sun, May 26, 2019, 4:45 PM Giuseppe Gerla notifications@github.com wrote:

Hi all I think that I found the problem. I did a lot of debug with the driver (v.5.3.4). In the end I focused on method

PHY_SetTxPowerIndex_8814A

in the file

hal/rtl8814a/rtl8814a_phycfg.c

This method is called for each antenna and set the tx power. The problem is that even if it is called for each antenna in the end only one works. I think that is because the RFPath is written in the registry in the wrong way.

Try to replace row 1258 with

txagc_table_wd |= (1 << (RFPath + 8)) | MRateToHwRate(Rate) | (PowerIndex << 24);

and now it seems work better. If I remove antenna 2 the signal decrease but lesser than before.

@htcohio https://github.com/htcohio can you do some test in this way?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aircrack-ng/rtl8812au/issues/280?email_source=notifications&email_token=AHCKTUSFNHHJJDCZ3RSCKW3PXLZHDA5CNFSM4GXPRIA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWINDZQ#issuecomment-496030182, or mute the thread https://github.com/notifications/unsubscribe-auth/AHCKTURPGY7ZRMHJ5JBLK6DPXLZHDANCNFSM4GXPRIAQ .

[ggerla]

Hi all after a lot of other tests I'm starting to lost hope about use 4 antenna. At this link

http://www.kalitut.com/2019/04/usb-wi-fi-adapters-supporting-monitor.html

you can read

The difference between RTL8812AU and RTL8814AU chipsets in the ability to support a different number of antennas. On the RTL8812AU, up to 2 antennas are supported, and Realtek RTL8814AU supports up to 4 antennas. In some cases, depending on the circuit design of the device manufacturer or firmware, one antenna can be used only for transmission, and the other only for reception. Also, some devices work only in one range of choice, others - in two ranges simultaneously. This also needs to be considered when purchasing devices.

So, I think that AWUS1900 can only transmit with one antenna :-(

[cedricbambooza]

pls consider closing the issue, when it's solved by now :)