RC exclusively working with Atheros AR9271

[careyer]

This issue is about the fact that RC control does only work with Atheros AR9271 at GroundPi (TX card). _In other words: RC control DOES NOT work on any RaLink cards as of now_

Originally posted by @Yes21 in https://github.com/bortek/EZ-WifiBroadcast/issues/165#issuecomment-431956693

>If it works only with old atheros chipset, the scope of this project is becoming 
>very reduced !

>I could see the uplink telemetry work only one time : with the last
> "russian image", and my rtl8812/14au >boards ...

This has long time been a rumour and nobody could answer why. I digged very deep in the beginnings of EZ-WBC in the german forum fpv-community.de. I was finally able to find the answer by Rodizio himself. (You may need to use Google Translate or Deepl to translate his answer from german to your native lanuage):

https://fpv-community.de/threads/ez-wifibroadcast-hd-fpv-in-g%C3%BCnstig-und-einfach.74933/page-68#post-1012933

Rodizio: Uh, I just noticed, you use Ralink cards on 5GHz? R/C only works with Atheros cards. Therotically it could maybe work via the missionplanner via the telemetry uplink, but don't think that works well. careyer: What exactly is the reason that it only works with Atheros cards? #Curious

https://fpv-community.de/threads/ez-wifibroadcast-hd-fpv-in-g%C3%BCnstig-und-einfach.74933/page-69#post-1013007

Rodizio: Careyer: 3 reasons ;) With Ralink there is no CTS protection, the medium access parameters are not suitable and no 'short' packets can be sent. Everything can be solved, but complex. I never put time into it because Ralink is used on 5GHz and the 2.4GHz band is free anyway.

[careyer]

@Yes21 : Please find above the answer about the topic that we were talking about just yesterday.... @All : I strongly believe this limitation needs to be overcome in one of the next releases to render EZ-WifiBroadcast a true AIO solution - otherwise it will only be half-baked for any 5GHz user.

[Yes21]

@careyer : Thanks. Do you think that uplink telemetry is linked with RC capabilities ? In both cases the groundPi should send orders to the airPi ...

Ps : I'm pretty sure I've seen uplink telemetry working with my AWUS1900 connected to the groundPi with the latest "russian image". But I can't reproduce it because I've changed the wiring to my PixHawk, and the new cable has perhaps a problem ...

[careyer]

@Yes21 : I cannot really tell. RC-control is definitely part of the telemetry uplink - that is for sure. So one needs to dig into the code and see if the RC signals (the raw data that is sent via the radio link) are transmitted exactly the same way as the uplink telemetry payload. If this is the case we just found the issue you are experiencing with uplink telemetry. Then it suffers form the same limitations.

Man this is really difficult since substantial design decisions were not documented properly but only got mentioned once or twice in a subclause hidden in literally thousands and thousands of forum posts. Took me about 3h to find this piece of information. Grrrr...

[zipray]

@Yes21 We met in "Russian image". Attempts to pass the 5.8g uplink telemetry and RC were possible only in the case of a single receiving WiFi adapter. I have three WiFi adapters similar to AWUS1900, and when one of them is on air PI and two are on ground PI, telemetry and rc will disconnect shortly after startup.But with both air PI and ground PI using one WiFi adapter, everything is fine.

[pilotnbr1]

@zipray thanks for the info! Very helpful while we backwards document this project

[pilotnbr1]

Another part of the rc mystery is the code in the arduino folder msp2ppm. Also a post on rcgroups referencing msp to ppm

https://www.rcgroups.com/forums/showthread.php?2664393-EZ-WifiBroadcast-cheap-digital-HD-transmission-made-easy%21/page120

I am guessing the groundpi sends rc as msp and the airpi converts to ppm outputs. But anemostec references pin 10 which is an RX pin so dont know... Just thought I would throw some more gas on this RC dumpster fire lol

[Yes21]

@zipray

