EZ-Wifibroadcast, HD FPV in günstig und einfach

[Schlonz]

Ich frage jetzt mal dumm. Wäre es nicht eventuell sinnvoll, die Mavlink-Pakete soweit zu parsen, dass man die Länge herausliest und dann entsprechend der paketsize das Ganze mit Leerbytes aufrundet? Ein Mavlink-Paket fängt ja immer mit 0xFE an, von daher wäre es ja kein Problem, wenn der TX immer nur ganze Messages in (paketsize)-Häppchen losschickt (Rest auffüllt) und der RX beim Empfang die ab dem ersten 0xFE erkannten Mavlink-Paket für Paket einliesst und die Füllbytes wegwirft.So müsste es einfach, dafür zu sorgen, dass immer komplette Mavlink-Messages in einem Rutsch übertragen werden.
Das müsste sogar ziemlich einfach gehen, den Cmavnode dazu etwas aufzubohren. Ich das ja machen, habe aber die nächsten Wochen leider beruflich ziemlich Landunter :-(
Oder was meint Ihr, bin ich gerade mit dem Gedanken völlig auf dem Holzweg?

Viele Grüße,
Stefan

 

[r0ck3t]

Ich frage jetzt mal dumm. Wäre es nicht eventuell sinnvoll, die Mavlink-Pakete soweit zu parsen, dass man die Länge herausliest und dann entsprechend der paketsize das Ganze mit Leerbytes aufrundet? Ein Mavlink-Paket fängt ja immer mit 0xFE an, von daher wäre es ja kein Problem, wenn der TX immer nur ganze Messages in (paketsize)-Häppchen losschickt (Rest auffüllt) und der RX beim Empfang die ab dem ersten 0xFE erkannten Mavlink-Paket für Paket einliesst und die Füllbytes wegwirft.So müsste es einfach, dafür zu sorgen, dass immer komplette Mavlink-Messages in einem Rutsch übertragen werden.
Das müsste sogar ziemlich einfach gehen, den Cmavnode dazu etwas aufzubohren. Ich das ja machen, habe aber die nächsten Wochen leider beruflich ziemlich Landunter :-(
Oder was meint Ihr, bin ich gerade mit dem Gedanken völlig auf dem Holzweg?

Viele Grüße,
Stefan

Ich hätte ein python snippet das genau das tut, aber keine Ahnung wohin damit...

 

[rodizio1]

@R0ck3t:

Ist nur meine Theorie und würde das Verhalten erklären. Nachdem du am FC direkt die Serielle mitschreibst, kannst Du mir mal den Dump vom Mission Upload zukommen lassen oder weisst wie ich das am Pixhawk hinbekomme?

Ich habe keine "echte" Mavlink FC, nur Cleanflight, da ist leider nichts bi-direktional. Inav soll wohl jetzt (oder bald?) bi-direktionales Mavlink bekommen, muss mal schauen dass ich damit teste.

Packetloss wäre nicht das Problem, es geht meiner Meinung nach eher um "Paketierung" mehrerer Messages und daher Delays und Sequenzproblemen in Workflows. Sendet wbc jedes Paket einzeln oder wird geblockt bis packetsize erreicht ist?

Okay, dachte da wäre noch Packetloss bei Dir. Der wbc TX sendet mindestens soviele bytes wie -m eingestellt ist, maximal -f bytes. Wenn die Mavlink messages vom seriellen Port "am Stück" kommen würden, würden die "am Stück" versendet. Kommen aber immer in 8 bis 24 bytes Stücken (immer vielfache von 8). Weiss noch nicht genau ob das bei seriellen Ports immer so ist, oder woran es genau liegt. Führt jedenfalls dazu, dass in einem wbc Paket nur ein "halbes" oder auch "eineinhalb" Mavlink Messages sind.

Dachte das liesse sich noch ein wenig verbessern mit den "neuen" Parametern die ich weiter oben gepostet habe. War wohl nicht so ...


@Schlonz:

Ich frage jetzt mal dumm. Wäre es nicht eventuell sinnvoll, die Mavlink-Pakete soweit zu parsen, dass man die Länge herausliest und dann entsprechend der paketsize das Ganze mit Leerbytes aufrundet? Ein Mavlink-Paket fängt ja immer mit 0xFE an, von daher wäre es ja kein Problem, wenn der TX immer nur ganze Messages in (paketsize)-Häppchen losschickt (Rest auffüllt) und der RX beim Empfang die ab dem ersten 0xFE erkannten Mavlink-Paket für Paket einliesst und die Füllbytes wegwirft.So müsste es einfach, dafür zu sorgen, dass immer komplette Mavlink-Messages in einem Rutsch übertragen werden.
Das müsste sogar ziemlich einfach gehen, den Cmavnode dazu etwas aufzubohren. Ich das ja machen, habe aber die nächsten Wochen leider beruflich ziemlich Landunter :-(
Oder was meint Ihr, bin ich gerade mit dem Gedanken völlig auf dem Holzweg?

Genau daran bin ich gerade am basteln Nimmt den Mavlink Parser um genau eine Mavlink Message abzuwarten und dann als ein einziges Paket herauszusenden. TX läuft schon, RX kommt noch.

 

[Gravity]

Feature Frequenz: (Vorschlag)
Wäre es möglichen RX seitig einen einblendbaren Frequenzscanner zu implementieren?
Dies könnte hilfreich sein um Störquellen und freie Frequenzen zu finden.
Ein/Aus schaltbar via GPIO Taster.

 

[Schlonz]

@Rodizio
Wegen der (Vielfachen von 8Bytes)-Geschichte: wie genau ließt Du die serielle Schnittstelle aus? Das klingt mir ganz arg danach, dass da ein Buffer gefüllt wird.

Viele Grüße,
Stefan

 

[nique]

Bereite mich auf 1.6 vor.... Will dazu ein Linux PC mit QGroundControl am Boden mit dem RX verwenden. Wie verbinde ich beide? USB oder Ethernet (Kreuzkabel oder Hub)?

 

[Gravity]

Als WiFi Equipment hab ich einen AWUS052NH (heute gekommen) und AWUS0521NH V2
Die Durchdringung bei 5805Mhz in der Wohnung durch 2 Wände finde ich nicht schlechter als unter 2,4Ghz jeweils mit den Wurstantennen.
AWUS0521NH als TX. Dort testete ich mal eine Pagoda Antenne. Das Ergebnis war enttäuschend. Über -67db. Und kein Bild mehr.
Beim AWUS052NH als RX ist mir aufgefallen das scheinbar diversity nicht funktioniert. Ich hab eine 5,8 Patch Antenne an den rechten Anschluss gemacht. Das Ergebnis war gleich +10db mehr. Wurst Links.
Andersrum: Patch links Wurst rechts brachte keine Verbesserung.
Muss ich für den Adapter etwas in der Config ändern? Die Einträge bezüglich Diversity beziehen sich doch alle auf den TX. !?
2,4 GHz Reichweiten Tests hatte ich am Dienstag. Mit Wurstantennen am Boden zu Fuß über 400m.

 

[rodizio1]

Gravity: Spektrumanalyzer mit super Grafik etc. ist möglich, aber nur mit Atheros Karten. Gibt auch schon ein Python Tool dafür namens 'speccy'. Das ist allerdings zu langsam für den Pi. Müsste man nochmal komplett neu schreiben in C und mit Nutzung der GPU zur Grafikausgabe (könnte man z.B. ins OSD mit integrieren). Problem ist nur, dazu reichen meine C-Kentnisse und Zeit nicht. Wenn jemand sowas schreibt, bau' ich das gerne ein.

Ansonsten bin ich auch noch dabei die Atheros Firmware weiter zu versuchen zu verstehen, vielleicht schaffe ich es wenigstens den Noisefloor für den aktuellen Kanal auszulesen, das würde auch schon helfen. Die Atheros Karten haben so ein abgefahrenes patentiertes Noisefloor-Calibration bzw. automatic noise immunity Verfahren, da muss ich erstmal durchsteigen

Wegen des Diversity: Die Karten sind für zwei gleiche Antennen ausgelegt das maximum ratio combining funktioniert dann am besten. Trotzdem sind die Unterschiede seltsam, die Ausgänge sind beide 100% gleich und unabhängig. Sollte also keinen Unterschied machen auf welchem Anschluss welche Antenne hängt. Könnte durch Reflektionen passiert sein. Würde aber trotzdem zwei gleiche Antennen nehmen. Wenn Du mehr 'Abdeckung' willst, mehr Karten.


Was meinst Du mit über -67dbm und kein Bild mehr? Die Ralink Karten sollten unabhängig von der Antenne von -30dbm bis runter auf ca. -86dbm null Packetloss (bei freiem Kanal natürlich) und stabiles Bild haben. Mit schlechten Antennen genauso, nur dass die minimale Empfindlichkeit von -86dbm halt schon bei weniger Entfernung erreicht ist. Stromversorgung hast Du vernünftig gemacht, Karten werden nicht heiss?

Konfig ändern musst Du nicht, nur bei TX diversity.

400m Bodenreichweite auf 2.4Ghz passt ungefähr (051/052NH haben auf 2.4Ghz nur ca soviel Leistung wie die 722N, um die 70mW).


Schlonz: Ja, ist ein Multitasking Betriebsystem, da sind jede Menge Buffer überall Aber die sollten viel grösser sein. Ich hatte noch keine Zeit zum recherchieren, aber ich habe das Gefühl, das sind die 'alten' 8byte FIFO triggerwert der seriellen Schnittstelle (Stichwort 16550A und 14.4kbit Modems damals). Auslesen habe ich bei meinen tests mit cat /dev/serial0 gemacht.


nique: Hub oder Switch braucht's nicht, ob straight oder crossover Kabel ist auch egal. USB geht nur mit einem Telefon/Tablet. Oder WLAN nehmen.

 

[Schlonz]

@Rodizio: Scherzkeks Das mit den Vielfachen von 8 macht mich halt stutzig.
Du pipest die Daten mit cat von der /dev/serial0 in die tx?

Viele Grüße,
Stefan

 

[herbs]

ALFA AWUS052NH wird sehr heiß und schaltet ab

Hallo Leute, hoffe ihr könnt mir helfen,

habe TX raspi3B und AWUS052NH auf 5540 Ghz - und RP Cam V2.1
und Rx Raspi2B und ebenso AWUS052NH auf 5540 Ghz,

funktioniert soweit auch bis der TX 052NH so heiß ist das er abschaltet.
der TX zieht ca. 1,2 A, der RX 0,3 A.
(Werte geändert, waren vorher mit der Stromaufnahme vom Raspi, 2,2 und 0,9 A))

Einstellunen sind original bis auf die Frequenz. V1.5

Wenn ich RX und TX tausche, also cam an raspi2 das gleiche Spiel, dann wird der andere 052NH heiß.

Ist die Sendeleistung möglicherweise zu hoch in der Software eingestellt.

sind diese https://github.com/bortek/EZ-WifiBroadcast/wiki/Wiring letztes Bild

bitte um Hilfe, vielen Dank, Herbert

PS
hier steht 330 mW https://github.com/bortek/EZ-WifiBroadcast/wiki/List-of-Wifi-cards-and-doungles

und hier gekauft steht 1000 mW bei 30 dbm
https://www.wlan-shop24.de/ALFA-Networks-AWUS052NH-24-5-GHz-USB-WLAN-Adapter-300-MBit-Ralink-RT3572

 

[rodizio1]

Schlonz: Ja genau, wie im 'originalen' Wifibroadcast 0.4. Habe den Grund mittlerweile gefunden: Ist tatsächlich der FIFO im seriellen Port. Liesse sich vielleicht mit einem Kernelpatch ändern, aber ich glaube das ist nicht nötig, ein Durchlauf der Schleife (1x 8byte lesen) dauert 5ms bei 19200, glaube das lohnt nicht da Arbeit reinzustecken um noch 1-2ms herauszuholen.


Ansonsten habe ich das OSD noch verbessert: Vorher war immer das Problem einen Kompromiss zwischen Updaterate und Latenz zu finden. Hatte schon (vor 1.5) versucht nur immer genau die Daten zu zeichnen die auch gerade hereinkommen, ging aber irgendwie nicht, flackerte immer. Dann entnervt wieder zurück auf "bei jedem read call zeichnen". Führt natürlich zu unnötig hoher update rate und Last (und auch einer 'nervösen' dbm Anzeige). Jetzt kam mir die Idee, zwar immernoch alles komplett zu zeichnen, aber nur wenn ATTITUDE Telemetrie messages kommen. Dadurch wird das was schnell sein muss (der künstliche Horizont) immer direkt upgedated sobald Daten kommen aber trotzdem nur 10x pro Sekunde (oder wie oft die FC halt die Daten sendet). In Verbindung mit dem neuen Telemetrie tx/rx sollte das dann bei V1.6 eigentlich perfekt laufen. Mal sehen


Herbs: Sendeleistung ist richtig, die war nur bei den ersten Versionen vor einem Jahr zu hoch. Bei mir wird die heisseste Stelle am 052NH (die beiden 5 5Ghz Amps) ca. 65Grad bei 22 Grad Raumtemperatur wenn die Karte mit serien-Antennen ohne Gehäuse auf dem Tisch liegt. Mit etwas Luftzug am Kopter gar kein Problem, auch nicht im Sommer. Im Schaum-Flügel im Wing habe ich einen Lüfter eingebaut (geht vielleicht auch ohne wenn man direkt losfliegt, aber im Stand wird die Karte in dem Flügel ohne Lüfter nach 5-10min zu heiss ...).

Du kannst die Sendeleistung runterstellen wenn Du willst, ist im Wiki auf Github beschrieben wie das geht, aber ich würde vielleicht erst mal die Kühlung prüfen. Oder vielleicht Antennen mit schlechtem SWR? Ja, ca. 330mW hat mal jemand gemessen. Die 1000mW sind halt "Werbe-mW". "Werbe-mw" geteilt durch 3 bis 4 gibt meist grob die wirkliche Sendeleistung.

Danke für die Ampere-Werte wollte das schon so lange mal messen, aber irgendwie nie zu gekommen

 

[herbs]

@rodizio1
Erstmals vielen Dank für das Image, EZ-Wifibroadcast ist spitze !!!

Da bin ich mal beruhigt, wenn der TX wirklich so heiß wird, Kühlkörper habe ich schon bestellt.

Habe nochmals die Ströme vom TX gemessen:

-4 db = 1,25 A
0 dp = 1,6 A

-4 dp sind natürlich keine Lösung, soweit ich richtig informiert bin sind -3 dp nur noch die halbe Sendeleistung. Werde mich, sobald der Kühler da ist, an die 0 dp herantasten.

Vielen Dank für die Infos

 

[Gravity]

Servus.
Auch von mir ein Update der Situation.
Ich habe die Verkabelung auf beiden Seiten so geändert dass die WiFi Adapter am Pi vorbei versorgt werden.
Erst wollte ich meine B+ „abräumen“ hab mich aber dagegen entschieden und eine Zero w gekauft. Das System soll später im Opterra Platz eingebaut werden, aber für erste Tests hab ich mich endschieden das System auf bzw. unter meinen Tragfalter 17“ zu packen. Damit kann man vermutlich bessere Aussagen bezüglich der (noch nicht vorhandenen) Antennen und Reichweite bekommen
Leider hat sich nichts an der Situation geändert. Das Bild ist bei mir immer noch um die -67db schlagartig weg ist. Keine Vorwarnung durch Fraktale im Bild.
TX 051NH
RX 052NH
Ob der 52 in der Luft besser ist werde ich dann sehen.
Hat vielleicht jemand gute Einstellungen für die Weitwinkel pi Cam?
Der Sensor bekommt vermutlich wegen der Optik mehr Licht.
Bezüglich des Zero W ist mir noch aufgefallen das er wohl keine Pixhawk Telemetrie verarbeitet.
Dies ist jetzt aber erst mal sekundär ich will heute noch in die Luft mit dem Ding.
BTW. hat Empfängerseitig schon jemand Experimente mit einer Patch Antenne + Tracker gemacht?

 

[rodizio1]

Gravity: Sehr seltsam. Ich habe mit 051/052NH als RX nicht viel getestet, werde aber nochmal versuchen das nachzuvollziehen.

Wie ist es denn bei anderen Signalstärken? Normalerweise ist (bei freiem Kanal, was bei 5Ghz ja nicht schwer ist im Gegensatz zu 2.4Ghz...) zwischen -30dbm und -84dbm (zumindest beim CSL300 Mbit stick) null Paketverluste sein (die 2. Zahl). Ist das bei Dir so nur bis -67dbm?

Wenn ich mich nicht täusche, nutzen andere Leute den 052NH aber auch als Empfänger, grundsätzlich sollte das eigentlich laufen.


Ansonsten bin ich hiermit weitergekommen:

In Verbindung mit dem neuen Telemetrie tx/rx sollte das dann bei V1.6 eigentlich perfekt laufen. Mal sehen

Telemetrie TX und RX sind jetzt fast fertig und was soll ich sagen, läuft top. Weniger CPU-Last und der Künstliche Horizon im OSD läuft auch viel flüssiger und mit weniger Latenz. Bin guter Dinge, dass damit auch der Uplink vernünftig funktionieren wird

 

[stxShadow]

@gravity: kannst Du mir sagen auf welcher Frequenz du getestet hast? Ich habe nämlich ein ähnliches Problem mit dem 052NH gehabt. Bei mir allerdings als TX in Verbindung mit CSL300 als RX.

Gesendet von meinem SM-G928F mit Tapatalk

 

[stxShadow]

@gravity: Aso .... noch was: speicherst du am RX auf sdkarte oder nutzt Du RAM als zwischenspeicher ?

Gesendet von meinem SM-G928F mit Tapatalk

 

[Gravity]

Ich hatte das Problem auch mit den default Einstellungen in der config.
Also auf auch auf 2,4
Getestet wurden folgende Komponenten in allen möglichen Kombinationen mit den WiFi Adaptern:
-Pi B+ Zero W und Pi3, alle mit SDHC Karte.
- 051/052 NH und ein Alfa AWUS036NEH (der kann aber kein 5GHz)
Bei meinen Tests war es egal wo und wie ich zu der Dämpfung gekommen bin, Wände oder Strecke, bei ziemlich genau -67db war auf einen Schlag das Bild weg.

Aktuell bin ich auf 5805Mhz ich erkenne keine unterschied was die Reichweite angeht im Haus durch 3 Wänden zu 2,4
Ich hab diverse Antennen getestet original und vom analog FPV. (darum auch die 5805)
Ich möchte noch mal erwähnen das ich das Gefühl habe dass der 052 nur auf einer Antenne empfängt.
Besonders warm wird das Equipment und der externe Stepdown auch nicht.

Das speichern auf SD karte oder RAM ich bewusst nicht aktiviert.
Ich hab die ext3 Partition erst mal vergrößert. gibt es ein erweitertes Logging was man aktivieren kann . ich meine hier irgendwo gelesen zu haben das es aus Performancegründen deaktiviert wurde.
Zur Not muss ich für das debugging die Bitrate runterdrehen.

 

[rodizio1]

Irgendwie seltsam, wenn es noch durch 3 Wände geht, scheint mir der Wert nicht 'echt' zu sein, da müsste vom Gefühl her weniger als -67dbm anliegen. Hast Du mal draussen getestet? Maxmyrange.com sagt 250m bei -67dbm.

Vielleicht ist es der LNA davor und Alfa hat dem Chip nicht mitgeteilt, dass da ein LNA mit 20db gain vorhängt (alles nur Spekulation)?


Ob die Antennen-Anschlüsse beide gehen lässt sich leicht testen: Entfernung so wählen, dass mit abgeschraubten Antennen am RX kein Empfang mehr ist. Eine Antenne draufschrauben und Empfang wieder da. Antenne wieder abschrauben und auf den anderen Anschluss setzen, Empfang auch wieder da.

Erweitertes Logging gibt's nicht. Tiefere Bitrate könntest Du testen, aber ich glaube, das Ergebnis wird sein, dass es dann halt bis ca. -70dbm geht (anstatt bis -88 oder so beim csl 300 stick).

 

[careyer]

@rodizio1 : Kannst du uns schon in Aussicht stellen wann vermutlich die v1.6 erscheint? LG Thomas

 

[Gravity]

Zahlen Daten Fakten:

Ich hab den 52er mal unter Linux im Monitor Mode getestet.
Es macht einen Unterschied von 10db welchen Anschluss man nimmt.
Toll is dat nicht.

Interessanterweise ist der unterschied noch größer wenn ich einen „analogen“ Test mit dem dem Pis und dem ezwifi Image mache.
Unterschiedliche Treiber, oder Parameter?