@Yes21 We met in "Russian image". Attempts to pass the 5.8g uplink telemetry and RC were possible only in the case of a single receiving WiFi adapter. I have three WiFi adapters similar to AWUS1900, and when one of them is on air PI and two are on ground PI, telemetry and rc will disconnect shortly after startup.But with both air PI and ground PI using one WiFi adapter, everything is fine.

Thanks. I can confirm that uplink telemetry did work (with last russian image) for me with only one wifi adapter on each side.

So that confirms that the 8812/14au adapters are RC and up telemetry compatible ...

[careyer]

That's all good news. At least there is hope that we can extend the RC capability beyond a specific chipset. It is really crucial to gather all the information and understand what exactly is happening and which parts of the code are still active and which ones are legacy code. I know that Rodizio was struggling with an own RC implementation which had bad latency and stability issues in the first place when dino.de stepped in and donated some code. Since the new code worked without problems I think this was adapted. And yes it is very likely that we find some abandoned code fragmenets from Rodizios first tries. Thanks for all trying to shed some light on this against all odds of the totally neglected documentation.

[Yes21]

I can now affirm that up telemetry is working well with rtl8812/14au, with the latest building script image. So the AWUS036ACH and AWUS1900 should be RC able, but didn't tried it yet ...

[zipray]

      I can now affirm that up telemetry is working well with rtl8812/14au, with the latest building script image.

So the AWUS036ACH and AWUS1900 should be RC able, but didn't tried it yet ...

Yes, I have tested RC and it works.However.after enabling RC, downlink bandwidth decreases, video compression ratio increases, and image quality decreases a lot.Is this normal?

[careyer]

@zipray : no you should not notice any impact on the downlink performance. Did you use multiple Wifi Adapters at the GroundPi or just one?

Why am I asking? User FlingW on RCgroups had a strange problem with servos moving rather sticky/erratic and not smooth on his ArduPLANE. Nobody else reported this behavior before. In the progress of debugging we found out that he was using only a single Wifi Adapter at his GroundPi and not multiple sticks which is common good practice. Obviously the only Wifi Adapter at the groundpi was rather busy with receiving downstream packets and could not send the uplink packets (which includes RC) with the required datarate. Once he added a 2nd Wifi adapter everything runs buttery smooth. I think we should investigate in this behavior . Maybe this has something to do with your observation?

[rodizio1]

So that confirms that the 8812/14au adapters >are RC and up telemetry compatible ...

No.

R/C has been designed to work with Atheros only so far, if it works with other chipsets, that's just coincidence and will surely not work properly.

Obviously the only Wifi Adapter at the groundpi was >rather busy with receiving downstream packets and >could not send the uplink packets (which includes >RC) with the required datarate.

You conclusion/explanation is wrong. Using a 2nd adapter shouldn't make a difference. After all, both adapters receive the same packets from the TX and thus, both are similarly busy. There must be a different explanation.

[careyer]

You are right Nico.... It was just an educated guess. However adding a 2nd adapter immediately remediated the issue.. There is a algorithm involved which decides which stick sends the uplink data depending on the RSSI value, is it? Maybe to look there?

Von meinem iPhone gesendet

Am 05.11.2018 um 18:22 schrieb Rodizio notifications@github.com:

R/C has been designed to work with Atheros only, if it works with other chipsets, that's just coincidence.

Obviously the only Wifi Adapter at the groundpi was >rather busy with receiving downstream packets and >could not send the uplink packets (which includes >RC) with the required datarate.

You conclusion/explanation is wrong. Using a 2nd adapter shouldn't make a difference. After all, both adapters receive the same packets from the TX and thus, both are similarly busy. There must be a different explanation.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Yes21]

@rodizio1 So can you explain us what is the relation between RC capability and telemetry uplink capability ?

[rodizio1]

This has long time been a rumour and nobody could answer why

Rumor? It clearly says "Atheros only" in the feature list: https://github.com/bortek/EZ-WifiBroadcast/wiki/General-~-Features

So can you explain us what is the relation between RC capability and telemetry uplink capability

There is no relation, telemetry uplink and R/C are handled by different programs/code in the image. To make R/C work with other adapters, somebody needs to actually dig into the drivers/kernel/radiotap headers of Ralink and Realtek adapters.

[zipray]

@rodizio1 Therefore, I understood that if RC=mavlink is enabled, whether uplink=mavlink or disable, RC andTelemetry should not be performed on the same serial port.Isn't it?

[careyer]

Rumor? It clearly says "Atheros only" in the feature list: https://github.com/bortek/EZ-WifiBroadcast/wiki/General-~-Features

Yes this is true. However people by accident found out that RC also works (or kinda works) with non-Atheros cards. A user on RCgroups even reported that a mixture of Atheros (I believe Air) and RaLink (Ground) adapters will do. This is what I was referring to as "rumor" ;-) So, indeed, at the end of the day it reads "(Atheros only)" but people see that it works with their other setups as well and that is what adds confusion. That is exactly the same thing that we are now observing with rtl8812/14au support as well.

I think we need to have more insight and a clear understanding of what prerequisites make RC work or not work because real life test results show that "Atheros only" does not cut it anymore.

From the posts I found on FPV community I read:

1. support for CTS protection needed
2. medium access parameters must be suitable
3. support for sending small packets must be available

Does (1) mean, that when using RC=mavlink this will force CTS to be enabled? I think we all are missing bits and pieces of information. It would be great to shed some light on this.

We are just trying to get a better understanding here :)

[Yes21]

I think we need to have more insight and a clear understanding of what prerequisites make RC work or not work

And same question for up telemetry : since it is separated from RC, it is supposed to work with all wifi adapters, or ?

[rodizio1]

@zipray R/C and telemetry can be sent over the same serialport, there is nothing wrong with that. See here for possible options: https://www.rcgroups.com/forums/showpost.php?p=39575125&postcount=4174

@careyer

Yes this is true. However people by accident found out that RC also works (or kinda works) with non-Atheros cards. A users on RCgroups even reported that a mixture of Atheros (I believe Air) and RaLink (Ground) adapters will do. This is what I was referring to as "rumor" ;-) So, indeed, at the end of the day it reads "(Atheros only)" but people see that it works with their other setups as well and that is what confuses them. That is exactly the same thing that we are now observing with rtl8812/14au as well.

I know for sure that it doesn't work with Ralink at the ground Pi.

Atheros at the ground and Ralink in the air might work (I have never tested that though), but due to the Ralink adapter in the air not sending CTS protection frames, packetloss will be higher.

Mixed Ralink/Atheros on the ground will lead to packets only being sent by the Atheros adapters (and currently, I'm not sure what happens if the Ralink adapter sees a higher signal strength, it could be then that the Atheros never gets used).

About RTL8812/14 I cannot really comment, as that chipset never was officially supported with EZ-Wifibroadcast.

Does (1) mean, that when using RC=mavlink this will force CTS to be enabled? I think we all are missing bits and pieces of information. It would be great to shed some light on this.

No, it isn't forced automatically, it has to be set manually, see here, in my original documentation: https://github.com/bortek/EZ-WifiBroadcast/wiki/How-to's#setting-up-rc-over-wifibroadcast-with-a-joystick

And same question for up telemetry : since it is separated from RC, it is supposed to work with all wifi adapters, or ?

Yes, it should work with all wifi adapters. But it has only been tested with Atheros and Ralink by me, not sure what happens with Realtek.

[zipray]

FC: f4 FW:inav V2.0(msp v2.0) Air pi:zero wifi:ASUS usb-ac56(rtl8812au)1 Ground pi:3b ASUS usb-ac56(rtl8812au)1 Radio:frsky Qx7 1.6RC6（ "Russian image".On October 16,） FREQ=5825 DATARATE=3 TELEMETRY_TRANSMISSION=wbc TELEMETRY_UPLINK=disable RC=sumd CTS_PROTECTION=N WIFI_HOTSPOT=N

/ TELEMETRY PROTOCOL /

define LTM

@careyer I adopted the Russian image because it is the closest version to the original 16rc6.Only minor modifications were made to support the rtl8812au chip.as I mentioned above about the transition of the signal mass.

[careyer]

Alright! I did some extensive testing this evening and these are the results:

dino.de Image (basically 1.6RC6 + MAVLink v2) : FREQ=2472; DATARATE=4; TELEMETRY_TRANSMISSION=wbc; TELEMETRY_UPLINK=mavlink; RC=mavlink; CTS_PROTECTION=auto; WIFI_HOTSPOT=Y (This is what I connect through)

Setup1:

• AirPi = 1x ALFA AWUS036NHA (Atheros AR9271)
• GndPi = 1x TPLink TL-WN722N V1.10 (Atheros AR9271)
• Video = OK
• Telemetry = OK
• RC = OK
• Mission Planner: OK (All connects buttery smooth)

Setup2:

• AirPi = 1x ALFA AWUS036NHA (Atheros AR9271)
• GndPi = 1x CSL 300Mbit (Ralink RT5572)
• Video = OK
• Telemetry = OK
• RC = OK <-- Should not work at all -- works perfectly
• Mission Planner: FAIL (HUD information updates, "Getting params" does not even start at all)

Setup3:

• AirPi = 1x CSL 300Mbit (Ralink RT5572)
• GndPi = 1x CSL 300Mbit (Ralink RT5572)
• Video = OK
• Telemetry = OK
• RC = FAIL
• Mission Planner: FAIL (HUD information updates, "Getting params" starts but gets stuck)

Setup4:

• AirPi = 1x CSL 300Mbit (Ralink RT5572)
• GndPi = 1x TPLink TL-WN722N V1.10 (Atheros AR9271)
• Video = OK
• Telemetry = OK
• RC = OK
• Mission Planner: OK (All connects buttery smooth)

All tests repeated several times. Results were consistent.

[rodizio1]

I have no explanation right now, why Ralink on the ground pi works for you. But as far as I remember, injecting RTS frames did not work with Ralink and thus R/C shouldn't work. But maybe my memory is wrong. However, it won't work 'perfectly', because packetloss is higher due to the more agressive medium access of the Ralink cards.

I still wouldn't recommend using Ralink cards for R/C (until somebody managed to change medium access parameters and make CTS protection work for Ralink).

[careyer]

Thank you very much for pointing this out. This makes total sense and is defintely a thing that we should have an eye on in one of the upcomming releases as Atheros cards are increasingly now hard to come by.

[zipray]

@careyer Is your mavlink test done in mavlink-routerd mode or cmavnode mode?When I use both RC and teletemtry at the same time, they are quite different.

[careyer]

@zipray : Honestly I have no idea if it uses mavlink-routerd oder cmavnode mode. What I can tell is that I always have RC and telemetry enabled by default so my tests always reflect the result of RC+TELEM. Valuable information that the MavLink communication with RC+TELEM and TELEM(only) look significanntly different! Thanks for sharing

[Yes21]

I can now confirm that RC is not working with RTL8812/14AU boards (with latest 2.0beta).

[zipray]

@Yes21 Can the use of dual wifi CARDS on the ground prevent RC bursts caused by a single network card flashover?

[Yes21]

@zipray Sorry, I don't understand your question.

[Yes21]

@rodizio1 I have many questions about wifi adapters RC compatibility :

• should only the wifi groundPi adapter be "compatible" ?
• are the only prerequisites CTS protection and RTS frames injection ? ( what means CTS and RTS ?)
• how to know if a wifi card is CTS/RTS compatible ?
• could you explain exactly what is needed to be done for making work RC with a particular wifi board ?

I'm asking all these questions, thinking of RTL8812/14 boards ... I'm pretty sure they are RC able, and I hope you will point us into the right way to make them work for RC.

Many thanks to you.

[Yes21]

This issue has been closed "accidentally" by @careyer last black friday ! @bortek Could you please reopen it ?

[Howie9600]

Has this been sorted yet? I really need RC working and having massive issues

[pilotnbr1]

No.. no development taking place here. Try OpenHD